[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/ghostscript-gpl: metadata.xml ChangeLog ghostscript-gpl-9.04-r4.ebuild
On 11/12/2011 12:21 PM, Justin Lecher (jlec) wrote: > jlec11/11/12 10:21:37 > > Modified: metadata.xml ChangeLog > ghostscript-gpl-9.04-r4.ebuild > Log: > Fixed slotting for media-libs/tiff > > (Portage version: 2.2.0_alpha73/cvs/Linux x86_64) > > Revision ChangesPath > 1.3 app-text/ghostscript-gpl/metadata.xml > > file : > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&view=markup > plain: > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&content-type=text/plain > diff : > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?r1=1.2&r2=1.3 > > Index: metadata.xml > === > RCS file: /var/cvsroot/gentoo-x86/app-text/ghostscript-gpl/metadata.xml,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- metadata.xml 2 Jun 2011 09:59:25 - 1.2 > +++ metadata.xml 12 Nov 2011 10:21:37 - 1.3 > @@ -1,8 +1,8 @@ > > http://www.gentoo.org/dtd/metadata.dtd";> > > -printing > - > -Disable dejavu support for binary distribution > because of licensing issue > - > + printing > + > + Disable dejavu support for binary > distribution because of licensing issue > + > I wonder what that has to do with "Fixed slotting for media-libs/tiff"? Do we have a guideline or policy on using 2 spaces vs. tabs in .xml files and gentoo-x86? Just asking because I prefer 2 spaces over tabs.
[gentoo-dev] Lastrite: net-p2p/bittornado
# Samuli Suominen (12 Nov 2011) # Masked for removal in 30 days since wxpython-2.6 is going away wrt bug 330683 net-p2p/bittornado
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/ghostscript-gpl: metadata.xml ChangeLog ghostscript-gpl-9.04-r4.ebuild
On 11/12/11 11:25 AM, Samuli Suominen wrote: > On 11/12/2011 12:21 PM, Justin Lecher (jlec) wrote: >> jlec11/11/12 10:21:37 >> >> Modified: metadata.xml ChangeLog >> ghostscript-gpl-9.04-r4.ebuild >> Log: >> Fixed slotting for media-libs/tiff >> >> (Portage version: 2.2.0_alpha73/cvs/Linux x86_64) >> >> Revision ChangesPath >> 1.3 app-text/ghostscript-gpl/metadata.xml >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?r1=1.2&r2=1.3 >> >> Index: metadata.xml >> === >> RCS file: /var/cvsroot/gentoo-x86/app-text/ghostscript-gpl/metadata.xml,v >> retrieving revision 1.2 >> retrieving revision 1.3 >> diff -u -r1.2 -r1.3 >> --- metadata.xml 2 Jun 2011 09:59:25 - 1.2 >> +++ metadata.xml 12 Nov 2011 10:21:37 - 1.3 >> @@ -1,8 +1,8 @@ >> >> http://www.gentoo.org/dtd/metadata.dtd";> >> >> -printing >> - >> -Disable dejavu support for binary distribution >> because of licensing issue >> - >> +printing >> + >> +Disable dejavu support for binary >> distribution because of licensing issue >> + >> > > I wonder what that has to do with "Fixed slotting for media-libs/tiff"? > This means, we better should use media-libs/tiff:0 to avoid problem if tkimg is installed. I added :0 to the tiff dep. > Do we have a guideline or policy on using 2 spaces vs. tabs in .xml > files and gentoo-x86? Just asking because I prefer 2 spaces over tabs. I asked and as far as I can remember, there was a "do what you like" answer. Especially older devs didn't like to be forced to anything here. Why I changed it? Not directly by purpose. I am trying to fix formating using xmlstartlet prior to commit, as I found that many metadata.xml do not follow a clear rule. And xml formatting is a quite straight thing, so I didn't thought people don't like it. justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/ghostscript-gpl: metadata.xml ChangeLog ghostscript-gpl-9.04-r4.ebuild
On 11/12/11 12:56 PM, justin wrote: > On 11/12/11 11:25 AM, Samuli Suominen wrote: >> On 11/12/2011 12:21 PM, Justin Lecher (jlec) wrote: >>> jlec11/11/12 10:21:37 >>> >>> Modified: metadata.xml ChangeLog >>> ghostscript-gpl-9.04-r4.ebuild >>> Log: >>> Fixed slotting for media-libs/tiff >>> >>> (Portage version: 2.2.0_alpha73/cvs/Linux x86_64) >>> >>> Revision ChangesPath >>> 1.3 app-text/ghostscript-gpl/metadata.xml >>> >>> file : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&view=markup >>> plain: >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?rev=1.3&content-type=text/plain >>> diff : >>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-text/ghostscript-gpl/metadata.xml?r1=1.2&r2=1.3 >>> >>> Index: metadata.xml >>> === >>> RCS file: /var/cvsroot/gentoo-x86/app-text/ghostscript-gpl/metadata.xml,v >>> retrieving revision 1.2 >>> retrieving revision 1.3 >>> diff -u -r1.2 -r1.3 >>> --- metadata.xml2 Jun 2011 09:59:25 - 1.2 >>> +++ metadata.xml12 Nov 2011 10:21:37 - 1.3 >>> @@ -1,8 +1,8 @@ >>> >>> http://www.gentoo.org/dtd/metadata.dtd";> >>> >>> -printing >>> - >>> -Disable dejavu support for binary distribution >>> because of licensing issue >>> - >>> + printing >>> + >>> + Disable dejavu support for binary >>> distribution because of licensing issue >>> + >>> >> >> I wonder what that has to do with "Fixed slotting for media-libs/tiff"? >> > I missread your question. This has nothing to do with slotting, but I don't think this needs an extra entry in the Changelog. Or am I wrong here? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/ghostscript-gpl: metadata.xml ChangeLog ghostscript-gpl-9.04-r4.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-11-2011 09:25, Samuli Suominen wrote: > > I wonder what that has to do with "Fixed slotting for > media-libs/tiff"? > > Do we have a guideline or policy on using 2 spaces vs. tabs in > .xml files and gentoo-x86? Just asking because I prefer 2 spaces > over tabs. Sometime ago when I did a few updates to metadata.xml related to retirements, I've asked around and there was no policy on whether to use 2 spaces or tabs. Back then the GDP preferred one over the other, but that only applied to GDP documents. On 12-11-2011 11:01, justin wrote: > On 11/12/11 12:56 PM, justin wrote: >>> >>> I wonder what that has to do with "Fixed slotting for >>> media-libs/tiff"? >>> >> > I missread your question. This has nothing to do with slotting, but > I don't think this needs an extra entry in the Changelog. Or am I > wrong here? Changing "style" on a package or supporting files is imho something that should be left for package maintainers. If some maintainers / herds agree with the change, one should probably add a note in the commit mentioning that. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOvo3zAAoJEC8ZTXQF1qEPa5UQAJ758RZlZGw7baix3oA19kw7 Cr9nRXFFlnXAq+8yws5kNi01N8Azhug+MH7lwTJyqnJADYHl8gti15iegW5iZW0r qxpwHE5XWjCKdST65kM1F3aDtaqvRQK/gd2mmQ9dgAzLWzwiy1tfI9aYxSUq7ufR KUbEuDoyATmddoAONMQIEgokTLWewESJ+3a8q1i87Yd+O2iii/JXo0GgcnWIsROU lwiEmK0G1iCIqzELik1ceeQ8BJanpPXuX06/fSAVmWNUKkKqATFiV1Q1qrNrIR1o akkpDTKNUPFXlVUl5IjohxpJ58ybIaBsklK7v8ceFF4I8mJgwjQLmjaruFB/yHuy t6g4FaS1BiIyQ6aiHxm62LVG8UTOKtxqHjke6JobRskIm/hsaG09R2G7d4Nzs3gU uycyBbu0QkmuC7emsZZw+cb89E3/TMQavMO/QWaCHpiBXEH0II/uXsl7LR8ZpdiB FXLxZNcN9mRPX7n1Q0FKNqwJH4cm4gZRto4PwbeTQ1Ls9aX26r5eBMlFBSzcI5f1 zKaS3GqXTvErSGKsDQxWB7RihH1fNbXEUm/GvXKG4dVRzYPT+VKTZBDW26gnBaWR C8zwXuuy3aOdUl1KKy4cDZRHVySojZarDXnxiiwtpImPq46nCZq8TCtxX1GgZxs4 Vx6I0sGNFJwVDK8jTZa6 =Y/gm -END PGP SIGNATURE-
[gentoo-dev] Lastrite: =wxGTK-2.6* and =wxpython-2.6*
# Samuli Suominen (12 Nov 2011) # Masked for removal in 30 days wrt bug 330683. Use at least 2.8. =dev-python/wxpython-2.6* =dev-python/wxpython-docs-2.6* =x11-libs/wxGTK-2.6*
Re: [gentoo-dev] have portage be quiet by default
On 11/11/11 16:44, Zac Medico wrote: good point. we don't want to punish old portage users. let's enable it by default in portage itself then. just add `elog` output to the portage ebuild to inform users of the change ? or do we want a news item ? what's the flag to negate the default ? --no-quiet-build ? ;) -mike It's --quiet-build=n. I've gone ahead and enabled it for release in portage-2.1.10.34: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39 Lots of people in #gentoo are unhappy with it. Most devs will be unhappy as it makes it harder to view the log while building. Please consider reverting it and let users set it with EMERGE_DEFAULT_OPTS if they want it less noisy. Patrick
Re: [gentoo-dev] have portage be quiet by default
On Sat, Nov 12, 2011 at 8:24 PM, Patrick Lauer wrote: > On 11/11/11 16:44, Zac Medico wrote: >>> >>> good point. we don't want to punish old portage users. let's enable it >>> by >>> default in portage itself then. just add `elog` output to the portage >>> ebuild >>> to inform users of the change ? or do we want a news item ? >>> >>> what's the flag to negate the default ? --no-quiet-build ? ;) >>> -mike >> >> It's --quiet-build=n. I've gone ahead and enabled it for release in >> portage-2.1.10.34: >> >> >> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39 >> > Lots of people in #gentoo are unhappy with it. > > Most devs will be unhappy as it makes it harder to view the log while > building. > > Please consider reverting it and let users set it with EMERGE_DEFAULT_OPTS > if they want it less noisy. +1 -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] have portage be quiet by default
On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote: > On 11/11/11 16:44, Zac Medico wrote: > >> good point. we don't want to punish old portage users. let's enable it > >> by default in portage itself then. just add `elog` output to the > >> portage ebuild to inform users of the change ? or do we want a news > >> item ? > >> > >> what's the flag to negate the default ? --no-quiet-build ? ;) > > > > It's --quiet-build=n. I've gone ahead and enabled it for release in > > portage-2.1.10.34: > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1 > > 74b6fc28feb26ea151d76f794e0ff2c2fa39 > > Lots of people in #gentoo are unhappy with it. most changes people will be unhappy with because it's different > Most devs will be unhappy as it makes it harder to view the log while > building. devs are not the normal case. it's trivial to have them use --quiet-build=n in their default emerge opts. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] have portage be quiet by default
On Sun, Nov 13, 2011 at 5:10 AM, Mike Frysinger wrote: > On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote: >> Lots of people in #gentoo are unhappy with it. > > most changes people will be unhappy with because it's different > This is objectively true. That's why you weigh changes based on whether they yield a net gain. I don't have strong opinions about this, but from the beginning, I've thought that *always* showing verbose output in emerge wasn't really useful for general users except as a CPU-intensive screensaver. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] have portage be quiet by default
On Sat, Nov 12, 2011 at 9:40 PM, Mike Frysinger wrote: > On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote: >> On 11/11/11 16:44, Zac Medico wrote: >> >> good point. we don't want to punish old portage users. let's enable it >> >> by default in portage itself then. just add `elog` output to the >> >> portage ebuild to inform users of the change ? or do we want a news >> >> item ? >> >> >> >> what's the flag to negate the default ? --no-quiet-build ? ;) >> > >> > It's --quiet-build=n. I've gone ahead and enabled it for release in >> > portage-2.1.10.34: >> > >> > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1 >> > 74b6fc28feb26ea151d76f794e0ff2c2fa39 >> >> Lots of people in #gentoo are unhappy with it. > > most changes people will be unhappy with because it's different > >> Most devs will be unhappy as it makes it harder to view the log while >> building. > > devs are not the normal case. it's trivial to have them use --quiet-build=n > in their default emerge opts. Then why not you and the other 2 guys that approved this change here (and are the only people I saw approving this, TBH), add --quiet-build=y to your default emerge opts and avoid this kind of change? Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] have portage be quiet by default
On 12 November 2011 15:40, Mike Frysinger wrote: > On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote: >> On 11/11/11 16:44, Zac Medico wrote: >> >> good point. we don't want to punish old portage users. let's enable it >> >> by default in portage itself then. just add `elog` output to the >> >> portage ebuild to inform users of the change ? or do we want a news >> >> item ? >> >> >> >> what's the flag to negate the default ? --no-quiet-build ? ;) >> > >> > It's --quiet-build=n. I've gone ahead and enabled it for release in >> > portage-2.1.10.34: >> > >> > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1 >> > 74b6fc28feb26ea151d76f794e0ff2c2fa39 >> >> Lots of people in #gentoo are unhappy with it. > > most changes people will be unhappy with because it's different I'm a bit surprised by the negative comments. I was pleasantly surprised this morning when I discovered the clean output now generated by default by Portage. After all, most of the time the build logs are "useless". By that I mean that one only looks at them when the build fails. So not seeing them by default seems the right thing to do. This may not always be true (especially for devs) but changing the default is very simple in those special cases. By the way, is there a noticeable difference in build time (for relatively large builds) when logging to the console is off? Not important, just curious. >> Most devs will be unhappy as it makes it harder to view the log while >> building. > > devs are not the normal case. it's trivial to have them use --quiet-build=n > in their default emerge opts. > -mike
[gentoo-dev] Re: have portage be quiet by default
Hilco Wijbenga posted on Sat, 12 Nov 2011 16:05:36 -0800 as excerpted: > By the way, is there a noticeable difference in build time (for > relatively large builds) when logging to the console is off? Not > important, just curious. There can be. AFAIK it's not too bad when output is to a vgacon text- console, but to frame-buffer (kms mode text console or X) tends to be more CPU intensive and to slow things down if you're bottlenecking on CPU as is often (but not always, especially on multi-core systems without emerge --jobs set to allow multiple parallel package emerges at once, as well as MAKEOPTS=-j, to allow multiple make jobs with a single merge job) the case. Terminal windows tend to use what a text console framebuffer does, often more, depending on effects and how much is hardware accelerated. Perhaps the biggest efficiency gain, however, if you have 4 gig plus of memory (and a 64-bit system to handle it reasonably efficiently), is to point PORTAGE_TMPDIR at a tmpfs and control its size and the number of parallel jobs to avoid more than a few MB of swappage. Based on my experience here, with four or even at two cores, the load average doesn't bog down the system anywhere close to what disk I/O does, regardless of whether it's swap or conventional disk I/O access. Putting the temp-dir in tmpfs means a lot of scratch files are never written to disk at all, thus saving that disk access, and theoretically it could even save if you're into swap (forums or user list for the details), but obviously far less then, so I now set jobs and load average to best control, if indirectly, for memory usage including the tmpfs, as opposed to direct CPU load control. But there's whole threads on optimizing emerges on the forums and user list. This really isn't the place for further discussion on that. -- 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
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
Joshua Saddler schrieb: > if net-tools isn't being dropped from the system set, don't force our > users to install redundant utilities. ip is not redundant. You need it for e.g. GRE tunnels. net-tools uses the old /proc/net/dev interface, while iproute uses netlink. This is very much like wireless extensions vs. cfg80211, where the old interface is still around for legacy compatibility but won't receive updates for new features. Eventually, you want to get rid of all /proc/net/dev and wext stuff in order to have a legacy-free system. I would be very much in favour of not installing net-tools by default as soon as openrc switches to iproute. However I think this would make many users unhappy so has to be carefully prepared and users educated first. Debian has set this goal in 2007[1] and they have not reached it yet. Best regards, Chí-Thanh Christopher Nguyễn [1] http://lists.debian.org/debian-user/2007/07/msg01113.html
Re: [gentoo-dev] have portage be quiet by default
On 11/12/2011 06:49 PM, Rafael Goncalves Martins wrote: > Then why not you and the other 2 guys that approved this change here > (and are the only people I saw approving this, TBH), add > --quiet-build=y to your default emerge opts and avoid this kind of > change? I like the new default. Anyone using the --jobs option has seen this behavior for a while. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
On Saturday 12 November 2011 20:26:54 Chí-Thanh Christopher Nguyễn wrote: > Joshua Saddler schrieb: > > if net-tools isn't being dropped from the system set, don't force our > > users to install redundant utilities. > > ip is not redundant. You need it for e.g. GRE tunnels. for basic setups, it is completely redundant. which is the only case we're talking about here. > net-tools uses the old /proc/net/dev interface, while iproute uses > netlink. This is very much like wireless extensions vs. cfg80211, where > the old interface is still around for legacy compatibility but won't > receive updates for new features. Eventually, you want to get rid of all > /proc/net/dev and wext stuff in order to have a legacy-free system. considering the tools work fine for the use cases we're talking about, and there are no plans i know of to ever have these interfaces go away, and there are no significant (or any at all?) efforts to replace all of net-tools. > I would be very much in favour of not installing net-tools by default as > soon as openrc switches to iproute. However I think this would make many > users unhappy so has to be carefully prepared and users educated first. > Debian has set this goal in 2007[1] and they have not reached it yet. you keep saying "net-tools" when you actually mean "ifconfig". the net-tools package provides quite a bit more than the common ifconfig/route/iptunnel tools which ip replaces and for which there are no replacements. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
On Friday 11 November 2011 16:53:44 William Hubbs wrote: > has prompted a discussion of whether or not we should use ifconfig in > openrc to configure networking on linux systems. no, the discussion is whether we should continue to have ifconfig be an option at all, not "always use ifconfig". as long as we need net-tools in the system, openrc should support ifconfig as an option for basic configuration. defaulting to iproute when it's available, and requiring it for more complicated stuff is fine by me. but adding static ip addresses and static routes is trivial to support. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
On Friday 11 November 2011 17:01:43 Chí-Thanh Christopher Nguyễn wrote: > Do you need iproute2 at all? I think you could fall back to busybox if > iproute2 is not installed. that introduces an unnecessary level of instability for us to worry about imo. if we want iproute, we should execute `ip` only. -mike signature.asc Description: This is a digitally signed message part.
