Re: [gentoo-dev] Global useflags zeroconf and avahi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kill zeroconf and use "dnssd", "upnp", "ssdp". Problem solved? On 01/04/13 06:43 PM, Andreas K. Huettel wrote: > Am Dienstag, 2. April 2013, 00:27:59 schrieb Chí-Thanh Christopher > Nguyễn: >>> I would like to suggest unifying use-flag usage, and use >>> "zeroconf" anywhere. >> >> Sounds good. Do you think the same should apply to >> non-mDNS/DNS-SD based zeroconf like UPnP/SSDP? > > No idea to be honest... :| opinions? > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRWkbRAAoJEJJZfKWYZ3eUmOgP/iUW6ubUy79R/nw92i7HtvR7 g84nyfOwQ5dw2vr0WguJCxrgipzAEdk4NjVQlLk9lUeEOnz3nvvTdxQYVwL1DAup pF0qE6Vc1tBznmaYwdBL6kA10FbSq+lswxhn7xiK6rIj4HoJmN7m2FQ26QBEv5wq 5TvTAaVdFa+RdxSttoq2WrP+pSOUzJA2PLRdRuIOgqBkrfHo1glEEY9wYyOw9eOr RNwFg0ifhjTwgve4tCR5Fmp5oaRipm1xvN8+ksctY8oB067uARGISYdtUz0siV3C j/O/GTkXY6BsVKR7x+TQ9H0S3Snt+BubYSk8u9Dnx+tKMwBH0HlEMwEdLUZuUlgs MjSB5k8105UBX2DZOSUBcEKELda5U1yMTQm4oVB2oJFpeSKDhRvF9g7nwATZL4FR XZvXAjLI7jtbVvhAWXQXSMSRoCEGZ+iCDGhjMoQKJf8uIrbPi8NuQ7d9vFxXKaMP ZbqFDR/8yG/E7yQR+GCg5VW3svPEfiDaRcMLE/XrUYtteEy+WaNd4VFio4abBfYY 2G//Lr+vZCMbA/zN9nY/UGmwK/5D/dYfCfIg6jO5JGQQyf7bIWXI4z9dDXaq0CjO SoIo8gFylhVcx4bFC2lAze7dLsgovJynVv+Ke/3q+VCENPUphLNGPTBBFQGeEh1g PkV0piWKafSJJ+d43y4T =WtVK -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 06/04/13 03:02 PM, "Paweł Hajdan, Jr." wrote: > Are there any other formats than unified and context diff? If not, it'd > be like another "for indoor or outdoor use only" or "home or office use" > - i.e. no need to explicitly list all possible options. From the man page: > -c, -C NUM, --context[=NUM] > output NUM (default 3) lines of copied context > > -u, -U NUM, --unified[=NUM] > output NUM (default 3) lines of unified context > > -e, --ed > output an ed script > > -n, --rcs > output an RCS format diff > > -y, --side-by-side > output in two columns Plus the default. On 06/04/13 03:02 PM, "Paweł Hajdan, Jr." wrote: > How about having a one guessing and one non-guessing variant of epatch, > and encouraging the non-guessing one? User1: how do i put a patch in an ebuild User2: use epatch_guesslevel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On 07/04/13 03:36 PM, William Hubbs wrote: > According to Gentoo policy, the support for migration from baselayout-1 > to baselayout-2 could end on 28 Jun 2012, a year after OpenRc became > stable. "could end" sounds a bit awkward. Try "was slated to end" or perhaps "could have ended". Be more consistent: it's either "OpenRC", "OpenRc" (?) or "openrc". signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
Notably, NetworkManager generates old-style net files.
On 07/04/13 04:13 PM, Roy Bamford wrote:
> On 2013.04.07 20:36, William Hubbs wrote:
>> All,
>>
>> We have continued support for baselayout-1 to baselayout-2/OpenRc
>> migration for almost two years now, so I think it is about time we
>> kill
>> this off.
>>
>> Here is the news item I want to send out on 10 Apr.
>>
>> Let me know what you think.
>>
>> Thanks,
>>
>> William
>>
>>
>
>
> If you do not upgrade your systems to openrc-0.11.8 before it leaves
> the tree, you may need to reinstall them.
>
>
> I think you mean
>
> If you do not upgrade your systems to baselayout-2 and openrc-0.11.8
> before openrc-0.11.8 leaves the tree, you may need to reinstall them.
>
> The problem is with baselayout-1 and that's what needs to be updated.
> The "you may need to reinstall them" is a bit over the top. You can
> always pick up the pieces with a liveCD.
>
> Do you need to point out that the old (" ... ") syntax will no longer
> be supported, or do you intend to tolerate the baselayout-1 syntax in
> /etc/conf.d/net and friends a while longer.
>
> A friendly link to the update guide
> http://www.gentoo.org/doc/en/openrc-migration.xml
> may be in order too.
>
> I've seen many users on baselayout-2 with baselayout-1 net files. This
> news item will bypass them.
>
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
Any reason why a pre-commit hook can't be used? Assuming that `git push -f` is never used and that every committer uses it, pre-commit is guaranteed to be executed on all commits that are pushed to the remote. pre-commit can check QA and even automate changelog, so instead of: $ cvs update $ cvs add foo $ echangelog "fixed #xx in foo" $ repoman commit We have: $ git pull $ git add foo $ echangelog "fixed #xx in foo" $ git commit To set up: $ cat > .git/hooks/pre-commit << EOF #!/bin/sh repoman scan EOF Seems simple enough, as long as `repoman scan` runs quickly. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 01/05/13 10:11 PM, Duncan wrote as excerpted: > Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted: > >>> Gentoo is about choice, which to me also means "embrace diversitiy". >>> If you want to keep living in your little world, fine, you can and >>> you're very welcome, but also people who want to have fun with new >>> stuff should get the same respect. >> >> You mean the respect you've shown me in this email, in my "little >> world"? *swoon* >> you hero. I give up trying to be polite in the face of such crap, it's >> more than I can stomach. >> >>> Implementing new stuff also means making things easier, especially in >>> the systemd case. >> >> LMAO. You go girl, strut that nonsense like it means something. > >> No way, sunshine. [...] Or at very least be polite when someone queries >> it. > > Unfortunately, I believe the above demands a public post... > > The above is taking it too far. Please take a bit of time to cool off if > you need it, then apologize, or if you choose not to do that, refrain > from further posts to the list. > Agreed in full. I was prepared to write a response, but this is far more eloquent than anything I could have written. I'll go one step further, and say that this is just an example of the toxic behavior that's been shown in the Gentoo community, in particular this mailing list. This complete lack of any semblance of empathy, even in some *Gentoo developers* is entirely unacceptable. Things like "a bunch of crybabies", "whinging threads", "Avoid spreading FUD", "Really, please stop spreading FUD." (from different people), "Good arguments! As usual I'd say." (sarcasm), "Just to annoy people who have successfully used...", ad nauseam are, at best, not remotely productive. Please, just consider for a second how your words will, or even /might/ be perceived by others. Even better: although it might seem beneath you, consider how you yourself might perceive them, were they to be said from someone else. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect init
On 25/05/13 03:55 PM, Tom Wijsman wrote:
>> > I don't have "init=" set on my machines and it seems to
>> > start /sbin/init. So that should be correct.
> Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
>
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820
> /*
>* We try each of these until one succeeds.
>*
>* The Bourne shell can be used instead of init if we are
>* trying to recover a really broken machine.
>*/
> if (execute_command) {
> if (!run_init_process(execute_command))
> return 0;
> printk(KERN_WARNING "Failed to execute %s. Attempting "
> "defaults...\n", execute_command);
> }
> if (!run_init_process("/sbin/init") ||
> !run_init_process("/etc/init") ||
> !run_init_process("/bin/init") ||
> !run_init_process("/bin/sh"))
> return 0;
>
> panic("No init found. Try passing init= option to kernel. "
> "See Linux Documentation/init.txt for guidance.");
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Usage of dev-utils/ninja in ebuilds
On 25/05/13 09:53 PM, Ryan Hill wrote: > Is NINJAOPTS a variable recognized by ninja or something that would be Gentoo > specific? MAKEOPTS is Gentoo-specific anyways. MAKEFLAGS is parsed by at least GNU make. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
Funny. This is starting to sound familiar... almost like some other software that runs at boot, every boot. Hm, what was the name... Oh, a *bootloader*! Something that *loads* different *boot* configurations! But seriously. For people that can install a bootloader, is there really any "reconfiguration" needed to reboot into a different init system? Just add configuration items as needed for different init systems. We've never automatically added bootloader options if sys-kernel/* is updated; why start now? For those who are on EFI with direct load of Linux, either install a bootloader or use efibootmgr or similar to add entries into the native boot selector (really another bootloader). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On 01/06/13 06:36 AM, Ulrich Mueller wrote: >> On Sat, 1 Jun 2013, Robin H Johnson wrote: > >> Title: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine > > Too long, maximum 44 characters according to GLEP 42. The above will even > be truncated by eselect news. > > Ulrich > echo -n "MySQL/MariaDB dropping PrimeBase (PBXT)" | wc -c 39 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [2&3]/3 API & files
On 16/06/13 03:44 PM, Robin H. Johnson wrote: Image resources: > >> These can be uploaded to the Wiki. >>> > > How can we ensure later that the media files don't get deleted? >> > Deletion is restricted to administrators, mediawiki also keeps old >> > versions around in case someone reuploads a file. >> > To prevent even that, we can restrict editing certain assets to developers. > See my other comment about git-mediawiki maybe, that would satisfy my > needs, just having old versions of the images around as needed (not > admin-deletable). > With modern MediaWiki, it is impossible to permanently remove a page or file without the system administrator (I mean SSH access, not MW sysop) intentionally permitting it or deleting the file archive. https://www.mediawiki.org/wiki/Manual:Image_administration#Undeleting_files https://www.mediawiki.org/wiki/Extension:Oversight https://www.mediawiki.org/wiki/Manual:RevisionDelete signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16/06/13 04:36 PM, Andreas K. Huettel wrote: > Hi Kent, >> >> IMHO, the criteria for being able to edit the wiki should be lower than the >> present requirements on "being a Gentoo Dev". > > Only a small subset of official pages is locked, everything else is free to > edit for anyone who signs himself up. > >> >> I'd be interested in seeing if theres' a way to have "vetted" edits of some >> kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to >> edit a page as they see fit, but the changes are only visible to them until >> they mark their edits "done" where it can be pushed to a moderation queue >> for somebody trusted to check over. >> > > That exists and is used in the German Wikipedia. > (Basically, you get the last "vetted" page by default, with a small message > saying "newer versions available".) > MediaWiki has a builtin "flag" mechanism for revisions, but this serves only to try to get all revisions reviewed by at least one person. "Pending Changes" as implemented by the English Wikipedia uses Extension:FlaggedRevs [0] which, in the most common configuration, allows anyone to edit but hides their changes from the general public until an authorized user approves the changes. [1] [0] https://www.mediawiki.org/wiki/Extension:FlaggedRevs [1] https://en.wikipedia.org/wiki/Wikipedia:Pending_changes signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last time touched bugs by year
On 21/06/13 03:27 PM, Sergey Popov wrote: > 21.06.2013 23:22, Sergey Popov пишет: >> 2) package has dead upstream, does not build with current >> gcc/glibc/binutils/whatever and can not be fixed - bug is closed as >> OBSOLETE. >> > > Of course i am talking about long-standing bugs, that assigned to > maintainer-wanted@. That's why OBSOLETE seems to be a better decision, > but WONTFIX is reasonable too :-) > nobody needs it: OBSOLETE it doesn't work: CANTFIX signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML->Wiki wiki.gentoo.org
(Delayed due to list servers being down)
On 08/07/13 06:48 PM, Alex Xu wrote:
> On 08/07/13 04:02 PM, Sven Vermeulen wrote:
>> On Wed, Jun 26, 2013 at 03:54:47PM +0200, Alex Legler wrote:
>> I keep track of the stuff at [1], an example output can already be found at
>> [2].
>>
>> [1] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki
>> [2] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki/test
>>
>> It would appreciate some feedback - things that do not need to be covered
>> anymore or so (I know our wiki supports some stuff that shouldn't be
>> rendered anymore).
>>
>
>
> I don't really like the default MW table style here; it doesn't really
> look... Gentoo, if you will. I hacked around the CSS a bit and I'd say
> the new look works better. http://i.imgur.com/5eD7FGy.png
>
>
> Another styling-related concern, the post- text is:
>
> All developers can be reached by e-mail using '''nickn...@gentoo.org''' .
>
> It should be:
>
> All developers can be reached by e-mail using
> nickn...@gentoo.org.
>
>
> Also, this output is not correct:
>
> ... join the mailing list at{{Mail|
> gentoo-harde...@lists.gentoo.org}}.
>
> There is a new line after "Mail|". It should be:
>
> ... join the mailing list at {{Mail|gentoo-harde...@lists.gentoo.org}}.
>
>
> should translate to , not '''.
>
>
> output, while a good start, is clearly incorrect. (Ctrl-F
> SELinux subproject resources)
>
>
>
> Other than that, there don't seem to be any major issues. Excellent work!
>
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML->Wiki wiki.gentoo.org
On 09/07/13 08:29 PM, Alex Legler wrote: > On 10.07.2013 01:53, Alex Xu wrote: >>> >>> I don't really like the default MW table style here; it doesn't really >>> look... Gentoo, if you will. I hacked around the CSS a bit and I'd say >>> the new look works better. http://i.imgur.com/5eD7FGy.png >>> > > Oh god no. The days of these tables are numbered. Okay, maybe they're a little excessive, but I still think the color scheme is a little inconsistent. (too much purple at the top of the page, not enough in the actual content.) > > Which brings me to... > > - Developer list: Moves to the sidebar. Not sure how to render that. > Maybe in a comment and people remove that once they have added all the > members? > > - Subproject list: Moves to the sidebar as well. Same treatment as for > the developer list. I'm not quite sure what you mean here. > >>> >>> Another styling-related concern, the post- text is: >>> >>> All developers can be reached by e-mail using '''nickn...@gentoo.org''' . >>> >>> It should be: >>> >>> All developers can be reached by e-mail using >>> nickn...@gentoo.org. >>> > > The line should just be removed altogether. > > On second thought, I agree. Maybe can be changed to show an Email column with mailto: links? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: ChangeLog package.use.force
On 19/07/13 11:46 AM, Michał Górny wrote: > Dnia 2013-07-19, o godz. 16:11:52 > Markos Chandras napisał(a): > >> On 19 July 2013 16:04, Ian Delaney (idella4) wrote: >>> idella4 13/07/19 15:04:28 >>> >>> Modified: ChangeLog package.use.force >>> Log: >>> Add entry to force use flags for pypy-bin >>> >>> Revision ChangesPath >>> 1.565profiles/base/ChangeLog >>> >>> file : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?rev=1.565&view=markup >>> plain: >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?rev=1.565&content-type=text/plain >>> diff : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?r1=1.564&r2=1.565 >>> >>> Index: ChangeLog >>> === >>> RCS file: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v >>> retrieving revision 1.564 >>> retrieving revision 1.565 >>> diff -u -r1.564 -r1.565 >>> --- ChangeLog 17 Jul 2013 15:23:53 - 1.564 >>> +++ ChangeLog 19 Jul 2013 15:04:28 - 1.565 >>> @@ -1,6 +1,10 @@ >>> # ChangeLog for Gentoo base-profile >>> # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 >>> -# $Header: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v 1.564 >>> 2013/07/17 15:23:53 chithanh Exp $ >>> +# $Header: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v 1.565 >>> 2013/07/19 15:04:28 idella4 Exp $ >>> + >>> + 19 Jul 2013; Ian Delaney >>> + package.use.force: >>> + Add flags for new pypy-bin >>> >>>17 Jul 2013; Chí-Thanh Christopher Nguyễn >>>package.use.mask: >>> >>> >>> >>> 1.37 profiles/base/package.use.force >>> >>> file : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?rev=1.37&view=markup >>> plain: >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?rev=1.37&content-type=text/plain >>> diff : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?r1=1.36&r2=1.37 >>> >>> Index: package.use.force >>> === >>> RCS file: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v >>> retrieving revision 1.36 >>> retrieving revision 1.37 >>> diff -u -r1.36 -r1.37 >>> --- package.use.force 9 Jul 2013 17:47:25 - 1.36 >>> +++ package.use.force 19 Jul 2013 15:04:28 - 1.37 >>> @@ -1,6 +1,10 @@ >>> # Copyright 1999-2013 Gentoo Foundation >>> # Distributed under the terms of the GNU General Public License v2 >>> -# $Header: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v 1.36 >>> 2013/07/09 17:47:25 graaff Exp $ >>> +# $Header: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v 1.37 >>> 2013/07/19 15:04:28 idella4 Exp $ >>> + >>> +# Ian Delaney (17 July 2013) >>> +# Selection of IUSE flags for bin build. >>> +dev-python/pypy-bin bzip2 ncurses sqlite ssl xml >>> >>> # Michał Gorny (26 Feb 2013) >>> # Meta-packages which use multilib ebuilds always install development >>> >>> >>> >>> >> >> I don't understand that. Why not use +bzip2 +ncurses +sqlite +ssl +xml >> in the ebuild? > > I guess that's because they are not optional :). > I still don't understand. If they are required to build pypy-bin, why are they USE flags? If they are not required, but build breaks without them, then there should be a bug #. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 21/07/13 02:25 PM, Zac Medico wrote:
> On 07/21/2013 03:53 AM, Pacho Ramos wrote:
>> El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
>>> On Mon, 02 Jul 2012 13:45:26 -0700
>>> Zac Medico wrote:
>>>
On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
> Il 02/07/2012 22:01, Zac Medico ha scritto:
>> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
>>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
Hi,
In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:
Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox (unless usersandbox is also
used).
The rationale for having the separate "usersandbox" setting, to
enable use of sys-apps/sandbox, is that people who enable
userpriv sometimes prefer to have sandbox disabled in order to
slightly improve performance. However, I would recommend to
enable usersandbox by default, for the purpose of logging
sandbox violations.
Note that ebuilds can set RESTRICT="userpriv" if they require
superuser privileges during any of the src_* phases that
userpriv affects.
I've been using FEATURES="userpriv usersandbox" for years, and I
don't remember experiencing any problems because of it, so I
think that it would be reasonable to have it enabled by default.
Objections?
>>> Looks like non important problems arised and, then, these could
>>> probably be enabled by default, no? :)
>> I'm not sure about the best way to handle migration for directories
>> inside $DISTDIR that are used by live ebuilds, since src_unpack
>> will run with different privileges when userpriv is enabled.
> tell the user to chown/remove the files/directories if and when
> needed,
How should we tell them? Elog message, news item, or both?
>>>
>>> I think this deserves a news item anyway.
>>>
> unless there is a very good reason (try) to automate it.
I guess something like this might work in pkg_postinst of the portage
ebuild:
find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage
>>>
>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
>>> chown -R portage:portage {} +
>>>
I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
>>>
>>> This will work only for users who actually keep those in DISTDIR. Some
>>> of them actually redefine E*_STORE_DIR to a more sane location. But
>>> that's probably irrelevant.
>>>
>>
>> Then, is there any other blocker? (apart of the needing of add a news
>> item)
>>
>> Thanks :)
>>
>
> I can't think of anything else. I've filed this bug:
>
> https://bugs.gentoo.org/show_bug.cgi?id=477664
>
userpriv and usersandbox don't work in pypy because os.setgroups isn't
implemented there.
I had a go at it a while back, but the complete and utter lack of any
documentation whatsoever... kinda threw me off.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On 24/07/13 10:33 AM, Alexandre Rostovtsev wrote: > On Wed, 2013-07-24 at 16:17 +0200, Ulrich Mueller wrote: >>> On Wed, 24 Jul 2013, Michał Górny wrote: >> >>> Pacho requested that to be able to warn users in GNOME packages that >>> do not work anymore without systemd. >> >> Why is the host where the package is built required to run systemd? >> Wouldn't a warning at runtime better suit the purpose? > > The purpose of systemd_is_booted() is to provide helpful postinst > messages to users depending on whether or not they are running systemd, > and for the vast majority of users, the machine where the package is > built is the machine where the package will be run. > > Runtime warnings would require non-trivial patching of the packages in > question, so it's not a realistic alternative. > > Those who have separate build hosts are probably sufficiently > technically proficient to understand if the message does not apply to > their case. > > So it is sufficient to add e.g. ewarn_systemd_is_not_booted() (possibly with a better name) to discourage inappropriate use cases? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:37 PM, Peter Stuge wrote: > Mike Pagano wrote: >> Team members working alongside upstream (and downstream) developer Greg k-h >> have decided to no longer request stabilization of the vanilla sources >> kernel. >> Team members and arch teams (understandably) are unable to keep up with the >> 1-2 weekly kernel releases, and therefore will now direct users to always >> run >> the latest vanilla sources > > Maybe it would make sense to automatically stabilize every v-s kernel > right away? > > > //Peter > As has been stated, this implies that Gentoo QA has tested the packages and found them to be reasonably safe for use. Although stable kernels *have* been tested by many people before use, Gentoo QA has *not* (officially) tested them, at least not on every architecture. On a technical level, it's not that hard to put "sys-kernel/vanilla-sources" in your package.accept_keywords. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:49 PM, Peter Stuge wrote: > Alex Xu wrote: >>> Maybe it would make sense to automatically stabilize every v-s kernel >>> right away? >> >> As has been stated, this implies that Gentoo QA has tested the packages >> and found them to be reasonably safe for use. > .. >> Although stable kernels *have* been tested by many people before use, >> Gentoo QA has *not* (officially) tested them, at least not on every >> architecture. > > I don't think that matters. If you don't care too much for Gentoo QA, then you are free to run global ~arch on your system. It works reasonably well (no sarcasm), and almost always, someone has tested most packages on most architectures. At least it's been tested by the programmer and maintainer. But that's how KEYWORDS have always been used in Gentoo, as far as I know. >> On a technical level, it's not that hard to put >> "sys-kernel/vanilla-sources" in your package.accept_keywords. > > But why should Gentoo users have to do that in order to use v-s? So they acknowledge that vanilla-sources has not been officially tested by Gentoo QA. You are free to do the simple procedure once and trust the kernel community to have done adequate testing. > If it is intentional to push g-s onto users then it makes good sense - > but if I were the sys-kernel team I wouldn't bother with g-s at all > and just make v-s as easily available to users as possible.. I can't comment on that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 08:09 AM, Vadim A. Misbakh-Soloviov wrote: > Hi, list! > > Many times somebody post buildlogs — they're translated to user's native > language due to system's /etc/env.d/02locale. > > What about adding "export LC_ALL=POSIX" (or, at least, LC_MESSAGES) to > /etc/portage/bashrc by default (out-of-the-box)? That'll 1) fix > buildlogs issue This doesn't seem like a major problem. Most errors can be easily deciphered, and if they can't, the user can be asked to run "LC_MESSAGES=C emerge". This also introduces a usability problem, in that a user's preference is being overridden. Presumably the user knows that they want their system in a particular language more than we do. > 2) fix some python-related compilation breakages, like > in xen-tools-4.3.0, for example. This is just papering over the actual issue that needs to be fixed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 10:36 AM, Vadim A. Misbakh-Soloviov wrote: > Unfortunately, gentoo.org's archive seems to be broken/frozen, while it > is a bit hard to grep 3party archives to find already discussed topics :-/ > > 27.07.2013 18:31, Jeroen Roovers пишет: >> We've been over this plenty of times in the past. > http://search.gmane.org/?query=lc_all+lc_messages&group=gmane.linux.gentoo.devel&DEFAULTOP=or signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] PYTHON flags grammar? why?
On 28/07/13 05:07 PM, Walter Dnes wrote: > On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote >>> On Sat, 27 Jul 2013, Leho Kraav wrote: >> >>> php5-5 vs python2_7 >>> Why, how did that happen? >> >> Using the hyphen is cleaner, because the underscore is used as the >> separator for USE_EXPAND. >> >> (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 >> variable, python2_7 will also work fine.) > > Out of sheer curiousity, why does make.conf need all 3 of... > > PYTHON_SINGLE_TARGET="python2_7" Because some packages only accept a single version of Python. e.g. Blender, systemd. I think this also applies to the default Python version for packages that install executables. > PYTHON_TARGETS="python2_7" Because the Python ABI [*] requires different libraries to be built for different versions and installed in different places. /usr/lib/python?.? [*] not really a binary interface, but let's call it that > USE_PYTHON="2.7" This is deprecated, AFAIK and used for old packages that do not support PYTHON_TARGETS. (something to do with EAPI or eclass or something like that) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [New eclass] twisted-r1.eclass
On 03/08/13 02:29 PM, Michał Górny wrote:
> Dnia 2013-08-03, o godz. 17:54:42
> Ulrich Mueller napisał(a):
>
>>> On Sat, 3 Aug 2013, Michał Górny wrote:
>>
>>> 2. The eclass comes with a pure bash-3.2 CamelCase converter for
>>> changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant code
>>> can be moved to eutils as portable replacements for bash-4 ${foo^}
>>> and friends.
>>
>>> # obtain octal ASCII code for the first letter.
>>> local ord=$(printf '%o' "'${fl}")
>>>
>>> # check if it's [a-z]. ASCII codes are locale-safe.
>>> if [[ ${ord} -ge 141 && ${ord} -le 172 ]]; then
>>> # now substract 040 to make it upper-case.
>>> # fun fact: in range 0141..0172, decimal '- 40' is fine.
>>> local ord=$(( ${ord} - 40))
>>> # and convert it back to the character.
>>> fl=$(printf '\'${ord})
>>> fi
>>
>> This looks just horrible. You do decimal arithmetic on octal numbers?
>
> Yes. Bash wasn't really happy to do octal arithmetic for me. Yet
> in this particular case, with proper assumptions, decimal arithmetic is
> practically equivalent.
>
# obtain decimal ASCII code for the first letter.
local fl=$(printf '%d' "'${w}")
# check if it's [a-z]. ASCII codes are locale-safe.
if [[ ${ord} -ge 97 && ${ord} -le 122 ]]; then
local ord=$(( ${ord} - 32 ))
# and convert it back to the character.
fl=$(printf '\'${ord})
fi
echo -n "${fl}${w:1}"
Probably var names should be adjusted, I'm not too familiar with bash
locals.
printf '%d' "'twisted" outputs "116" as expected, similar to
printf("%d", *"asdf qwerty") in C.
Tested in Bash 4.2.45.
Now time to sit back and wait for it to break in bash
.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [New eclass] twisted-r1.eclass
On 03/08/13 03:37 PM, Alex Xu wrote:
> On 03/08/13 02:29 PM, Michał Górny wrote:
>> Dnia 2013-08-03, o godz. 17:54:42
>> Ulrich Mueller napisał(a):
>>
>>>>>>>> On Sat, 3 Aug 2013, Michał Górny wrote:
>>>
>>>> 2. The eclass comes with a pure bash-3.2 CamelCase converter for
>>>> changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant code
>>>> can be moved to eutils as portable replacements for bash-4 ${foo^}
>>>> and friends.
>>>
>>>># obtain octal ASCII code for the first letter.
>>>>local ord=$(printf '%o' "'${fl}")
>>>>
>>>># check if it's [a-z]. ASCII codes are locale-safe.
>>>>if [[ ${ord} -ge 141 && ${ord} -le 172 ]]; then
>>>># now substract 040 to make it upper-case.
>>>># fun fact: in range 0141..0172, decimal '- 40' is fine.
>>>>local ord=$(( ${ord} - 40))
>>>># and convert it back to the character.
>>>>fl=$(printf '\'${ord})
>>>>fi
>>>
>>> This looks just horrible. You do decimal arithmetic on octal numbers?
>>
>> Yes. Bash wasn't really happy to do octal arithmetic for me. Yet
>> in this particular case, with proper assumptions, decimal arithmetic is
>> practically equivalent.
>>
>
> # obtain decimal ASCII code for the first letter.
> local fl=$(printf '%d' "'${w}")
>
> # check if it's [a-z]. ASCII codes are locale-safe.
> if [[ ${ord} -ge 97 && ${ord} -le 122 ]]; then
> local ord=$(( ${ord} - 32 ))
> # and convert it back to the character.
> fl=$(printf '\'${ord})
> fi
>
> echo -n "${fl}${w:1}"
>
> Probably var names should be adjusted, I'm not too familiar with bash
> locals.
>
> printf '%d' "'twisted" outputs "116" as expected, similar to
> printf("%d", *"asdf qwerty") in C.
>
> Tested in Bash 4.2.45.
>
> Now time to sit back and wait for it to break in bash
> .
>
I am dumb. Please disregard the previous message.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
Minor grammar/typographical errata: On 04/08/13 12:53 AM, Mike Pagano wrote: > The Gentoo Kernel Team will no longer be providing stable vanilla-sources > kernels. All currently stabilized vanilla-sources versions will be dropped > to ~arch. The Arch teams, via normal requests of the Kernel Team, will > continue to stabilize gentoo-sources kernels upon request. This decision is > based on the facts that upstream is now releasing approximately 1-2 vanilla- try not to wrap vanilla-sources on the hyphen if possible > sources kernels a week. Arch teams, understandable, are unable to keep up with s/understandable/understandably/ > this rate of release. As most vanilla releases contain security fixes, the > user who only runs stable vanilla-sources will consistently be behind and > potentially at risk. For the latest upstream non Gentoo patched vanilla s/non Gentoo patched/non-Gentoo-patched/ or "upstream kernel unpatched by Gentoo" > kernel, we recommend user add 'sys-kernel/vanilla-sources' to their s/user add/adding/;s/their/the/ or similar; "recommend user add" is not grammatically correct > package.accept_keywords file. Gentoo-sources will continue to be a tested and s/Gentoo-sources/gentoo-sources/ > supported version for Gentoo users. s/\. /. /g (or vice versa) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
Further minor grammar/typographical errata: On 04/08/13 11:16 PM, Mike Pagano wrote: > Title: vanilla-sources stabilization policy > Author: Mike Pagano > Content-Type: text/plain > Posted: 2013-08-07 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: sys-kernel/vanilla-sources > > The Gentoo Kernel Team will no longer be providing stable > vanilla-sources kernels. All currently stabilized vanilla-sources > versions will be dropped to ~arch. The Arch teams, via normal requests > of the Kernel Team, will continue to stabilize gentoo-sources kernels > upon request. This decision is based on the facts that upstream is now > releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, > understandably, are unable to keep up with this rate of release. As > most vanilla releases contain security fixes, the user who only runs > stable vanilla-sources will consistently be behind and potentially at > risk. For the latest "upstream kernel unpatched by Gentoo" kernel, we > "upstream kernel unpatched by Gentoo" kernel wat. Possibly intended: > For the latest upstream kernel unpatched by Gentoo > recommend users add 'sys-kernel/vanilla-sources' to their > package.accept_keywords file. gentoo-sources will continue to be a > tested and supported version for Gentoo users. > > > Note: This news item only applies to gentoo-sources and vanilla-sources. > Other kernels currently maintained in portage have their own policies > and procedures in place toda toda? derp. "today" or just remove it. s/\. /. /g or s/\. ([^ ])/. \1/g (consistently use one space between sentences or two) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On 04/08/13 11:29 PM, Mike Pagano wrote: > On Sunday, August 04, 2013 07:24:23 PM Alex Xu wrote: > >> wat. Possibly intended: >>> For the latest upstream kernel unpatched by Gentoo > > Not intended > --- > > > Title: vanilla-sources stabilization policy > Author: Mike Pagano > Content-Type: text/plain > Posted: 2013-08-07 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: sys-kernel/vanilla-sources > > The Gentoo Kernel Team will no longer be providing stable > vanilla-sources kernels. All currently stabilized vanilla-sources > versions will be dropped to ~arch. The Arch teams, via normal requests > of the Kernel Team, will continue to stabilize gentoo-sources kernels > upon request. This decision is based on the facts that upstream is now > releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, > understandably, are unable to keep up with this rate of release. As > most vanilla releases contain security fixes, the user who only runs > stable vanilla-sources will consistently be behind and potentially at > risk. For the latest "upstream kernel unpatched by Gentoo", we still not sure that the quotes are really needed here, but it's not a big issue > recommend users add 'sys-kernel/vanilla-sources' to their > package.accept_keywords file. gentoo-sources will continue to be a > tested and supported version for Gentoo users. > > > Note: This news item only applies to gentoo-sources and vanilla-sources. > Other kernels currently maintained in portage have their own policies > and procedures in place today. > > > LGTM otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 06/08/13 10:02 AM, hasufell wrote: > It seems none of them (except the overview GLEP 57) are implemented yet, > although they are roughly 6-8 years old. > > What is holding it back? Is it just that we don't have a PM > implementation yet or is it some political nonsense and PMS blocking > progress again? > > I am not criticizing the portage team in any way here. I just want to > push for some attention. > > > -- > http://www.gentoo.org/proj/en/glep/glep-0057.html > http://www.gentoo.org/proj/en/glep/glep-0058.html > http://www.gentoo.org/proj/en/glep/glep-0059.html > http://www.gentoo.org/proj/en/glep/glep-0060.html > http://www.gentoo.org/proj/en/glep/glep-0061.html > https://bugs.gentoo.org/show_bug.cgi?id=64258 > http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709 > AFAIK, the status is "unimplemented, and nobody's working on it". I believe that the reason is simply that nobody has done the work yet, not due to bikeshedding. I agree that these should be implemented at a rate faster than the current one (i.e. not at all). (FYI, you spelled "improvements" wrong. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 08/08/13 11:26 AM, Rich Freeman wrote: > Honestly, we're probably getting to the point where we should offer a > choice of init systems in our handbook. It doesn't make sense for > Gnome users to go configuring openrc in the handbook only to throw out > all that work and start over with systemd. The only lingering problem is that bug 373219, after over 2 years, is still not fixed in-tree. "wget https://bugs.gentoo.org/attachment.cgi?id=303775 -O /etc/init.d/functions.sh" should not be part of the handbook. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On 20/08/13 11:42 AM, Ian Stakenvicius wrote: > It's a feature; all features are optional. It's just not going to be > able to be enabled along with FEATURES="distcc" is all. I'm sure we > have other features that collide with one-another too, so i don't see > this being a big issue. FEATURES="nostrip splitdebug" neither makes sense nor works. > ... similarly, though, i wonder if this would cause issues with i.e. > diskless systems or others, that use nfs-mounts for /var/tmp/portage ..? I imagine that that should work fine, since the NFS client is implemented (usually) in the kernel. FUSE mounts *might* be an issue, but I think they should be fine too because the handling process is outside of the sandbox. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Moving more arches to dev profiles
On 21/08/13 12:23 PM, Michael Palimaka wrote: >> Imho the situation is that agos intensive work displaced all the other >> ones, or they at least rely on ago doing the work and loose focus. >> > At one point before Ago came along, stabilisation of Qt was taking so > long we had to start masking reverse dependencies for minor archs, so > please don't blame Ago. I believe the point that xmw was trying to make was that ago is doing *too good* of a job, not too poor of a job. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New license: Adaptec
On 29/08/13 06:29 AM, Tiziano Müller wrote: > I would like to add arcconf (binary to manage aacraid-based controllers) > to the tree, which is protected by a mandatory clickthrough witch the > attached text. > > The license would be named "Adaptec" and added to the NON-FREE license > group. > > Objections? > Yes. 1. The license expressly forbids redistribution, so RESTRICT=mirror is mandatory. RESTRICT=fetch may be required, but I haven't read it that carefully. 2. The "NON-FREE" license group does not exist in the g-x86 tree. I don't think this license falls under any current license group. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 31/08/13 09:00 AM, Gilles Dartiguelongue wrote: >> > And please ensure to remove it in pkg_postrm() when last version >> > of gdk-pixbuf is unmerged. > I am not clear on this last sentence. Could you reformulate it please ? Ensure that the loaders.cache file is removed correctly when all versions of gdk-pixbuf have been removed from the system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 09/09/13 08:29 PM, Gilles Dartiguelongue wrote:
>
> [1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
> [1;32m===[0;0m
> [1;32mRCS file:
> /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
> [1;32mretrieving revision 1.3[0;0m
> [1;32mdiff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild[0;0m
> [1;31m--- gdk-pixbuf-2.28.2.ebuild 3 Sep 2013 21:59:11 -
> 1.3[0;0m
> [1;34m+++ gdk-pixbuf-2.28.2.ebuild 9 Sep 2013 22:28:20 -[0;0m
> [1;35m@@ -67,6 +67,15 @@[0;0m
> [0;0m [0;0m
> [0;0m pkg_preinst() {[0;0m
> [0;0mgnome2_gdk_pixbuf_savelist[0;0m
> [1;34m+[0;0m
> [1;34m+ # Make sure loaders.cache belongs to gdk-pixbuf alone[0;0m
> [1;34m+ local
> cache="usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache"[0;0m
> [1;34m+[0;0m
> [1;34m+ if [[ -e ${ROOT}${cache} ]]; then[0;0m
> [1;34m+ cp "${ROOT}"${cache} "${D}"/${cache} || die[0;0m
> [1;34m+ else[0;0m
> [1;34m+ touch "${D}"/${cache} || die[0;0m
> [1;34m+ fi[0;0m
> [0;0m }[0;0m
> [0;0m [0;0m
> [0;0m pkg_postinst() {[0;0m
Index: gdk-pixbuf-2.28.2.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v
retrieving revision 1.3
diff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild
--- gdk-pixbuf-2.28.2.ebuild3 Sep 2013 21:59:11 - 1.3
+++ gdk-pixbuf-2.28.2.ebuild9 Sep 2013 22:28:20 -
@@ -67,6 +67,15 @@
pkg_preinst() {
gnome2_gdk_pixbuf_savelist
+
+ # Make sure loaders.cache belongs to gdk-pixbuf alone
+ local cache="usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache"
+
+ if [[ -e ${ROOT}${cache} ]]; then
+ cp "${ROOT}"${cache} "${D}"/${cache} || die
+ else
+ touch "${D}"/${cache} || die
+ fi
}
pkg_postinst() {
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
On 06/11/13 08:00 PM, Michael Orlitzky wrote: > On 11/06/2013 02:11 PM, Thomas D. wrote: > >> This is going OT but I cannot leave this statement uncommented, >> because from my knowledge this is wrong/you are hiding important >> information everyone should know about: > > I figure everyone here is smart enough to google "OCSP" before > unchecking the box. This isn't the place to argue that the CA system > is broken, but I will respond to a few points. I figure everyone here is smart enough not to spread knowingly-incorrect propaganda. > >> Yes, there is a known MITM attacks against OCSP, see [4]. But this >> is only possible due to bad default settings: Just change your OCSP >> setting to *require* a valid answer. In Firefox: > >> ... > >> If you are aware about any other know attacks, please share. > > > Replay attacks, mentioned in the RFC (or Google). These could be > mitigated, but no one has bothered. > > > >> Regarding your privacy concerns: No, your OCSP-enabled browser >> won't share the address (URL) with the OCSP responder. Your browser >> will use the site's certificate serial number to ask the OCSP >> responder if the certificate is still valid. Yes, the company who >> is running the OCSP responder is able to log "You [IP, UA...] >> requested status for certificates with the serial number 0x1, 0x2, >> 0x3" and because the OCSP responder needs some basic knowledge >> about the certificates it should provide answers for, the operator >> may know that the certificate with the serial number 0x1 has the >> Common Name (CN) "www.mysecretsite.invalid" and 0x2 was issued for >> "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but >> the operator doesn't know the URL you visited. > > This is a long way of saying "it sends the address of every website > you visit to a third party." Addresses, in the context of web browsing, are commonly understood to mean URLs, which include protocol, name, port, and path. OCSP only sends the "name" portion. Thus, the statement was a long way of saying "you are wrong.". > > >> They are improving OCSP. The next big thing is OCSP stapling [8,9] >> which is now supported by all major browsers and patches are >> available for most web servers. OCSP stapling was developed to save >> the extra round trip to the OCSP responder, but OCSP >> stapling-enabled websites will also "increase" your privacy, >> because you don't longer have to tell the OCSP responder the >> certificate (CN) you want to check. > > That's cool, but it doesn't exist now and won't for years. And as a > visitor you have no way of knowing whether the server supports it (== > your privacy will be kept). DH3, and incorrect. Firefox, Apache, and nginx all support OCSP stapling RIGHT NOW. > >> If you are still really concerned about what OCSP may do to your >> privacy, may I ask if you are also concerned about DNS servers? If >> not, what's the difference between an OCSP responder which you ask >> for a serial number, which can be resolved to a CN and a DNS server >> which you ask for a ... CN? :) > > Only two DNS servers are involved; mine and those of the domain I'm > visiting. Not necessarily. "Your" name server may in fact not be a recursive name server, but delegate some portion to a recursive name server. > >> Also, you are trusting a CA to secure your connections, but you >> don't trust the same CA due to privacy concerns? > > You're conflating two things here. I trust AES to keep my connection > safe. I don't send my data to the CA. You're conflating two things here. If you trust the CA, you trust them not to perform a MitM attack. > >> If you don't trust any CA, we don't have to talk about things like >> OCSP or CRL and revocation... > > Well there we agree. Why would you trust the CAs? You don't know them > personally and you aren't their customer. > > Do you trust the governments of the USA and China? (Hint: you > shouldn't.) If the answer is no, then you don't trust the CA system. > So whether or not you trust them to revoke that authentication is a > moot point. > False dichotomy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On 06/01/14 03:20 PM, Robin H. Johnson wrote: > This is a small feature request, but it will require a modification to > PMS, so I describe it here. > > The present thirdpartymirrors file is unwieldy, and difficult to manage > due to it's format with very long lines. It also doesn't permit easy > comments. Presently commits to it look very ugly, because diffs are > line-based, and we pack a lot into each line. > > I would like to make it a directory instead of a single file, and extend > the internal syntax. I like the idea, but I'm not too sure about the execution. > 1. New location: $PROFILEDIR/thirdpartymirrors/$MIRRORNAME > 1.1. The name of the mirror is now the name of the file. > 1.2. We can have a file extension of .mirrors if somebody would like > that. > 2. New format (for directory-mode): > 2.1. Comments permitted, shell-style. > 2.2. Blank lines ignored > 2.3. One URL per line, optionally prefixed with "-" or "+" > 2.4. For stack repos/overlays: > 2.4.1. No prefix: replace all prior mirrors from masters with new URLS in > this file. > 2.4.2. "-" prefix: remove this URL from the list from masters. > 2.4.2. "+" prefix: append this URL to the list from masters. So if *any* line doesn't have a prefix, then *everything* gets overwritten? What about the prior mirrors listed in the file? There needs to be some mechanism for specifying this, but I don't think this is it. Perhaps a header with a special line? > 3. New format (for file-mode): > 3.1. This is for cases where thirdpartymirrors is still a file. > 3.2. The first token on a line remains the name of the mirror. > 3.3. Each subsequent token may be prefixed with "+" or "-", and impacts > prior lines/masters. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On 08/01/14 10:11 AM, Jeroen Roovers wrote: > On Tue, 7 Jan 2014 21:12:59 + > "Robin H. Johnson" wrote: > >> I was also asked by a user to make it possible to adjust the priority >> of some mirror URLs, instead of only random choice. > > While we are at it, we could add keywords for (global) regions, so > that I can set portage to look for a European mirror and portage will > avoid contacting a distant mirror in Asia or America. > > It's probably worth it in the long run to do a little more here than > have users simply express priorities for specific mirrors. > > We could probably set up the path structure like this: > > profiles/thirdpartymirrors/gnu/Europe > > and add a blacklist/whitelist/priority structure > in /etc/portage/profiles/thirdpartymirrors, maybe? > > Portage might even use the local system's timezone to determine what > mirror set to use. > Eww. Geographically-close files should be made available through GENTOO_MIRRORS and the regular distfiles system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas
On 17/01/14 08:08 PM, hero...@gentoo.org wrote: > Michał Górny writes: > >> However, it may be actually beneficial to provide other durations, like >> weekly deltas. In my tests, the daily updates for this week summed up >> to almost 50M while the weekly was barely 20M. > > Is there a way to merge the deltas without the original squashfs? Uh... what? How would that work? > how fast is the delta generation? Very. > It could be done on the server side on the fly and cached. Too much work. > Or we provide a set of 16,8,4,2,1 day deltas, then > > 16d: 1 piece needed > 8d: 2 needed > 4d: 4 needed > 2d: 8 needed > 1d: 16 needed > > The total of 31 pieces will cover a month (31 days) with at most 5 > deltas to be downloaded. > > e.g. If the system is 19 days old, then we download a 1d, 2d, and 16d. > This doesn't really help. Consider that deltas require both a *start* and *end*. It's not as simple as adding it all up, since you would need a 19-3d, then 3-1d, then 1-0d. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: overlays.gentoo.org restoration & post-mortem
On 18/01/14 05:57 AM, Martin Vaeth wrote: > Robin H. Johnson wrote: >> >> FYI: The following repos contained dangling commits/tags/blobs >> [...] you are encouraged to push again [...] >> user/mv.git (+blobs) > > I cannot imagine that the suggested "git push" removed orphaned blobs: > AFAIK it is not possible to execute commands like "git prune", > "git gc --aggressive", or "git repack -a -d" remotely. > Perhaps such things should run as a cron job? > > From what I know, dangling commits are part of the git workflow if one rewrites history. If you push A -> B -> C, then reset --hard to B, then push, C will be dangling on the remote and will not be cleaned until git gc is automatically run on the remote, controlled by the gc.auto config variable (on by default). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few packages up for grabs
On 21/01/14 10:54 PM, Mike Gilbert wrote: > x11-misc/x11vnc I can proxy this if nobody wants. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dropping redundant stable keywords
On 28/01/14 11:33 AM, "Paweł Hajdan, Jr." wrote: > Here's a proposal that may address concerns from the long "rfc: > revisiting our stabilization policy" thread. > > It seems at least one of the problems is that with old ebuilds being > stable on slow arches but not the more recent ebuilds, it is a > maintenance burden to keep supporting the old ebuilds even on fast > arches where it's still stable. > > Why not allow maintainers to drop redundant stable and even ~arch > keywords from their packages? > > Then these old ebuilds will stay with _only_ slow arch keywords. If they > were working back then, they will continue to work now, since there are > not that many changes to break things as opposed to faster-moving arches. > > What do you think? Please let me know if I should clarify this. > > Paweł > I thought there was a general consensus that only the latest stable on a given arch is considered actually-stable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Catalyst news item
On 29/01/14 10:36 PM, Jorge Manuel B. S. Vicetto wrote: > On Wed, 29 Jan 2014, Matt Turner wrote: > >> On Wed, Jan 29, 2014 at 7:14 PM, Jorge Manuel B. S. Vicetto >> wrote: >>> +Display-If-Installed: dev-util/catalyst >> >> Display-If-Installed: >=dev-util/catalyst- > > Matt, > > my plan was to show this to anyone using catalyst. I believe this news > item is relevant and interesting for anyone using catalyst, but if > others disagree, I can restrict it to only those using catalyst-. > > Regards, > > Jorge Manuel B. S. Vicetto > Gentoo Developer > If you insist on showing it to everyone, make it clear that this only affects people on -. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] February 2014 QA policy updates
On 20/02/14 04:46 PM, Mike Gilbert wrote: > On Wed, Feb 19, 2014 at 5:07 PM, Chris Reffett wrote: >> This does not affect sys-boot/grub's USE=multislot, as that >> does not mangle the SLOT value like the others (as I understand it). > > Right. USE=multislot on grub just toggles the renaming of the grub-foo > commands to grub2-foo, in case someone (like me) prefers the upstream > naming convention. There is also a conditional blocker on > sys-boot/grub:0. The SLOT value is always '2'. > > I would be happy to rename the use flag if anyone else has a better name for > it. > All other packages use it to mean "make multiple versions in a single SLOT installable". I think "vanilla" should be used, or possibly a different local USE flag, like "grub2-bins". The argument of wanting this globally is not valid, since multislot should not be set globally either. signature.asc Description: OpenPGP digital signature
Re: AW: Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
On 24/02/14 12:48 PM, Lars Wendler (Polynomial-C) wrote: > This is another good reason why udev should have _never_ been integrated into > systemd! > > In case someone still wants to retain his original systemd INSTALL_MASK, just > use udev ebuilds from poly-c overlay. These ebuilds > > - still install udevd into /sbin where a daemon belongs to. > - disable the crappy new network naming scheme by default > - install the new naming scheme config files into /lib/udev/network/ (version > >=209) > - try to prevent most naming pollution of pure udev with systemd crap. > > I have no plans to stop fixing the annoyances the gentoo udev ebuilds have > since udev was integrated into systemd in the ebuilds from my overlay. > > Ursprüngliche Nachricht Von: Mike Gilbert > Datum:24.02.2014 16:55 (GMT+01:00) > An: Gentoo Dev Betreff: > Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade > On Mon, Feb 24, 2014 at 7:58 AM, Thomas D. wrote: >> Hi, >> >> not everyone is using systemd. On my systems for example, I don't have >> "/lib/systemd/" (INSTALL_MASK). >> >> The current news item draft raises question like "When the 'actual >> configuration' is in /lib/systemd/network/99-default.link... what will >> happen to people without systemd (and a INSTALL_MASK set)?" >> >> Would be nice if the news item and Wiki could handle upgrade path for >> systemd *and* non-systemd users... >> > > You need to remove /lib/systemd/ from INSTALL_MASK. If you don't want > unit files, mask /lib/systemd/system/ instead. > While you're whinging about integration, you're sending bad HTML email. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: git-r3, additional clone types
On 24/02/14 04:00 PM, Michał Górny wrote: > Dnia 2014-02-24, o godz. 21:13:15 > Peter Stuge napisał(a): > >> Michał Górny wrote: >>> Shallow clone >>> - >>> - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), >> >> Hm, why is that? This seems like an unfortunate and inconvenient >> limitation which might actually reduce usefulness of shallow mode >> quite severely? :\ > > Limitation of git design. You can only fetch remote refs, you can't > fetch an arbitrary hash. And since we don't download the whole history, > we can't use a hash that was past 'depth' of the branch/tag clone. So > in order to use an arbitrary hash, we actually have to download > the history. Perhaps you could have EGIT_FETCH_REF and EGIT_CHECKOUT? >>> - changing branches may be very inefficient (since it implies >>> re-fetching all objects implied by --depth 1), >> >> If it's the same local repo then at least in theory all existing >> blobs and trees don't strictly need to be transfered, only unseen >> ones and all the refs. But I'm not sure if git is so good at dealing >> with this - I haven't looked at exactly how packs are structured. > > It's not good at all. In fact, if you try to update a shallow clone > with 'git fetch --depth 1', it's going to refetch all the objects > (while plain 'git fetch' only downloads new objects). It's just another > limitation of protocol that we can't do much about. Can't you use `git fetch` as usual to download old..new commits only? This wouldn't help with switching branches though. >> I would prefer if I needed to allow such mode upgrades explicitly. > > That sounds like a lot ebuilds failing, requesting you to explicitly > change the mode. For example, all Google Code hosted repositories > do not support shallow mode. Some projects may require single-branch > mode to handle their 'git log' play. Perhaps EGIT_CLONE_MODE could be a USE_EXPAND (yes, another one)? >>> When mirror or single-branch mode is used on a shallow repository, >>> the repository is still marked 'shallow' even if the full history is >>> available. I don't know if this wouldn't break some of 'git foo' uses >>> in the checkout but that probably can't be predicted. Moreover, I don't >>> know if it is safe to remove 'shallow' after doing full-fetch in mirror >>> mode. git fetch --unshallow according to https://stackoverflow.com/questions/6802145/convert-shallow-clone-to-full-clone signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Title: >=sys-fs/udev-210 upgrade Author: Samuli Suominen Content-Type: text/plain Posted: 2014-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 [2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 07/10] Support shallow clones.
On 26/02/14 06:59 AM, Michał Górny wrote: > Implementation-wise 'shallow' mode differs only when starting a new > branch. In that case, '--depth 1' is used to avoid fetching earlier > commits. Further updates are done through plain 'git fetch'. So this fetches all a..b commits. If the package hasn't been updated in a while, wouldn't this be less efficient than a new clone? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
On 26/02/14 10:29 AM, Ulrich Mueller wrote: > This is part of normal operation, so maybe downgrade these ewarns to > elog? There's nothing the user can do to suppress these warnings, > apart from changing his global setting for the clone type, which we > won't want him to do. You can put EGIT_CLONE_TYPE in package.env. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default
On 08/03/14 05:37 AM, Tom Wijsman wrote:
> On Sat, 8 Mar 2014 01:46:52 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> 0 1 2 3 4
>> 012345678901234567890123456789012345678901234
>> Ruby MRI 1.8 removal; 1.9 recommended default
>>
>> (The latter is GLEP 42's max 44 chars exactly, and accurately
>> represents the recommended eselect ruby setting.)
>
> $ x="Ruby MRI 1.8 removal; 1.9 recommended default" ; echo ${#x}
> 45
>
> Since you have started with 0 instead of 1, you have one character
> more; thus we'll need to find another character to cut, since that
> doesn't seem possible I suggest we drop the word "default" instead.
>
> $ x="Ruby MRI 1.8 removal; 1.9 recommended" ; echo ${#x}
> 37
>
$ x="Ruby MRI 1.8 removal; 1.9 now recommended" ; echo ${#x}
41
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On 12/03/14 03:15 AM, Yuxuan Shui wrote: > Hi, > > I would like to implement cp --reflink support for ZFSOnLinux as my GSoC > project. > > cp --reflink is used to create a COW copy of a file, so the file will not > take any disk space if it's not modified. This feature is very useful for > cases like storing a lot of almost identical virtual machine images. Also > this is a frequently requested feature for ZoL. [1][2][3] > > Currently only btrfs support this feature, so my goal it to bring it to ZoL > as well. > > I think the only way to do it (without changing too many parts of ZoL) is > to use the deduplication feature of zfs. A COW copy could be done by create > a new entry in ddt for the old file, and create a new file which points to > the ddt entry. > > Please let me know if this proposal makes sense, and if that's the right > way to do it. > > Thanks. > > [1]: > https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w > [2]: https://github.com/zfsonlinux/zfs/issues/405 > [3]: https://github.com/zfsonlinux/zfs/issues/1063 > While I can't comment too much on the technical aspects, they seem to be relatively sound. However, there are some issues with the, er... other aspects, for lack of better terminology. 1. This is possibly out of scope as a Gentoo project, since ZOL is not really part of Gentoo. If it's not, then you're out of luck, because ZOL is not an accepted organization. 2. This is likely too small to be a GSoC project. Perhaps see [0] for a list of example ideas, if only so you can get a grasp on the size of a good project. It does sound like a good idea though, and even if you can't do it as part of GSoC, you should pursue it anyways. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On 29/03/14 06:07 AM, Toralf Förster wrote: > WRT to but 504616 I'd like to address my questions made in > https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : > > "Since the Debian debakel with "fixing" an uninitialized memeory I'm > very skeptical to distribution specific corrections which are not included > upstream. At least I'm wondering if the USE flag hpn should be enabled by the > user explicitely - currently it is in IUSE already." > > > > 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On 31/03/14 03:36 AM, Dirkjan Ochtman wrote: > So, I'm interested... How widely used is the HPN patch set? Are there > any good indications that it doesn't negatively impact security? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292932 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693424 https://lists.fedoraproject.org/pipermail/devel/2007-July/105570.html https://aur.archlinux.org/packages/openssh-hpn/ https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/162253 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy
On 02/04/14 04:02 PM, Rich Freeman wrote: > Another option might be to have a tag in metadata.xml that flags > packages as never-stable Arguments have been made that such packages do not belong in g-x86. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 14/04/14 04:41 AM, Tom Wijsman wrote: > There are still other Gentoo Developers listed in some of them, for > example owncloud and wpa_supplicant; are they really up for grabs? $ equery -N m $(cat) | grep '^[ HM]' * app-text/fbreader [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.fbreader.org/ * dev-libs/liblinebreak [gentoo] Herd:kde (k...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://vimgadgets.sourceforge.net/liblinebreak/ * net-wireless/madwimax [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://code.google.com/p/madwimax/ * net-wireless/wimax-tools [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.linuxwimax.org * net-wireless/wimax [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.linuxwimax.org/ * net-wireless/wpa_supplicant [gentoo] Maintainer: gurlige...@gentoo.org (Bjarke Istrup Pedersen) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Maintainer: zeroch...@gentoo.org (Rick Farina) Homepage:http://hostap.epitest.fi/wpa_supplicant/ * sys-fs/ocfs2-tools [gentoo] Herd:cluster (clus...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://oss.oracle.com/projects/ocfs2-tools/ * www-apps/owncloud [gentoo] Herd:web-apps (web-a...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Maintainer: voyag...@gentoo.org (Bernard Cafarelli) Homepage:http://owncloud.org * www-apps/rutorrent [gentoo] Herd:web-apps (web-a...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://code.google.com/p/rutorrent/ So in fact, only app-text/fbreader and net-wireless/*wimax* are up for grabs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: LTO use in the tree
On 26/04/14 08:34 PM, "C. Bergström" wrote: > Pragmatically nobody gives a f* if grep has been optimized to the max > since it's usually not the bottleneck. http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Update to elisp-common.eclass
On 18/05/14 02:13 PM, Ulrich Mueller wrote:
> if [[ ${EBUILD_PHASE} = *rm && ! -e ${sitelisp}/site-gentoo.el ]]; then
> ewarn "Refusing to create site-gentoo.el in ${EBUILD_PHASE}
> phase."
> return 0
> fi
>
> + [[ -d ${sitelisp} ]] \
> + || die "elisp-site-regen: Directory ${sitelisp} does not exist"
> +
> + [[ -d ${T} ]] \
> + || die "elisp-site-regen: Temporary directory ${T} does not
> exist"
> +
!qefs
if ROOT, EPREFIX, or SITELISP has whitespace, this will throw a syntax
error.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Update to elisp-common.eclass
On 19/05/14 07:17 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 19 May 2014, Alex Xu wrote:
>
>> On 18/05/14 02:13 PM, Ulrich Mueller wrote:
>>> if [[ ${EBUILD_PHASE} = *rm && ! -e ${sitelisp}/site-gentoo.el ]]; then
>>> ewarn "Refusing to create site-gentoo.el in ${EBUILD_PHASE} phase."
>>> return 0
>>> fi
>>>
>>> + [[ -d ${sitelisp} ]] \
>>> + || die "elisp-site-regen: Directory ${sitelisp} does not exist"
>>> +
>>> + [[ -d ${T} ]] \
>>> + || die "elisp-site-regen: Temporary directory ${T} does not
>>> exist"
>>> +
>> !qefs
>
>> if ROOT, EPREFIX, or SITELISP has whitespace, this will throw a syntax
>> error.
>
> Where? In the snippet you quoted, I don't see where whitespace in
> ${sitelisp} could cause any problems.
>
> "Word splitting and filename expansion are not performed on the words
> between the `[[' and `]]'" -- GNU Bash Reference Manual
>
> Ulrich
>
/me ponders
hm...
never mind, I was mistaken.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] /sys/fs/cgroup/openrc/???/tasks sometimes missing
On 03/06/14 02:08 PM, Toralf Förster wrote: > If I boot a 32 bit stable Gentoo Linux as a user mode linux guest with > current kernels (host is a 32 bit stable Gentoo too), then I do observe > sometimes during the boot process error messages from the init system of > Gentoo (OpenRC) like the following (for subsystem rngd in this example) : > > * Starting haveged ... > [ ok ] > /lib/rc/sh/rc-cgroup.sh: line 87: /sys/fs/cgroup/openrc/rngd/tasks: No such > file or directory > * Starting rngd ... > [ ok ] > > And indeed, that directory is missing. A restart of the appropriate service > however creates those entries. The Gentoo bug entry > https://bugs.gentoo.org/show_bug.cgi?id=489386 tells me : > > "It's known race in cgroups, I'm going to address this issue on one of the > following weekends. The problem is that issue is not reproducible on my > systems." > > but that's all since 5 months. Now I'm wondering if this just happens for an > UML guest and who knows how to fix it ? > Please address these mails to gentoo-user@. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The infinite git migration
On 10/06/14 06:59 PM, Patrick Lauer wrote: > [snip] https://bugs.gentoo.org/show_bug.cgi?id=333531 > The current state is almost usable, but it is still obscenely slow > (e.g. initial clone taking ~10 CPU-minutes just to figure out what to > do), but we can just throw more hardware at it. https://bugs.gentoo.org/show_bug.cgi?id=333685: > git 2.0 has pack-bitmap apparently :) so once infra lands that that's basically the end of the major blockers afaik On 10/06/14 06:59 PM, Patrick Lauer wrote: > Another part: Few people thought about the difficult problems in the > migration. For example the rsync mirrors, which will still be used - the > scripts that generate those will need to be changed, tested, and then > replaced if a migration ever happens. https://bugs.gentoo.org/show_bug.cgi?id=333701: > What comment #2 should have said: "This bug is so low priority to the > overall initiative that there shouldn't be anyone considering it a > blocker, show me the git repo then we can talk" :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Changes in installed ebuilds
On 25/06/14 06:42 PM, Jörg Schaible wrote: > Except if they're locally hard masked ... ;-) there's nothing we can do if you intentionally break your own system >> In that case I think revbump is not warranted since it should continue >> to work for existing installation and new installations shouldn't be >> any different beside the dependency and not revbumping eliminates some >> needless rebuilts. > > > The point is: Why update silently the dependency versions for a stable > release? Especially in this case, because the now "required" versions are > the oldest stable ones in the official tree. Therefore anyone with the > official tree would have had those anyway. But such an action may affect > anyone with a local tree or overlays. wrong, please read the mail regarding the >= deps in the first place which you have been referred to repeatedly. >> I guess you could fork the needed packages (you can always get older >> versions from cvs) into your custom overlay for old eclipse and maintain >> them there under some slot. > > > That's what I actually did for all "bumped" packages in the end. Effort for > nothing. broken system is broken signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using LINGUAS
On 21/07/14 12:23 AM, Thomas Kahle wrote: > Hi, > > the OCR software tesseract has many different plugins for > language packs used for OCR for different languages. The ebuild > uses the LINGUAS variable to pass the choice of which packages to > install to the user. > > A reverse dependency is app-text/pdfsandwich which roughly puts > OCR'ed text in a scanned pdf. Since it uses tesseract it > supports exactly those languages that tesseract supports. > > Should its ebuild have LINGUAS use flags and then depend on > tesseract with at least those flags set? > > While it seems consistent to put the LINGUAS choice in the most > user facing package, in this case I would actually not put it in > here. It would introduces a point of failure and maintenance > work for the each tesseract upgrade (since the language set > slightly changes from time to time). A typical user would set > LINGUAS in her make.conf anyway. In this case the same choice > applies to both packages anyway. Maybe an einfo is sufficient to > inform the user it? > > Cheers, > Thomas > there are two possible scenarios here. 1. the dependency is COMPILE TIME (ABI, API, whatever). in this scenario, the depender *must* have appropriate LINGUAS, even if that means copying and pasting from the dependee. this is necessary for correct rebuilding, and everything else associated with automagic deps. 2. the dependency is RUN TIME. in this scenario, the case is the same with all other runtime USE dependencies; that is to say, the correct solution is USE_RUNTIME or something along those lines. [0] here, I would say that einfo is superior to copying IUSE, since these flags should be set globally anyways to make sense. [0] please no bikeshedding on whether to call it RUNTIME_USE or ǝsn‾ǝɯıʇunɹ. signature.asc Description: OpenPGP digital signature
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
On 27/07/14 08:32 PM, James Cloos wrote: >> "PR" == Pacho Ramos writes: > > PR> # Pacho Ramos (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 > Please don't crosspost followup messages, especially to the same mailing list twice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 28/07/14 08:15 PM, Denis Dupeyron wrote: > On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen > wrote: >> x265-1.2.ebuild:KEYWORDS="~amd64 ~arm ~x86" >> x265-1.3.ebuild:KEYWORDS="~amd64 ~x86" >> x265-.ebuild:KEYWORDS="~amd64 ~x86" >> >> As in... You forgot to add ~arm to -.ebuild > > Wait, what? Live ebuilds are keyworded now? > > Denis. > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9&view=markup#l9 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On 12/08/14 01:29 AM, Duncan wrote: > Follow the instructions, as found in the headers of every mail on the > list including the one you replied to, or the ones on the site you > presumably signed up from? Seriously: s/presumably //, this list is closed-loop. signature.asc Description: OpenPGP digital signature
tl;dr: [gentoo-dev] Fw: reviewboard and its bugs
tl;dr: python package has nodejs dependencies, we don't have a mechanism like distutils.eclass to install those system-wide. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] systemd profiles
On 29/08/14 07:09 PM, Jauhien Piatlicki wrote: > Hi all, > > I have a simple question: why do we have systemd subprofiles only in gnome > and kde profiles? > > Could we add systemd subprofiles also to default/linux/$arch/13.0/ and > desktop (and any other profiles where it makes sense)? > > Thanks for answers, > Jauhien > long time question. no simple answer. but basically, systemd is a feature, not a hardware profile. the best architecture should allow one to mix and match features, like funtoo's mixins. search gmane for more details. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set
On 05/09/14 01:34 PM, William Hubbs wrote: > All, > > there is a bug open requesting that we add sys-apps/iproute2 to the > system set [1]. Originally the request was to drop net-tools, but it has > become just adding iproute2. > > If no one objects, I would like to do this sometime in the next 72 > hours by adding sys-apps/iproute2 to profiles/default/linux/packages. > > Thoughts? > > William > > [1] https://bugs.gentoo.org/189149 > no, because it's not necessary to bring up a working system. we don't have wpa_supplicant, and we shouldn't have net-tools now that openrc isn't in @system anymore. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why masks are being used for security issues instead of GLSA?
On 25/09/14 08:42 AM, Andrew Savchenko wrote: > Hello, > > many packages in tree are masked due to security issues instead of > issuing GLSA for them. Why? At this moment I counted 56 such > packages in package.mask. > > Some of these packages have GLSAs issued (e.g. nethack and friends) > and have no fixes, so this is understandable. But most packages are > just masked "due to security bugs", I recently stumbled upon: > ppp, mariadb, mysql, vlc... > > Why such masking is bad? Because it undermines the whole idea of > GLSA as a sole security provider for Gentoo users. > > I manage about 50 Gentoo boxes (with more than 10 unique setups) > and I'm not an update monkey to update them weekly. My usual > workflow is to emerge all world somewhere within 6 month and 1 > year, but to install security updates regularly and critical ones > ASAP. GLSA serves this purpose well (Yes, I understood that > security team can't embrace all issues so some extra lookup for > CVEs is needed as well). But security-masked packages undermine > such approach, because they're not listed in glsa-check -l affected > and message about masked packages doesn't appear in elog, only on > top of build log, which is likely to be lost. > > Best regards, > Andrew Savchenko > 1. one of your examples is clearly wrong, mariadb has no masked versions in the tree. 2. since you claim to have read package.mask, you will have noticed that each mask (bar one) has a bug attached or easily accessible via alias. the single one that does not have a bug number can easily be found via search on the package name. if you bothered to read a single one of them, they will have said that there is a GLSA in progress or that stabilization is still in progress. 3. if you want to use old-ass packages from the age of bourne shell, use debian, not gentoo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add gcc-specs-stack-check() to toolchain-funcs.eclass
On 12/10/14 05:22 PM, Anthony G. Basile wrote:
> # @FUNCTION: tc-export_build_env
> @@ -578,37 +578,37 @@
> gcc-specs-relro() {
> local directive
> directive=$(gcc-specs-directive link_command)
> -return $([[ "${directive/\{!norelro:}" != "${directive}" ]])
> +[[ "${directive/\{!norelro:}" != "${directive}" ]]
> }
> # Returns true if gcc sets now
> gcc-specs-now() {
> local directive
> directive=$(gcc-specs-directive link_command)
> -return $([[ "${directive/\{!nonow:}" != "${directive}" ]])
> +[[ "${directive/\{!nonow:}" != "${directive}" ]]
> }
> # Returns true if gcc builds PIEs
> gcc-specs-pie() {
> local directive
> directive=$(gcc-specs-directive cc1)
> -return $([[ "${directive/\{!nopie:}" != "${directive}" ]])
> +[[ "${directive/\{!nopie:}" != "${directive}" ]]
> }
> # Returns true if gcc builds with the stack protector
> gcc-specs-ssp() {
> local directive
> directive=$(gcc-specs-directive cc1)
> -return $([[ "${directive/\{!fno-stack-protector:}" !=
> "${directive}" ]])
> +[[ "${directive/\{!fno-stack-protector:}" != "${directive}" ]]
> }
> # Returns true if gcc upgrades fstack-protector to fstack-protector-all
> gcc-specs-ssp-to-all() {
> local directive
> directive=$(gcc-specs-directive cc1)
> -return $([[ "${directive/\{!fno-stack-protector-all:}" !=
> "${directive}" ]])
> +[[ "${directive/\{!fno-stack-protector-all:}" != "${directive}" ]]
> }
> # Returns true if gcc builds with fno-strict-overflow
> gcc-specs-nostrict() {
> local directive
> directive=$(gcc-specs-directive cc1)
> -return $([[ "${directive/\{!fstrict-overflow:}" != "${directive}" ]])
> +[[ "${directive/\{!fstrict-overflow:}" != "${directive}" ]]
> }
>
>
> 2) Then I'll add gcc-specs-stack-check()
>
>
> --- toolchain-funcs.eclass2014-10-12 17:19:30.086154455 -0400
> +++ /root/toolchain-funcs.eclass2014-10-12 17:19:05.983153358 -0400
> @@ -610,6 +610,12 @@
> directive=$(gcc-specs-directive cc1)
> [[ "${directive/\{!fstrict-overflow:}" != "${directive}" ]]
> }
> +# Returns true if gcc builds with fstack-check
> +gcc-specs-stack-check() {
> +local directive
> +directive=$(gcc-specs-directive cc1)
> +[[ "${directive/\{!fno-stack-check:}" != "${directive}" ]]
> +}
>
could merge local directive with the next line too while you're at it
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On 13/10/14 05:35 AM, Michał Górny wrote: > Please review the following news item. > > - > > Title: bash-completion-2.1-r90 > Author: Michał Górny > Content-Type: text/plain > Posted: -MM-DD > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: > Starting with app-shells/bash-completion-2.1-r90, we are enabling > the completion autoloading support. Along with it, we are replacing > the eselect-bashcomp module with a new one suited better for the new > framework. > > Users will notice that the new framework is opt-out rather than opt-in. > Since completions are loaded on-demand, all of them are enabled > by default. If some of them are undesired, eselect-bashcomp can be used > to explicitly disable (mask) them. > > The current eselect-bashcomp setup will *not* be migrated. It may be > necessary to rebuild packages installing completions after the upgrade, > and remove old configuration symlinks afterwards. For details, please > consult the app-shells/bash-completion post-install messages. > > seems too oriented towards developer audiences, whereas news items are intended to target users; iow, I don't care what's going on behind the scenes, just tell me what I need to do to fix it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new virtual: virtual/podofo-build
On 13/10/14 03:46 PM, Zac Medico wrote: > Hi, > > In order to solve bug #503802 [1], I would like to add a > virtual/podofo-build package to pull in app-text/podofo and > dev-libs/boost. Then packages like app-text/calibre can put > virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The > advantage of this approach is that it makes it possible to use a command > like `emerge --depclean --with-bdeps=n` to remove the build-time only > boost package (and virtual/podofo-build), since boost is only needed for > build-time headers. There may be some other possible ways to specify the > dependency, but this approach is the most attractive one that I've seen. > In fact, this approach is basically identical to the "Virtual for C++ > tr1 " example that's given in the dev-manual [2]. > > Would anyone like to suggest improvements to this idea, alternatives, or > raise any objections? > > [1] https://bugs.gentoo.org/show_bug.cgi?id=503802 > [2] http://devmanual.gentoo.org/general-concepts/virtuals/ > I feel like there should be a DEPEND specifier for "packages required to build against this package". For example, xproto is required to build against SDL (at least using pkg-config), but not to simply use it at runtime. This applies even if one does not directly use xproto headers. It would not be sufficient to specify that "DEPEND includes the DEPENDs and RDEPENDs of the dependencies", since then it would be impossible to specify build dependencies that only require the runtime of the dependee, like most build tools. It seems like a poor solution to have to create virtuals for every package that requires such an arrangement. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: News item regarding c++98 vs c++11
On 19/10/14 06:53 PM, Anthony G. Basile wrote: > the default is still gnu++98 what does this mean, how does it differ from c++98? > in the older ABI, can lead to a crippled system. what do you mean, will other packages break too? maybe "may lead to non-functioning or possibly broken packages". adjust as necessary; I am not familiar with what may break if incompatible libraries are linked together. > However, as c++11 gains in popularity and the number of packages using it > increase, it is important that users understand these precautions. what precautions? what am I supposed to do? is there a option to warn me if I try to do something stupid? should I check some packages on my system? remember that gcc-4.7 is literally all (standard) gentoo users, so a news item needs to be clear about who exactly needs to care about the issue, which here appears to be a small subset of "all (standard) gentoo users"; namely, those who specifically opt in to using C++11 (or are compiling such packages manually). also, strictly speaking, last I checked, the name of the standard is C++11; c++11 is just what gcc takes. and maybe some links about what could break if I link incompatible libraries together would be helpful, since the links don't seem to go over that (at least apparently; I did not read the entire contents). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11
On 24/10/14 10:31 AM, Anthony G. Basile wrote: > HI everyone, > > I've update the c++ news item for your consideration. I incorporated > suggestions, in particular a note about incompatibility between c++11 > compiled with different version of gcc differing in minor number (eg 4.7 > and 4.8). > > lgtm. also mime attachments are hard to comment on. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item
On 29/10/14 07:28 AM, Samuli Suominen wrote: > request for review before committing, suggestions welcome since it's > rather short what > i got to say > > thanks, > Samuli > typical news items are in the format " no longer/now do . [ is >.] if you need , do . if you do not need , do ." [blah blah metadata, I hereby assign all copyright for the following text to the Gentoo Foundation] sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace firmware loader. If you require firmware loading support, you must use kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is required if none of your kernel modules need firmware. See [1] for more information on the upgrade. [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] typo in "scrypt" USE-Flag
On 02/11/14 11:41 AM, Marco Ziebell wrote: > There's a typo in the "scrypt" USE-FLAG. A bug-report seemed to big for > that. > Correct would be "scrypt: Use libscrypt for the scrypt > algorithm" so... instead of emailing 4 people (three bug-wranglers plus one maintainer), you email around 300 people (assuming that subscriber count is around the same as #gentoo-dev users, which is probably a severe underestimate). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item
On 07/11/14 07:13 AM, Samuli Suominen wrote: > > On 29/10/14 13:42, Alex Xu wrote: >> On 29/10/14 07:28 AM, Samuli Suominen wrote: >>> request for review before committing, suggestions welcome since it's >>> rather short what >>> i got to say >>> >>> thanks, >>> Samuli >>> >> typical news items are in the format " no longer/now do >> . [ is >.] if you need , do >> . if you do not need , do ." >> >> [blah blah metadata, I hereby assign all copyright for the following >> text to the Gentoo Foundation] >> >> sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace >> firmware loader. If you require firmware loading support, you must use >> kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is >> required if none of your kernel modules need firmware. See [1] for more >> information on the upgrade. >> >> [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217 >> > > The news item has been committed today. :-) > > Sorry for the delay. I'm running out of excuses with my health issues. :-( > > Thanks and sorry, > Samuli > oh, I just figured something. what about systemd? looks like IUSE=firmware-loader was removed in 217. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 23/11/14 08:17 PM, hasufell wrote: > packages up for grab: > > I didn't change metadata.xml, nor bug reports for any of those, because > I was too lazy. If you grab one, please do so yourself. how will bug-wranglers know where to assign packages then? > app-misc/trash-cli > > co-maintained by games > games-misc/katawa-shoujo > games-roguelike/FTL > > co-maintained with Lars Wendler > media-sound/umurmur I can proxy these if the relevant people agree. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new bitcoin eclass
On 05/02/15 07:11 PM, Anthony G. Basile wrote: > Hi everyone, > > I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds > make use of the same codebase, so its probably a good idea to migrate > that code to an eclass. Can we have the following eclass reviewed > before committing it to the tree: > > https://gitorious.org/bitcoin/gentoo/source/674d32a2d029aed3bc967a1949f75586828ebe14:eclass/bitcoincore.eclass > > > Thanks. > Why can't the ebuilds be merged into one with USE flags? They are even from the same repository. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
On 15/03/15 10:11 AM, Michał Górny wrote: > In case of issues, blockers especially, the users users are recommended looks OK otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] oops: "portage-latest.tar.*" are off-by-one.
On 04/06/15 11:46 AM, Vadim A. Misbakh-Soloviov wrote: > В письме от Чт, 4 июня 2015 11:17:01 пользователь Mike Frysinger написал: >> if you have a bug to report, please use bugs.gentoo.org >> -mike > > I bet, "bug" will deprecate itself before even bug wranglers takes a look on > it. > excellent theory, let's see how well it holds up in practice. https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&namedcmd=Bug Wranglers&remaction=run&sharer_id=46764 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New email list and alias for the musl project --- a note for bug wranglers
On 03/07/15 08:20 AM, Anthony G. Basile wrote: > Hi everyone, > > This one is mostly for the bug wranglers. There is a new email list and > alias for the musl (sub?)project [1]. > > List: gentoo-m...@lists.gentoo.org > alias: m...@gentoo.org > > musl is a new C standard lib [2]. It adheres scrictly to POSIX, XOPEN, > SUSv3 standards. As a result, a number of packages break with musl. > Usually these are small bugs, like missing headers mandated by POSIX, > but still even a small error breaks a package. > > I don't want to burdon the maintainers with these bugs, so I'd like to > ask bug wranglers that if they see a bug due to musl, to please assign > it to me and cc the maintainer. I'll fix the bugs on the musl overlay > [3] and upstream the patches, while keeping the maintainers informed > about what's going on. Don't worry, I won't touch any packages. > > Bug wrangling usually proceeds via the metadata.xml, but there really is > no structure there for communicating the above situation. > > > Refs. > [1] https://wiki.gentoo.org/wiki/Project:Hardened_musl > [2] http://www.musl-libc.org/ > [3] https://gitweb.gentoo.org/proj/musl.git > > why not make a "musl" component in bugzilla? signature.asc Description: OpenPGP digital signature
