[gentoo-dev] linux-firmware (was: Re: Packages up for grabs due lack of time)
On Sun, 17 Feb 2013, Rick \Zero Chaos\ Farina wrote: I would be very happy to have the licensing issues fixed, it looks like it won't be fun, however I was originally told that redist was a required right for things to be added to linux-firmware at all so I fear a lot of things may be out of sync in the upstream package. IIUC, they require new additions to be redistributable, but don't remove old images if they're not. Which doesn't make sense. You should consider mirror restriction for this package. Ulrich
Re: [gentoo-dev] Packages up for grabs due lack of time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 17 Feb 2013 00:06:19 -0500 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/16/2013 10:11 AM, Ulrich Mueller wrote: Can we please stop removing individual firmware packages until sys-kernel/linux-firmware has proper license labels, and allows for selective installation? I would be very happy to have the licensing issues fixed, it looks like it won't be fun, however I was originally told that redist was a required right for things to be added to linux-firmware at all so I fear a lot of things may be out of sync in the upstream package. Please though, can we all stop pretending savedconfig doesn't exist? We allow for selective installation already, AND you can install none of it if you want, no one is forcing files on anyone that doesn't want them. savedconfig is a cheap hack. It lacks all the features USE flags have. Really. We're talking here about replacing well-organized packages with one cheap hack for the laziness of a few developers. But that's how Gentoo worked for a long time. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlEgq4IACgkQfXuS5UK5QB1t3AQAkIzPTeQNhqUTbKWc5PakR5sJ HYGBwYUi4j6Ljl7pQN/dDJaNmBy5rfRF3vyoIeglSt9IoHsNsDp+2bEY+easUx/W fAJPMgdGWg8u3/Sr/SgMzqFrJayiMZjqHKy6tPQFnCh9Kxx0HuP8/XBT1eyJkByY DfmO8DI/ps1rUKYpJcg= =X/fN -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs due lack of time
On 17/02/13 12:05, Michał Górny wrote: savedconfig is a cheap hack. It lacks all the features USE flags have. Really. We're talking here about replacing well-organized packages with one cheap hack for the laziness of a few developers. But that's how Gentoo worked for a long time. This is how you would justify adding separate ebuild for every firmware from the linux-firmware bundle? Please
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
Regarding licensing issues, maybe we could take fedora package as reference for clarifying firmware licenses and so: http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due lack of time
On Sun, 17 Feb 2013 12:09:22 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: On 17/02/13 12:05, Michał Górny wrote: savedconfig is a cheap hack. It lacks all the features USE flags have. Really. We're talking here about replacing well-organized packages with one cheap hack for the laziness of a few developers. But that's how Gentoo worked for a long time. This is how you would justify adding separate ebuild for every firmware from the linux-firmware bundle? I would justify it through keeping things split and bit-exact clean, instead of tightly integrated. Separate ebuilds mean that: - each firmware has proper license, - each firmware can be installed separately and it is _clean_ which firmwares are actually installed (think of binpkgs), - each firmware can be upgraded when it needs to be (alternatively: all firmwares are re-installed over and over again when new firmware is added). And I wouldn't mind having even 200 sys-firmware/ packages. And don't tell me that firmwares change every month, these are particularly maintenance-free packages. And I don't mind having meta-packages for lazy people. Although I believe that having a few 'group' packages for firmwares will be 'acceptable'. Assuming those firmwares share a common license. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] The status of the 'minor' arches in gentoo
In the last time I'm helping some other arches (also arches which I have no interest) because they appears understaffed. Days ago, I tried to make a virtual machine with qemu, for SH since the dev- machine[1] is a bit slow; well, I discovered we have no ISO[2] available and there is no handbook[3] for it. The same thing is for S390/S390X/M68K/. So how I am able to install one of that _supported_ arches if there isn't any sort of guide? An interesting fact is that we have an handbook for MIPS[4], a declared unsupported architecture (does not make sense for me). Another example is that we have no stable keyword on GCC/glibc for m68k and I don't know if I need to use another compiler or another libc. Checking on bugzilla I saw no report for some of those arches, so for me that _partially_ means that probably there are very few users for those arches on gentoo. Now, imho, we have 2 choice: 1)Support them with an iso or at least a manual if we can't do an handbook 2)Lose the stable keyword and don't waste manpower anymore. What do you think about? Ref: [1]: http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml [2]: http://www.gentoo.org/main/en/where.xml [3]: http://www.gentoo.org/doc/en/handbook/#doc_chap2 [4]: http://www.gentoo.org/doc/en/handbook/handbook- mips.xml?style=printablefull=1 -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sun, Feb 17, 2013 at 05:03:43PM +0100, Agostino Sarubbo wrote: Now, imho, we have 2 choice: 1)Support them with an iso or at least a manual if we can't do an handbook 2)Lose the stable keyword and don't waste manpower anymore. We also have another choice if there is so little interest in these arch's. 3) get rid of their keywords entirely. If there is no manual, no installation cd, no stages, and no supported way to install on an arch, why keep it? William pgpxKFHHJ_XFD.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
On Sun, Feb 17, 2013 at 7:08 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: 1.) No new firmware is being added to the linux kernel anymore, so this doesn't apply at all. Of course it applies — interaction of make modules_install with emerging linux-firmware can result in collisions. And before you write yet another dismissive email — yes, I know that for users not using savedconfig there will most likely be no collisions due to kernel's modules_install overwriting existing files. 2.) Fun fact but I don't see how that make much difference to anyone or this thread. It is relevant in the sense that it is not straightforward to prevent the kernel from installing firmware in /lib/firmware, which might result in collisions. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
Maxim Kammerer schrieb: On Sat, Feb 16, 2013 at 8:14 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Kernel sources providing /lib/firmware itself shouldn't be a problem either, as that's just a dir, which many packages may own. The individual firmware files would be a problem, but the USE=firmware RDEPEND solution should solve that. What is everyone's opinion of adding a USE=firmware option to pull in PDEPEND=linux-firmware in linux-2.eclass? Not exactly an opinion, but a couple of notes: 1. Kernel's make modules_install triggers make firmware_install, which installs a strict subset of linux-firmware (for enabled modules — e.g., 3com/typhoon.bin). A way to work around that is to supply INSTALL_FW_PATH=... to make. Most if not all such conflicts can be avoided by USE=deblob Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
Rick Zero_Chaos Farina schrieb: What is everyone's opinion of adding a USE=firmware option to pull in PDEPEND=linux-firmware in linux-2.eclass? No, USE flags that trigger only dependencies and do not change the package should be restricted to virtuals or metapackages, with as few exceptions as possible. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Packages up for grabs due lack of time
Diego Elio Pettenò schrieb: On 16/02/2013 14:08, Pacho Ramos wrote: sys-firmware/iwl3945-ucode sys-firmware/iwl4965-ucode Are these included in linux-firmware (i.e. could we just remove them) or not? These are included in linux-firmware. And because Intel has EOL'ed the chipsets, it is unlikely that the firmware will ever be updated again. So technically there is no necessity to keep them. On the non-technical side, there are users who prefer them over the linux-firmware package and will be upset if we remove them. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Packages up for grabs due lack of time
Peter Stuge schrieb: linux-firmware is okey but not great. The high resolution is there, which was my main concern, but it's not so easy to know how to create a savedconfig without installing the package. Just create a text file /etc/portage/savedconfig/sys-kernel/linux-firmware with the desired filename(s) and emerge linux-firmware with USE=savedconfig enabled. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
Am Sonntag, 17. Februar 2013, 17:03:43 schrieb Agostino Sarubbo: In the last time I'm helping some other arches (also arches which I have no interest) because they appears understaffed. Days ago, I tried to make a virtual machine with qemu, for SH since the dev- machine[1] is a bit slow; well, I discovered we have no ISO[2] available and there is no handbook[3] for it. Not having an ISO is not really an issue. After all CD drives are something fairly modern :D... Joking aside, I can imagine architectures where it's preferable to set up a stage directly from a running maintenance system (maybs s390???). Also, none of my arm gadgets comes with a CD drive, so I had to e.g. prepare the stage on a memory card with another box. That said, blindly stabilizing more and more stuff on dying arches certainly is a waste of time. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Hi all I'm taking a look at etherpad-lite ebuild at https://bugs.gentoo.org/show_bug.cgi?id=328897 It's a pretty big of a mess, but as I'm searching around, I can't really find any guidelines on how nodejs / npm stuff is supposed fit in with Portage. dev-nodejs/ doesn't even exist. Is this nodejs beast too new? Anyone care to point me in some direction with this?
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sun, Feb 17, 2013 at 12:45 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Joking aside, I can imagine architectures where it's preferable to set up a stage directly from a running maintenance system (maybs s390???). Also, none of my arm gadgets comes with a CD drive, so I had to e.g. prepare the stage on a memory card with another box. I wonder if there is a market for selling pre-imaged core planes with Gentoo in ramfs? Rich
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2013 04:03 PM, Agostino Sarubbo wrote: In the last time I'm helping some other arches (also arches which I have no interest) because they appears understaffed. Days ago, I tried to make a virtual machine with qemu, for SH since the dev- machine[1] is a bit slow; well, I discovered we have no ISO[2] available and there is no handbook[3] for it. The same thing is for S390/S390X/M68K/. So how I am able to install one of that _supported_ arches if there isn't any sort of guide? An interesting fact is that we have an handbook for MIPS[4], a declared unsupported architecture (does not make sense for me). Another example is that we have no stable keyword on GCC/glibc for m68k and I don't know if I need to use another compiler or another libc. Checking on bugzilla I saw no report for some of those arches, so for me that _partially_ means that probably there are very few users for those arches on gentoo. Now, imho, we have 2 choice: 1)Support them with an iso or at least a manual if we can't do an handbook 2)Lose the stable keyword and don't waste manpower anymore. What do you think about? Ref: [1]: http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml [2]: http://www.gentoo.org/main/en/where.xml [3]: http://www.gentoo.org/doc/en/handbook/#doc_chap2 [4]: http://www.gentoo.org/doc/en/handbook/handbook- mips.xml?style=printablefull=1 First you need to tell us what arches you think they are considered 'minor' and/or understaffed so we can finally document that. Then, in my opinion, the ideal approach would be to just drop the stable keywords for them. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJRITEwAAoJEPqDWhW0r/LCiiQP/2vpx4QuEgJqB3vYpcmmYcwa jLleJnWeat/IsVx3cH28Wy0fLra4MWe8sTGDjtbNBnZZ1z59Fep2Nk/8z3KpoBI0 gcKzRinBbqhDjUmoJDQGW16zvTrNWmkAfwkclPTM8v3mJKFl01pODcJUgAk7UrLM NVLyp3OpToF7ZTrJr+lFeHEUB88vcdfnMeV3bM3XZEfifL5cabzUjVibL08utaz2 zYL9Rn6UMmzZvYTSrnsOBTOt2uI8ptzp9Ih7mRI5zt8aKrQd5vCYZ/aLXvObF+64 ZTjxzMWAC8GbXqQxXAQ/VNKryFyDV8OKj39QsQwoxLNMIV4Pg4Yc1u+fJMqXTu+X nXyvHMM/lcHq6h37E2ua1BjL0tLZGq4kxsGgKuSCzt7gwNAoyCE7eY1V5qFk/uAL U4ATVsY2Q4mKFdu2FlHbn4LfY9D7Rn3OlJhbA2J7108g4BMm70Q++qrxSBAj1xGu VobIkvg5E73Jb3sbcdOS1QOk5cviev4LTh3HjWO6Ozc4HkhdpWk/NlqmQ9SN7J6b hz5sVyV1vPI5/19kfAjBaMotlmLjhq+WgAYRZfeeXJbV/hWXz96eigoxT5n7FbM6 aeZKG2Oj8CD0ndH+nf0bg/dACmGJwVnSRBV5iQSuEFO+kLnANRtYEBicjBR92WaJ LiRb4ul/HhURsWeCgIqU =SsrL -END PGP SIGNATURE-
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 19:36:16 Markos Chandras wrote: First you need to tell us what arches you think they are considered 'minor' and/or understaffed so we can finally document that. Then, in my opinion, the ideal approach would be to just drop the stable keywords for them. http://www.gentoo.org/proj/en/base/index.xml#doc_chap4 I don't see project page for: m68k, sh, s390 20:41 ago expn m68k 20:41 willikins m68k = vapier, 20:41 ago expn sh 20:42 willikins sh = vapier,matsuu,armin76,ago, 20:42 ago expn s390 20:42 willikins s390 = vapier,armin76,ago, -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2013 07:43 PM, Agostino Sarubbo wrote: On Sunday 17 February 2013 19:36:16 Markos Chandras wrote: First you need to tell us what arches you think they are considered 'minor' and/or understaffed so we can finally document that. Then, in my opinion, the ideal approach would be to just drop the stable keywords for them. http://www.gentoo.org/proj/en/base/index.xml#doc_chap4 I don't see project page for: m68k, sh, s390 20:41 ago expn m68k 20:41 willikins m68k = vapier, 20:41 ago expn sh 20:42 willikins sh = vapier,matsuu,armin76,ago, 20:42 ago expn s390 20:42 willikins s390 = vapier,armin76,ago, I am not sure what are you trying to prove here. No project page does not mean the arch is minor or dead or whatever. Moreover, you see that there are devs in these arches. Did you try to talk to them? I also asked for a list of minor arches and you didn't provide one. I presume, you think that m68k, sh, and s390 are minor? What about ia64, ppc? Do we have enough manpower there? Because iirc there arches also lack in stabilization bugs as well. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJRITvoAAoJEPqDWhW0r/LC+rwQAL366SHQxH5Q//cR7HFmYTrE epB02TpQPNkwp25fn5eFqX3Y3xrvPyLKbIh2dnCV+Z+i4oRV49QDW5SXlGfF2HlW yvopL2wf5D9eaYri28pnAqW3SQxX/bdUun1k2erpR7YwNlP7pyeIKvlL9/62kXgR qkHYbRa8ZOwkM+kFU66ZwwjGFgMdKvoq7psU6Lj5bnscuFYbevWCGXfNMf10QaYf 6EhsEPt7N3jO+z0pk2DQdZ/L7eA4XXxcnRxBSKQIuN9bwf1hX1c8JP+puAmx69zr 34uNcS5K6AtvBoALcuIsSI5e2uU4GYEMPEmRNqsfR6z/pzs8um/Pp/UKEiqesK7W tqs3D6r+wiEL2/T9QByDUCNXouUUoAEtFlw/ugE2MTgx2AGAu0iMZBFDqZjn8Ptx 4pJpCrCONUPHVis1nfehlZZTwoQXB09C1yFP5qVN5i+pUKpfzINUeaICR5vLarbY ul158Wc9ps7pyZJkLlKrv3/Fz5wCnVgQ2NY1nUG++vmPtJMAaWUwoU465aMDb67z oyVvgfKvUA9t1jgLXMkg7NWqieI5YtTM8Qvx5U7X5weGCPZA8LF5DpJZG8OacAv6 6Qm2L4YuIMsT9YMZ1AxeSrlVZ/DNYkrtonQN6CMEhW0Dw/n9IF+ydHvzWqZPELYv L3HtIc+uEFQOe8/IrgPn =hsQ7 -END PGP SIGNATURE-
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 20:22:00 Markos Chandras wrote: I am not sure what are you trying to prove here. I point out that there is not iso, no manual, no manpower. No project page does not mean the arch is minor or dead or whatever. For me this means that there is no enough support. Moreover, you see that there are devs in these arches. Did you try to talk to them? For what purpose? I'm asking a general opinion based on some facts. I also asked for a list of minor arches and you didn't provide one. I presume, you think that m68k, sh, and s390 are minor? Yes, they can be. Seriously, who has an m68k? do you see reports/requests on bugzilla? What about ia64, ppc? Do we have enough manpower there? Because iirc there arches also lack in stabilization bugs as well. https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20keywords_type=allwordsf1=cco1=equalsquery_format=advancedbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSv1=ppc%40gentoo.orgproduct=Gentoo%20Linuxlist_id=1560890 https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20keywords_type=allwordsf1=cco1=equalsquery_format=advancedbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSv1=ia64%40gentoo.orgproduct=Gentoo%20Linuxlist_id=1560892 I don't see big queue for those arches. -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Leho Kraav wrote: I'm taking a look at etherpad-lite ebuild at https://bugs.gentoo.org/show_bug.cgi?id=328897 It's a pretty big of a mess, but as I'm searching around, I can't really find any guidelines on how nodejs / npm stuff is supposed fit in with Portage. dev-nodejs/ doesn't even exist. Is this nodejs beast too new? Anyone care to point me in some direction with this? Not many nodejs fans in Gentoo land it seems. My suggestion would be to make it all work and neat in an overlay, then see if you can convince someone to add it into the tree, or I guess proxy. The dependency list sure is long. :( I made an effort with the scala one but hit a roadblock with a magic circular dependency between two java packages one of which would need to be split into two ebuilds - which was too much java surgery for me to manage. I might be able help with the MySQL problem, but yeah, if I had time I would make an etherpad overlay with dev-nodejs/ and all those deps. //Peter
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sun, Feb 17, 2013 at 11:43 AM, Agostino Sarubbo a...@gentoo.org wrote: On Sunday 17 February 2013 19:36:16 Markos Chandras wrote: First you need to tell us what arches you think they are considered 'minor' and/or understaffed so we can finally document that. Then, in my opinion, the ideal approach would be to just drop the stable keywords for them. http://www.gentoo.org/proj/en/base/index.xml#doc_chap4 I don't see project page for: m68k, sh, s390 20:41 ago expn m68k 20:41 willikins m68k = vapier, 20:41 ago expn sh 20:42 willikins sh = vapier,matsuu,armin76,ago, 20:42 ago expn s390 20:42 willikins s390 = vapier,armin76,ago, Afaik sh and s390 were both vapier-driven projects. I'd recommend chatting with him as to whether they are worth salvaging. It is not clear to me why you would email the -dev list about these arches, vapier is pretty responsive over email and irc. -A -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 13:14:28 Alec Warner wrote: It is not clear to me why you would email the -dev list about these arches, vapier is pretty responsive over email and irc. I don't guess is a good idea have a private conversation and then drop an arch... -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
[gentoo-dev] Re: [gentoo-dev-announce] Qt category move
On 16/02/2013 13:08, Ben de Groot wrote: Questions can be directed to our IRC channel #gentoo-qt or email q...@gentoo.org So what's the final word on the move? dev-qt/core or dev-qt/qt-core ? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2013 08:40 PM, Agostino Sarubbo wrote: On Sunday 17 February 2013 20:22:00 Markos Chandras wrote: I am not sure what are you trying to prove here. I point out that there is not iso, no manual, no manpower. No manual does not mean no manpower. Moreover, you see that there are devs in these arches. Did you try to talk to them? For what purpose? I'm asking a general opinion based on some facts. The first step you need to do when you seek activity reports is to contact the teams/project members. I also asked for a list of minor arches and you didn't provide one. I presume, you think that m68k, sh, and s390 are minor? Yes, they can be. Seriously, who has an m68k? do you see reports/requests on bugzilla? I don't know who has or has not. What's the point of that question? - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJRIU1IAAoJEPqDWhW0r/LCTG0P/jivkqRVcE7P8vzEICpasSVa QmtTuRbORoEw5EANan+X3kEFNPmdZKpbvCXx1VIksgwUkJ2KNeVe37yGxPi99siF 267nqKOOcGYDidsfLkDLCnh2i1iFPRypT+D3ViaQUff5q4xEocI2WFYdZa1pJRCW fMP1gyirBRxYGOzmfZKzufbXrjh9I9F/w5wYQYx5tPG9DK5lDrBshlQOkIcIzmfQ NezWgKd5yAkdFtkVrGi2gZJPoInpOM7wGBLqr85JPj37jl448EvJsw7nyk7yHr3I lG0jsjKfyRSFk/ZSQ0KofPNGo8CO4NlcjzJWe9S73d8xocqtT1IG1C0Xv4yh/roW hv9q5S59i4OHBAtAb6GhGMLps61L4tBuHdRz48pMvMTGgoUzGCRe5EuuHx+nrTpd DulDjzrHhkcjkT2vOeO+cGneoKambEYkKpmgLVDBJGNrSBAfa7UJKq4YCTFQa3jx uf8ShsWjLQDph2hV2APaPHA3vkkI3jAmPimgxAhnRxbVzfrifvqcWmutDLGyVJoM 6YHEgnDQzogMVokmpv7p7GfQPptKhx0lZZxvuedGVFOaCNOcj6GQIwYSycR8/OLn lv+IiRLBSmDnlrf4lgnb4Y/i2fxE7ykF5OFGOmND0zmmkHzdagTzTkR7DWx14/yd N2mOXhpIq0O/pdiXJEwU =SO73 -END PGP SIGNATURE-
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2013 09:30 PM, Agostino Sarubbo wrote: On Sunday 17 February 2013 13:14:28 Alec Warner wrote: It is not clear to me why you would email the -dev list about these arches, vapier is pretty responsive over email and irc. I don't guess is a good idea have a private conversation and then drop an arch... Drop an arch? Who said that? We are talking about moving arches to ~testing. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJRIU10AAoJEPqDWhW0r/LCf0AQAMVJMM1qXWaPkAM2fKSOJ7cJ bVXSHkdwEOLT1ubtHl1mI+WVldsmo6InZKEoWb/NmMz0bc0a3V3ppwpoUqr5afmG Z056nc6geXQE9ipj9FWAhluD9uCY8mlmw7NHzs/AAhWWyMqf9Vt0sS2so/qnVPrM VA/dkVzJHpKvwaIOBSZzL5cci6qMEKG5LjZkbkHdFmZMYrSftcsdVREdOCsWE3Az uYvS2kV5AUeZknZUPRhB63LYnJBU+QrQRUK+tz9UH59K3u8aeaxUjIvKGtD+xdZp h9yy6+4VbA7Ox2MQLi46SVIBD8ulOWyEAnT2v3bEHpyA31O3fYDivyyJ9SlnaFBc 74Rgr2mTyVOIZ1a58CTGJzRiZzND97of1dXTKap046ggVobf/ZFILzHKKGmKN1Ui lN1MKA2ODpgozA8jU1STPLY+VKP38fw2mbBIAMcWPftiNq3FUg4/AF6gO7IlX0SO rNH2k/bogb4oEy089vUW7jz+CUYORcGcDKLsZ76RnCx4GWun86fn6LTgwo9TlkNS koKpAYnCyXCMOC0WsiDxO6Xo29HhpAqJV0d4Y40onhm24UGo6HK9WAf24ATip5pG o9WI0kTWXkTdSVNtjzmtVSKh+GHg3Fbemv9p/IF4KO6hc+/6W3xbv/4tFRP3VFsF ThFGF+0qZ/3TIEMgxKy+ =A2Sr -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Qt category move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2013 09:35 PM, Diego Elio Pettenò wrote: On 16/02/2013 13:08, Ben de Groot wrote: Questions can be directed to our IRC channel #gentoo-qt or email q...@gentoo.org So what's the final word on the move? dev-qt/core or dev-qt/qt-core ? We will use qt* instead of qt-*[1] to match the way upstream names the modules. So that would be dev-qt/qtcore etc [1]: http://wiki.gentoo.org/wiki/Project:Qt/Meeting/2013-01#2._Qt_category_move - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJRIVPXAAoJEPqDWhW0r/LCmrEP/3d/zfRu0MlC9hN18+OM9J6f RE0dNyr/12JOsUmzckkeJI42N854x6fUxJBuOr8EuhMzaxhsAG64bQPDdgwSgFl7 iFh2Qv/2RcV7keB7AMr/E3iIAupleW20pes9Da20AS335BMcrR+3EQIiGzlx4BWv V7Czzyo+XbiobYuV4N5rywTnvOtbYzbtQxrKqf8FwoAoN7afHoSc4SbsskmaECG3 fOM1FWDuFZe/r4KwNs1jXf0XH2fthA+aFe3ty8Nzvt1xynrQvj0MZHQ0T/9ea92e SAYKU3C02fjrhf2T8qYLq8UTioFurF+FIHJ7tC2DFB1BiXHS7a2Hk9xWL63emta7 qdw5+E2DslCejZ+tkd/uVRUNRoNR19zWl8+tdK5T9gwJXpSyjw/tBl3ilYAcfz7V qojXPl7/4TI5Y57vkxb4dY/96PRANzUb2uP/RK0gsVExcEHRiJ1pYd8CpwZdfcs0 vSljNB8BfN8F0aOZNJbsLzgCcM0I4aeGABJUKc221QaruqW05kdFMxy1ipvgaYOA zdMx10+SUhdXiacj80aP7pKVBS+7By388yJaAQuzoUhIwzoezbTslxbCzjjWhvap JCGx4hGuR0L45KlsSc2YufQ2S/cu9q307pxAdXDk7EPqkmG3q7IbHAGt/V7iIfA5 NAUExBCV0QPMl+FHq4v6 =Ma9a -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Qt category move
On 17/02/2013 23:04, Markos Chandras wrote: We will use qt* instead of qt-*[1] to match the way upstream names the modules. So that would be dev-qt/qtcore etc Thanks, and thanks for the link, as I wouldn't have known how to rename the deps myself otherwise... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On 02/17/2013 11:03 AM, Agostino Sarubbo wrote: In the last time I'm helping some other arches (also arches which I have no interest) because they appears understaffed. Days ago, I tried to make a virtual machine with qemu, for SH since the dev- machine[1] is a bit slow; well, I discovered we have no ISO[2] available and there is no handbook[3] for it. The same thing is for S390/S390X/M68K/. So how I am able to install one of that _supported_ arches if there isn't any sort of guide? An interesting fact is that we have an handbook for MIPS[4], a declared unsupported architecture (does not make sense for me). I am supporting mips for the Lemote loongson2f and for the Atheros AR7161. I'm trying to get my hands on a godson and Stuart will be sending me two fulongs, which you can add to that list. Don't let the fact that MIPS is a ~arch fool you. I don't think we should make it a fully supported arch because of the number of ISA's and ABI's and endiannesses (if such a word exists). It is impossible to test for all combos which is what stable should mean. So don't even think of dropping MIPS! Just leave it ~arch and I'll give it love. As far as the other arches go, I'm interested in: amd64, arm, mips, ppc, ppc64 and x86. Another example is that we have no stable keyword on GCC/glibc for m68k and I don't know if I need to use another compiler or another libc. Checking on bugzilla I saw no report for some of those arches, so for me that _partially_ means that probably there are very few users for those arches on gentoo. Now, imho, we have 2 choice: 1)Support them with an iso or at least a manual if we can't do an handbook ISOs don't make sense on all hardware. Eg. I offer an netboot image for the lemotes. 2)Lose the stable keyword and don't waste manpower anymore. I agree, but please keep at least the ones I mention above. Other devs may have different ideas. What do you think about? Ref: [1]: http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml [2]: http://www.gentoo.org/main/en/where.xml [3]: http://www.gentoo.org/doc/en/handbook/#doc_chap2 [4]: http://www.gentoo.org/doc/en/handbook/handbook- mips.xml?style=printablefull=1 -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le dimanche 17 février 2013 à 21:08 +0200, Leho Kraav a écrit : Hi all I'm taking a look at etherpad-lite ebuild at https://bugs.gentoo.org/show_bug.cgi?id=328897 It's a pretty big of a mess, but as I'm searching around, I can't really find any guidelines on how nodejs / npm stuff is supposed fit in with Portage. dev-nodejs/ doesn't even exist. Is this nodejs beast too new? Anyone care to point me in some direction with this? I have package some nodejs stuff related to rethinkdb in my overlay if you want to have a look. Namely lessc and coffee-script. There is close to no packaging (let alone decent) with nodejs apps but if you are motivated enough, maybe there is something to explore from how npm works and map that to an eclass. Usual disclosure about overlays applies. http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=summary -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
On 18/02/2013 00:39, Gilles Dartiguelongue wrote: I have package some nodejs stuff related to rethinkdb in my overlay if you want to have a look. Namely lessc and coffee-script. There is close to no packaging (let alone decent) with nodejs apps but if you are motivated enough, maybe there is something to explore from how npm works and map that to an eclass. Oh god why does it need static-libs on google-perftools? That's calling for trouble. But I guess I have to restore that crap :( -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le lundi 18 février 2013 à 00:42 +0100, Diego Elio Pettenò a écrit : On 18/02/2013 00:39, Gilles Dartiguelongue wrote: I have package some nodejs stuff related to rethinkdb in my overlay if you want to have a look. Namely lessc and coffee-script. There is close to no packaging (let alone decent) with nodejs apps but if you are motivated enough, maybe there is something to explore from how npm works and map that to an eclass. Oh god why does it need static-libs on google-perftools? That's calling for trouble. But I guess I have to restore that crap :( No you don't :) rethinkdb is a young project and its build system is a 1.5k lines makefile horror. I wouldn't reintroduce stuff that isn't used in tree just for this. I, at least, am not interested in moving this to the tree. I just added it to my overlay for a testing work stuff and that need is gone for now :). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: [gentoo-dev-announce] Qt category move
On Sun, Feb 17, 2013 at 2:08 PM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
On 17/02/2013 23:04, Markos Chandras wrote:
We will use qt* instead of qt-*[1] to match the way upstream names the
modules. So that would be dev-qt/qtcore etc
Thanks, and thanks for the link, as I wouldn't have known how to rename
the deps myself otherwise...
Three notable exceptions to the general rule of dropping the hyphen
from ${PN} are:
qt-assistant - qthelp (because the lib is actually called
libQtHelp.so, the assistant application will be split into a separate
package later on)
qt-qt3support - qt3support (again, the lib is libQt3Support.so)
qt-meta stays unchanged (not an upstream module, therefore it follows
gentoo *-meta naming convention, nothing should depend on the
meta-package anyway)
Cheers,
Pesa
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-02-17 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-02-17 23h59 UTC. Removals: media-tv/ivtv-firmware 2013-02-11 05:02:06 cardoe net-wireless/zd1201-firmware2013-02-11 14:15:51 ssuominen net-wireless/zd1211-firmware2013-02-11 14:15:51 ssuominen dev-php/ezc-Archive 2013-02-11 14:26:11 olemarkus dev-php/ezc-Authentication 2013-02-11 14:26:11 olemarkus dev-php/ezc-AuthenticationDatabaseTiein 2013-02-11 14:26:11 olemarkus dev-php/ezc-Cache 2013-02-11 14:26:12 olemarkus dev-php/ezc-Configuration 2013-02-11 14:26:12 olemarkus dev-php/ezc-ConsoleTools2013-02-11 14:26:12 olemarkus dev-php/ezc-Database2013-02-11 14:26:12 olemarkus dev-php/ezc-DatabaseSchema 2013-02-11 14:26:12 olemarkus dev-php/ezc-Debug 2013-02-11 14:26:13 olemarkus dev-php/ezc-Document2013-02-11 14:26:13 olemarkus dev-php/ezc-EventLog2013-02-11 14:26:13 olemarkus dev-php/ezc-EventLogDatabaseTiein 2013-02-11 14:26:13 olemarkus dev-php/ezc-Execution 2013-02-11 14:26:13 olemarkus dev-php/ezc-Feed2013-02-11 14:26:14 olemarkus dev-php/ezc-File2013-02-11 14:26:14 olemarkus dev-php/ezc-GraphDatabaseTiein 2013-02-11 14:26:14 olemarkus dev-php/ezc-ImageAnalysis 2013-02-11 14:26:15 olemarkus dev-php/ezc-ImageConversion 2013-02-11 14:26:15 olemarkus dev-php/ezc-Mail2013-02-11 14:26:16 olemarkus dev-php/ezc-MvcAuthenticationTiein 2013-02-11 14:26:16 olemarkus dev-php/ezc-MvcFeedTiein2013-02-11 14:26:16 olemarkus dev-php/ezc-MvcMailTiein2013-02-11 14:26:16 olemarkus dev-php/ezc-MvcTemplateTiein2013-02-11 14:26:16 olemarkus dev-php/ezc-MvcTools2013-02-11 14:26:16 olemarkus net-wireless/ipw2100-firmware 2013-02-11 14:26:16 ssuominen net-wireless/ipw2200-firmware 2013-02-11 14:26:17 ssuominen dev-php/ezc-PersistentObject2013-02-11 14:26:17 olemarkus dev-php/ezc-PersistentObjectDatabaseSchemaTiein 2013-02-11 14:26:17 olemarkus dev-php/ezc-PhpGenerator2013-02-11 14:26:18 olemarkus dev-php/ezc-Search 2013-02-11 14:26:18 olemarkus dev-php/ezc-SignalSlot 2013-02-11 14:26:18 olemarkus dev-php/ezc-SystemInformation 2013-02-11 14:26:18 olemarkus dev-php/ezc-Template2013-02-11 14:26:19 olemarkus dev-php/ezc-TemplateTranslationTiein2013-02-11 14:26:19 olemarkus dev-php/ezc-Translation 2013-02-11 14:26:19 olemarkus dev-php/ezc-TranslationCacheTiein 2013-02-11 14:26:19 olemarkus dev-php/ezc-Tree2013-02-11 14:26:19 olemarkus dev-php/ezc-TreeDatabaseTiein 2013-02-11 14:26:20 olemarkus dev-php/ezc-TreePersistentObjectTiein 2013-02-11 14:26:20 olemarkus dev-php/ezc-Url 2013-02-11 14:26:20 olemarkus dev-php/ezc-UserInput 2013-02-11 14:26:20 olemarkus dev-php/ezc-Webdav 2013-02-11 14:26:21 olemarkus dev-php/ezc-Workflow2013-02-11 14:26:21 olemarkus dev-php/ezc-WorkflowDatabaseTiein 2013-02-11 14:26:21 olemarkus dev-php/ezc-WorkflowEventLogTiein 2013-02-11 14:26:21 olemarkus dev-php/ezc-WorkflowSignalSlotTiein 2013-02-11 14:26:22 olemarkus dev-php/ezc-eZcomponents2013-02-11 14:26:22 olemarkus app-vim/threesome 2013-02-12 10:46:48 radhermit app-vim/bufferexplorer 2013-02-12 11:10:57 radhermit net-wireless/bluez-firmware 2013-02-12 16:01:23 ssuominen net-wireless/atmel-firmware 2013-02-13 18:48:06 ssuominen net-wireless/b43-firmware 2013-02-13 18:57:01 ssuominen net-wireless/b43legacy-firmware 2013-02-13 18:57:01 ssuominen net-wireless/rt61-firmware 2013-02-14 22:30:10 ssuominen net-misc/gtk-youtube-viewer 2013-02-16 23:09:33 hasufell Additions: sci-libs/libspatialindex
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
On 18/02/2013 00:46, Gilles Dartiguelongue wrote: rethinkdb is a young project and its build system is a 1.5k lines makefile horror. I wouldn't reintroduce stuff that isn't used in tree just for this. I, at least, am not interested in moving this to the tree. I just added it to my overlay for a testing work stuff and that need is gone for now :). It was in my TODO anyway as I was asked about it before. I guess I'll re-introduce it under p.use.mask until it's actually needed. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: The status of the 'minor' arches in gentoo
Markos Chandras posted on Sun, 17 Feb 2013 21:36:53 + as excerpted: On 02/17/2013 09:30 PM, Agostino Sarubbo wrote: On Sunday 17 February 2013 13:14:28 Alec Warner wrote: It is not clear to me why you would email the -dev list about these arches, vapier is pretty responsive over email and irc. I don't guess is a good idea have a private conversation and then drop an arch... Drop an arch? Who said that? We are talking about moving arches to ~testing. Time again for the periodic minor archs discussion, apparently... While I have no direct personal interest in anything under discussion here, two observations, FWIW... 1) Having the private conversation (presumably with vapier) first, collecting information that could then go in the post to -dev, would seem useful. Doing anything without talking to him first is inappropriate in any case (as would be doing anything without a discussion on -dev, both would seem required), and that would have made the -dev conversation more useful, sooner. 2) That said, without pre-existing knowledge, no project page and etc makes it difficult to even find the person one should have a conversation with, in which case mailing -dev is at least some way to initialize the conversation. At least a stub project page, with contact info and some minimal description of the arch, perhaps a link to its page on wikipedia, when the project was started on gentoo and its goals, etc, could be useful. Which brings us full circle to the initial post, no project page or contact info, let's change that, either creating at least some minimal project pages with contact info at minimum (preferred if they are to be kept), or if that's considered not worth the bother, then really, why are they worth the bother to other gentooers at all, they should be dropped? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Packages up for grabs due lack of time
On Sun, 17 Feb 2013 18:40:10 +0100 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Peter Stuge schrieb: linux-firmware is okey but not great. The high resolution is there, which was my main concern, but it's not so easy to know how to create a savedconfig without installing the package. Just create a text file /etc/portage/savedconfig/sys-kernel/linux-firmware with the desired filename(s) and emerge linux-firmware with USE=savedconfig enabled. He means that until you install the package with all firmware enabled you don't know what lines you need to put into the savedconfig file. Even after you do that it's hard to figure out what firmware files you actually need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but linux-firmware contains: iwlwifi-6000-4.ucode iwlwifi-6000g2a-5.ucode iwlwifi-6000g2a-6.ucode iwlwifi-6000g2b-5.ucode iwlwifi-6000g2b-6.ucode Are these different versions? Different cards? Which do I need? I had to go back and reinstall sys-firmware/iwl6000-ucode to see which file was the right one. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Re: Packages up for grabs due lack of time
On Sun, 17 Feb 2013 12:42:11 +0100 Michał Górny mgo...@gentoo.org wrote: I would justify it through keeping things split and bit-exact clean, instead of tightly integrated. Separate ebuilds mean that: - each firmware has proper license, - each firmware can be installed separately and it is _clean_ which firmwares are actually installed (think of binpkgs), - each firmware can be upgraded when it needs to be (alternatively: all firmwares are re-installed over and over again when new firmware is added). And I wouldn't mind having even 200 sys-firmware/ packages. And don't tell me that firmwares change every month, these are particularly maintenance-free packages. And I don't mind having meta-packages for lazy people. Although I believe that having a few 'group' packages for firmwares will be 'acceptable'. Assuming those firmwares share a common license. I very much agree with all of this. It would be nice if we could keep the individual firmware packages but just have them be a wrapper that depends on linux-firmware and ensures that the required files get installed (maybe by adding them to the savedconfig if it finds they aren't there). Yes, there are several problems with that idea, I know. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] depgraph: tweak required by message format
The current output format for listing a chain of dependencies produces one long flat line that can be hard to read. For example, if you mask dev-lang/ruby and then try to install dev-ruby/json, you'll see: The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) =dev-lang/ruby-1.9.3_p385 =dev-lang/ruby-1.8.7_p371 Tracing your way through that list is not easy. Instead, let's use newlines and now we get: The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) =dev-lang/ruby-1.9.3_p385 =dev-lang/ruby-1.8.7_p371 Signed-off-by: Mike Frysinger vap...@gentoo.org --- pym/_emerge/depgraph.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py index bab1c32..6f7b673 100644 --- a/pym/_emerge/depgraph.py +++ b/pym/_emerge/depgraph.py @@ -3617,7 +3617,7 @@ class depgraph(object): else: display_list.append(required by %s % node) - msg = # + , .join(display_list) + \n + msg = # + \n# .join(display_list) + \n return msg -- 1.8.1.2
Re: [gentoo-portage-dev] [PATCH] depgraph: tweak required by message format
On 02/17/2013 06:21 PM, Mike Frysinger wrote: The current output format for listing a chain of dependencies produces one long flat line that can be hard to read. For example, if you mask dev-lang/ruby and then try to install dev-ruby/json, you'll see: Looks like the comments got stripped by git-commit or something. Anyway, looks good to me. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH] depgraph: tweak required by message format
On Sunday 17 February 2013 22:18:30 Zac Medico wrote: On 02/17/2013 06:21 PM, Mike Frysinger wrote: The current output format for listing a chain of dependencies produces one long flat line that can be hard to read. For example, if you mask dev-lang/ruby and then try to install dev-ruby/json, you'll see: Looks like the comments got stripped by git-commit or something. ah, so it did. i'll fix that. -mike signature.asc Description: This is a digitally signed message part.
