Re: [gentoo-dev] ekeyword written in python from scratch
On Mon, 20 Jan 2014 01:01:40 -0500 Mike Frysinger vap...@gentoo.org wrote: at any rate, if other devs who use this want to give it a crack, that'd be great. iron out bugs before the next release. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=blob_plain;f=src/ekeyword/ekeyword.py;hb=gentoolkit- dev # cp nvidia-drivers-304.117.ebuild nvidia-drivers-304.119.ebuild # ~/bin/ekeyword ~all nvidia-drivers-304.119.ebuild nvidia-drivers-304.119: -~* ~amd64 ~x86 ~amd64-fbsd ~x86-fbsd It's more obvious with the fancy colouring, but here it removes -* and adds ~*. Regards, jer
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
On 01/27/14 08:35, Steev Klimaszewski wrote: On Sun, 2014-01-26 at 21:00 +0100, Michał Górny wrote: Hi again. If someone is interested in the results of my tests and benchmarks, I've uploaded the initial version of my article on the topic in our dev-space. http://dev.gentoo.org/~mgorny/tmp/squashfs-deltas.pdf I am terribly busy with the uni right now so it will take some time before I continue working on it. I will try to provide a final specification for the first attempt at the idea and ask infra if they are ready to sacrifice the hardware for it. Further possible improvements: 1. switch to LZ4 (stronger compression, even faster) -- will require a newer kernel (3.14?), it should be in kernel 3.11 windows for workgroups release (check anyway) While the stronger compression, and being faster is definitely nice, having portage on squashfs is really nice on ARM devices, however the number of them that have a decently running kernel newer than 3.8 are few and far between, so I'd like to ask that this be held off as long as possible. I know these are just possible improvements, but doing so would definitely alienate a really good place where this would shine. yes, there are good reasons also for amd64 2. dedicated SquashFS delta tool -- I'm working on it but the format seems to be poorly documented so it will take some time :).
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
Dnia 2014-01-27, o godz. 14:53:34 viv...@gmail.com viv...@gmail.com napisał(a): On 01/27/14 08:35, Steev Klimaszewski wrote: On Sun, 2014-01-26 at 21:00 +0100, Michał Górny wrote: Hi again. If someone is interested in the results of my tests and benchmarks, I've uploaded the initial version of my article on the topic in our dev-space. http://dev.gentoo.org/~mgorny/tmp/squashfs-deltas.pdf I am terribly busy with the uni right now so it will take some time before I continue working on it. I will try to provide a final specification for the first attempt at the idea and ask infra if they are ready to sacrifice the hardware for it. Further possible improvements: 1. switch to LZ4 (stronger compression, even faster) -- will require a newer kernel (3.14?), it should be in kernel 3.11 windows for workgroups release (check anyway) That's just the LZ4 library code. We additionally need the SquashFS support code. It has been introduced in squashfs-tools lately (4.2_p20140119 has it, though disabled by ebuild) and I don't see it in the kernel's master branch yet. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
Dnia 2014-01-27, o godz. 01:35:52 Steev Klimaszewski st...@gentoo.org napisał(a): On Sun, 2014-01-26 at 21:00 +0100, Michał Górny wrote: Hi again. If someone is interested in the results of my tests and benchmarks, I've uploaded the initial version of my article on the topic in our dev-space. http://dev.gentoo.org/~mgorny/tmp/squashfs-deltas.pdf I am terribly busy with the uni right now so it will take some time before I continue working on it. I will try to provide a final specification for the first attempt at the idea and ask infra if they are ready to sacrifice the hardware for it. Further possible improvements: 1. switch to LZ4 (stronger compression, even faster) -- will require a newer kernel (3.14?), While the stronger compression, and being faster is definitely nice, having portage on squashfs is really nice on ARM devices, however the number of them that have a decently running kernel newer than 3.8 are few and far between, so I'd like to ask that this be held off as long as possible. I know these are just possible improvements, but doing so would definitely alienate a really good place where this would shine. I think that if we decide to do the switch, we will host multiple formats at least for some time. It won't be really helpful to prevent people from upgrading their kernel due to new repo archive format :). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski st...@gentoo.org wrote: It's not necessarily the STABLEREQs stopping, some of the issues are (at least on some arches!) that some of the unstable software doesn't quite work properly anymore, and we are failing at communicating. And in those cases, we on the arch teams should definitely be pointing this out, and filing bugs so that the issues can be sorted. Well, if the package or some version of it doesn't work at all, you can always mask it on the arch or drop keywords. The arch team doesn't need permission to do this stuff - the keywords and profiles really belong to the arch team, and we just allow maintainers to do their best job with them to make the job of the arch team easier. Obviously if you actually want the problem fixed that requires bugs/etc. But you don't need a bug to drop a keyword and at least make it clear that the package doesn't work. Rich
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
On Mon, 27 Jan 2014 16:52:09 +0100 Michał Górny mgo...@gentoo.org wrote: That's just the LZ4 library code. We additionally need the SquashFS support code. It has been introduced in squashfs-tools lately (4.2_p20140119 has it, though disabled by ebuild) and I don't see it in the kernel's master branch yet. I'll be glad to add that squashfs-tools support for you shortly. Regards, jer
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
Le lundi 27 janvier 2014 à 02:10 +0100, Peter Stuge a écrit : here any other solution for users than fixing the ebuilds and/or eclass(es)? Any dev is supposed to know if his/her package complies to XDG specifications, easy enough to figure out in most cases. Like other packages affected by environment variables they use (gstreamer, glib, etc), we just need a sane place to properly reset/set those to ensure repeatability of builds. Given current PM behavior, it is not possible to change what is exported to build environment without an EAPI bump because the potential for breakage is huge and you do not want to spend your next month building the tree to build a whitelist of environment variables, right ? Imho, the best course of action is to move that to an eclass for now. People are encouraged to provide a prototype implementation of such eclass in the previously mentioned bug report. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] ekeyword written in python from scratch
On Monday, January 27, 2014 14:01:58 Jeroen Roovers wrote: # cp nvidia-drivers-304.117.ebuild nvidia-drivers-304.119.ebuild # ~/bin/ekeyword ~all nvidia-drivers-304.119.ebuild nvidia-drivers-304.119: -~* ~amd64 ~x86 ~amd64-fbsd ~x86-fbsd It's more obvious with the fancy colouring if you dislike the color format, then pick a different one. there are a large number available. but here it removes -* and adds ~*. this should fix it: http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commitdiff;h=465c0532f88df7bf3af08e84172ea5a908105fc1 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Mon, 2014-01-27 at 09:52 -0500, Rich Freeman wrote: On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski st...@gentoo.org wrote: It's not necessarily the STABLEREQs stopping, some of the issues are (at least on some arches!) that some of the unstable software doesn't quite work properly anymore, and we are failing at communicating. And in those cases, we on the arch teams should definitely be pointing this out, and filing bugs so that the issues can be sorted. Well, if the package or some version of it doesn't work at all, you can always mask it on the arch or drop keywords. The arch team doesn't need permission to do this stuff - the keywords and profiles really belong to the arch team, and we just allow maintainers to do their best job with them to make the job of the arch team easier. Right, but, afaik, an unstable ebuild can go away at any point in time, and then we'd be back in this same place - newer ebuilds are around, older working ones are gone... Obviously if you actually want the problem fixed that requires bugs/etc. But you don't need a bug to drop a keyword and at least make it clear that the package doesn't work. Right, and this goes as a point towards splitting out the arm keywords, and maybe I'll bring it up at the next ARM team meeting... I don't think it would get much traction, but I suppose it wouldn't hurt to at least throw it out there and see what sticks. Rich
Re: [gentoo-dev] ekeyword written in python from scratch
On Mon, 27 Jan 2014 18:14:54 -0500 Mike Frysinger vap...@gentoo.org wrote: It's more obvious with the fancy colouring if you dislike the color format, then pick a different one. there are a large number available. I didn't intend that at all. A coloured multiline output would be a nice default, though, since not everyone/everywhere is able to display/read in colours. jer
Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/01/14 23:00, Tom Wijsman wrote: A first idea from looking at search engine results is through the menu View and then click Message Source; maybe there's some faster way around, changing the options of what header fields to show perhaps? That was my first hunch, but there is no field like this in Mike's email. On yours (the email I'm replying to) and others, there is such a field though. The email I'm replying to has the ID Message-ID: 20140127230019.0d787808@TOMWIJ-GENTOO. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLm2gAACgkQRtClrXBQc7VXwAD/QJr2RE6dQeWW2vUxnFCY/yUp 3a34izKWHoMjCid3KxAA/R6AfxOTiPJYMV/c4l0FR64qyk1yKlwWJPFIM9caTFru =/5Wf -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jan 2014 23:13:20 +0100 Alexander Berntsen alexan...@plaimi.net wrote: On 27/01/14 23:00, Tom Wijsman wrote: A first idea from looking at search engine results is through the menu View and then click Message Source; maybe there's some faster way around, changing the options of what header fields to show perhaps? That was my first hunch, but there is no field like this in Mike's email. On yours (the email I'm replying to) and others, there is such a field though. The email I'm replying to has the ID Message-ID: 20140127230019.0d787808@TOMWIJ-GENTOO. It's somewhere near the end of the header: Message-ID: CAJ0EP408ncVB5zMF92upG+eQ0K2JT8WJbchm3XJFzrWj=c2...@mail.gmail.com If we fill that in in GMANE's Message ID finder it yields his mail: http://news.gmane.org/find-root.php?message_id=CAJ0EP408ncVB5zMF92upG%2beQ0K2JT8WJbchm3XJFzrWj%3dc2%5fsw%40mail.gmail.com - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS5t0RAAoJEJWyH81tNOV9AwkIAKBXdmfbx3DMNYwldONf3Mq4 nqH4RQavnrUQ6IYodFAgpAQG+BEgsHPu9TK6EBf8BHxpj0vOZHpmy1T/h/ISqlbf V4vYgDplV6Dc8buApoTXiCDKlQ4KiGf0x3zhrWdh7mDlLK+8nT0+9lmfXRP3Ut6A of+D0hSo6tsSzVTZjC4ko3wBxudySDAcz5UfpAP2LO/kCysN1fEOPUyddfACs9G1 +bDLQ6Ovm8b5IBL6P9LX0Z/+D+jDANjTZI8EmxwDrmi/bqsuWnQpEOoUy4UC7DJm YdRjiTJoZ9ApR41rLgokDZuTsjvDOcOxpas+jW2SVjdIoQhDdKYNKW01AN7pUAI= =298c -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/01/14 23:26, Tom Wijsman wrote: It's somewhere near the end of the header: Message-ID: CAJ0EP408ncVB5zMF92upG+eQ0K2JT8WJbchm3XJFzrWj=c2...@mail.gmail.com Oh, right. I was being stupid. Case matching was enabled, so /message didn't exactly work. Thanks. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLm454ACgkQRtClrXBQc7UINgD8DUF8MIyIxMnNjZZjfufioAzk npqa1IZHqahr/ELZeRQA/igIJohmmJ8YTuwp0uTC3NGYT7QidOIPtsH/3RbFW0NA =qp0x -END PGP SIGNATURE-
Re: [gentoo-portage-dev] xattr wrapper for install, bug #465000
On Monday, January 27, 2014 15:02:30 viv...@gmail.com wrote: patch install from coreutils (and then upstream changes) is not an option? that route is being pursued independently. we already have a wrapper and will have one for the foreseeable future. -mike signature.asc Description: This is a digitally signed message part.
