Re: [gentoo-dev] Re: New global useflag proposals

2012-11-23 Thread Peter Stuge
Duncan wrote: I'd guess that the global/local USE flag distinction is in practice lost on most users, and that of those that /do/ know the technical difference, likely most use make.conf for most local USE flags anyway, at least setting a system default, from which individual packages may

Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-24 Thread Peter Stuge
Diego Elio Pettenò wrote: On 24/11/2012 07:46, Brian Dolbec wrote: For ruby19, split in the middle to get 1.9, but what about 110, is it 11.0 or 1.10. Okay stop. There's no 1.10. There's 2.0 that's being developed for a long time. And we're not going to change our scheme just

Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-24 Thread Peter Stuge
Jauhien Piatlicki wrote: PHP_TARGETS=5.3 5.4 RUBY_TARGETS=1.9 PYTHON_TARGETS=2.7 But maybe it would be too problematic? What will you do with PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 then? That's an excellent point. Thanks! Thinking out loud another round: _TARGETS is

Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-24 Thread Peter Stuge
Peter Stuge wrote: Thinking out loud another round: _TARGETS is an interface by Gentoo, so maybe it would not be such a bad idea to use existing Gentoo identifiers there, ie. (a subset of?) PMS version specifications. Including the package name. This would also make the UX change smaller

Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-25 Thread Peter Stuge
Ole Markus With wrote: Maybe I could change the currently masked php5-5 slot to php5_5 instead and then eventually phase our the hyphen based slots. This would mean inconsistency between the php slots for some time, but eventual consistency with Python, which I do see as a good thing. I think

Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]

2012-12-01 Thread Peter Stuge
Michael Orlitzky wrote: I just get annoyed with the don't use Gentoo unless you like your stuff broken attitude. Don't confuse stuff changing with stuff breaking - they are very different things. In Gentoo stuff changes every single day. I heard that gentoo-x86 gets some number of commits per

Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]

2012-12-02 Thread Peter Stuge
Alec Warner wrote: Testing all the updates is basically not possible. Understanding the updates is basically not possible. I think it's very possible to understand updates which are important for the system. Of course it is a lot of work if it is to be done every day. I would not update

Re: [gentoo-dev] Help on adapting cman init scripts to kernels with things built in instead of modules

2012-12-02 Thread Peter Stuge
Pacho Ramos wrote: Looks like cman stabilization (that is needed to stabilize newer lvm2, that is needed to stabilize newer udev...) is blocked by its init.d script wanting to load modules even on kernels without modules: https://bugs.gentoo.org/show_bug.cgi?id=442512#c5 Arch team people

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

2012-12-06 Thread Peter Stuge
Markos Chandras wrote: This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. The reason is that I as a developer (whenever I become one) want to be able to fix stuff right now that is broken

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

2012-12-06 Thread Peter Stuge
Ian Stakenvicius wrote: Essentially, if the problem is with the ebuild or the way the package is integrated into gentoo, then fixing it immediately is fine. If the problem is with the software itself, then usually upstream needs to be involved before the fix will occur in gentoo. Yes that's

Re: [gentoo-dev] borked release media

2012-12-08 Thread Peter Stuge
Matt Turner wrote: I think we should consider things that break release media serious regressions. I think we should consider things that break anything serious regressions. Why should release media be more special than anything else? My email and bugzilla sweep a few days ago was during a

Re: [gentoo-dev] borked release media

2012-12-08 Thread Peter Stuge
Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

2012-12-09 Thread Peter Stuge
Brian Dolbec wrote: remove entries in profiles/updates for tree-cleaned packages... What's the advantage of doing that? None .. FYI... Currently there are updates files in profiles/updates/ dating back to 2004 Do they take up significant storage space or transfer time, compared to

Re: [gentoo-dev] borked release media

2012-12-09 Thread Peter Stuge
Chí-Thanh Christopher Nguyễn wrote: # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Bug was already

Re: [gentoo-dev] eudev project announcement

