[gentoo-dev] Re: [PATCH v2] 2023-05-08-openssh-configuration-changes: add item
>>>>> "SJ" == Sam James writes: SJ> +Such admins will need to edit the new files in the new directories or SJ> +make overrides in their own files in the new directories using a higher SJ> +number in the filename. given that openssh uses first-wins rather than last-wins, should than not be 'smaller number'? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-gfx/colorhug-client
Does fwupd do all of the other stuff the binaries in colorhug-client support? Or just firmware updates? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-portage-dev] Changing the VDB format
>>>>> "MT" == Matt Turner writes: MT> For example the 'EAPI' file MT> that contains a single character will consume a 4K block on disk. the sort of filesystes one expects to be used for /var all store short files either directly in the inode or in the directory entry¹. that said, Fabian’s suggestion of tar(1)ing those files sounds like a winner. a number of tools and editors allow r/w access to tar(5) files, including to the individual files therein. 1] or at least unix/linux filesystems all used too -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
>>>>> "UM" == Ulrich Mueller writes: UM> I was specifically asking about Gentoo infra there. ah; i completely missed that bit. sorry for the misunderstanding. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
>>>>> "UM" == Ulrich Mueller writes: UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine, UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. why do you thing gentoo is everyone's first or only dist on their network? or even on any given box? forcing existing boxen to change just because a new dist is added is also unacceptable. for me though, it would be enough if there is something i can add to make.conf to ensure that the acct-user and acct-group builds avoid the ranges i already use. that may also work for others. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
gentoo definitely should not permit fixed use for installed packages in
the 500-600 range.
500+ was for many, many years the start for users, and forcing anyone to
change decades-long use of particular uids or gods is not acceptable.
really all of 101-499,701-999,6-{nobody--} should be dynamic.
and 500-700 never touched by the distribution.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default
>>>>> "RHJ" == Robin H Johnson writes: RHJ> The best I can come up with at the moment, is that any packaging should RHJ> detect if there are user modifications, and provide control to users RHJ> based on that fact. Exactly. Akin to etc-update. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Getting rid of USE=unicode
there are not too many packages to look at:
:; git grep -P IUSE.+unicode.*\"|awk -F/ '{print $1 "/" $2}'|sort -u|wc -l
82
so it should ot take too uch effort.
and it definitely would be worth it!
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Last rites: media-fonts/symbola
>>>>> "UM" == Ulrich Mueller writes: UM> So, removal of the package seems to be the only option that makes sense, UM> unless we would downgrade to that old version. Agreed. Cest la vie. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Last rites: media-fonts/symbola
>>>>> "UM" == Ulrich Mueller writes: UM> I've sent an e-mail message upstream, asking for confirmation that 10.24 UM> can be used, copied, modified, and/or distributed freely. cool. i hope useful info results. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Last rites: media-fonts/symbola
>>>>> "UM" == Ulrich Mueller writes:
>>>>> On Tue, 31 Mar 2020, Alessandro Barbieri wrote:
>> Version 10.23 is here
>> https://web.archive.org/web/20180129230141/http://users.teilar.gr/~g1951d/Symbola.zip
UM> Actually, that zipball contains version 10.24, which is under the
UM> restrictive license already:
UM> $ fc-query -f '%{fontversion}' Symbola.ttf | awk '{ print $1/65536 }'
UM> 10.24
The only license i can see in that zip is the line in the pdf (which
also says 10.24) that they are 'free for any use'.
If 10.24 is in wayback, 10.23 probably is as well.
The last usable version would be a useful find.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Last rites: app-dicts/sword-*
>>>>> "UM" == Ulrich Mueller writes: >> That is untrue. They are public domain. UM> Where did you get that information from? Some may not be. I didn't look at every page, but for ones like: http://crosswire.org/sword/modules/ModInfo.jsp?modName=DutSVV it says so on that page. My recollection was pd in general, but i see there may be some not. I paid closer attention to things that would go under app-dict before the last couple of strokes -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Last rites: app-dicts/sword-*
>>>>> "UM" == Ulrich Mueller writes: UM> # Ulrich Müller (2020-01-06) UM> # No license, therefore we have no permission to redistribute That is untrue. They are public domain. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] New distfile mirror layout
>>>>> "RY" == Richard Yao writes: RY> ext4 is probably okay, but don’t quote me on that. Ext4 works fine here for a local distfiles mirror. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags
On an odroidc1, I get: # ./hwcap-dump hwcap:0009b0d7 hwcap2: # uname -m armv7l On an original dragonboard, I get: # ./hwcap-dump hwcap:0087 hwcap2: # uname -m aarch64 (Both run gentoo.) The pi3 says: hwcap:003fb0d6 hwcap2:0010 armv7l I have a couple of cheap arm32 (don't recall manuf) which report: hwcap:000fb8d7 hwcap2: armv7l A c.h.i.p. says: hwcap:0008b0d6 hwcap2: armv7l All of my other arm boards are offline. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] dynamic groups and users
>>>>> "MO" == Michael Orlitzky writes: MO> and set the desired ID to either 999 or a random number like MO> floppym suggested. Remember that there are sites where user uids still start at 500, and even recent installs have to work there, too. Nothing over 499 should be used for system uids. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Current status with openssl-1.1
>>>>> "LW" == Lars Wendler writes: LW> openssh upstream even raised the idea to simply focus crypto support in LW> their software on libressl Debian plans on using libressl for openssh (statically, I presume), once openssl-1.0 is removed from their archive. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[gentoo-dev] libressl blocker
Bug 626298 should block 561854 (the LibreSSL tracker). Could someone with the required perms mark it so? Thanks, -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
WH == William Hubbs willi...@gentoo.org writes:
WH The other change I want to make, considering that the mount.* scripts
WH will actually do the work of mounting the file systems, is to turn
WH localmount and netmount into wrappers which will do nothing other than
WH pull in the appropriate mounts. The sys admin would have to configure
WH which mounts are local vs network using settings in
WH /etc/conf.d/{local,net}mount.
WH What do folks think of these changes?
For local filesystems, mount -a is exactly right and should remain. At
least for those of us who prefer only ever halving to edit fstab(5).
Remote filesystems might be differnt, but for local filesystems the
status quo is better.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] bugs.gentoo.org and dnssec
AB == Alon Bar-Lev alo...@gentoo.org writes: AB When using bugs.gentoo.org with dnsmasq and dnssec enabled, I cannot AB access attachments. It works here using a local unbound. But dnsmasq had some growth pains when it added dnssec verification, due to its bottom-up rather than the ususal top-down approach. AIUI, the current release should work. If you see that issue with 2.72 or later, they'd like to hear about it. Their list is: dnsmasq-disc...@lists.thekelleys.org.uk -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Lastrites: www-servers/publicfile, www-apache/mod_roaming, gnome-base/gnome-js-common, dev-libs/seed, net-irc/xchat-gnome, app-backup/rdiff-backup, app-backup/pybackpack, sys-fs/rdiff
PR == Pacho Ramos pa...@gentoo.org writes: PR # Pacho Ramos pa...@gentoo.org (22 Mar 2015) PR # Cannot be fetched, also has licensing issues (#531270). PR # Removal in a month. PR www-servers/publicfile Sine when ca
Re: [gentoo-dev] Lastrites: www-servers/publicfile, www-apache/mod_roaming, gnome-base/gnome-js-common, dev-libs/seed, net-irc/xchat-gnome, app-backup/rdiff-backup, app-backup/pybackpack, sys-fs/rdiff
PR == Pacho Ramos pa...@gentoo.org writes: PR # Pacho Ramos pa...@gentoo.org (22 Mar 2015) PR # Cannot be fetched, also has licensing issues (#531270). PR # Removal in a month. PR www-servers/publicfile Since when can it not be fetched? http://cr.yp.to/publicfile/publicfile-0.52.tar.gz fetches fine. Just curious. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
MG == Michał Górny mgo...@gentoo.org writes: MG sse4_1 - Enable SSE4.1 instruction support MG sse4_2 - Enable SSE4.2 instruction support Does everything use the _ versions? The docs should cover the . versions, as well, if anything still expects them. I've had to use sse4.1 and sse4.2, too, for some stuff. (Obviously . xor _ in the ebuilds (a/o eclasses?) would be nice.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
MG == Michał Górny mgo...@gentoo.org writes: MG This means we don't have to wait till someone figures out the perfect MG way of converting the old CVS repository. You don't need that history MG most of the time, and you can play with CVS to get it if you really do. MG In any case, we would likely strip the history anyway to get a small MG repo to work with. +1 on that. The cvs repo can be converted to an historical git repo on a slower timeframe, and remain available as cvs until then. That old-vs-fresh concept worked fine for other projects (including Linux). -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
AX == Alex Xu alex_y...@yahoo.ca writes: AX Please don't crosspost followup messages, especially to the same mailing AX list twice. Ick. I didn't notice the cc details when I replied. ☹ -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
PR == Pacho Ramos pa...@gentoo.org writes: PR # Pacho Ramos pa...@gentoo.org (27 Jul 2014) PR # Doesn't build on non-selinux setups (#498032) PR # Removal in a month. PR dev-lang/gforth Did you even try 0.7.3 before coming to that conclusion? It needs a bump, not a dump. And for a GNU package at that. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys
A quick test shows that the sshfp for the ed25519 key for the current host is not published; those who configure ssh to prefer ssh-ed25519 and VerifyHostKeyDNS will get an error about that, even after accepting the key, just because the other keys' sshfps are published. Please be sure to publish sshfp for all four keys when the new host takes over. Thanks! -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 signature.asc Description: PGP signature
Re: [gentoo-dev] old masked for testing entries
MG == Mike Gilbert flop...@gentoo.org writes: MG For example, I think the major reason for the sys-libs/db mask is a MG weird licensing issue. It's still nice to have it in the tree. That only applies to db:6.0. I know debian and ubuntu primarily use 5.3 these days, with the only issues being related to upgrading existing stores to the newer formats as they release newer versions and re-compilations of the reverse dependencies linked against 5.3. I've read that some heavy users of db, such as sks, work better with 5.3 than they did with older versions. But upgrading needs to be done with care. So it should be fine to unmask 5.3 and slowly update reverse dependencies to depend on 5.3 instead of whichever 4.x they currently demand. Unmasking the earlier 5.x releases seems unnecessary, though. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] old masked for testing entries
MG == Michał Górny mgo...@gentoo.org writes: MG Dnia 2014-06-30, o godz. 17:40:16 MG James Cloos cl...@jhcloos.com napisał(a): So it should be fine to unmask 5.3 and slowly update reverse dependencies to depend on 5.3 instead of whichever 4.x they currently demand. Unmasking the earlier 5.x releases seems unnecessary, though. MG While at it, please don't unmask 5.3.28-r1 (EAPI5 ebuilds). Multilib MG relies heavily on not having anything EAPI5 over 4.8.30-r1. Good point. I should have more precise and said the most recent ebuild in the 5.3 SLOT, which is what I was thinking. -JimC -- -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] old masked for testing entries
KF == Kristian Fiskerstrand kristian.fiskerstr...@sumptuouscapital.com writes: KF I'm not familiar with any large difference. I only mentioned sks because it is the only heavy user of berk db I currently run. Most either moved on to other libs or I use w/ pg. I did get the impression from the sks list that db5 worked better than db4, though. Or perhaps that was something which sleapycat fixed in more recent versions of 4, too? KF I'm testing with 5.2 for my live SKS ebuild which I've been using KF for quite some time on a few of my servers as backends of the KF load-balanced without any issues, KF Upgrading is relatively easy, mostly involving cleaning the KF environment, which will be re-generated with the updated version. The issue seen on debian was that the tools for 5.1 were used by the upgrade script when the sks-dependent-on-5.3 was released, but there was no dependency so apt didn't know to ensure that the binary dpkg required was installed. That shouldn't be an issue on Gentoo, given that the programs installed with a given db SLOT are not dependent on any USE flags and the parallel versions tend to remain longer. It seems, even though I only mentioned it in an aside, I could have thought of a better example. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Re: News item draft for =sys-fs/udev-209 upgrade
D == Duncan 1i5t5.dun...@cox.net writes: D 2) The former /lib/udev/rules.d/80-net-name-slot.rules file is renamed to D 80-net-setup-link.rules in the same location. If you were overriding D udev's predictable naming feature using an identically named file in D /etc/udev/rules.d, either rename it accordingly or see the wiki link[1] D below for other options. +1 on that. The proposed rewrite does a much better job of explaining why anyone should care about the change. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Should we allow picture files in the Portage tree?
JAD == Jason A Donenfeld zx...@gentoo.org writes: UM Should we allow pictures if the image file format is a text file? JAD I think we should not. Even if you can open it in a text editor, JAD you can't read it or interact with it in the same way that you JAD can a text-based patch. That's not true for xbm and xpm files; those are valid C programs and are completely readable. And editable. The gentoo.logo file from app-misc/linux-logo is also easily read and edited. Diff(5)s also work well, so their cvs and git history is usable. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] new eclass proposal, perl-mb-tiny.eclass
Please eliminate the call to perl_delete_module_manpages.
perl-module.eclass's malicious abuse of that should not propagate.
The man pages are as valuable as the modules themselves.
I wonder about:
if [[ -z ${mytargets} ]] ; then
case ${CATEGORY} in
dev-perl|perl-core) mytargets=install ;;
*) mytargets=install ;;
esac
fi
Did the case block originally have different results for different CATEGORYs?
Otherwise it looks good. And useful.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
(I think I forgot to mention when I wrote about keeping git-2 around for a while that I like the plan for git-3; that should have been explicit.) It looks good. I haven't worked out what the storage names under EGIT3_STORE_DIR will be for submodules, though. If multiple parent gits want the same submodule, and/or if a package exists for it in its own right, will the same store clone be used for all of them? Including when some use git://, others https://, et al? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
TW == Tom Wijsman tom...@gentoo.org writes: TW Also, please just call it git-3.eclass as it is a major change; any TW other form of naming will introduce confusion (eg. -r1 -2), also we TW probably shouldn't change git-2.eclass as even when masked it doesn't TW seem like a good thing to break its current API and documentation as TW well as what actually works in the Portage tree. +1 on all of that. git-3 is a better name than using -r1. And leave git-2 there for at /least/ a year. There are a LOT of out of tree git-2 users. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] font.eclass add Xorg FontPath elements for non-standard paths
While making it easier for those who want all of their fonts included in the x11 server-side font list is not an unreasonable goal, forcing them to be is unreasonable. As someone who has run X11 regularly for over 20 years now, I absolutely do not want any type1 or SFNT fonts in my x server font path. Any app I use these days with such fonts supports client-side fonts. For the apps which require server-side fonts, the bfd fonts suit best. Putting all of /usr/share/fonts into the fontpath will only slow the X11 startup. I'd suggest either an eselect(1) driven applet to let one choose which directories to add to a single .d conf file, or perhaps a non-gentoo- specific gui app to do so. Either of those would provide exactly the right sort of configuation assistance for users who are not comfortable editing their configs in text editors. Or, if you are feeling ambitious, write an X-Font-Server which uses libfontconfig to find fonts, generates and keeps a cache of fc-pattern to/from xlfd mappings, and serves said fonts to X servers. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] News item preceding net-print/cups-1.6 stabilization
AKH == Andreas K Huettel dilfri...@gentoo.org writes: AKH As there is a pending security bug, I'd like to commit this news item on AKH Sunday 2013/6/30 12:00 UTC and immediately afterwards request cups-1.6 AKH stabilization. Note that =cups-filters-1.0.34-r1 has several regressions from cups-1.5 A couple of them which involve postscript documents and/or postscript printers have been fixed in bzr and should be part of the next release. I'm also working on additional improvements I hope to see in the next release of the filters. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-portage-dev] portage 9999 at commit 2d5e38b495776e5bb2266848a3365667f3ca7233 **SLOW**
My typical emerge -upvDN world went up from 10s of minutes to several hours sometime between portage 37f33e9 and 2d5e38b. I noticed by way of strace(8) that it access(2)es each ebuild in /usr/portage on each configured overay 10 times. Each. It does so in order from the last overlay in PORTDIR_OVERLAY to the first. It is the whole cycle which repeats a total of 10 iterations. Seems it would be simpler to do the python equiv of ls */*/*.ebuild in each overlay's top dir, note what ebuilds exist in each overlay in a data structure, and use that. Portage shouldn't worry about any changes which occur in the middle of any single run. (Which is not to claim that it currently does, lest that sentence be misunderstood. :) Each access(2) is averaging about 300 or so micro seconds. So about 66 miliseconds per ebuild. There are 33728 ebuild files in /usr/portage, so that is about 2226 seconds. Or nearly 40 minutes just wasting time. I run it in script(1) these days; /usr/bin/time output for one run was: 4314.78user 305.06system 5:17:03elapsed 24%CPU (0avgtext+0avgdata 4977056maxresident)k 145208inputs+14296outputs (9major+34541240minor)pagefaults 0swaps So that is on the order of 20 times as long as it used to take. I looked at git log. The depgraph commit (62dbcaa4d873784f1) seems to be the only one in that range which could have an effect. At least at first glance. After doing the 7420160 access(2) calls, it read in some from a file (the descriptor was closed by the time a was able to run lsof(8) to see what fd 4 was), seek(2)ing between reads, and then seems to have started doing the 7420160 access(2) calls again. (!) As if once wasn't enough. :^/ No wonder the first run took 5+ hours. (I'm falling asleep at the kbd; I hope I didn't miss any needed edits above.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
MF == Mike Frysinger vap...@gentoo.org writes: It will impact everyone who has /dev/pts in fstab(5). MF don't do that. *I* didn't. I don't know /what/ added it, but something did. With noauto, just like the other reported case. It shouldn't matter how rare it is though. A general announcement won't hurt anyone. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
MF == Mike Frysinger vap...@gentoo.org writes: MF this should impact very few (if any) MF users, so i don't think a news item makes sense. It will impact everyone who has /dev/pts in fstab(5). I doubt that any say gid=5. I don't remember why this box has it in fstab; it looks like it always did. The backup of my (now dead) laptop also has such an entry. The rcs log for that one shows that it got added in late '03, and not manually. I imagine therefore that it is not all that uncommon. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Last rites: app-text/cuneiform
MC == Markos Chandras hwoar...@gentoo.org writes: MC # Removal in 30 days MC app-text/cuneiform That one should not go. There are not enough quality ocr engines available, Gentoo needs to keep all of them. And a couple of bugs is never a sufficient reason to kick a package. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Last rites: app-text/cuneiform
MC == Markos Chandras hwoar...@gentoo.org writes: MC Please do not reply to gentoo-dev-announce. I didn't. I explicitly replied to the message in gentoo-dev. If doing that resulted in a cc to announce that means there was no reply-to header in the message posted to dev. Had there been a reply-to header gnus would have asked me whether to accept it. MC The package is going away unless someone fixes the bugs and properly MC maintains the package Again, that is an irresponsible mistake. It is better to just leave it as is than to kick it. Dropping important packages can only harm the community and is never welcome. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Last rites: app-text/cuneiform
RF == Rich Freeman ri...@gentoo.org writes: RF Is this package working in the typical case? That is, when you aren't RF intentionally trying to buffer-overflow it or otherwise break it? I haven't found an image file which causes it to crash. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-portage-dev] [PATCH v2] prepman: do not compress files =128 bytes
MF == Mike Frysinger vap...@gentoo.org writes: MF the subject does say prepman ;) I guess that blended in with the [] sections; all I remember noticing in the subject was the text after the last colon -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] How is group usb used in your system, if at all?
SS == Samuli Suominen ssuomi...@gentoo.org writes:
SS # find /dev -group usb -exec ls -l {} +
SS results nothing on every system tested
:; find /dev -group usb -ls
93030 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/009/001
93000 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/008/001
92970 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/007/001
92940 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/006/001
92910 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/005/001
90430 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/004/006
1080 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/004/005
90380 crw-rw-r-- 1 root usb Mar 5 11:24
/dev/bus/usb/004/003
90340 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/004/002
92880 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/004/001
92850 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/003/001
90330 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/002/002
92820 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/002/001
92790 crw-rw-r-- 1 root usb Mar 15 23:13
/dev/bus/usb/001/001
I also noticed that vdr added itself to that group.
:; egrep ^vdr /etc/passwd
vdr:x:113:1013:added by portage for gentoo-vdr-scripts:/var/vdr:/bin/bash
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: Gentoo GPG key policies
RHJ == Robin H Johnson robb...@gentoo.org writes: RHJ 2. Root key type of RSA, 4096 bits rsa 4k provides no real benefits over rsa 3k here; it is just slower for everyone, signing or verifying. Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384 and rsa 15k for aes256/sha512. If 3k provides comparable security to aes128 and sha256, and one needs to more than double the rsa key length to compare with aes192 and sha384, there is no reason to bother with rsa 4k. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] On the good usage of subslots
AB == Alexis Ballier aball...@gentoo.org writes: AB Well, if we have to advertise the usage of this option that basically AB disables subslot rebuilds, it only means we are doing something AB seriously wrong with subslots :=) So far, I've found the sub slots to be more of a pain in the ass than helpful. They get in the way of things like automated 'emerge --sync;emerge -upvDN', since portage craps out complaining about the subslots rather than showing the list of what need to be built. Perhaps that is just an implementation detail to be worked out, but for now they haven't done anything helpful here. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
PR # Pacho Ramos pa...@gentoo.org (10 Feb 2013) PR # Fails with gcc-4.7, crashes (#301946, #312073), problems with PR # boost (#319921), problems with python-2.7 (#338826), really old PR # version in the tree, people should move to sci overlay one (#424659). PR # Removal in a month. PR sci-visualization/paraview Or, more responsibly, the version in the sci overlay should move to the main tree. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
AKH == Andreas K Huettel dilfri...@gentoo.org writes: AKH To be honest I did not really see the necessity since the big red AKH warning exactly tells you what to do (and even which profile to AKH pick, which would be more complicated in a news item). But it doesn't tell one why the change was made, what differences to expect once it is done. What does: diff -uNr profiles/default/linux/amd64/10.0/eapi profiles/default/linux/amd64/13.0/eapi --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 -0400 +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 -0500 @@ -1 +1 @@ -2 +5 actually *do* to one's system? A useful news item would have explained what was changing, why it was done, and what to expect once one makes the change. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: News item
Since I just sent a why to post a news item note, that exactly covers things. Thanks! -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] last rites: games-arcade/xboing
AKH == Andreas K Huettel dilfri...@gentoo.org writes: AKH Well, except for the fact that it AKH 1) did not start (immediate fortify crash because the string buffer was too AKH short to hold the font name for a debug output) AKH 2) was unplayably fast (imagine what you get when you pass milliseconds to AKH usleep...) AKH So in this case the mask was quite adequate. Works here. I tested before posting. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] last rites: games-arcade/xboing
MS == Michael Sterrett mr_bon...@gentoo.org writes: MS # Old, dead upstream, slightly broken and uses imake. Nothing wrong with old. The web page is still there. It works reasonably well and THERE IS NOTHING WRONG WITH IMAKE. MS # Masked for removal on 20130302 MS games-arcade/xboing One should just let it be. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: Please stop useless removals
AW == Alec Warner anta...@gentoo.org writes: AW If folks do not want to maintain it anymore, then it will be removed. That is about as harmful an attitude as possible. If you don't personally care about a package just leave it alone! And if you want more maintainers, then drop the schoolkid nonsense to join the club. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] USE flags dri, cups, pppd
AWS == Aaron W Swenson titanof...@gentoo.org writes:
AWS That's why there's a base desktop profile and desktop/{gnome,kde}
AWS profiles.
/usr/portage/profiles/targets/desktop/make.defaults still has too much
crap for a real base profile for a box which (might) run X or wl.
Also, I suspect the things dri brings in (or that one would presume dri
to bring in) are needed for gpGPU and the like.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] USE flags dri, cups, pppd
This question only matters if you expect there to be non-desktops where there are packages installed that IUSE dri. I'd note that there is no correlation between the use of the desktop profiles and the use of an X11 or wayland server on any given box. The (gui) world is much more than gnome+kde. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes: CM Which is a good thing, since it will force people to stop making CM incorrect assumptions. No, its a bad thing because it makes it harder to grep out the non category dirs. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
BdG == Ben de Groot yng...@gentoo.org writes: BdG After some initial bikeshedding we came to the conclusion that naming BdG the category simply qt is the most elegant solution. We will then BdG also be dropping the qt- prefix in package names. This means BdG x11-libs/qt-core will be moved to qt/core, and so on. Please don't. Every current category matches /^[a-z]+-[a-z]+$/. With the possible exception of adding moving from [a-z]+ to [a-z0-9]+, that shoud remain. Only non-category directories under /usr/portage should lack a hyphen. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes: CM That's what's known as doing it wrong. You should be querying your CM package mangler for a list of categories, not doing an 'ls'. ls(1) isn't relevant. find(1) is. grep(1) is. There are others. Using the 'package managers' isn't very helpful. They generally do everything poorly. And usually **s*l*o*w*l*y**, if they compile at all. I can't even remember every time I've needed to use a regex, glob or other pattern match where the fact that the real categories had a dash made things easier and faster. Its been way too many years to change that now. Much better to standardize it as m/[a-z0-9]+-[a-z0-9]+/. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Cleaning tree of outdated packages
WH == William Hubbs willi...@gentoo.org writes: WH For example, glibc-2.9 and gcc-2.95. I think that if we are going to WH keep things this old in the tree we need a good reason for them. gcc-2.95 is still the current version for some non-mainstream dist+ architecture tuples. The ability to test whether one's code works on 2.95 has value. Of course, if it will not compile on mainstream systems, that is and entirely different story. The older compiles also do support some targets which since have been dropped, should one want to cross-compile for such systems one would require the archaic compiler. In short, as long as it doesn't require *too* much effort, old versions of slotted packages shouldn't be dropped *only* because they are old. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
The percentage of bogosity is nicely small, but there are a couple in there which shouldn't be dropped. # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Lots of bug report, use version from science overlay as pointed # in bug #339364#c3 . Removal in a month sci-mathematics/scilab The version in portage (scilab 4) works fine here; I've never gotten scilab 5 (the version in sci) to build. So that should remain. Much worse, however, is this insanity: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fail to start due missing fonts (bugs 395353, 402713, 429234). # Removal in a month. x11-misc/bbdate x11-misc/bbweather x11-misc/bbsload So, you advocate removing x11 client packages because, oooh, they require *server-side fonts*. AGH! Seriously, it is bug-reports 395353 and 402713 which are flawed, not the packages. And 429234, requesting stabilization, should get it. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] Dropping slotted boost
DEP == Diego Elio Pettenò flamee...@flameeyes.eu writes: DEP Among other things, with each GCC/GLIBC update all but a handful of DEP slots are kept working; in this case I think most if not all 1.50 DEP are broken. One datapoint: Since protage failed to preserve icu-49 for me, upon which boost depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none of the earlier versions did. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes: CM This doesn't work if we have, for example, foo:1 and foo:2 both using CM the same SCM repository, but different branches. The subversion eclass already handles that; it stores in $distfiles/$P/$branch. The cvs eclass also could do so. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] inittab with SIGPWR support
DEP == Diego Elio Pettenò flamee...@flameeyes.eu writes: DEP They _are_ deprecated after all. Where is that documented? DEP man inittab Not here. (/usr/share/man/man5/inittab.5.bz2 from sys-apps/sysvinit-2.88-r3.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] inittab with SIGPWR support
DEP == Diego Elio Pettenò flamee...@flameeyes.eu writes: DEP They _are_ deprecated after all. Where is that documented? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] inittab with SIGPWR support
DEP == Diego Elio Pettenò flamee...@flameeyes.eu writes: DEP To have a better support for Gentoo lxc guests, it would be nice if our DEP default inittab contained a line for handling SIGPWR sent to PID 1 to DEP shut the system down. I'm embarrased to have to say that I hadn't noticed that gentoo lacked power lines in its inittab(5). Please cover the set, not just powerfail. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] metadata/md5-cache
ZM == Zac Medico zmed...@gentoo.org writes: Thanks for the quick reply and the reference to the bz. ZM We had a bug about that [1] when we first deployed md5-cache, but it's ZM supposed to have been fixed. It is not fixed. The behavior has not changed in any way since md5-cache was added. ZM [1] https://bugs.gentoo.org/show_bug.cgi?id=410505 I've added a please re-open note to that bug. Thanks for working on it. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
WH == William Hubbs willi...@gentoo.org writes: WH My big complaint about merge commits is if you do a git show hash on WH a merge commit, you get nothing, With current git and proper merge logs you get useful info. The headers contain the hashes, so you can get the list of commits pulled by that merge. The signed tag log is show. And merge conflicts also are shown. Based on the hashes in the Merge: header, you can use git log to see the individual commits or git diff to see the whole picture at once. Linus’ current tip is a good example: cd .../linux git show 1193755ac632 So, Gentoo shouldn't prohibit merges. Instead, it should demand that all merges be of signed tags. The plan includes signed commits anyway, so signed tags for pulls will be fully supported by any version of git which might be used. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new global USE flag: jit
AR == Alexandre Rostovtsev tetrom...@gentoo.org writes: AR www-servers/nginx:pcre-jit - Enable JIT for pcre This one also should remain un-unified. There may be other, unrelated jit options in the future, whether affecting nginx itself or potential PDEPENDs or ???. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
My USB drive reports 0. WD You're right. Same for me. Thanks for pointing it out. The removable flag specifies whether the drive has removable media; before flash drives only things like floppy, optical, zip, etc drives had removable==1. It also would be accurate for flash card readers. If thumb drives specify it, then they lie. The flag is read from the drive's metadata. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
OC == Olivier Crête tes...@gentoo.org writes: OC And I'm sure it works fine with udev? It automounts when plugged in, if that is what you mean. (In fact each partition does; the one in fstab(5) where it should and the one not in fstab in a mount point based on its label.) And the dev files get removed when the drive is unplugged. (unplugged here means either the usb cable or the power cable.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
MS == Marc Schiffbauer msch...@gentoo.org writes: MS IIRC usr = unified system resources (not an abbrev. for user) Nope. It is in fact for user. Before sysv created /home, bsd used /usr for user dirs. /usr/bin et all came later. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: About gcc-4.6 unmasking
B == Ben yng...@gmail.com writes: stabilizing Grub 2 ASAP is the sanest thing you can do, since even though it's also beta software, it's at least maintained by upstream. B I would hesitate to say it's the *sanest* thing to do, but we should at B least get it into ~arch and make sure our documentation is up to date. Actually, given grub2's crazy config, the real upgrade from grub1 is sys-boot/syslinux's extlinux(1). The configuration and operation styles are much more comfortable for those who are familiar with grub1. It would make a better default for x86/amd64 than grub1 or grub2. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
KM == Kerin Millar kerfra...@gmail.com writes: KM Arch also used to define LC_COLLATE=C by default, probably to KM mitigate unpredictable behaviour in some applications, but have KM since dropped this additional variable so they must have deemed it KM no longer necessary. Without LC_COLLATE=C things like [a-z]* gets a false=positive match on files like Makefile. I recently noticed a bug on b.g.o where the ebuild has something like doc/[A-Z]* expecting that it will not match doc/some_lowercase_subdir. The bug, of course, is that glibc fraudulently defaults the latin, greek and cyrillic locales to case-insensitive. The real fix is to have root be C.UTF-8. Which differs from C only in that the charset is utf-8. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] So now that we have --quiet-build as default, can we talk about a forced LC_ALL=C again?
As someone who leaves root w/o LANG, I would note that there are a few packages which cannot build unless LANG is set to a UTF-8 locale. What we really need is C.UTF-8 and/or POSIX.UTF-8, and to force *that* in emerge(1), ebuild(1), etc. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation
MT == Matt Turner matts...@gentoo.org writes: MT Is that a problem with the ABI, or just that gcc-4.6 is more strict? MT I think it's the latter. The failure occurs at the linking stage, not the compiling stage. Ie, ln(1) cannot find some of the symbols it needs if the .so was compiled with 4.5 and the .o files with 4.6. Which looks like an ABI issue, yes? Again, though, only for some libs. And I do not remember which. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation
SV == Sven Vermeulen sw...@gentoo.org writes: SV - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds SV from that version onwards should not be needed That is not generally true. I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things outside of portage. I still run into compilation errors with C++ which go away if I compile said code with 4.5. GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-portage-dev] GLEP59: Manifest2 hash types implementation
If you are going to update the hash code, you also should parallelize the calculation. Ie: call the initialization function of hash loop: read a block of the file mix it into each hash in turn end loop: finalize each hash It is silly and, for large DIST files, slow to read(2) the file n times when it is only needed once. To be clear, I'm not suggesting doing each hash in its own thread. Just using their lower-level APIs avoid read(2)ing through the file n times. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] fhs and multilib question
WH == William Hubbs willi...@gentoo.org writes: WH Here is what I've found in fhs [2]. [ the fhs's nonsense about lib vs lib32 vs lib64 ] WH If there is no opposition, what would it take for us to do this? Please do not break the amd64 status quo; lib - lib64 is the correct thing to do for both existing and new installs. The fhs fails to acknowledge the fact that the 64bit abi on amd64 is the native abi, and the 32bit is just a legacy compatibility. In reality amd64 should be treated exactly like ia64. The fhs got it wrong only due to an historical accident; (some at) amd was/were initially concerned that w/o harping on the ia32 compatibility as amd64's primary feature that they would loose sales. There might have been some reason to that argument at first -- at least for designed-to-be-out-of-date dists like rhel. But once 64 bit became mainstream and 64 bit dists hit the streets that old argument lost all of its value. Arguably, it should be lib64 pointing to lib, but lib pointing to lib64 works and can make some logic easier, so it should remain as is. Please ignore the fhs nonsense and leave it as it is. Thank you. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
Your idea is a step in the right direction, but the ideal config would have a top level portage.git with sub-modules for each category, as well as for eclass, licenses, profiles and scripts. Each category.git should have sub-modules for each package therein. Within the profiles.git it *might* be reasonable for each directory in arch/ also to be a sub-modules. Or not. That should be dicussed. And the bureaucracy should be minimal. Adding, changing or removing a submodule from its parent repo should only require a call for consensus among the devs, and not be pushed through a small set of devs on some given team. It may also be useful for the process which generates metadata/ to push out to a repo, too, just before syncing out to the rsync mirrors. Having each package in its own repo is a great idea. But a simple recursive git pull to update the whole thing is highly desireable. Git submodules fit the bill perfectly. This would require re-doing the cvs→git conversion, but it’d be worth it. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC Remove USE=fortran in default profile
j == justin j...@gentoo.org writes: j 1. leave [the fortran USE flag] as it is as global USE enabled. This is the best option for the vast majority of users. There are just too many important and useful apps which (rely on libraries which)* include fortran code. The few cases where it is not a benefit can add -fortran to their /etc/make.conf or profile-specific make.defaults files. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] rfc: use of the /run directory
WH == William Hubbs willi...@gentoo.org writes: WH Once /run is in place, WH /var/run will be a symbolic link to /run and /var/lock will WH be a symbolic link to /run/lock. There are files which need to be in /var/lock and which should survive a reboot, so it is not a good idea to make /var/lock a symlink to /run/lock. (And I don't just mean .keep files.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] rfc: use of the /run directory
MC == Markos Chandras hwoar...@gentoo.org writes: MC Can you please provide some examples that require /var/lock to MC survive a reboot? Not everything is part of the distribution. The one which first comes to mind are lock files placed to prevent certain cron-initiated jobs from running right after a reboot. Or locks preventing certain daemons from accepting connections. Such locks often are used to protect net bandwidth when it is needed for real-time use. A reboot of some random box on the lan should not break such locks. And /var/lock is the standard place to put and look for lock files. Got to run; can't contiue to write right now -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Camellia?
PC == Panagiotis Christopoulos pchr...@gentoo.org writes: PC Please, can you continue this somewhere more privately? I wouldn't PC like it if I were a sysadmin and someone was posting information PC about versions of software of production machines publicly. I hope PC you understand. This isn't private information. Everyone who receives mail from these lists can see what crypto gentoo's outgoing servers use when connecting to one's MXs. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Camellia?
Is there any specific reason why smtp.gentoo and pigeon.gentoo use camellia for their outbound smtp starttls connections? Not complaining or anything. Just curious. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: git-2.eclass final review
TC == Tomáš Chvátal scarab...@gentoo.org writes: TC No need to escape it if it is in . it is parsed as the char itself TC like this. The escaping is for grep(1), not for sh(1). -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: git-2.eclass final review
That looks good (by inspection).
My only concern is the branch deletion in the non-bare update.
First of all, * should be escaped. It seems to work OK with gnu grep,
but it would be better to be explicit. (grep(1) says that only ?+{|()
loose their meta-meaning in basic regexps.)
Second, why delete the other branches at all? I'd rather have a
complete clone. Just the checkout ought to be enough.
Otherwise, cool.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-portage-dev] dodoc creating a symlink to distfiles?
ZM It's a side-effect from this fix which makes dodoc preserve symlinks ZM http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2e334d77e3d1836ab6ba5dfc1700e90f9599d4d3 ZM http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=de9a536f470919651e83ece51923594e8605781b Confirmed working: /usr/share/doc/minisat-2.2.0-r2/MiniSat.pdf --- replaced sym /usr/share/doc/minisat-2.2.0-r2/MiniSat.pdf -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-portage-dev] dodoc creating a symlink to distfiles?
the recently added sci-math/minisat ebuild has this:
dodoc ${DISTDIR}/MiniSat.pdf || die
which results in:
sym /usr/share/doc/minisat-2.2.0-r2/MiniSat.pdf -
/usr/portage/distfiles/MiniSat.pdf 1302537422
Is that a portage issue or an issue with the ebuild?
My portage is a few days old; I last merged commit 1d6e6b2fe3b01 from 27 March.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Please enhance your USE descriptions!
j == justin j...@gentoo.org writes: j In my opinion some thing like j Enables foo intergration j or j Enables support for foo j if it isn't totally clear what foo is Even preferring $C/$PN where $PN is currently used would help, since it makes it clear that the foo is a package. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: git-2.eclass final review
DB == Donnie Berkholz dberkh...@gentoo.org writes: JC Or better yet, git clone. DB This could work well with --shared; even worked for me on separate DB partitions. Yes, I did mean »git clone -l -s«. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: git-2.eclass final review
MF == Mike Frysinger vap...@gentoo.org writes: MF ideally, the git eclass should be creating bare checkouts only in its MF store dir, in which case it could use `git archive | tar` to move MF things over ... Or better yet, git clone. Most builds from vcs work best when they know that they are building from vcs. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: git-2.eclass final review
TC == Tomáš Chvátal scarab...@gentoo.org writes: TC I explained multiple times already why bare checkouts are not TC working in our case. Wait a minute. Not using bare clones in DISTDIR is completely unacceptable here. It is bad enough to have to use non-bare for repos which have submodules. Doing so for all is b0rked. TC I don't get why you guys keep repeating it like in the loop. I didn't notice that bug until you just pointed it out. Nor did I see any of the explanations you mention above. TC (I also asked for some implementation where the bare would be possible TC with submodules stored in distdir, yet nobody said it is possible) TC So live with it. I cannot. It makes the eclass useless. I have almost 2 gigs of bare repo in distdirs/git-src. A forced re-download of all of that is just not possible! The existing distdir clones *MUST* continue to work. My applogies for not having looked for this kind of breakage in the new eclass before now. The current git eclass finally got the submodules- vs-normal stuff worked out some time ago; the possibility of going backwards never occurred to me ☹ As someone who makes heavy use of live ebuilds, someone who will be directly and severely affected by such a change, I have to beg you to keep the current logic for submodule-less repos. P.S. The kind of clone used in distdir is irrelevant to the fact that git-clone should be used to populate $S. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
MG == Mike Gilbert floppymas...@gmail.com writes: MG Chromium tarballs are actually around 140 MB. It would be MG interesting to see if we can trim that tarball down. Woops. Misremembered. It is qt that is over 200 MB. On the plus side it is going down. Chromium 5 was ~160 MB. MG For comparison, Firefox weighs in at about 50 MB. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
PH == Paweł Hajdan, phajdan...@gentoo.org writes: PH That's the chromium-bin, really. The difference is that chromium has PH more deps and takes more time to compile than grub. Also, it has much PH more frequent releases, and almost every stable release is a security PH update. And every one of those chromium releases is another 200 Meg download. Or is that yet another? Still yet another? -JimC (who still prefers the src) -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
UM == Ulrich Mueller u...@gentoo.org writes: JC Unless, of course, a patch is added which makes «set term pdf» an JC alias for «set term cairopdf». UM Upstream has wisely named the terminal pdfcairo (not cairopdf). UM Therefore, gnuplot's autocompletion will do its job, without any UM additional patch. I should've remembered that when I replied. [SIGH] And it looks like pdfcairo alread is sufficiently compatible with pdf. So no objections here to the change you already pushed. ☺ -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
FR == Francesco R viv...@gmail.com writes: FR Last time (many moons ago) I've checked cairo did not generated pdf FR it did generated raster images and wrapped them in a thin pdf layer. FR pdflib is generating vector pdf which is a different thing. Cairo will fall back to an image for anything which cannot be described by whichever output driver one uses. Transparency will cause that when generating PostScript, for instance, because PostScript does not support transparency. But there are few—if any—ops which cairo supports which are not also supported by pdf. Gnuplot’s cairopdf terminal generates vector output. One might argue that it is not optimal, but only because it uses line segments rather than cubic curves to approximate graphs. (Ie, it uses cairo’s lineto rather than curveto functions.) But so do gnuplot’s native terminals (I tested postscript and svg.) That is just how gnuplot draws. I’d still keep the pdf USE flag with its current meaning; users may have existing gnuplot scripts which use gnuplot’s pdf terminal and/or apps which generate such scripts. Unless, of course, a patch is added which makes «set term pdf» an alias for «set term cairopdf». -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: Re: Downgrading glibc?
MH == Michael Haubenwallner ha...@gentoo.org writes: MH I've heard a colleague of mine debugged for 50(!) hours after moving MH some quite old application to some recent Linux before he replaced a MH memcpy by memmove, so this did ring some bells. MH However, now he said this was on Ubuntu 10.04.1 LTS, having MH glibc-2.11, so this might have been unrelated indeed. Check the archives of the glibc lists, as well as its bug db. There has been quite a bit of discussion there on that issue. It was added for sse3 some time ago; I beleive it was Intel engineers who contributed it for sse3, showing that it was inedeed faster on their chips to start at the high point and decrement the counter rather than starting at the low point and incrementing. The discussion in their lists does a better job of documenting the issue. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Please review: updates for bzr.eclass
UM == Ulrich Mueller u...@gentoo.org writes: but please mv(1) old repos rather than rm(1)ing them; UM Is the following better? UM https://overlays.gentoo.org/proj/emacs/changeset?reponame=new=1609%40emacs-overlay%2Feclass%2Fbzr.eclassold=1608%40emacs-overlay%2Feclass%2Fbzr.eclass That looks perfect. Thanks! -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Please review: updates for bzr.eclass
UM == Ulrich Mueller u...@gentoo.org writes:
UM 1) initial branch with bzr branch --no-tree,
UM 2) subsequent updates with bzr pull,
UM 3) export to ${WORKDIR} with bzr export.
I applaud those changes, but please mv(1) old repos rather than rm(1)ing
them; bandwidth is often more of a premium than storage and a manual
cleanup is better than a magic behind-the-back permanent deletion. This
follows the same principles as portage does in $DISTFILES.
Thank you.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
