You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Off-topic » [SOLVED] New Github repo: Protect Children From Violence » 2022-06-06 04:55:29
There's already a lot of online discussions about specifics of the issue, and I've already participated in some. The repo's purpose isn't about discussing solutions online. There's nothing controversial there to censor. I simple chose to use GitHub for now because it's a platform I use frequently, and I've seen other GitHub repos that have non-code-related content as well.
#2 Off-topic » [SOLVED] New Github repo: Protect Children From Violence » 2022-06-02 05:12:14
- andy5995
- Replies: 3
Hi. I started a new GitHub organization and added a repo to it:
https://github.com/Protect-Children-Fro … m-Violence
On the repo settings, I enabled it to be a public template repo, so it can either be forked or be recreated under anyone's account as a detached project.
If you'd like to be invited to the org, just let me know here what your GitHub username is. Joining the org has no practical purpose... unless you set your visibility to "public" to help display how many people are interested in the "project".
If anyone is wondering, at this time I don't actually have any code planned for the repository.
#3 Off-topic » Self-care / mental health » 2019-09-04 19:08:57
- andy5995
- Replies: 0
A site I stumbled upon a couple years ago:
not that long ago, i had a minor wake up call. i wasn't taking care of myself and and my body told me so in no uncertain terms. the experience started me thinking about how important self care is, and how little we pay attention to it in the tech community.
so often i see my fellow developers ignoring their basic needs for rest and refreshment. i started this site to provide a central location to find links that will help us all take better care of ourselves.
not a developer or involved in tech? you still deserve to take time for self-care, too! you don't have to be in tech to contribute and use these links.
And an "awesome" mental health resource list, done by a friend of mine:
#4 Re: Other Issues » Submission to Experimental: rmw (ReMove to Waste) » 2019-08-25 22:30:51
Nothing special, other than the name.
In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a
(new)"Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.
Working with golinux on forming a complete and updated doc.
#5 Other Issues » modemu2k - submission to experimental » 2019-08-24 07:39:55
- andy5995
- Replies: 0
Hi folks,
I've submitted another project for consideration
modemu2k adds telnet capability to a comm program. It can redirect
telnet I/O to a pty so that a comm program can handle the pty as a tty
with a real modem, and allows you to use a comm program's scripting
and file transfer features over telnet. Now supports IPv6 connections.
modemu2k is a fork of modemu, originally developed by Toru Egashira.
#6 Re: Other Issues » Requesting bug reports » 2019-08-22 21:51:54
Got it, thanks.
#7 Re: Off-topic » Rust install? » 2019-08-15 20:39:14
I did a quick search for an explanation for why rust chooses to install this way rather than through package-managers. I couldn't find any good answers, but I do guess this is because all crates and such becomes managed centralized, so you will not end up with a lot of packages in different distros that is different versions of crates.
It would be very nice to get a definitive answer for this, if anyone here has this knowledge!
I couldn't say for sure, but I assumed it was so users could stay more up-to-date with stable releases, and partly for the reason you mentioned.
#8 Other Issues » Requesting bug reports » 2019-08-14 05:27:23
- andy5995
- Replies: 2
Hi
I submitted 2 bugs a few days ago, found them on the recent bug list page.
I sent an email to request@bugs.devuan.org, and in the body used
`send <bugnumber>`
I received the log, but does that also subscribes me to future activity on the bug? I felt that instructions weren't clear on that point (friendly feedback 
).
Also, when using the `send` command, is preceding the bug number with `#` required (I'm so used to adding that when writing GitHub tickets or in commit messages).? The example in the bug docs wasn't clear to me, so I sent 2 separate emails, one using `#` and one without...
#9 Re: Other Issues » Submission to Experimental: rmw (ReMove to Waste) » 2019-08-14 05:07:20
Wow, thanks for using Devuan as the upstream for your project. I personally won't have a use for this project, because I'm one of those old fogies who just rm -rf $ITEM which of course has bitten me a few times but you can't teach an old-hearted dog new tricks. I appreciate that you are endeavoring to comply with the freedesktop.org Trash spec. Just because some projects from them seem a little... unwanted doesn't mean it all is unwanted.
Wow, thank you very much for the feedback. 
I understand what you mean about changing old ways and appreciate your honesty about your intent not to use my little program
Great, Andy.
As you are experiencing, there is a bottleneck in the Devuan package building process, where the creative efforts end, and the software transitions into the more "formal" and process oriented treatment at the mouth of Devuan's automated build system. Sometimes tasks end up waiting there for some while simply because the person/people to move it along are few and with already full schedules.
Don't despair; it's not a deliberate inaction against your project and effort.
@ralph... Thank you for the reassurance. I'm not despairing yet. I hope I didn't sound like I was being unrealistic about my expectations. I really didn't mean to try to make anyone feel like I was trying to rush. I had only posted the link in IRC less than 24 hours ago, so I certainly am fine to wait much longer for CenturionDan to review. I've contributed to several projects on GitHub, so am pretty used to sometimes waiting over a month for PRs to get reviewed!
[*]The build dependencies (in control) seem incomplete; e.g., is there a dependency on gettext at the build stage? The control file should include "all" dependencies of what is required for building the package as well as what is required for using the built software.[/*]
I did some work on this and created a ticket. And yes, gettext is a build dep (unless --disable-nls is used). I omitted it earlier because that's usually installed, but I think I get what your saying:
As you know, it's very important to have both the build dependencies and the run-time dependencies set out relative to a "pristine", minimal installation.
[*]The version code (in changelog) might need to separate the source versioning from the packaging versioning. There are some "rules" regarding this, and some "tradition", and in particular, it would be sensible to start at 1 (or 0 even) for the first appearance in Devuan/experimental. I'm fairly sure Dan'll want to discuss this.[/*]
ticket for that created as well
Nothing special, other than the name.
In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a
(new)"Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.
I'm open to helping with some documentation; I'll give it more thought after this process is completed. I tend to get overwhelmed and scattered if I try to focus on too many things that are new. If there are any existing doc-related tickets that are open, feel free to ping me on them and I"ll have a look.
One thing I thought worth adding to a guide like you mentioned, is how to sync a source package repo with the original distribution archive. I managed to do it with rsync, using some exclude flags, etc, but never quite got rsync to do exactly what I wanted... But that can be worked out in another post or ticket. But do you think info like that would be suitable to include in a package prep guide?
#10 Re: Other Issues » Submission to Experimental: rmw (ReMove to Waste) » 2019-08-13 23:17:41
Thanks ralph.ronnquist...
I'll see how far I get with your feedback and post back when I get stuck.
Does the suites/experimental branch have to be the default branch, or just exist and be up-to-date?
#11 Other Issues » Submission to Experimental: rmw (ReMove to Waste) » 2019-08-13 20:01:08
- andy5995
- Replies: 6
Hi, I've prepared a source package for rmw, one of my projects. On IRC, Centurion_Dan said after I did that, I could let him know and he'd help me get it into Experimental. I pinged him and posted the link in IRC yesterday, but while I"m patiently waiting to hear back from him, wondering if anyone would be willing to review the files under debian/, as this is the first time I've prepared a debian package.
Pretty sure it's all good. It builds, and lintian reports no errors or warnings. When I extract the resulting deb package, all the files appear to be in the correct places.
Anyway, thought it'd be a good idea to get a little review before Centurion_Dan looks at it to save him a little time.
One thing I noticed is when I run `dpkg-buildpackage` I have to use '-tc' to do a post-clean. I tried figuring out how to create rules to do that, but had to take a break from that. Should I even worry about that? Since -tc does it?
#12 Re: Off-topic » Rust install? » 2019-08-13 03:32:29
If you're talking about installing rust using the method mentioned at the top of this page, my guess is that you should be pretty safe to do so. I have used that method for installing rust on Debian 9 and 10 (I have not done so on Devuan yet). The rust installer installation is separate from the regular distro package information, so there isn't any conflict, if I'm correct.
Where you're more likely to run into conflict is if you try to install Devuan rust packages after you've already installed rust using its own installer, or vice versa.
When I installed rust, it put most of the binaries and data files in ~/.cargo, whereas typically when you install packages from a distro repo, they'd go into /usr...
You may want to wait for more feedback though first before deciding, I'm not an "expert." Good luck, seeker.
Pages: 1
Board footer
