Re: [gentoo-dev] Re: Disabling locale at emerge output
On Wed, 27 Apr 2011 21:10:55 -0600 Ryan Hill wrote: > I _am_ arguing for non-English user's rights. That's the whole > reason I'm here, annoying you and whatnot. Great, now we're getting somewhere. > See, you're thinking primarily in terms of bugzilla. Like the only > reason someone would want to see this stuff is to paste it to a bug > report for a developer to look at. I'm saying someone who doesn't > speak English at all (who won't be filing bugs btw) might want to be > able to understand the error the compiler just dumped on them without > needing a translator. I countered that with the argument that if users cannot read "No such file or directory" then they cannot read "ERROR: app-arch/rpm-4.4.6-r7 failed (compile phase)" either. How does that work? > But whatever, I appear to be the only person who has a problem with > this. But you just said "I _am_ arguing for non-English user's rights"! :-) jer
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
2011/4/27 Tomáš Chvátal : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dne 27.4.2011 10:04, Corentin Chary napsal(a): >> I updated http://euscan.iksaif.net yesterday. >> >> I also added some overlays, and I now use local portage portage trees >> instead of system trees (a script to do that is available in >> euscanwww/script). >> >> New features: >> - Handle overlays correctly (special column for overlays) >> - Add some charts (small bar charts in table, pies at the bottom) >> - Less false positives with euscan >> >> I'll try to add "all time" line charts this week. >> >> Thanks, > Found another issue, package stays there even if it was removed from the > portage tree (kde-misc/plasmaboard is a good example). Good catch, I'll add a --purge option to scan-portage. -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Camellia?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2011 06:14 PM, Eray Aslan wrote: > openssl ciphers -v 'ALL:@STRENGTH' I find it somewhat hard to believe that they are using a version of OpenSSL that doesn't have AES-256. It's been around since 0.9.7. Having said that, I don't know of any major weakness with the cipher. The only thing I don't personally really love about it is the lack of analysis. Something like AES has been the majority of the fields notice and gets more attention, so it is likely better analyzed and understood. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNuWgfAAoJEEsurZwMLhUx1c0P/RVO1g0Ph9zl6YmlLHwJVH/h RrAN/OdSQRoefGrSEuzKGQJtegmvNakzc4+YOxPsM8nXg2bBBokxkm2smr2H9YQ1 07Gf6kgLw7ZmPzy5sVPDaqd3Y6P9PQa9rvwwejX4XvQZAtFRC/jljPk1qLUutxte vCdlHQUl2cpV01qzFDtm+YRThPqTSA91Ecrq3yaqZn9mtPmcKjS5uz4eUPSJrepm xDnXUeCstgEADcjgVA2ofshpdrBLKNcePQQ/FDOuGXkGeQM70CO+U4Yekhe7fvF6 tEK7QomLxPOvTz2OZsSQErmXhysfHHBEM/uo1Mxnk4zkGZzBpexGsEhkPESsTkVR k8wiwQvLacr+NslDNRAa1c08HU+j6JcvjTbcq8shMD8PvsmS+I3TbUEZsVOBGe6E kMxG+zwWD3LmXSZCvrUtQeBN+aLpRpa5cibGIgYZtoYe9miT2LW3D1UmvzYNvlZA 0QW0zEOrxrBgHdxBBOgZLN+hCZUaMoAfi0m7AMqFczmyulXsER/ROFsCZmLhzKPK yK9Y3kAAU7Y0aOjVhwqU4JKuyPvho0SntpRZGSCIXPMncySb163CkeecJ1to8+1O IN5rY4O9jFMWDHNFz7NMSD6Hnk4zoem6b/+v6qYoT6uHx3sYT/C7l3E0OJ2B7SI/ tXeYUYa/mR49AszHpaes =lpeo -END PGP SIGNATURE-
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
So once again: https://bugs.gentoo.org/docs/en/html/lifecycle.html *Every* new bug filed by a user without editbugs will have "UNCONFIRMED" (old NEW) as fixed status. *If* we don't enable the UNCONFIRMED status at all then it will CONFIRMED as default but we would enable the UNCONFIRMED status. Bug wranglers can then assign the bug and they also *can* mark it as CONFIRMED *if* they *can* confirm it. The maintainer may change the status to IN_PROGRESS (old ASSIGNED) afterwards. The snipped of my first mail may be a bit confusing... It just means: NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED would/could be the default for everybody with editbugs. ASSIGNED gone, replacement: IN_PROGRESS, REOPENED gone, CLOSED gone. VERIFIED will be added. So I think we should convert... -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 16:07 Thu 28 Apr , Christian Ruppert wrote: > So once again: > > https://bugs.gentoo.org/docs/en/html/lifecycle.html Ok, so, we should choose one of two ways: 1. The old one [1] 2. The new one [2] From my point of view, the problem currently is that the ways above are mixed. A user files a bug. The bug has UNCONFIRMED status. Then, someone with editbugs priveleges tries to assign the bug. He has the NEW, ASSIGNED and RESOLVED options to change its status. A bug is assigned to a team/ maintainter. The maintainer can change its status from NEW to ASSIGNED or RESOLVED. The maintainer marks the bug as RESOLVED. He can change that status again to UNCONFIRMED, REOPENED, VERIFIED or CLOSED. Even the RESOLVED can be FIXED, INVALID, WONTFIX, DUPLICATE, WORKSFORME, CANTFIX, NEEDINFO, TEST-REQUEST, UPSTREAM, OBSOLETE. Someone would say that CANTFIX and UPSTREAM could be merged. The same with WONTFIX and OBSOLETE (it's a theory, I don't say we should do it). > ... > REOPENED gone, > CLOSED gone. VERIFIED will be added. What is the meaning of VERIFIED? (I also never understood the meaning of the old CLOSED). > > So I think we should convert... I think we should convert to the new [2] model too. The only reason I asked about the whole "workflow thing" on irc was because sometimes I get confused by all these options. I believe we should simplify them and update the bug-wranglers guide accordingly. [1] http://www.bugzilla.org/docs/3.6/en/html/lifecycle.html [2] http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html ps: To everyone who helped with the upgrade of bugzie: Thanks guys! I can understand it wasn't easy. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp8oqwPzsbMS.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thu, Apr 28, 2011 at 04:07:24PM +0200, Christian Ruppert wrote: > So once again: > > https://bugs.gentoo.org/docs/en/html/lifecycle.html > > *Every* new bug filed by a user without editbugs will have "UNCONFIRMED" > (old NEW) as fixed status. > *If* we don't enable the UNCONFIRMED status at all then it will > CONFIRMED as default but we would enable the UNCONFIRMED status. > > Bug wranglers can then assign the bug and they also *can* mark it as > CONFIRMED *if* they *can* confirm it. > The maintainer may change the status to IN_PROGRESS (old ASSIGNED) > afterwards. > > The snipped of my first mail may be a bit confusing... It just means: > NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so > NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED > would/could be the default for everybody with editbugs. > ASSIGNED gone, replacement: IN_PROGRESS, > REOPENED gone, > CLOSED gone. VERIFIED will be added. > > So I think we should convert... +1 The new workflow makes more sense. I would mark any new bug as UNCONFIRMED by default, having editbugs doesn't ensure your bugs will be confirmed. > -- > Regards, > Christian Ruppert > Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure > member > Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgp5InJUXFVoy.pgp Description: PGP signature
Re: [gentoo-dev] Camellia?
On Thu, Apr 28, 2011 at 09:14:07AM -0400, Dane Smith wrote: > I find it somewhat hard to believe that they are using a version of > OpenSSL that doesn't have AES-256. It's been around since 0.9.7. It does have AES256 just lower in the list: eras@woodpecker ~ $ openssl ciphers -v ALL:@STRENGTH | head -n5 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 eras@woodpecker ~ $ openssl version OpenSSL 0.9.8o 01 Jun 2010 Presumably smtp.g.o and pigeon.g.o has the same setup. ssl_create_cipher_list() makes the above list if you want to check its history. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] Camellia?
On 18:35 Thu 28 Apr , Eray Aslan wrote: > > eras@woodpecker ~ $ openssl version > OpenSSL 0.9.8o 01 Jun 2010 > > Presumably smtp.g.o and pigeon.g.o has the same setup. > ssl_create_cipher_list() makes the above list if you want to check its > history. > Please, can you continue this somewhere more privately? I wouldn't like it if I were a sysadmin and someone was posting information about versions of software of production machines publicly. I hope you understand. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpvH5Ou0RXFJ.pgp Description: PGP signature
Re: [gentoo-dev] Camellia?
> "PC" == Panagiotis Christopoulos writes: PC> Please, can you continue this somewhere more privately? I wouldn't PC> like it if I were a sysadmin and someone was posting information PC> about versions of software of production machines publicly. I hope PC> you understand. This isn't private information. Everyone who receives mail from these lists can see what crypto gentoo's outgoing servers use when connecting to one's MXs. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Camellia?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/28/11 14:30, James Cloos wrote: >> "PC" == Panagiotis Christopoulos writes: > > PC> Please, can you continue this somewhere more privately? I wouldn't > PC> like it if I were a sysadmin and someone was posting information > PC> about versions of software of production machines publicly. I hope > PC> you understand. > > This isn't private information. Everyone who receives mail from these > lists can see what crypto gentoo's outgoing servers use when connecting > to one's MXs. > > -JimC The cipher in use is public. The version of OpenSSL in use is not. He's not referring to the cipher talk, but to the version information as far as I can tell. - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNuXs5AAoJEEsurZwMLhUxS1UP/2lg96cjD6pK4cnuwEbF/chE EUQsLcOxycUkOAE5o+kYruksHY07LWmcY7ULG470xnxY/Szs+kT/KbwXXXEKcu+n LwuYM8nxmGnjAv1CIMsHIgvowZ3USJ312BTbvBPRTdADNlUtcSBlHCbgs2otVI62 wiBUxvZqm+IsDaXWO83lAcN06EOd2TQVLBXMucNATwWxOuPGuRtBC1oU+xzAdxJD 5y2JGw3P2DuU6TjcDV1Zj6W44QrKTbk6wjK8HCpElTEwr/RpwdPEGlQeH8dv3BZz nI7IatDBANFRawMDwsbnvgNRqjNO4AalFh/8fy4Up9PWcbVCPSRCSPMAT4O2zj4y M5PmbVshfziLVlzQSqqU7SjgBP99ue4Mbzb3M4zNqKYzfYj+VuS8KEEQVz6qk4HO IET106tfh7ShMaAMUi6C8Bb0KQhIMYYCYAUH34kaYc6teX9N8/+s/ceumrTUZoa5 BrdNu9+tbMYlY5eZxIsblqNuwp+L53pmA1VePQUCQStcELVPQhflWG27kb8SajlG tCj0686VjgPlso7PS3hveMYrYu2ifSRmvfdAUB1F9+D/LrEZie/UViY43MhJ/Ios bXlwIP7kcrx6axm1x32ao0iaRays9+EiVh6sgmbnIfB0uP5AWZW3qzV4DFbRNVVB MIURStrba1iNISDVXNad =joaK -END PGP SIGNATURE-
Re: [gentoo-dev] Camellia?
On Thu, Apr 28, 2011 at 06:59:05PM +0300, Panagiotis Christopoulos wrote: > Please, can you continue this somewhere more privately? I wouldn't like it if > I were a sysadmin and someone was posting information about versions of > software of production machines publicly. I hope you understand. Security through obscurity does not work. It especially will not work for the infrastructure of a Linux distribution. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] Camellia?
Eray Aslan said: > On Thu, Apr 28, 2011 at 06:59:05PM +0300, Panagiotis Christopoulos wrote: > > Please, can you continue this somewhere more privately? I wouldn't like it > > if > > I were a sysadmin and someone was posting information about versions of > > software of production machines publicly. I hope you understand. > > Security through obscurity does not work. It especially will not work for the > infrastructure of a Linux distribution. What does any of this have to do with development of Gentoo? Go send an email to infrastructure if you want to talk to those that administer those services. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
[gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
Hello! Gentoo's official logo originates from a Blender file [1] created by Daniel Robbis over 8 years ago. He used Blender 2.04 and Python 1.6 at that time. When rendering that .blend file with Blender 2.49b (or a more recent version), Blender does not apply the reflection texture needed [2] to give the metal look that you know. I don't know why that is. All I know is that Blender does find the file: it's not about the location. Trying Blender 2.04 binaries on a Windows VM, it turned out that Blender 2.04 is still able to render our logo as expected. In my eyes rendering our logo should not depend on a proprietary operating system or binary blobs. The source tarball of Blender 2.04 is hard to find (if available at all), the available sources of 2.03 [7] are incomplete. Binaries of 2.04 [8] are 32bit only and crash on startup on my system. The earliest source tarball after 2.04 that upstream offers for download [3] is Blender 2.26. That version does not compile with GCC 4.4 and turns out to be home with Python 2.2. In hope that this version would be able to render our logo in the way that Blender 2.04 did, I tried fixing compilation against GCC 4.4.5. That worked [4]. The need for Python 2.2 became clear when all of Python 2.4, 2.4 and 2.6 made it segfault in Python related code instantly. Therefore I tried bringing our old Python 2.2-r7 ebuild to life. Smaller changes like -fPIC were needed but it wasn't too hard. You can find the Python 2.2-r8 in the betagarden overlay [6]. In the end I could do sudo eselect python set python2.2 to compile and run Blender 2.26 and make it render g-metal.blend (after adjusting the path to the reflection texture) with metal look in a resolution of a few megapixel on transparent background. I have the impression, that the rending is the same as of Blender 2.04. However, this is not a good long-term solution. For instance Portage doesn't operate under Python 2.2 so an ebuild for Blender 2.25 is a tricky thing to do nowadays. Among the options I see is the following: A) Find out how to render g-metal.blend with recent Blender (2.57b at best) to give pixel-identical results to Blender 2.04. Needs an advanced Blender user ideally. B) Port Blender 2.26 to a recent version of Python. Are there any other options? What do you think? I would also like to encourage you to reproduce the process I described to spot any problems I overlooked. Thanks for reading up to this point. Best, Sebastian [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/gentoo-web/blend/g-metal.blend [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/gentoo-web/blend/metallandscape1.jpg [3] http://download.blender.org/source/ [4] http://git.goodpoint.de/?p=blender-2.26.git;a=summary [5] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.2-r7.ebuild?hideattic=0&view=markup [6] http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=commitdiff;h=a3712c45dee61717cbc09b39ff868af7a3ccaa89 [7] http://download.blender.org/source/chest/blender_2.03_tree.tar.gz [8] http://download.blender.org/release/Blender2.04/
[gentoo-dev] Re: Disabling locale at emerge output
On Thu, 28 Apr 2011 14:00:23 +0200 Jeroen Roovers wrote: > On Wed, 27 Apr 2011 21:10:55 -0600 > Ryan Hill wrote: > > See, you're thinking primarily in terms of bugzilla. Like the only > > reason someone would want to see this stuff is to paste it to a bug > > report for a developer to look at. I'm saying someone who doesn't > > speak English at all (who won't be filing bugs btw) might want to be > > able to understand the error the compiler just dumped on them without > > needing a translator. > > I countered that with the argument that if users cannot read "No such > file or directory" then they cannot read "ERROR: app-arch/rpm-4.4.6-r7 > failed (compile phase)" either. How does that work? Why would you need to read that? See compiler error, portage explodes, lots of red stars everywhere. If I can read the compiler error I know what happened. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
On Fri, 29 Apr 2011 02:29:42 +0200 Sebastian Pipping wrote: > Gentoo's official logo originates from a Blender file [1] created by > Daniel Robbis over 8 years ago. He used Blender 2.04 and Python 1.6 > at that time. > > When rendering that .blend file with Blender 2.49b (or a more recent > version), Blender does not apply the reflection texture needed [2] to > give the metal look that you know. I don't know why that is. All I > know is that Blender does find the file: it's not about the location. > > [...] > > Among the options I see is the following: > > A) Find out how to render g-metal.blend with recent Blender > (2.57b at best) to give pixel-identical results to Blender 2.04. > Needs an advanced Blender user ideally. > > B) Port Blender 2.26 to a recent version of Python. > > Are there any other options? Maybe it's time to make the SVG variant the official logo, and leave the blender file as a historical variant. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Review for initial systemd.eclass
Hello,
I'd like to submit an initial version of systemd.eclass, providing
helper functions for packages installing systemd unit files. Such
an eclass would be pushed to gx86 before first systemd packages
to control the packages installing upstream systemd units.
The eclass currently provides four functions:
- systemd_get_unitdir() which simply outputs the unitdir (for insinto),
- systemd_dounit() which installs the specified units into unitdir,
- systemd_enable_service() which symlinks service ${2} into target ${1},
creating that target if necessary,
- systemd_with_unitdir() which outputs
the '--with-systemdsystemunitdir' option as expected
by systemd-capable configure scripts.
The eclass currently assumes the following:
- systemd units are installed into /$(get_libdir)/systemd/system,
- systemd units are installed unconditionally.
Though it should be possible to change that behaviour within the eclass
without modifying the ebuild files.
I'm attaching the eclass file. It is also available in my devoverlay
[1].
[1]
http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=blob;f=eclass/systemd.eclass
--
Best regards,
Michał Górny
systemd.eclass
Description: Binary data
signature.asc
Description: PGP signature
