[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2019-03-03 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2019-03-03 23:59 UTC. Removals: app-crypt/etcd-ca 20190302-18:11 zlogene c0c5b1b04dd app-emulation/ganeti-htools 20190302-18:06 zlogene c04a11eae02 app-text/pdf2htmlEX 20190302-17:59 zlogene e4b60317619 dev-go/sarama 20190302-18:08 zlogene b50599bf3fe dev-java/jcs20190302-07:28 zlogene 25a641de5b7 dev-java/jcs20190302-07:42 zlogene 102a8d4cd9b dev-python/fusil20190228-01:12 vdupras fb9f9cb69c8 dev-python/python3-openid 20190228-01:10 vdupras f8371bc4b2b dev-python/python-social-auth 20190228-01:11 vdupras f784e0f7d08 Additions: dev-java/jcs20190302-07:37 zlogene dc529fbabd8 dev-libs/mmtf-cpp 20190226-14:13 alexxycd3082575ec dev-python/mypy_extensions 20190226-22:05 ikelos9de96f9c5cb dev-python/pytest-helpers-namespace 20190228-01:54 chutzpah 0995d9847c9 dev-python/python-pluginloader 20190301-22:16 junghans bdb754b55af dev-python/pywinrm 20190226-08:55 chainsaw d87df6f6fcb kde-plasma/discover 20190225-17:01 asturmb9d2de76f5f kde-plasma/xdg-desktop-portal-kde 20190225-17:02 asturmfffdffeb005 media-gfx/ttygif20190227-10:33 monsieurp 31b38030085 net-wireless/kismetdb 20190227-22:21 zerochaos 8e7bbf4ce5e sys-apps/xdg-desktop-portal 20190225-17:00 asturm277c9e63019 www-apps/trickster-bin 20190227-23:16 williamh 48dfbcc541e -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-crypt/etcd-ca,removed,zlogene,20190302-18:11,c0c5b1b04dd dev-go/sarama,removed,zlogene,20190302-18:08,b50599bf3fe app-emulation/ganeti-htools,removed,zlogene,20190302-18:06,c04a11eae02 app-text/pdf2htmlEX,removed,zlogene,20190302-17:59,e4b60317619 dev-java/jcs,removed,zlogene,20190302-07:42,102a8d4cd9b dev-java/jcs,removed,zlogene,20190302-07:28,25a641de5b7 dev-python/fusil,removed,vdupras,20190228-01:12,fb9f9cb69c8 dev-python/python-social-auth,removed,vdupras,20190228-01:11,f784e0f7d08 dev-python/python3-openid,removed,vdupras,20190228-01:10,f8371bc4b2b Added Packages: dev-java/jcs,added,zlogene,20190302-07:37,dc529fbabd8 dev-python/python-pluginloader,added,junghans,20190301-22:16,bdb754b55af dev-python/pytest-helpers-namespace,added,chutzpah,20190228-01:54,0995d9847c9 www-apps/trickster-bin,added,williamh,20190227-23:16,48dfbcc541e net-wireless/kismetdb,added,zerochaos,20190227-22:21,8e7bbf4ce5e media-gfx/ttygif,added,monsieurp,20190227-10:33,31b38030085 dev-python/mypy_extensions,added,ikelos,20190226-22:05,9de96f9c5cb dev-libs/mmtf-cpp,added,alexxy,20190226-14:13,cd3082575ec dev-python/pywinrm,added,chainsaw,20190226-08:55,d87df6f6fcb kde-plasma/xdg-desktop-portal-kde,added,asturm,20190225-17:02,fffdffeb005 kde-plasma/discover,added,asturm,20190225-17:01,b9d2de76f5f sys-apps/xdg-desktop-portal,added,asturm,20190225-17:00,277c9e63019 Done.
Re: [gentoo-dev] Last rites: some old X11 packages
On 3/3/2019 14:15, Matt Turner wrote: > On Sun, Mar 3, 2019 at 1:09 AM Joshua Kinard wrote: >> >> On 3/2/2019 13:46, Matt Turner wrote: >>> # Matt Turner (02 Mar 2019) >>> # Old, unused drivers. >>> # Masked for removal in 30 days. Bug #679256 >> >>> x11-drivers/xf86-video-newport >> >> This is for the SGI Indy's newport graphics board. Does it not build with >> modern Xorg or anything, or not maintained upstream? My Indy is dead due to >> a bad RTC, so I can't test it for the foreseeable future. > > Yes, it no longer builds and it requires packed 24-bit color support > which has been removed from the xserver. Fair enough. Could that bit be documented in the package.mask entry for the record, should anyone want to tackle trying to resurrect it, they'll know why it was masked and removed? > We would have to package an old xserver for -newport to be useful > (which is something I'd be interested to do with sufficient time). Long down on my TODO list is to figure out how to replace the RTC and resurrect the Indy. Wesolows gave it to me years ago, and it was pretty chipper for a 150MHz box. But the disk drive died and I never got around to replacing it. Maybe one day... -- 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] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Sat, 2019-03-02 at 18:41 -0500, Mike Gilbert wrote:
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny wrote:
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > ># Don't install libtool archives (even for modules)
> > > > > > > - prune_libtool_files --all
> > > > > > > + find "${D}" -name '*.la' -delete || die
> > > > > >
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place. Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > >
> > > > I have updated the example in ltprune.eclass now.
> > > >
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > >
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > >
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > >
> >
> > How many valid cases for this are there? For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
>
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.
>
Do you have any estimates how much more time is wasted on verifying
the result of find one-liner vs. verifying the result of complex
function (which used to have false negatives)? Please note I'm talking
about effort in case people are doing the right thing, not ignoring
the problems with the function and assuming it will always work fine.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Sun, 2019-03-03 at 20:29 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 02 Mar 2019, Michał Górny wrote: > > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote: > > > Perhaps we should un-ban the ltprune eclass for EAPI 7? > > > > > > It seems like it would still be useful to have a way of detecting > > > libtool-archives instead of removing any file that ends with ".la". > > How many valid cases for this are there? For comparison, how many > > useless complexity will be added to ebuilds by thoughtless maintainers > > using the first thing that seems to work without actually verifying > > whether it is necessary? > > Removing code that is working perfectly fine (at least, I don't see any > open bug for ltprune.eclass) doesn't look like the right instrument to > inform maintainers about a potential QA issue. After all, the eclass has > a warning in its description that is hard to miss. Actually, the code sometimes left .la files that weren't really needed after all. Then people either replaced it with oneliner, or used ' --all' which made it equivalent with the oneliner. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
> On Sat, 02 Mar 2019, Michał Górny wrote: > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote: >> Perhaps we should un-ban the ltprune eclass for EAPI 7? >> >> It seems like it would still be useful to have a way of detecting >> libtool-archives instead of removing any file that ends with ".la". > How many valid cases for this are there? For comparison, how many > useless complexity will be added to ebuilds by thoughtless maintainers > using the first thing that seems to work without actually verifying > whether it is necessary? Removing code that is working perfectly fine (at least, I don't see any open bug for ltprune.eclass) doesn't look like the right instrument to inform maintainers about a potential QA issue. After all, the eclass has a warning in its description that is hard to miss. OTOH, nobody has spoken up when the patch that deprecated the eclass in EAPI 7 was posted [1]. So maybe we should wait for a couple of valid use cases to be raised, before discussing this further. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/a5df51aa115c31737d54ece23446db76 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Sat, Mar 2, 2019 at 3:41 PM Mike Gilbert wrote:
>
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny wrote:
> >
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > ># Don't install libtool archives (even for modules)
> > > > > > > - prune_libtool_files --all
> > > > > > > + find "${D}" -name '*.la' -delete || die
> > > > > >
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place. Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > >
> > > > I have updated the example in ltprune.eclass now.
> > > >
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > >
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > >
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > >
> >
> > How many valid cases for this are there? For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
>
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.
Exactly.
Re: [gentoo-dev] Last rites: some old X11 packages
On Sun, Mar 3, 2019 at 1:09 AM Joshua Kinard wrote: > > On 3/2/2019 13:46, Matt Turner wrote: > > # Matt Turner (02 Mar 2019) > > # Old, unused drivers. > > # Masked for removal in 30 days. Bug #679256 > > > x11-drivers/xf86-video-newport > > This is for the SGI Indy's newport graphics board. Does it not build with > modern Xorg or anything, or not maintained upstream? My Indy is dead due to > a bad RTC, so I can't test it for the foreseeable future. Yes, it no longer builds and it requires packed 24-bit color support which has been removed from the xserver. We would have to package an old xserver for -newport to be useful (which is something I'd be interested to do with sufficient time).
Re: [gentoo-dev] rfc: cron.* and modern cron implementations
On 3/2/19 9:01 PM, Rich Freeman wrote: > > So, the problem with cron.d is that you're now using crontab syntax, > and for compatibility you have to use the lowest common denominator > which is vixie. > > That means your jobs are STILL running as root, so the only problem > you had with run-parts isn't solved. vixie-cron's crontab has a "user" field The rest of this post sounds like it's conflating the two issues again... which is completely my fault. I saw "run-" and got triggered. I think I've said everything that can be said against run-crons on the bug. I don't have any better ideas for the run-parts scheme.
Re: [gentoo-dev] rfc: cron.* and modern cron implementations
* Toralf Förster: > I'm not 100% but IMO for a desktop this seems works whereas @daily or > @weekly in crontab works only for systems running 24h per day, isn't > it? That depends on what flavour of cron is used (see https://en.wikipedia.org/wiki/Anacron). -Ralph
Re: [gentoo-dev] rfc: cron.* and modern cron implementations
On 3/3/19 1:05 AM, William Hubbs wrote:
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
I'm not 100% but IMO for a desktop this seems works whereas @daily or @weekly
in crontab works only for systems running 24h per day, isn't it?
--
Toralf
PGP 23217DA7 9B888F45
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] util-linux build time increase?
On 3/1/2019 10:01, Mart Raudsepp wrote: > Ühel kenal päeval, N, 28.02.2019 kell 04:13, kirjutas Joshua Kinard: >> On 2/25/2019 05:18, Alexander Tsoy wrote: >>> В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет: В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет: > Does anyone have an idea why util-linux's build time would go > up > significantly from 2.32.x to 2.33.x? It may be a MIPS thing, > as my > x86_64 > box shows no discernible change in build times between the same > versions. > Can any other archs check w/ genlop to see if they see a large > jump > in build > time? > > 'genlop -t util-linux' output on my SGI system (some entries > removed > for > brevity): > > Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 >merge time: 27 minutes and 48 seconds. > > Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 >merge time: 28 minutes and 44 seconds. > > Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 >merge time: 32 minutes and 58 seconds. > > Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 >merge time: 1 hour, 19 minutes and 49 seconds. > > Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 23 minutes and 37 seconds. > > Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 25 minutes and 15 seconds. > 2.33 was changed to use python-r1 eclass instead of python- single-r1 eclass. And the increase of build time seems caused by an out-of- source build for each python implementation. Some libraries are built several times (for native abi + for each python implementation). >>> >>> And there is additional configure run for each python >>> implementation. >> >> Hmm, this might explain things, somewhat. I think there's possibly >> some >> truth to the getcwd bit discussed earlier, but that may be limited to >> glibc >> only. > > Right, util-linux doesn't conduct that test. coreutils and tar do, > maybe some more. > That doesn't mean running with sandbox doesn't have a slowdown effect - > it most certainly does, just hopefully not so drastic as that > particular case - it involves glibc own generic getcwd being slow with > long paths, and sandbox calling it three times for its access checks > even for mkdir call, just to error with ENAMETOOLONG, in addition to > many getcwd calls the configure check itself does. So it's slow even > without sandbox, but with sandbox that slowness is doubled or more. > That has made me wonder if maybe by having some more ENAMETOOLONGs > earlier, the test would finish earlier, instead of slowly spinning > through paths that are in length between PATH_MAX and PATH_MAX*2, when > it's slow.. > But not sure why these m4 macros seems to be calling getcwd after each > mkdir+chdirm etc just to get a boolean configure check result. Didn't > look into the specific case, I only debugged the test case that just > loops mkdir+chdir. > Someone should maybe convert these project to meson and do that check > smarter :D > >> util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins. Have to >> re-time the glibc build to see if it's something w/ the libc >> implementation. >> >> Temp workaround I guess is to cut down on the PYTHON_TARGETS before >> my next >> catalyst attempt. 2.7 + 3.7 should be enough... > > Personally I seem to get by with just USE=-python on util-linux (it's > actually not globally enabled on my systems, it seems). Otherwise, > sure, if the slowness is in configure. > > > Mart Yeah, I forgot I had a global 'python' USE set on the Octane. It's not been fun trying to disentangle the mess after removing it. But... Before: Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 merge time: 1 hour, 25 minutes and 15 seconds. After: Sun Mar 3 03:22:26 2019 >>> sys-apps/util-linux-2.33.1 merge time: 18 minutes and 35 seconds. The above is also with sandbox disabled for now until the getcwd issue is fixed. If I'd known that sandbox slowed stuff down that much, I'd have stopped using it a long time ago. This machine is top of its class, but it's taking longer to build stuff as new versions come out due to new features being added, compiler taking longer, etc. I miss the days when this thing could build gcc in 3-4 hours. More like 14hrs now. -- 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] Last rites: some old X11 packages
On 3/2/2019 13:46, Matt Turner wrote: > # Matt Turner (02 Mar 2019) > # Old, unused drivers. > # Masked for removal in 30 days. Bug #679256 > x11-drivers/xf86-video-newport This is for the SGI Indy's newport graphics board. Does it not build with modern Xorg or anything, or not maintained upstream? My Indy is dead due to a bad RTC, so I can't test it for the foreseeable future. -- 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
