Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Patrick Lauer: > On Saturday 17 January 2015 17:25:15 hasufell wrote: >> Patrick Lauer: >>> On Friday 16 January 2015 18:29:08 hasufell wrote: Patrick Lauer: > On 01/16/15 23:26, hasufell wrote: >> Patrick Lauer (patrick): >>> patrick 15/01/16 04:16:55 >>> >>> Modified: ChangeLog >>> Added:libuv-1.2.1.ebuild >>> Log: >>> Bump >> >> I expect people to ask me for review if they bump any of my packages. >> That includes QA team members. > > Are you always in such a bad mood? Do you, as QA team member, think that a review workflow improves quality? >>> >>> No. >>> >>> Bureaucracy does not improve quality by itself. >> >> Patrick, I am really sorry, but this answer made me laugh and cry. >> >> A review workflow is a fundamental concept in programming methodology >> and we have decades of experience that taught us how important it is. > > But just "add review" or "add agile" doesn't fix quality. Same way Security > is > not just a checkbox, but a process. (Plus there's the whole manpower thing > we'll ignore for now, etc. etc. ...) > Yes exactly. A review is not a checkbox, but a process (in contrary to running repoman). It's the process of asking someone for comments on your patch, getting useful answers and then going ahead with a commit maybe. You didn't follow that process. That in conjunction with your weird answer makes me think that you really don't like getting reviews. Your attempts to relativize the review workflow defined in devmanual (which is still a bit lax, tbh) is confusing at best. So unless you can tell me how your flawed commit (the sed call was silently broken) did improve the quality of my ebuild, I am still insisting on a review workflow.
Re: [gentoo-dev] Things one could be upset about
On 01/17/2015 04:46 PM, Patrick Lauer wrote: > On Saturday 17 January 2015 13:12:56 Zac Medico wrote: >> On 01/17/2015 03:35 AM, Patrick Lauer wrote: >>> * Portage is too slow >>> >>> On 'small' hardware emerge -upNDv @world can take enough time >>> to make updates prohibitive - on an 800Mhz machine it took me >>> about 3 days to figure out a solution to some silly blockers due to >>> the >>> very slow change test cycle >>> Fix: Do some profiling and un-refactoring to remove useless code >>> Fix: Set up a reference system (CI) to catch future regressions >> >> I'm certainly in favor of improving portage performance. However, for >> "small" hardware (which includes many ARM and MIPS systems), we really >> need to focus on binary package support. Note that dependency resolution >> for installing binary packages tends to be much simpler than for >> building ebuilds from source, and this translates into much shorter >> dependency resolution time. >> > That's an orthogonal problem. And that's coming from someone who extensively > uses binpkgs already ... Sure, but building from source on "small" hardware is not necessarily the best practice. If our binary package support was better, then people might be more likely to use "big" hardware to build packages for distribution to "small" hardware. > The problem with (dependency resolution) performance is that in some > scenarios, even on fast machines, it takes "too long" - especially if there's > some silly useflag mismatch and two packages that have ~arch keywords, and > now > you need 12 attempts to figure out a solution that works for you ... > At 30 seconds for each resolution cycle that's 6 minutes waiting for portage. > > If it were faster it'd almost be interactive ... Yeah, that would be great. On a related note, I think that the default emerge --backtrack=10 setting is too high, causing emerge to waste lots of cpu time before it ultimately fails to find a valid solution. I've filed a bug to make it default to --backtrack=3 [1]. > Also - just for comparison: > On my currently fastest box "emerge -ep @world" takes about 3 seconds since > there's almost no packages installed. > On my currently slowest box same takes about 15 minutes, because (1) lots of > packages installed and (2) slow CPU and (3) brutally slow IO > > Binpkgs only help so much - if any dependencies change I need to sync the > configuration between client and server, and to see if it resolves I need to > do > a dryrun on the client (or be very certain that the configuration really > matches) - or risk that it's going to fail because of mismatches. For some, maybe a nice way to sync configuration would be to create a customized profile. Then, emerge --sync would pull in your configuration updates from the server. With "profile-formats = portage-2" in metadata/layout.conf of your profiles repository, you can put things like "gentoo:default/linux/amd64/13.0/desktop" in the parent file of your profile, so it inherits from a profile in the "gentoo" repository. > I haven't quite figured out why portage needs such humongous amounts of > memory > (>300MB ?!) Yes, I would like to work on reducing the memory consumption. > and why it needs to spend a minute to figure out how to install a > simple almost-no-dependencies tool like htop or iotop. Note that the emerge --complete-graph-if-new-ver and --complete-graph-if-new-use options are enabled by default. These options will force emerge to create a complete dependency graph, in order to ensure that all reverse-dependencies are respected. > There's some obvious > badness, and just saying "well let's use binpkgs" won't fix it (and, well, on > the binpkg server if you have 3k packages installed you get the same > performance issues, so ignoring the issue is kinda not a good idea) Of course not. > There's been some good progress, I remember you reducing memory usage already > (>500MB -> 350MB or so for merging kernel sources) and there's some speedups > from the last round of performance work. Still I think we can do a lot better > :) Sure we can. > Thanks for your efforts, > > Patrick [1] https://bugs.gentoo.org/show_bug.cgi?id=536926 -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Saturday 17 January 2015 17:25:15 hasufell wrote: > Patrick Lauer: > > On Friday 16 January 2015 18:29:08 hasufell wrote: > >> Patrick Lauer: > >>> On 01/16/15 23:26, hasufell wrote: > Patrick Lauer (patrick): > > patrick 15/01/16 04:16:55 > > > > Modified: ChangeLog > > Added:libuv-1.2.1.ebuild > > Log: > > Bump > > I expect people to ask me for review if they bump any of my packages. > That includes QA team members. > >>> > >>> Are you always in such a bad mood? > >> > >> Do you, as QA team member, think that a review workflow improves quality? > > > > No. > > > > Bureaucracy does not improve quality by itself. > > Patrick, I am really sorry, but this answer made me laugh and cry. > > A review workflow is a fundamental concept in programming methodology > and we have decades of experience that taught us how important it is. But just "add review" or "add agile" doesn't fix quality. Same way Security is not just a checkbox, but a process. (Plus there's the whole manpower thing we'll ignore for now, etc. etc. ...) I'm unwilling to entertain your attempts at baiting me into statements you hope to use against me, and I'm unwilling to play your passive-agressive whining game. > > I have no words to describe how disappointed I am right now. It'll pass, don't worry ...
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 13:12:56 Zac Medico wrote: > On 01/17/2015 03:35 AM, Patrick Lauer wrote: > > * Portage is too slow > > > > On 'small' hardware emerge -upNDv @world can take enough time > > to make updates prohibitive - on an 800Mhz machine it took me > > about 3 days to figure out a solution to some silly blockers due to > > the > > very slow change test cycle > > Fix: Do some profiling and un-refactoring to remove useless code > > Fix: Set up a reference system (CI) to catch future regressions > > I'm certainly in favor of improving portage performance. However, for > "small" hardware (which includes many ARM and MIPS systems), we really > need to focus on binary package support. Note that dependency resolution > for installing binary packages tends to be much simpler than for > building ebuilds from source, and this translates into much shorter > dependency resolution time. > That's an orthogonal problem. And that's coming from someone who extensively uses binpkgs already ... The problem with (dependency resolution) performance is that in some scenarios, even on fast machines, it takes "too long" - especially if there's some silly useflag mismatch and two packages that have ~arch keywords, and now you need 12 attempts to figure out a solution that works for you ... At 30 seconds for each resolution cycle that's 6 minutes waiting for portage. If it were faster it'd almost be interactive ... Also - just for comparison: On my currently fastest box "emerge -ep @world" takes about 3 seconds since there's almost no packages installed. On my currently slowest box same takes about 15 minutes, because (1) lots of packages installed and (2) slow CPU and (3) brutally slow IO Binpkgs only help so much - if any dependencies change I need to sync the configuration between client and server, and to see if it resolves I need to do a dryrun on the client (or be very certain that the configuration really matches) - or risk that it's going to fail because of mismatches. I haven't quite figured out why portage needs such humongous amounts of memory (>300MB ?!) and why it needs to spend a minute to figure out how to install a simple almost-no-dependencies tool like htop or iotop. There's some obvious badness, and just saying "well let's use binpkgs" won't fix it (and, well, on the binpkg server if you have 3k packages installed you get the same performance issues, so ignoring the issue is kinda not a good idea) There's been some good progress, I remember you reducing memory usage already (>500MB -> 350MB or so for merging kernel sources) and there's some speedups from the last round of performance work. Still I think we can do a lot better :) Thanks for your efforts, Patrick
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 14:00:34 William Hubbs wrote: > On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote: > > On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer wrote: > > > * Stage3 archives are too fat > > > > > > See https://bugs.gentoo.org/show_bug.cgi?id=531632 > > > We're now shipping three python versions and glib for extra fun! > > > Fix: Motivate releng to stop being silly > > > > Why the heck do we ship both 3.3 and 3.4? I forget the exact situation > > with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only > > is a great option if that remains the default after installation > > (although it would be fine for just the initial stages). > > I'm going to be very blunt. I am sick of the finger being pointed > only at releng for this. > > The issue is package dependencies. > > If even one package in the tree has a dumb dependency on python, e.g. > dev-lang/python, it will pull in all stable versionf of python. Only if you absolutely insist that releng can never deviate from tree. Which is a silly idea, see bindist useflag, which is locally enabled for stage building and then removed. Oh wait, it's not removed because we can't deviate while deviating. So users regularly find ssl 'broken' ... It took me about 2h of fiddling around to find a few spots where stage3 has useless bloat: - pkgconfig pulling in 30MB of glib - python installing tests (that's 3x 25MB now ...) - having more than one python installed (which is not really absolutely necessary, and could easily be reduced to one) Out of 700MB on-disk I could prune about 150MB - about 20%, without affecting functionality It's not about pointing a finger, it's about fixing issues when they are easy to fix and not hiding behind a fake complexity argument. (I would fix things, if I had access and/or certainty that patches provided would be integrated ...) Have fun, Patrick
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 15:03:05 Ciaran McCreesh wrote: > On Sat, 17 Jan 2015 22:58:33 +0800 > > Patrick Lauer wrote: > > On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote: > > > On Sat, 17 Jan 2015 21:03:30 +0800 > > > > > > Patrick Lauer wrote: > > > > Last time I tested paludis it was slower > > > > > > You've yet to do a like-for-like comparison... > > > > Hello hostile upstream. > > > > It was as "like for like" as possible > > Well that's the point... A rare case of violent agreement? Excellent. And/or you're terminally bored - either way you're not adding anything relevant to this conversation.
Re: [gentoo-dev] Things one could be upset about
On Sat, Jan 17, 2015 at 12:00 PM, William Hubbs wrote: > On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote: >> On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer wrote: >> > * Stage3 archives are too fat >> > See https://bugs.gentoo.org/show_bug.cgi?id=531632 >> > We're now shipping three python versions and glib for extra fun! >> > Fix: Motivate releng to stop being silly >> >> Why the heck do we ship both 3.3 and 3.4? I forget the exact situation >> with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only >> is a great option if that remains the default after installation >> (although it would be fine for just the initial stages). > > I'm going to be very blunt. I am sick of the finger being pointed > only at releng for this. Well, there are trivial things that could be done on the stage building end... and complete intransigence toward totally reasonable ideas like not building with default options for a particularly specialized target (stages, livecds, etc.). Blame whomever you like, but ultimately the stages are a product of the release engineering team who has the ability to fix the issue themselves but choose not to.
Re: [gentoo-dev] Things one could be upset about
On 01/17/2015 03:35 AM, Patrick Lauer wrote: > * Portage is too slow > On 'small' hardware emerge -upNDv @world can take enough time > to make updates prohibitive - on an 800Mhz machine it took me > about 3 days to figure out a solution to some silly blockers due to the > very slow change test cycle > Fix: Do some profiling and un-refactoring to remove useless code > Fix: Set up a reference system (CI) to catch future regressions I'm certainly in favor of improving portage performance. However, for "small" hardware (which includes many ARM and MIPS systems), we really need to focus on binary package support. Note that dependency resolution for installing binary packages tends to be much simpler than for building ebuilds from source, and this translates into much shorter dependency resolution time. As I have expressed in other emails [1], I am currently working on making Gentoo's binary package support more competitive with binary distros. I have created a sys-apps/portage- ebuild [2] for people who would like to test features not released in mainline portage yet. [1] http://thread.gmane.org/gmane.linux.gentoo.project/4205/focus=4217 [2] https://github.com/zmedico/portage-binpkg-support-overlay -- Thanks, Zac
[gentoo-dev] Last rites: rox-base/* and rox-extra/*; rox.eclass and rox-0install.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Manuel Rüger (17 Jan 2015) # Unmaintained. Old eclasses, EAPIs and various bugs. # See bug #533642 # Removal in 30 days. rox-base/mime-editor rox-base/oroborox rox-base/pager rox-base/rox rox-base/rox-autostart rox-base/rox-clib rox-base/rox-launch rox-base/rox-lib rox-base/rox-session rox-base/systemtrayn rox-base/tasklist rox-base/tasktray rox-base/thumbs rox-base/traylib rox-base/volume rox-base/xdg-menu rox-base/zeroinstall-injector rox-extra/archive rox-extra/clock rox-extra/contacts rox-extra/diff rox-extra/edit rox-extra/fetch rox-extra/find rox-extra/gnome-thumbnailer rox-extra/lithium rox-extra/magickthumbnail rox-extra/memo rox-extra/mp3ogg2wav rox-extra/musicbox rox-extra/picky rox-extra/resolution rox-extra/reticker rox-extra/ripper rox-extra/rox-tail rox-extra/rox-wifi rox-extra/rox-xplanet rox-extra/roxcd rox-extra/roxdao rox-extra/roxget rox-extra/roxiso rox-extra/songer rox-extra/videothumbnail rox-extra/wallpaper rox-extra/weather In addition rox.eclass and rox-0install.eclass have been marked @DEAD and will be removed in 30 days. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUuszYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNceLgP/ijIpkO/ruEnVGxd31XYcj+h yITErG121GND1H+57gZJiQ0KfKCXiQc84Nnl46nFU5wNV/3hxyN3SDroPDmgcO3f l66Z/I4356EEi926YvT7tvkfmOPdAPQp3UX8uR/olx6TSSvEW3DR2bBVOWDeKgE9 5ofNwUz6phz+rW0e+dDBQ4sCT+QkEzMT9NKqEwmGa+koPcVOsa4xdi5qhz9IGGuV 0b9Jd27UFWsbi9OpXBPyd1s3qHxWPJEBnxpapwwSQj0pZcId9LUaypF2otZ8YESZ xe8iF+72YmyE5ExrN1udw/51OIiu8h5tOOYC31mJAddYctBxK8NUnPKhKh/JMq3V kc8iJqwuLjgyKBFosw9PAA7ZCvKlWmkAwGloFFvegGDgRrEY8rVvi2L6s9ShST/e WZnkEUQZ2qPTiZ0ypEQ3yD4NTo3FNhBlcA8FLNCxJiyaou0VohkTz/Us1eH/iNbE LXAsJszXtyJVJRch9zogir6+Bylo2rUe/wntPHKoSuOgysEwMcZbHaGDTzWny/dt MXYVsU9wtiDZWAY79P5MylWCzkZ9cp3/1LLogCO6UoYL1kCfCoywVhai6dlSjGR9 VPXxyev3qMqLTw15tlk3666JZIWHqGbNzhtqYdt+uAY7nS+qZqP2HGU1mQ3plPKL GXBOby2q6VS3gR65+i4L =fzsO -END PGP SIGNATURE-
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer wrote: > * AutoRepoman catches issues, but no one but me seems to care > Fix: Remind people of > http://packages.gentooexperimental.org/repoman-current-issues.txt I've tweaked two random things in this list :) Thank you! -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote: > On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer wrote: > > * Stage3 archives are too fat > > See https://bugs.gentoo.org/show_bug.cgi?id=531632 > > We're now shipping three python versions and glib for extra fun! > > Fix: Motivate releng to stop being silly > > Why the heck do we ship both 3.3 and 3.4? I forget the exact situation > with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only > is a great option if that remains the default after installation > (although it would be fine for just the initial stages). I'm going to be very blunt. I am sick of the finger being pointed only at releng for this. The issue is package dependencies. If even one package in the tree has a dumb dependency on python, e.g. dev-lang/python, it will pull in all stable versionf of python. If all the dependencies are correct, on the other hand, it is a matter of setting python_targets to include the versions of python we want in the stages and making sure that everything we include in the stages works with those versions of python. William signature.asc Description: Digital signature
[gentoo-dev] keywording gcc-4.9 branch
Hi everyone, It looks like there aren't too many bugs against gcc-4.9 (bug #495124). There are a couple having to do with lto and one which is hardened specific, but its probably a good idea to start keywording on the various arches so we can get more bug reports and not trail behind. So I opened bug #536874. I've followed Ryan's workflow where he has one bug for gcc 4.9 porting and another for keywording/stabilization. I'm not sure why he did it this way, but it may be less confusing in the future to have just one which track the state of the ebuild from keyword masked, to keyworded to stabilization. @rhill, any advice here :) -- 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] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Patrick Lauer wrote: > > Do you, as QA team member, think that a review workflow improves quality? > > No. > > Bureaucracy does not improve quality by itself. A review workflow isn't about bureaucracy, it's about review. :) Now, review means different things to different people, and some will sometimes do mediocre review and consider that sufficient while others will usually always do excellent review. //Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Patrick Lauer: > On Friday 16 January 2015 18:29:08 hasufell wrote: >> Patrick Lauer: >>> On 01/16/15 23:26, hasufell wrote: Patrick Lauer (patrick): > patrick 15/01/16 04:16:55 > > Modified: ChangeLog > Added:libuv-1.2.1.ebuild > Log: > Bump I expect people to ask me for review if they bump any of my packages. That includes QA team members. >>> >>> Are you always in such a bad mood? >> >> Do you, as QA team member, think that a review workflow improves quality? > > No. > > Bureaucracy does not improve quality by itself. > Patrick, I am really sorry, but this answer made me laugh and cry. A review workflow is a fundamental concept in programming methodology and we have decades of experience that taught us how important it is. I have no words to describe how disappointed I am right now.
Re: [gentoo-dev] Things one could be upset about
Patrick Lauer wrote: > they can all be fixed. > > Let's not tolerate mediocrity. All you can do is to try to set an example, but you'll likely find that most of the time, nobody is willing to live with the tradeoffs for excellence - the obvious one being perceived slower development. Countless others are perfectly happy with mediocrity, and wouldn't care even if they were to understand just how mediocre. //Peter
Re: [gentoo-dev] Things one could be upset about
Dnia 2015-01-17, o godz. 19:35:09 Patrick Lauer napisał(a): > Here's a random unsorted list of things that it would make sense to be upset > about. Some issues that people have successfully ignored for a few years ... > > In no way exhaustive list, feel free to remember a dozen things I forgot ;) > (If you suggest other things please try to offer constructive criticism, > i.e. possible strategies to fix issues ... whining by itself is not very > useful) * people writing to the mailing lists and starting pointless discussions which never bring anything good and only waste people's time. -- Best regards, Michał Górny pgp_ADBD4x_m1.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 19:49:24 +0400 Сергей wrote: > Any random user can tell you: -u means UPDATE, -D means DEEP (follow > dependencies). And what do those actually mean? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 18:33:45 +0300 Andrew Savchenko wrote: > Oh, this was discussed so many times already... There is NO single > correct solution to such problems. And some mathematically correct > solutions are impractical (e.g. half of the tree rebuild), so other > ones which are good enough are preferred. As long as imperfect > solution works fine, I'm ok with it. And this is how errors accumulate until your system is a broken mess... > - slower then portage Not to do the same thing it isn't. > (I don't care here if it is more correct or not, I just want to do my > daily job); Well, either you spend a tiny bit more time every now and again avoiding problems, or you spend a huge amount of time when something breaks at the least convenient possible moment. > - not fully compatible with portage: it triggers a lot of problems > portage doesn't. While this may be good for QA and tree > improvement, I don't want to hang my workflow due to these issues; Most of the problems you'll encounter are a one-off thing when switching, particularly if you've allowed your system to be full of broken dependencies etc by long-term use of Portage (see above). Once you've cleaned up your system and fixed all the breakages you've introduced by general sloppiness over the years, the problems you'll see are genuine ones that need to be dealt with properly. > - importare instead of local overlay is a complete nightmare: > usually I don't want to install package exactly as make install > does: often it lacks some required files (e.g. init scripts) or > installs something unneeded on Gentoo system. > Besides I use local overlay to test packages before committing to > public overlays or Gentoo main tree. Lack of local overlay support > is sufficient to send paludis straight to waste bin on my systems. Uh, Paludis supports overlays, and always has. > - completely insane command line options, arguments required to do > what I want to do are quite cumbersome, portage is much saner here. "emerge -uUDpvN --with-bdeps=y" vs "cave resolve --complete"? Here's a quiz for you: exactly what do -u and -D even do with Portage? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
> * AutoRepoman catches on average maybe 2 user-visible breakages. > Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours) > Fix: Remind people that using repoman is not optional Fix: Make more repoman warnings fatal. Please. Fix: Make the QA team deliver a friendly but stern warning to people who don't use repoman and thus commit crap. If repeated or blatantly wrong, revert [1]. Dream: If the git migration ever happens, make later git refuse pushes that break the tree. (if only by pushing to a staging area first, which is then automatically forwarded to the main tree if ok.) > * AutoRepoman still runs on my hardware > Fix: Remind infra of https://bugs.gentoo.org/show_bug.cgi?id=484064 > * mail archives have been broken since 2012 > Fix: get infra to either fix it, or provide enough information that it > can be fixed. See https://bugs.gentoo.org/show_bug.cgi?id=424647#c27 > * git.overlays.gentoo.org only partially functional (web interface / cgit > down) > * euscan doesn't run on infra hardware > Fix: https://bugs.gentoo.org/show_bug.cgi?id=453886 > * libreoffice-bin isn't built on infra hardware > Fix: Remind infra to set up a build environment for that Fix: Maybe accept more volunteers into infra? It would be interesting to hear if/how recruiting of new infra members progresses, in relation to workload. [I don't buy the argument that the mail archives are unneeded, ever since I've tried assembling a council agenda and half the relevant e-mails were missing at gmane. AutoRepoman and irker are extremely useful and a direct help for all developers.] * Our main website is still stuck in the 90ies. Fix: migrate all remaining projects to the wiki, then set up something new as main page. Willing to help out with the first step (generating the wiki pages) if people are willing to accept help. * We need a bit more Public Relations. Feeling a bit annoyed right now that we still don't have a FOSDEM booth (maybe we should just occupy the ChromeOS one). Fix: Next year, start getting annoyed in time and annoy some fellow Europeans. :] [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusbhp/ChangeLog?hideattic=0&view=log -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote: > On Sat, 17 Jan 2015 17:39:29 +0300 > Andrew Savchenko wrote: > > There is some progress here. In portage-2.2.15 profile based > > optimizations are included (see bugs 529660, 530010). On my > > hardware (Athlon-XP, 2200 MHz and Intel Atom N270, 1600 MHz) they > > speed up dependency resolution by ~ factor 2. > > The problem isn't the constants, though. The problem is the resolution > algorithm. There's not much point tweaking performance until the > resolver is fixed to produce a correct answer... Oh, this was discussed so many times already... There is NO single correct solution to such problems. And some mathematically correct solutions are impractical (e.g. half of the tree rebuild), so other ones which are good enough are preferred. As long as imperfect solution works fine, I'm ok with it. As for paludis, I tried it. Everything mentioned below is my _personal_ experience and not supposed to pretend to be objective. So, from my experience paludis turned out to be: - slower then portage (I don't care here if it is more correct or not, I just want to do my daily job); - not fully compatible with portage: it triggers a lot of problems portage doesn't. While this may be good for QA and tree improvement, I don't want to hang my workflow due to these issues; - importare instead of local overlay is a complete nightmare: usually I don't want to install package exactly as make install does: often it lacks some required files (e.g. init scripts) or installs something unneeded on Gentoo system. Besides I use local overlay to test packages before committing to public overlays or Gentoo main tree. Lack of local overlay support is sufficient to send paludis straight to waste bin on my systems. - completely insane command line options, arguments required to do what I want to do are quite cumbersome, portage is much saner here. Everything above is just my personal experience, so your mileage may vary. But after all that issues I don't even want to try paludis in the foreseeable future. Best regards, Andrew Savchenko pgpCxUFZ8zSgo.pgp Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 22:59:08 +0800 Patrick Lauer wrote: > > The problem isn't the constants, though. The problem is the > > resolution algorithm. There's not much point tweaking performance > > until the resolver is fixed to produce a correct answer... > > Patches welcome :) If I send you a patch that updates all the documentation to use Paludis rather than Portage, will you welcome it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 22:58:33 +0800 Patrick Lauer wrote: > On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote: > > On Sat, 17 Jan 2015 21:03:30 +0800 > > Patrick Lauer wrote: > > > Last time I tested paludis it was slower > > > > You've yet to do a like-for-like comparison... > > Hello hostile upstream. > > It was as "like for like" as possible Well that's the point... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 14:45:51 Ciaran McCreesh wrote: > On Sat, 17 Jan 2015 17:39:29 +0300 > > Andrew Savchenko wrote: > > There is some progress here. In portage-2.2.15 profile based > > optimizations are included (see bugs 529660, 530010). On my > > hardware (Athlon-XP, 2200 MHz and Intel Atom N270, 1600 MHz) they > > speed up dependency resolution by ~ factor 2. > > The problem isn't the constants, though. The problem is the resolution > algorithm. There's not much point tweaking performance until the > resolver is fixed to produce a correct answer... Patches welcome :)
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote: > On Sat, 17 Jan 2015 21:03:30 +0800 > > Patrick Lauer wrote: > > Last time I tested paludis it was slower > > You've yet to do a like-for-like comparison... Hello hostile upstream. It was as "like for like" as possible, even when there had to be workaround to make paludis build (and wait multiple hours as it is kinda horribly C++) as it tried to OOM very nicely. You can continue whining about it as much as you want, my results were duplicated by multiple people and you never offered a tweaked comparison that is to your liking. So stop whining (which is amusingly the trigger for my initial email - people whining about irrelevant things instead of doing something useful).
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Am Samstag, 17. Januar 2015, 01:56:01 schrieb Patrick Lauer:
> On Friday 16 January 2015 18:29:08 hasufell wrote:
> > Patrick Lauer:
> > > On 01/16/15 23:26, hasufell wrote:
> > >> Patrick Lauer (patrick):
> > >>> patrick 15/01/16 04:16:55
> > >>>
> > >>> Modified: ChangeLog
> > >>> Added:libuv-1.2.1.ebuild
> > >>> Log:
> > >>> Bump
> > >>
> > >> I expect people to ask me for review if they bump any of my packages.
> > >> That includes QA team members.
> > >
> > > Are you always in such a bad mood?
> >
> > Do you, as QA team member, think that a review workflow improves quality?
>
> No.
>
> Bureaucracy does not improve quality by itself.
Oh for ${DEITY}'s sake, get a soundproof basement somewhere and fight it out.
Yes we have that rule about "touching other developer's ebuilds", and it also
applies to >10year devs. So since the maintainer insists, how about "ok, I'm
sorry, will do better next time"?
I see absolutely no need to invoke any QA privileges here, and it also wasn't
done when doing the bump. So the only QA team "involvment" would be that it's
expected of members of privileged teams to be sensitive about doing things by
the book.
--
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 17:39:29 +0300 Andrew Savchenko wrote: > There is some progress here. In portage-2.2.15 profile based > optimizations are included (see bugs 529660, 530010). On my > hardware (Athlon-XP, 2200 MHz and Intel Atom N270, 1600 MHz) they > speed up dependency resolution by ~ factor 2. The problem isn't the constants, though. The problem is the resolution algorithm. There's not much point tweaking performance until the resolver is fixed to produce a correct answer... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer wrote: > * Portage is too slow > On 'small' hardware emerge -upNDv @world can take enough time > to make updates prohibitive - on an 800Mhz machine it took me > about 3 days to figure out a solution to some silly blockers due to the > very slow change test cycle > Fix: Do some profiling and un-refactoring to remove useless code > Fix: Set up a reference system (CI) to catch future regressions There is some progress here. In portage-2.2.15 profile based optimizations are included (see bugs 529660, 530010). On my hardware (Athlon-XP, 2200 MHz and Intel Atom N270, 1600 MHz) they speed up dependency resolution by ~ factor 2. Of course it will be great to see further optimizations, though as far as I remember this will require more complicated changes. Best regards, Andrew Savchenko pgpOKujBNeLwv.pgp Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 21:03:30 +0800 Patrick Lauer wrote: > Last time I tested paludis it was slower You've yet to do a like-for-like comparison... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
El sáb, 17-01-2015 a las 13:44 +0100, Dirkjan Ochtman escribió: [...] > Also, I hate something like > "['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]']". > What the hell kind of warning is that? I guess maybe these are the > results of USE_EXPAND trickery and what not, but it would sure be nice > to have something more readable. Yeah, sometimes the output are really fat, not sure if some heuristic could be done to, for example, collate the exact same errors that are coming from every single subprofile.
Re: [gentoo-dev] Things one could be upset about
El sáb, 17-01-2015 a las 19:35 +0800, Patrick Lauer escribió:
[...]
> * stable genkernel still doesn't enable all useful kernel features
>e.g. accounting statistics are absent, so iotop doesn't work ootb
>See for example #442936 (from 2012 ?!)
>Fix: Stable newer versions
>
I see there isn't even any stable bug report for that, is anyone major
blocking newer versions to be stabilized?
> * AutoRepoman catches issues, but no one but me seems to care
> Fix: Remind people of
> http://packages.gentooexperimental.org/repoman-current-issues.txt
> Fix: Make it yell louder? It currently reports on IRC to #gentoo-{bugs,qa}
>
Maybe some warnings could be raised to fatal to prevent to commit them
(that shouldn't be a problem as that are usually easy to fix problems).
For example, the dodoc "LICENSE" stuff and WANT_AUTOCONF=latest
> * mail archives have been broken since 2012
> Fix: get infra to either fix it, or provide enough information that it
> can
> be fixed. See https://bugs.gentoo.org/show_bug.cgi?id=424647#c27
>
Is there any advantage of setting them up again instead of relying on
other existing external resources? :/
Re: [gentoo-dev] Things one could be upset about
On Sat, Jan 17, 2015 at 2:03 PM, Patrick Lauer wrote: > Most issues are transient, often fixed with either a keywording bug, or > careful > masking of useflags / pruning of old versions. Per-maintainer doesn't really > make sense as most issues are indirect - things like "removing package.mask > entry for new version causes dependency breakage on ia64 to become visible", > or "dependency of dependency changed". In both cases it's often hard enough to > figure out what caused the issue. I think louder in the sense of a weekly -dev email could still makes sense. #-bugs and #-qa are way too noisy for me. Cheers, Dirkjan
Re: [gentoo-dev] Things one could be upset about
On Saturday 17 January 2015 13:44:21 Dirkjan Ochtman wrote:
> On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer wrote:
> > * AutoRepoman catches issues, but no one but me seems to care
> >
> > Fix: Remind people of
> > http://packages.gentooexperimental.org/repoman-current-issues.txt
> > Fix: Make it yell louder? It currently reports on IRC to
> > #gentoo-{bugs,qa}
> I'll happily fix my repoman issues when I notice them. I try to always
> run repoman full on a package, but like you say, a tree-wide scan
> isn't really viable on a per-commit basis. Can we have AutoRepoman
> report open issues to gentoo-dev on a weekly basis? That seems like a
> fine idea to me. Per-maintainer and per-team/project/herd RSS/Atom
> feeds would also be pretty nice to have.
Most issues are transient, often fixed with either a keywording bug, or careful
masking of useflags / pruning of old versions. Per-maintainer doesn't really
make sense as most issues are indirect - things like "removing package.mask
entry for new version causes dependency breakage on ia64 to become visible",
or "dependency of dependency changed". In both cases it's often hard enough to
figure out what caused the issue.
> Also, I hate something like
> "['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_pyt
> hon2_7(-)]']". What the hell kind of warning is that? I guess maybe these
> are the results of USE_EXPAND trickery and what not, but it would sure be
> nice to have something more readable.
Indeed, portage output is quite complex and often hard to read. I'm not sure
what's the best way to improve it - I've filed a few small bugs for output
prettyfication, but I don't even know what I'd want to be displayed for these
useflag / blocker issues.
>
> > * Portage is too slow
> >
> > On 'small' hardware emerge -upNDv @world can take enough time
> > to make updates prohibitive - on an 800Mhz machine it took me
> > about 3 days to figure out a solution to some silly blockers due to
> > the
> > very slow change test cycle
> > Fix: Do some profiling and un-refactoring to remove useless code
> > Fix: Set up a reference system (CI) to catch future regressions
>
> Why not use paludis, or another package manager?
Last time I tested paludis it was slower (and building it OOMed on that
machine with default settings, so that's quite amusing)
Also it suffers from a hostile upstream, makes bugreports very tricky to handle
etc.etc.
Pkgcore is in hibernation, it needs a bit more work to become really useful
again. Possibly some ideas from pkgcore can be migrated to portage again, but
that'd need someone with lots of free time.
Thanks for your feedback,
Patrick
Re: [gentoo-dev] Things one could be upset about
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer wrote:
> In no way exhaustive list, feel free to remember a dozen things I forgot ;)
> (If you suggest other things please try to offer constructive criticism,
> i.e. possible strategies to fix issues ... whining by itself is not very
> useful)
I think this is a good list, thanks for coming up with it. I very much
agree that whining by itself is not very useful, and we should find
ways to move things forward (even if sometimes it's not the most
straightforward way?).
> * AutoRepoman catches on average maybe 2 user-visible breakages.
> Mostly removing stable on HPPA ;)
> Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
> Fix: Remind people that using repoman is not optional
>
> * AutoRepoman catches issues, but no one but me seems to care
> Fix: Remind people of
> http://packages.gentooexperimental.org/repoman-current-issues.txt
> Fix: Make it yell louder? It currently reports on IRC to #gentoo-{bugs,qa}
I'll happily fix my repoman issues when I notice them. I try to always
run repoman full on a package, but like you say, a tree-wide scan
isn't really viable on a per-commit basis. Can we have AutoRepoman
report open issues to gentoo-dev on a weekly basis? That seems like a
fine idea to me. Per-maintainer and per-team/project/herd RSS/Atom
feeds would also be pretty nice to have.
Also, I hate something like
"['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]']".
What the hell kind of warning is that? I guess maybe these are the
results of USE_EXPAND trickery and what not, but it would sure be nice
to have something more readable.
> * Portage is too slow
> On 'small' hardware emerge -upNDv @world can take enough time
> to make updates prohibitive - on an 800Mhz machine it took me
> about 3 days to figure out a solution to some silly blockers due to the
> very slow change test cycle
> Fix: Do some profiling and un-refactoring to remove useless code
> Fix: Set up a reference system (CI) to catch future regressions
Why not use paludis, or another package manager?
> * Stage3 archives are too fat
> See https://bugs.gentoo.org/show_bug.cgi?id=531632
> We're now shipping three python versions and glib for extra fun!
> Fix: Motivate releng to stop being silly
Why the heck do we ship both 3.3 and 3.4? I forget the exact situation
with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only
is a great option if that remains the default after installation
(although it would be fine for just the initial stages).
> * AutoRepoman still runs on my hardware
> Fix: Remind infra of https://bugs.gentoo.org/show_bug.cgi?id=484064
>
> * euscan doesn't run on infra hardware
> Fix: https://bugs.gentoo.org/show_bug.cgi?id=453886
>
> * mail archives have been broken since 2012
> Fix: get infra to either fix it, or provide enough information that it can
> be fixed. See https://bugs.gentoo.org/show_bug.cgi?id=424647#c27
>
> * libreoffice-bin isn't built on infra hardware
> Fix: Remind infra to set up a build environment for that
These ones, the euscan one in particular, also have been stuff I cared
about, but after trying a bunch of times to start helping infra out,
apparently they don't have any ways to absorb new contributors. This
does seem like a big problem given the amount of technical debt on the
infra-side you're laying out here.
I understand that it's a big job and that there are security aspects
to it, but if there are no ways to empower new people to help them
out, that is worrying to me.
> * Some stable bugs are left alone for months
>See e.g. https://bugs.gentoo.org/show_bug.cgi?id=485632
>Fix: Have more people work on stable bugs
>Fix: Motivate people to file more stable bugs (continuous updates)
This is a thorny problem as well. I worry that we lose momentum here
due to size and perfectionism (e.g. we can only stable new gcc once we
fix all the blockers, and we don't have enough active maintainers on
some of those blockers). I think we should maybe stabilize more
optimistically at least on common architectures, e.g. by having a
lighter-weight upfront testing process and relying more on maintainers
keeping up to speed on subsequent bugs.
I also wonder if we could sort of crowd-source archtesting, maybe by
having people contribute their package.keywords through gentoo-stats
or some such to see how well an unstable package is being tested on
stable systems already.
Or if we should have a different process for e.g. Python/Ruby/Perl/PHP
packages compared to C/C++ packages, since the former are much less
sensitive to architecture differences.
Also, one thing you didn't mention is the git migration; I think our
usage of CVS definitely counts as a big gob of technical debt. What's
that currently blocked on, anyway?
Cheers,
Dirkjan
[gentoo-dev] Things one could be upset about
Here's a random unsorted list of things that it would make sense to be upset
about. Some issues that people have successfully ignored for a few years ...
In no way exhaustive list, feel free to remember a dozen things I forgot ;)
(If you suggest other things please try to offer constructive criticism,
i.e. possible strategies to fix issues ... whining by itself is not very
useful)
* stable genkernel still doesn't enable all useful kernel features
e.g. accounting statistics are absent, so iotop doesn't work ootb
See for example #442936 (from 2012 ?!)
Fix: Stable newer versions
* stage3 still enables bindist in make.conf
See https://bugs.gentoo.org/show_bug.cgi?id=473332
Causes random breakage of tools like wget/curl, etc.
Fix: poke releng until they stop being silly
* AutoRepoman catches on average maybe 2 user-visible breakages.
Mostly removing stable on HPPA ;)
Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
Fix: Remind people that using repoman is not optional
* Portage is too slow
On 'small' hardware emerge -upNDv @world can take enough time
to make updates prohibitive - on an 800Mhz machine it took me
about 3 days to figure out a solution to some silly blockers due to the
very slow change test cycle
Fix: Do some profiling and un-refactoring to remove useless code
Fix: Set up a reference system (CI) to catch future regressions
* Stage3 archives are too fat
See https://bugs.gentoo.org/show_bug.cgi?id=531632
We're now shipping three python versions and glib for extra fun!
Fix: Motivate releng to stop being silly
* AutoRepoman catches issues, but no one but me seems to care
Fix: Remind people of
http://packages.gentooexperimental.org/repoman-current-issues.txt
Fix: Make it yell louder? It currently reports on IRC to #gentoo-{bugs,qa}
* AutoRepoman still runs on my hardware
Fix: Remind infra of https://bugs.gentoo.org/show_bug.cgi?id=484064
* mail archives have been broken since 2012
Fix: get infra to either fix it, or provide enough information that it can
be fixed. See https://bugs.gentoo.org/show_bug.cgi?id=424647#c27
* git.overlays.gentoo.org only partially functional (web interface / cgit
down)
* euscan doesn't run on infra hardware
Fix: https://bugs.gentoo.org/show_bug.cgi?id=453886
* libreoffice-bin isn't built on infra hardware
Fix: Remind infra to set up a build environment for that
* Some stable bugs are left alone for months
See e.g. https://bugs.gentoo.org/show_bug.cgi?id=485632
Fix: Have more people work on stable bugs
Fix: Motivate people to file more stable bugs (continuous updates)
* Updates from very old installs are still difficult
Fix: Collect stage3 archives and tree snapshots maybe every 3 months apart
then update from one snapshot to the next. Possibly fix upgrade bugs
retroactively in the snapshots and automate the process
It'd be nice to have such things fixed, but alas, many rely on someone else to
respond. And for some there's no 'easy' solution.
But they can all be fixed.
Let's not tolerate mediocrity.
Take care,
Patrick
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/17/2015 05:09 AM, Andrew Savchenko wrote: > On Sat, 17 Jan 2015 08:56:01 +0800 Patrick Lauer wrote: >> On Friday 16 January 2015 18:29:08 hasufell wrote: >>> Patrick Lauer: On 01/16/15 23:26, hasufell wrote: > Patrick Lauer (patrick): >> patrick 15/01/16 04:16:55 >> >> Modified: ChangeLog Added: >> libuv-1.2.1.ebuild Log: Bump > > I expect people to ask me for review if they bump any of my > packages. That includes QA team members. Are you always in such a bad mood? >>> >>> Do you, as QA team member, think that a review workflow >>> improves quality? >> >> No. >> >> Bureaucracy does not improve quality by itself. > > This is not a formal bureaucracy, there are some rules to behave > in community and these rules are supposed to be equal for > everyone: > http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html > > "Touching other developers ebuilds". > > The fact that developer with QA team member mandate (even if it > was not used in this case) intentionally violates this policy > without even considering this action as something abnormal is very > disturbing. > > Best regards, Andrew Savchenko > we are having the same discussion every couple of months. It should have been a clue that such issues are not meant to be solved in the list since we tend to drive everything off-topic in the end. It might be best to report such issues to the designated teams. At least then, if there is no solution, at least you followed the normal procedure - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUujN7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZWegH/jaswVnHB14ozVO54TWwiThf VWMoFlvE093jYIU/pxWK+4+petQX5ikAONagcnR4zPKIQybtUEnLGTH70A/lFvyU oDjyroJg2Mq2auRD7s1pETEVXWhroh+gDLmR7SBcHXCAcJSyOlu4rhPRDlZPkBJV BaeMMUE+0dcHQYypKGizSt20ov0LT396smGWgFZFxjSJsEs8H6iDuxzJm5JdB+AZ S6AFbIlwsXi4gTWIk2fxbGg2pRUUDwykhoWfu3pv2iIwuOLbGGrct6xRm/vlzLrB HFdnqVqVEzd/LcjW4cYmTkFbup6L0qCfUKu2cxkRI/EJfIIsJLmN9O557r47Gm8= =JH6B -END PGP SIGNATURE-