2012-12-14 Thread Peter Stuge
Richard Yao wrote: Where is development now? We have rewritten the build system and restored support for older kernels and verified compatibility as far back as Linux 2.6.31. We have tagged 1_beta1 and eudev is in the portage tree. A few lingering dependency issues exist, but we

Re: [gentoo-dev] Re: Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Peter Stuge
Duncan wrote: Apparently, IRC is a hard requirement. At least the one final evaluation must be done on IRC. I understand why online communication is not everyone's prefered format. I guess that the IRC part of the recruitment is not very formal, I don't know as I haven't seen one, but in

Re: [gentoo-dev] Time based retirements

2012-12-20 Thread Peter Stuge
Rich Freeman wrote: I think the bar for keeping access should be kept low - they shouldn't be forced to go find some trivial change to make just to get their name in the logs. When I first started looking into becoming a Gentoo developer I got a very strong and very clear impression that this

Re: [gentoo-dev] Time based retirements

2012-12-20 Thread Peter Stuge
Peter Stuge wrote: I think the bar for keeping access should be kept low - they shouldn't be forced to go find some trivial change to make just to get their name in the logs. When I first started looking into becoming a Gentoo developer I got a very strong and very clear impression

Re: [gentoo-dev] Re: Time based retirements

2012-12-21 Thread Peter Stuge
Markos Chandras wrote: I'm really just trying to understand the sense in this. -- Doug Goldstein Your tone is not appropriate for discussion. Sorry Markos, I disagree with you. Doug makes it abundantly clear that he wants to understand. I think we can all recognize that, in particular

Re: [gentoo-dev] Time based retirements

2012-12-21 Thread Peter Stuge
Markos, Markos Chandras wrote: I totally disagree with the way Doug started this thread. That's of course completely fair, but try to look beyond that, and let's focus on how we can make things better for everyone. Calling us brain dead ? Please read email even more carefully, especially

Re: [gentoo-dev] Is /var/cache the right place for repositories?

2012-12-25 Thread Peter Stuge
Michael Hampicke wrote: can binpackages easily be regenerated locally if their ebuilds are not in portage anymore? If the package is still installed it is very easy with quickpkg. //Peter

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2012-12-26 Thread Peter Stuge
Jeroen Roovers wrote: For once someone suggests a single good case where git beats CVS for portage tree changes: easily checking suggested changes ... Did you look at Gerrit one of the many times I mentioned it already? That is what it is for, and it is pretty great. A shiny new workflow

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

2013-01-02 Thread Peter Stuge
Samuli Suominen wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. That's one awful double standard. :\ dev-libs/libusb is the default implementation from libusb.org, yet you are astonishingly eager to *avoid* that it is the

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

2013-01-02 Thread Peter Stuge
Rich Freeman wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. That's one awful double standard. :\ Double-standards aside, I don't think the original implementation is what matters, so much as what works best for our

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

2013-01-02 Thread Peter Stuge
Alexis Ballier wrote: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a

Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?

2013-01-07 Thread Peter Stuge
Ben de Groot wrote: Is it really newsworthy to say that the Gentoo developer community thinks we haven't accomplished much? Spin it: Write that you asked developers but only got very little feedback (literally only a handful of people replied), summarize the replies, and then ask for a dialogue

Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org

2013-01-07 Thread Peter Stuge
Maxim Kammerer wrote: Also, how widespread is client DNSSEC support? E.g., I enabled DNSSEC for my domain, but not sure yet whether DNS resolution anywhere will fail in case DNS responses are spoofed. There is a gap between applications asking resolvers to do lookups and resolvers which can do

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

2013-01-14 Thread Peter Stuge
Steven J. Long wrote: What I'm not in favour of is making the simple cases more difficult, to deal with the complex ones. It's completely brain-dead thinking. This is exactly what some people think or say when they learn that I use Gentoo. I appreciate Gentoo because I am able and willing to

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

2013-01-14 Thread Peter Stuge
William Hubbs wrote: I have a bug opened with the docs team and release engineering to discuss whether we want the new names for new installs. IMO yes we do. What's that bug - or what is the good way to thumbs up/down? //Peter pgpswXbIiseJI.pgp Description: PGP signature

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

