Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Tue, Mar 26, 2019 at 04:24:07PM -0500, William Hubbs wrote: > On Tue, Mar 26, 2019 at 09:02:07PM +0100, Michał Górny wrote: > > mail-mta/postfix > > I have an interest in this one since my employer uses it. > I don't know how fast I'll work the bugs right now, but I'll take a > look. :-) > > Eray, go ahead and co-maintain with me if you still want to. I've maintainer postfix for the last several years and I will continue maintaining it. Anyone is more than welcome to co-maintain if they wish. Cheers, -- Eray
Re: [gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding
El 26/3/19 a las 22:15, Ralph Seichter escribió: > * Francisco Blas Izquierdo Riera: > > All of my systems, and a big part of my business, depend on Postfix. I > don't want to start a tug-of-war, but I have been building and using > Postfix for roughly ten years now. I'm *certain* I'll do a good job. Good for me xD I think I have been building and using postfix for more than 10 years but I just don't find it so critical given my usage (mostly receiving and sending my personal mail). I just stood up to make sure somebody would maintain it (hence why I suuggested Eras as most of the work on the package in the last years has been his). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] the state of dev-lang/lua
On Mon, 25 Mar 2019 04:23:08 + "Robin H. Johnson" wrote: > On Sat, Mar 23, 2019 at 04:23:27PM -0500, William Hubbs wrote: > > Hi all, > > > > Soon I will be working on fixing up the state of dev-lang/lua, and > > there are a couple of things I want to mention. > > > > The first thing is liblua as a shared library. If you are using lua > > internally in a program, upstream strongly recommends not linking it > > this way; it is supposed to be statically linked into the > > executable. Because of this, and because of the amount of custom > > patching we do to maintain liblua as a shared library, I plan to > > stop creating the shared library. > Please don't go back to static libraries. Look at the other major > distros, all of them shipped shared Lua as the primary method. +1 > > > I'm a bit undecided still about slotting lua. I'm sure we > > need subslots so we can force rebuilds when new lua releases enter > > the tree. However, I'm still unsure whether we need slots. I don't > > know of many things in the tree that are locked to a specific > > version of lua (there is only one package based on an irc > > conversation I had this week). > > Does anyone have any thoughts? > Lua needs first class slots, just like Python & Ruby, not just > subslots. Changing between versions can be a major undertaking. > > I think the slots to start with should be: > - lua5.1 > - lua5.2 > - lua5.3 > - luajit5.1 (this is basically an alternative implementation of > Lua5.1, much like pypy implements Python2). I think we are going to have to have slots for the "openresty" lua fork here as well. Several nginx modules require this version to work properly (I can provide more details if needed).
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Tue, Mar 26, 2019 at 09:02:07PM +0100, Michał Górny wrote: > mail-mta/postfix I have an interest in this one since my employer uses it. I don't know how fast I'll work the bugs right now, but I'll take a look. :-) Eray, go ahead and co-maintain with me if you still want to. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Francisco Blas Izquierdo Riera: > > mail-mta/postfix > > Some of my systems depend on this one so unless eras wants to take > care of it, I can try to do that. I doubt I'll do as good of a job > as he has done so far. All of my systems, and a big part of my business, depend on Postfix. I don't want to start a tug-of-war, but I have been building and using Postfix for roughly ten years now. I'm *certain* I'll do a good job. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Michael Orlitzky: > I'd be happy to work on all of that stuff either before or after you > guys take over and get settled in. I'd appreciate you adding all improvements you already have in store. It would be a shame to waste the work you have already done. -Ralph
[gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding
El 26/3/19 a las 21:02, Michał Górny escribió: > mail-filter/opendkim I'm unsure if anybody feels responsible for this one. Upstream is pretty silent and made no releases since 2015. In a modern mail system it is important to be able to sign outgoing e-mail with DKIM as things like mailing lists may fail otherwise. So I can take maintainership if somebody is willing to proxy for me. > mail-mta/postfix Some of my systems depend on this one so unless eras wants to take care of it, I can try to do that. I doubt I'll do as good of a job as he has done so far. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On 3/26/19 4:32 PM, Aaron Bauman wrote: > On Tue, Mar 26, 2019 at 09:10:28PM +0100, Ralph Seichter wrote: >> * Michał Górny: >> >>> mail-filter/opendkim >> >> I can take OpenDKIM if no former team member wants to. >> > > Please have a look at bug #629914 as well. Let me know if you submit a > pull request and I will take a look. > I have fixes for that, bug 629888, and bug 575666 in an overlay. There are some other notes I was just in the process of making: * Don't generate a default config file conditionally, the package image should not change randomly. * /var/lib/opendkim should be created with keepdir. * I think pkg_config should put the keys in /var/lib/opendkim rather than /etc/opendkim, because they're data (not text configuration). I'd be happy to work on all of that stuff either before or after you guys take over and get settled in.
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Aaron Bauman: > Please have a look at bug #629914 as well. Yeah, I've come across the key file permissions issue already. I've added myself as Cc for the bug for now, and I'll have a closer look over the coming days. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Tue, Mar 26, 2019 at 09:10:28PM +0100, Ralph Seichter wrote: > * Michał Górny: > > > mail-filter/opendkim > > I can take OpenDKIM if no former team member wants to. > Please have a look at bug #629914 as well. Let me know if you submit a pull request and I will take a look. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Michał Górny: > mail-filter/opendkim I can take OpenDKIM if no former team member wants to. > mail-mta/postfix > net-mail/pflogsumm I will gladly take these. Postfix is highly important for me, and the Postfix log summary seems like a natural addition. -Ralph
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-doc/eclass-manpages/files/
On Tue, Mar 26, 2019 at 08:43:11PM +0100, Michał Górny wrote: > On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote: > > commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df > > Author: Michael Mair-Keimberger gmail com> > > AuthorDate: Tue Mar 26 19:28:48 2019 + > > Commit: Aaron Bauman gentoo org> > > CommitDate: Tue Mar 26 19:32:52 2019 + > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e32186b > > > > app-doc/eclass-manpages: remove unused file > > > > Cool. It figures life's gonna be much easier now that we don't have > the tool to generate those manpages. > > -- > Best regards, > Michał Górny > It is reverted/restored now. Should probably find a proper place to store it... -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-doc/eclass-manpages/files/
On Tue, 2019-03-26 at 15:52 -0400, Michael Orlitzky wrote: > On 3/26/19 3:43 PM, Michał Górny wrote: > > On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote: > > > commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df > > > Author: Michael Mair-Keimberger gmail > > > com> > > > AuthorDate: Tue Mar 26 19:28:48 2019 + > > > Commit: Aaron Bauman gentoo org> > > > CommitDate: Tue Mar 26 19:32:52 2019 + > > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e32186b > > > > > > app-doc/eclass-manpages: remove unused file > > > > > > > Cool. It figures life's gonna be much easier now that we don't have > > the tool to generate those manpages. First of all, I'm sorry, this wasn't supposed to go to -dev. I removed -commits but failed to notice -dev appended somewhere as well. > > In their defense, that package is structured ridiculously. Yep, guess who did it. > We certainly > shouldn't be using $FILESDIR as the source control repository for the > shell/awk scripts that generate the man pages. If anything, they belong > in their own package, with their own "upstream" project/repository. The > eclass-manpages package would then (build-) depend on the scripts -- at > least for - version that builds them on the fly. I was thinking about doing this for quite some time. Never found enough motivation though. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
Hello, everyone. The net-mail project is being disbanded. As a result, the following 142 packages are up for grabs. Please note that many of them will probably be taken by the past project members, so there's no need to panic. app-misc/abook app-shells/smrsh dev-libs/cyrus-sasl dev-perl/File-Scan-ClamAV mail-client/biabam mail-client/clawsker mail-client/cone mail-client/etpan-ng mail-client/hap mail-client/mailx-support mail-client/mailx mail-client/nail mail-client/nmh mail-client/pinepgp mail-filter/amavisd-milter mail-filter/anubis mail-filter/ask mail-filter/bmf mail-filter/clamassassin mail-filter/clamsmtp mail-filter/disspam mail-filter/dspam mail-filter/gld mail-filter/imapfilter mail-filter/libmilter mail-filter/libspf2 mail-filter/libsrs2 mail-filter/libsrs_alt mail-filter/maildrop mail-filter/mailfilter mail-filter/mapson mail-filter/mimedefang mail-filter/normalizemime mail-filter/opendkim mail-filter/policyd-weight mail-filter/policyd mail-filter/procmail-lib mail-filter/procmail mail-filter/rblcheck mail-filter/sid-milter mail-filter/spamass-milter mail-filter/spamdyke mail-filter/spampd mail-filter/spamprobe mail-filter/sqlgrey mail-filter/tmda mail-filter/zdkimfilter mail-mta/esmtp mail-mta/mini-qmail mail-mta/msmtp mail-mta/netqmail mail-mta/postfix mail-mta/qmail-ldap mail-mta/qpsmtpd mail-mta/ssmtp mail-mta/sendmail net-analyzer/postal net-libs/c-client net-libs/libesmtp net-libs/libetpan net-libs/libgsasl net-libs/liblockfile net-libs/libntlm net-mail/altermime net-mail/archivemail net-mail/asmail net-mail/bincimap net-mail/checkpassword-pam net-mail/cmd5checkpw net-mail/courierpassd net-mail/cyrus-imapd net-mail/dot-forward net-mail/email net-mail/eps net-mail/ezmlm-idx net-mail/fastforward net-mail/fetchmail net-mail/gensig net-mail/getmail net-mail/gnubiff net-mail/grepmail net-mail/hotwayd net-mail/imapsync net-mail/kuvert net-mail/lbdb net-mail/mailbase net-mail/maildirtree net-mail/mailfront net-mail/mailgraph net-mail/mailsync net-mail/mailutils net-mail/mairix net-mail/mboxgrep net-mail/mess822 net-mail/metamail net-mail/mhonarc net-mail/mlmmj net-mail/mpack net-mail/mpop net-mail/mswatch net-mail/mu net-mail/nmzmail net-mail/offlineimap net-mail/peephole net-mail/pflogsumm net-mail/pfqueue net-mail/pop-before-smtp net-mail/pop2imap net-mail/popa3d net-mail/popick net-mail/poppassd_ceti net-mail/qmail-autoresponder net-mail/qmail-notify net-mail/qmail-qfilter net-mail/qpopper net-mail/qprint net-mail/queue-repair net-mail/randomsig net-mail/ripmime net-mail/ripole net-mail/serialmail net-mail/signify net-mail/smtptools net-mail/spamcup net-mail/swaks net-mail/tnef net-mail/tpop3d net-mail/up-imapproxy net-mail/uw-imap net-mail/uw-mailutils net-mail/vchkuser net-mail/vpopmail net-mail/yosucker net-misc/gsasl sys-apps/ucspi-tcp virtual/checkpassword virtual/gsasl virtual/imap-c-client virtual/mailx virtual/mda virtual/mta virtual/qmail -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?
On 3/26/2019 10:22, Michał Górny wrote: > On Mon, 2019-03-25 at 15:19 -0400, Joshua Kinard wrote: >> Throwing a question out there on whether to keep both the net-fs/ncpfs and >> net-misc/ipx-utils packages around any longer. Kernel upstream removed both >> the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core >> Protocol Filesystem) support back in ~4.18 due to lack of maintenance. I >> know the code in both generally worked fine back then, as I have a few >> NetWare VMs that I was able to mount filesystems from in Linux, even on my >> MIPS hardware. >> >> However, it is effectively a dead protocol and dead filesystem for a dead >> operating system (NetWare). I don't see anyone resurrecting IPX/NCPFS and >> updating to get it re-included it in the kernel, either. I was tempted once >> to try, but I just don't have the time anymore. >> >> I think we're one of the last distros to even keep IPX/NCPFS-related >> packages around long-term. With no viable upstream for ncpfs anymore, and >> with no kernel support in Linux (or even FreeBSD; they deprecated IPX in >> ~10.0-RELEASE), I think it's time to remove this package and any related >> packages. >> >> One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14 >> stable kernel series around. These can still technically use IPX/NCPFS, and >> therefore, there might be users using it. >> >> A quick poll of the portage tree suggests these changes are needed: >> >> Delete USE flag reference: >> net-analyzer/hydra >> profiles/use.local.desc (remove hydra's local 'ncp' entry) >> >> Remove ebuilds: >> net-fs/ncpfs >> net-misc/ipx-utils >> >> Remove filesystem reference?: >> sys-apps/mlocate/files/updatedb.conf >> >> Remove reference to 'ipx-utils': >> profiles/license_groups >> >> >> Thoughts? >> > > Last rite them with 60 day period. If someone actually uses them, > you'll learn about it and get some data to decide how to proceed > afterwards. Plus, users who actually might still use them would get > a fair warning they're going to be dropped in the future. > Thanks, good advice. I've created a bug for myself (#681820) and opted for 75 days, as 60 days is too close to a major US holiday period where I might be preoccupied. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-doc/eclass-manpages/files/
On 3/26/19 3:43 PM, Michał Górny wrote: > On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote: >> commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df >> Author: Michael Mair-Keimberger gmail com> >> AuthorDate: Tue Mar 26 19:28:48 2019 + >> Commit: Aaron Bauman gentoo org> >> CommitDate: Tue Mar 26 19:32:52 2019 + >> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e32186b >> >> app-doc/eclass-manpages: remove unused file >> > > Cool. It figures life's gonna be much easier now that we don't have > the tool to generate those manpages. > In their defense, that package is structured ridiculously. We certainly shouldn't be using $FILESDIR as the source control repository for the shell/awk scripts that generate the man pages. If anything, they belong in their own package, with their own "upstream" project/repository. The eclass-manpages package would then (build-) depend on the scripts -- at least for - version that builds them on the fly.
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-doc/eclass-manpages/files/
On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote: > commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df > Author: Michael Mair-Keimberger gmail com> > AuthorDate: Tue Mar 26 19:28:48 2019 + > Commit: Aaron Bauman gentoo org> > CommitDate: Tue Mar 26 19:32:52 2019 + > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e32186b > > app-doc/eclass-manpages: remove unused file > Cool. It figures life's gonna be much easier now that we don't have the tool to generate those manpages. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?
On Tue, Mar 26, 2019 at 03:22:08PM +0100, Michał Górny wrote: > Last rite them with 60 day period. If someone actually uses them, > you'll learn about it and get some data to decide how to proceed > afterwards. Plus, users who actually might still use them would get > a fair warning they're going to be dropped in the future. This makes sense to me. This way you would learn for sure how many people are using them. If no one complains during the 60 days, nuke them. ;-) William signature.asc Description: Digital signature
Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?
On Mon, 2019-03-25 at 15:19 -0400, Joshua Kinard wrote: > Throwing a question out there on whether to keep both the net-fs/ncpfs and > net-misc/ipx-utils packages around any longer. Kernel upstream removed both > the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core > Protocol Filesystem) support back in ~4.18 due to lack of maintenance. I > know the code in both generally worked fine back then, as I have a few > NetWare VMs that I was able to mount filesystems from in Linux, even on my > MIPS hardware. > > However, it is effectively a dead protocol and dead filesystem for a dead > operating system (NetWare). I don't see anyone resurrecting IPX/NCPFS and > updating to get it re-included it in the kernel, either. I was tempted once > to try, but I just don't have the time anymore. > > I think we're one of the last distros to even keep IPX/NCPFS-related > packages around long-term. With no viable upstream for ncpfs anymore, and > with no kernel support in Linux (or even FreeBSD; they deprecated IPX in > ~10.0-RELEASE), I think it's time to remove this package and any related > packages. > > One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14 > stable kernel series around. These can still technically use IPX/NCPFS, and > therefore, there might be users using it. > > A quick poll of the portage tree suggests these changes are needed: > > Delete USE flag reference: > net-analyzer/hydra > profiles/use.local.desc (remove hydra's local 'ncp' entry) > > Remove ebuilds: > net-fs/ncpfs > net-misc/ipx-utils > > Remove filesystem reference?: > sys-apps/mlocate/files/updatedb.conf > > Remove reference to 'ipx-utils': > profiles/license_groups > > > Thoughts? > Last rite them with 60 day period. If someone actually uses them, you'll learn about it and get some data to decide how to proceed afterwards. Plus, users who actually might still use them would get a fair warning they're going to be dropped in the future. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?
On Mon, 25 Mar 2019 15:19:06 -0400 Joshua Kinard wrote: > Throwing a question out there on whether to keep both the net-fs/ncpfs and > net-misc/ipx-utils packages around any longer. Kernel upstream removed both > the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core > Protocol Filesystem) support back in ~4.18 due to lack of maintenance. I > know the code in both generally worked fine back then, as I have a few > NetWare VMs that I was able to mount filesystems from in Linux, even on my > MIPS hardware. > > However, it is effectively a dead protocol and dead filesystem for a dead > operating system (NetWare). I don't see anyone resurrecting IPX/NCPFS and > updating to get it re-included it in the kernel, either. I was tempted once > to try, but I just don't have the time anymore. > > I think we're one of the last distros to even keep IPX/NCPFS-related > packages around long-term. With no viable upstream for ncpfs anymore, and > with no kernel support in Linux (or even FreeBSD; they deprecated IPX in > ~10.0-RELEASE), I think it's time to remove this package and any related > packages. > > One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14 > stable kernel series around. These can still technically use IPX/NCPFS, and > therefore, there might be users using it. > > A quick poll of the portage tree suggests these changes are needed: > > Delete USE flag reference: > net-analyzer/hydra > profiles/use.local.desc (remove hydra's local 'ncp' entry) > > Remove ebuilds: > net-fs/ncpfs > net-misc/ipx-utils > > Remove filesystem reference?: > sys-apps/mlocate/files/updatedb.conf > > Remove reference to 'ipx-utils': > profiles/license_groups > > > Thoughts? Keep them around as long as we have kernel versions supporting IPX/NCPFS in the tree. When they will pass, perform the cleanup listed above. Best regards, Andrew Savchenko pgp7nZ7kgv7kd.pgp Description: PGP signature