2013-01-15 Thread Peter Stuge
Rich Freeman wrote: Anybody who runs debian knows that the only two commands you really need to know are apt-get --update and apt-get --upgrade. We really need to keep things just that simple. We're halfway there; emerge --sync So how about adding: emerge --upgrade ? //Peter

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-15 Thread Peter Stuge
Rich Freeman wrote: Not that anybody is taking requests, but it would be really handy if serial ports were deterministically labeled. Does /dev/serial/* solve the problem? //Peter

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

2013-01-17 Thread Peter Stuge
Samuli Suominen wrote: I almost changed it back myself already but to avoid stupid commit wars didn't. Interesting comment considering how blazing fast you were to commit a change of the default for another forked project. It's just another fork, not an upgrade. Interesting comment indeed.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

2013-01-17 Thread Peter Stuge
Rich Freeman wrote: I'd just stick with a simple parameter like --upgrade Yes please! or an alternative command name like emerge-update. Please no! Oh, here's another crazy thought. How about some directory in /etc that sets rules for emerge-update (or whatever we call it)? You might

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-17 Thread Peter Stuge
Tobias Klausmann wrote: It has been rather nifty that if I walk up to a random machine with exactly one NIC (that I've been asked to examine/fix), I _know_ that there will be eth0 and only that. Only as long as that system hasn't seen *another* NIC first, if it has persistent interface name

Re: [gentoo-dev] Re: Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c

2013-01-17 Thread Peter Stuge
Paul Arthur wrote: On 2013-01-17, Maxim Kammerer m...@dee.su wrote: All in all, secure-delete has its uses. What are people supposed to use instead, dd if=/dev/zero of=/media/sdcard/naked_gf_0001.jpg? Perhaps 'shred', which is part of coreutils? From man shred: CAUTION: Note

Re: [gentoo-dev] Getting the general dev opinion (Meinungsbild) on some feature

2013-01-20 Thread Peter Stuge
Alec Warner wrote: [..removed 25 lines of quoted text which I had already read..] The primary complaint was the fact that there is too much email. Many emails are not neccessarily a problem if only they have high signal-to-noise ratio. I have *never* seen so competent people output so

Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)

2013-01-20 Thread Peter Stuge
Panagiotis Christopoulos wrote: I don't build server machines every day, others do and it would be much appreciated if they could respond here. I build catalyst stage4s. Any default profiles are kindof pointless for me; I have USE=-* and the flags that I want. Anything else seems a bit too

Re: [gentoo-dev] Separately buildable binary blobs

2013-01-20 Thread Peter Stuge
Doug Goldstein wrote: sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, sys-firmware/vgabios .. So basically, how important is it to keep supporting these separately buildable blobs knowing that it might slow the release of QEMU within our own tree. Each of those sys-firmware/

Re: [gentoo-dev] Separately buildable binary blobs

2013-01-20 Thread Peter Stuge
Doug Goldstein wrote: we go through the effort to ALLOW users to build their own binary blobs but is it really necessary as part of our culture? I don't think that question can be answered? The way I see it either someone maintains those packages, or not. I'd be sad to see them go, but am not

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-26 Thread Peter Stuge
Rich Freeman wrote: having a standardized kernel with a few flags probably isn't a bad idea. That doesn't scale at all. Suggest instead take a .config as input to the emerge, maybe something like savedconfig for busybox, and add shortcuts for common options. That way, the same mechanism can be

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

2013-02-06 Thread Peter Stuge
Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? I mean: You are saying that given two options, Gentoo will do whatever major distros are doing. (Never mind that Gentoo *is* a

Re: [gentoo-dev] !!! ERROR !!!

2013-02-08 Thread Peter Stuge
!!! ERROR !!! SYSTEM ERROR !!! SYSTEM FAIL !!! Yikes. I didn't touch anything, honest! lets hope infra will ban him from the list What's with all the leniency? I thought we used the death penalty on the first offense? Oh I am sorry. I didn't realize you like spammers on this

Re: [gentoo-dev] How to publish an overlay

2013-02-08 Thread Peter Stuge
Rich Freeman wrote: any tag in Github can be downloaded as a tarball with a constant md5 Note that gitweb also offers snapshot links. Many upstream gitwebs have that feature enabled, saving even the work of mirroring to github. //Peter

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Peter Stuge
Tomáš Chvátal wrote: Having nice mailinglist where users can contribute simple patches would be briliant thing to use :-) That's still a waste of time compared to gerrit. You should look at it if you don't know it already. //Peter

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Peter Stuge
hasufell wrote: there should only be two reasons to have ebuilds in a seperate overlay: they depend on dropped packages or they are unsupportable (e.g. because they are in early alpha stage or broken in some ways). Keep in mind that there may be lots of other cases which you have not and can

Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

2013-02-10 Thread Peter Stuge
Alec Warner wrote: Having nice mailinglist where users can contribute simple patches would be briliant thing to use :-) That's still a waste of time compared to gerrit. You should look at it if you don't know it already. I'll take patchwork over gerrit, honestly ;) Did you use

Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory

2013-02-10 Thread Peter Stuge
J. Roeleveld wrote: I, as a user, prefer not to have to hunt for firmware for devices supported vy the kernel. I would either install all of them or filter out the firmwares for devices I am unlikely to get. I, as another user, prefer not to have a whole bunch of firmware installed if I only

Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?

2013-02-11 Thread Peter Stuge
Maxim Kammerer wrote: * These packages depend on libusb: One stands out: app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1) app-crypt/gnupg-2.0.19 (usb ? virtual/libusb:0) dev-libs/openobex-1.5 (usb ? virtual/libusb:0) media-libs/libmtp-1.1.5 (virtual/libusb:1) net-libs/libpcap-1.3.0-r1

Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?

2013-02-11 Thread Peter Stuge
Diego Elio Pettenò wrote: Can you try swapping the two in the virtual? Or not. I guess that you assumed that I suggested to test this in-tree, so I guess I should clarify that I would expect it to be tested in PORTDIR_OVERLAY. If my guess is correct then you are really way too eager to

Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?

2013-02-11 Thread Peter Stuge
Diego Elio Pettenò wrote: it's because of what Maxim already said: it's not an LTR/RTL issue. Do you have an idea about what the issue is? //Peter

Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?

2013-02-11 Thread Peter Stuge
Zac Medico wrote: My guess is that there were one or more ebuilds that inappropriately specified dev-libs/libusb:0 instead of virtual/libusb:0, and they have since been fixed. I believe they were all changed some months ago, but it's of course still possible if either the snapshot was old or

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

2013-02-11 Thread Peter Stuge
Alexis - thanks a lot for the awesome response! Alexis Ballier wrote: 'those who are right' (Just a note that I am in no way invested in libav/ffmpeg, I merely speak from experience with another fork.) However, as I said, maybe with an incorrect tone, I do not think libav ignoring what

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

2013-02-11 Thread Peter Stuge
Luca Barbato wrote: May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? There was probably a reason for Fabrice to do that, and majority

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

2013-02-11 Thread Peter Stuge
Luca Barbato wrote: Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. It is not related to users, I was trying to come back on topic. :) is related to me being called as swine a traitor and having death threats.

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-13 Thread Peter Stuge
Diego Elio Pettenò wrote: People who don't need the firmware can deal with disabling it themselves. I don't like the binary distribution argument of include everything to cover as many possible use cases as possible in one go. I very much like the high resolution of Gentoo packages. I'd hate to

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

2013-02-13 Thread Peter Stuge
Diego Elio Pettenò wrote: I don't like the binary distribution argument of include everything to cover as many possible use cases as possible in one go. I very much like the high resolution of Gentoo packages. I'd hate to enter a slippery slope toward lower resolution. Are you really

Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

2013-02-13 Thread Peter Stuge
Agostino Sarubbo wrote: I'm using ssh -A to forward the key and I'm interested to find a way to do it for the gpg key. I found an how-to that uses socat ( http://superuser.com/questions/161973/how- can-i-forward-a-gpg-key-via-ssh-agent ) but does not work as expected. Did you debug? Rather

Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

2013-02-13 Thread Peter Stuge
Michael Weber wrote: Rather than creating a TCP socket I would look into using the ssh -W option. gpg agent works with unix domain sockets. I know. It would look something like socat + ssh -W socat //Peter

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

2013-02-14 Thread Peter Stuge
Diego Elio Pettenò wrote: Ah, I always thought of overlays as places where apps tend to reside, but of course you could have glibc in there for all we know... Good point... Welcome to the life of your average Gentoo ebuild maintainer. Stop complaining (and with foul language! come on,

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

2013-02-14 Thread Peter Stuge
Diego Elio Pettenò wrote: Stop complaining (and with foul language! come on, you sound like an idiot, which seems unneccessary) and let's think about solutions. Your laziness makes you sound like an idiot too, thank you very much. Send me constructive criticism in an email and I'll of

Re: [gentoo-dev] Packages up for grabs due lack of time

2013-02-16 Thread Peter Stuge
Diego Elio Pettenò wrote: sys-firmware/iwl3945-ucode I want this installed on my system. sys-firmware/iwl4965-ucode But not this. could we just remove them Please don't. I think it would suck to lose the higher resolution. On the plus side it seems that these particular packages would

Re: [gentoo-dev] Packages up for grabs due lack of time

2013-02-16 Thread Peter Stuge
Diego Elio Pettenò wrote: Please don't. I think it would suck to lose the higher resolution. Use savedconfig 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.

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

2013-02-16 Thread Peter Stuge
Diego Elio Pettenò wrote: So because we did things badly in the past, that is an excuse to do things badly in the future? :) No. I still argue that this is NOT doing things badly. Masking a package will NOT cause it to get unmerged by default. Hm, can you expand on by default ? When will

Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?

2013-02-17 Thread Peter Stuge
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

Re: [gentoo-dev] Re: linux-firmware

2013-02-20 Thread Peter Stuge
Duncan wrote: Is it possible to tell git to only clone/pull specific files in a repo? No. //Peter

Re: [gentoo-dev] Re: linux-firmware

2013-02-20 Thread Peter Stuge
Diego Elio Pettenò wrote: The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time While noble, I think it is a bit naïve. Reality is that many if not most ebuilds *anyway* rely on temporal things - such as a current enough

Re: [gentoo-dev] Re: linux-firmware

2013-02-20 Thread Peter Stuge
Greg KH wrote: If there really are firmware blobs that are only available via git and which cannot be redistributed we might consider whether it makes sense to not support them entirely, or to force them to be masked. Did anyone actually consider the fact that there should not be

Re: [gentoo-dev] Gentoo Bugday

2013-02-27 Thread Peter Stuge
Alexander Berntsen wrote: I would like to announce you a new try to 'revive' the Bugday event. I don't have anything to add. I just wanted to express my support. Yeah! Me too! :) //Peter

Re: [gentoo-dev] Re: Evaluating a new malloc()

2013-02-27 Thread Peter Stuge
Ryan Hill wrote: I think I see a lot of our upstream bug reports being closed as invalid/unsupported. I think that if upstreams wanted to use jemalloc they would just do so. If they don't then obviously what they have is working fine for them. It can make sense to try further discussion,

Re: [gentoo-dev] Re: Gentoo Bugday

2013-02-27 Thread Peter Stuge
Pavlos Ratis wrote: Unfortunately I didn't have much time to 'refresh' the website. As Theo said, he gave me the code of the site but I think it would be great to have something new. If anyone wants to join, ping me on irc. We could create a new repo at our Github and start developing. Don't

Re: [gentoo-dev] Re: Gentoo Bugday

2013-02-27 Thread Peter Stuge
Tom Wijsman wrote: We could create a new repo at our Github and start developing. Don't start developing, plz work on bugs instead. Then who will develop useful tools to handle bugs more efficiently? Don't get me wrong: I am not hating on useful tools! I am saying that working on

Re: [gentoo-dev] Re: Gentoo Bugday

2013-02-27 Thread Peter Stuge
Tom Wijsman wrote: I am saying that working on tools that help you work on open bugs is not orthogonal to fixing open bugs, it helps you fix them efficiently. Sure, but on the bugday itself it sounds on the name like the idea is to work on bugs with currently available tools, rather than work

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-02 Thread Peter Stuge
Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. //Peter

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Peter Stuge
Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. good thing you are not a dev then. Thanks for the heads up in case you ever want to become one I explain to you what happened and you, a recruiter, proceed to threaten me in case I want to become a

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Peter Stuge
Markos Chandras wrote: I explain to you what happened getting stuff done is not an answer. I still don't understand why stable keywords had to be added directly. Do you understand why Mike did that or just playing smart here? To me it's obvious that he did it because it made something

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Peter Stuge
Markos Chandras wrote: getting stuff done is not an answer. it made something easier for him I asked why he did it, and you keep telling me because he had to. I'm guessing that it didn't have much to do with Gentoo. Maybe he'll fill in. I am reviewing commits from time to time

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-04 Thread Peter Stuge
Andreas K. Huettel wrote: Starting as a developer or aspiring to become one with that attitude is not acceptable. That doesn't make sense to me. If the reason is good, surely it does not matter who is doing the breaking? //Peter pgpvkacjjiVYz.pgp Description: PGP signature

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

2013-03-06 Thread Peter Stuge
Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? //Peter

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

2013-03-06 Thread Peter Stuge
Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so

Re: [gentoo-dev] Make inotify a global USE flag?

2013-03-21 Thread Peter Stuge
Ulrich Mueller wrote: Should we make it a global flag? Sure. What description is better: inotify - Enable inotify filesystem monitoring support inotify - Enable inotify file change notification support The former is more correct, because inotify provides notifications for more than

Re: [gentoo-dev] Make inotify a global USE flag?

2013-03-21 Thread Peter Stuge
Samuli Suominen wrote: Samuli Suominen wrote: it should always be enabled with 'kernel_linux' and let the application itself do a runtime check if inotify is available or not I think it's great if you are working on such patches for upstreams! no, i'm talking from experience -- every

Re: [gentoo-dev] Make inotify a global USE flag?

2013-03-21 Thread Peter Stuge
Samuli Suominen wrote: i'm referring to the mistakes done by maintainers by adding unnecessarily the flag That was not at all clear, but that's great! Then you could fix those ebuilds. Yes, I could, or I could just let other maintainers know about it, like on the ML, wait... that's what I

Re: [gentoo-dev] Re: Last rites: media-tv/tvtime

2013-03-24 Thread Peter Stuge
Nuno Silva wrote: mplayer *can* play it, but tuning is a different story. mplayer is not really an alternative. tvtime looks and feels significantly better. A lot like saying that Fiat is an alternative to Ferrari. I'm also curious if there are more known bugs than those noted in the mask. I

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Alec Warner wrote: MC The package is going away unless someone fixes the bugs and MC properly maintains the package Again, that is an irresponsible mistake. It is better to just leave it as is than to kick it. Dropping important packages can only harm the community and is never

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Markos Chandras wrote: The masks are sort of announcements as you have 30 days to revert that decision. You don't seem to recognize the quite significant psychological impact of you having already made the decision, compared to, say, having an actually inclusive package removal process.

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Rich Freeman wrote: something is bound to break for good sooner or later if things don't change. Certainly. But consider the chain of events: * user is happily using outdated, but working, software without knowing how behind the times upstream really is, because it works * gentoo masks and

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Rich Freeman wrote: A per-ebuild bug metric would be cool. A kind of health indicator for individual ebuilds, alerting users when some of our installed ebuilds go yellow, so that we have perhaps on the order of six months before the package goes red, at which point it would be fine to

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Alan McKinnon wrote: Masking already accomplishes everything you propose, which is to communicate there is something wrong with this package and it is in danger of leaving the tree. To get it out of this state, you need to take action. I disagree strongly that this is what masking

Re: [gentoo-dev] Re: Last rites: media-tv/tvtime

2013-03-24 Thread Peter Stuge
Markos Chandras wrote: You keep complaining about everything I keep complaining about things that I think can be improved, while I don't generally praise things that I think are already good enough. There are so many problems to fix that I basically feel that time is better spent on problems

Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Peter Stuge
Markos Chandras wrote: A per-ebuild bug metric would be cool. A kind of health indicator for individual ebuilds, alerting users when some of our installed ebuilds go yellow, so that we have perhaps on the order of six months before the package goes red, at which point it would be fine

Re: [gentoo-dev] bash-3.1 stable

2013-04-02 Thread Peter Stuge
Samuli Suominen wrote: imho, .. we should stick to the latest stable is the stable mantra (i'm not sure if this is even documented anywhere? and propably should not be? keep it as maintainer specific decision like it's now?) If it's the agreen-upon way then why not document it? //Peter

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

2013-04-24 Thread Peter Stuge
Jeroen Roovers wrote: Er, you can't be seriously suggesting we will drop repoman checks with the migration to git? I don't see how that would benefit anyone. I would argue that repoman and/or corresponding checks should be run by a CI system hooked up to the Gerrit instance that developers push

Re: [gentoo-dev] RANT: Upgrade icu and KDE at once

2013-05-01 Thread Peter Stuge
Jörg Schaible wrote: icu. The ebuild happily removes any trace of the old shared libs with the result that half of the stuff that is *required* to build kdelibs is now broken. The build aborts and leaves behind a broken system. And this happened now not for the first time! Tom Wijsman wrote:

Re: [gentoo-dev] RANT: Upgrade icu and KDE at once

2013-05-01 Thread Peter Stuge
Peter Stuge wrote: Jörg Schaible wrote: icu. The ebuild happily removes any trace of the old shared libs with the result that half of the stuff that is *required* to build kdelibs is now broken. The build aborts and leaves behind a broken system. And this happened now not for the first

Re: [gentoo-dev] Making systemd more accessible to normal users

2013-05-01 Thread Peter Stuge
Fabio, I think you're doing awesome work! Steven, I think you can behave a lot better on the internet. kthx. Steven J. Long wrote: It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also consensus that this approach is wrong for

Re: [gentoo-dev] Packages using -Werror

2013-05-02 Thread Peter Stuge
Ryan Hill wrote: If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. How about sending the fix upstream instead? Thanks, from an upstream //Peter pgpHGm3ZpE6z3.pgp Description: PGP signature

Re: [gentoo-dev] OpenRC supporting systemd units

2013-05-09 Thread Peter Stuge
Michael Mol wrote: obviously you have an interesting position as a dev in a distribution, and you might make your change there, but that certainly shouldn't be your default course of action. +1 and not just for unit files. //Peter pgpQGx9XaD1PC.pgp Description: PGP signature

Re: [gentoo-dev] devmanual moved to github

2013-05-12 Thread Peter Stuge
Rich Freeman wrote: The devmanual git repository[1] moved to github[2]. The only thing that isn't FOSS is github itself. Not sure if others feel strongly about it. I feel strongly against github. Making something like github the primary point of contact communicates many negative things

Re: [gentoo-dev] Re: devmanual moved to github

2013-05-12 Thread Peter Stuge
Markos Chandras wrote: The repository is still accessible in http://git.overlays.gentoo.org and read-only access is still available. However, the write access removed because of potential conflicts between g.o.g.o and github. If you can guarantee me that people will not mess things up and not

Re: [gentoo-dev] Re: devmanual moved to github

2013-05-12 Thread Peter Stuge
Rich Freeman wrote: Gerrit .. I've never used it myself but I'm tempted to install it just to start messing with it personally. Go for it! It's a few steps to set up, but it's not too bad. Michael Palimaka wrote: I believe Gerrit has been suggested before and rejected because it relies on

  1   2   3   4   5   >