[00:05] <norsetto> see u all
[01:52] <ScottK> jdong: clamav 0.93 is the one we're doing as a pre-backport.  It's a mess and it may be a couple of days before I have something.
[01:53] <jdong> ScottK: sounds good :)
[01:57] <emgent> motu-release people please ACK bug #216591 and bug #216117
[01:57] <ubotu> Launchpad bug 216591 in sympa "[CVE-2008-1648] denial of service via crafted Content-Type header" [High,In progress] https://launchpad.net/bugs/216591
[02:35] <bddebian> Heya gang
[02:35] <RAOF> Howdie bddebian.
[02:35] <bddebian> Hi RAOF
[02:36] <RAOF> Damn you, st_string_notify!    Homepage at http://nouveau.freedesktop.org/ - EXPERIMENTAL packages at https://launchpad.net/~raof/+archive
[02:39] <RAOF> I may have been raving about it's awesome 2d performance recently :)
[02:40] <RAOF> (Because it's 2d performance _is_ awesome)
[02:40]  * RAOF is attacked by the society for the prevention of cruelty to apostrophes.
[02:41] <bddebian> Oh aye, right
[02:46] <RAOF> Everyone should totally test the randr12 codepath before it's pushed to the kernel, lest kittens be killed.
[02:48] <StevenK> RAOF: s/recently/all the time/
[02:50] <RAOF> StevenK: Well, it's _still_ quite a lot faster than the blob :)
[02:51] <StevenK> RAOF: When I can play WoW reasonably, I'll be very impressed. :-)
[02:51] <RAOF> Yeah, yeah.  You could play neverball now, with reflections.
[02:52] <RAOF> And ppracer, and openarena, etc.
[02:52] <bddebian> For about 2 minutes until you are asleep from the boredom.. ;-P
[02:52] <RAOF> Well, yes.
[02:54] <StevenK> RAOF: What about crack-attack?
[02:54] <RAOF> What is crack-attack?
[02:55] <StevenK> apt-cache show it
[02:55] <RAOF> Hm.  It'll probably run fine.
[02:55] <StevenK> crack-attack is adictive
[02:55] <RAOF> I don't have it here, nor do I have an internet connection for my laptop.
[02:56] <jml> RAOF: I can't believe we haven't played crackattack!
[02:56] <StevenK> Ha!
[02:56]  * StevenK shall have to play jml
[02:56] <RAOF> jml: I'll schedule a duel, shall I?
[02:57] <jml> RAOF: sure.
[02:57] <jml> RAOF: what are you up to this weekend anyway?
[02:57] <RAOF> Naught much.
[02:57]  * jml takes off channel
[03:51] <slangasek> wow, I was right about the patch in bug #215729 having a memory leak; I'm not sure if that's uncanny prescience, or jaded lack of confidence in people's C skills... :)
[03:51] <ubotu> Launchpad bug 215729 in seahorse "Seahorse fails to import keys" [Medium,In progress] https://launchpad.net/bugs/215729
[03:53] <lifeless> slangasek: assume noone can write C correctly.
[03:53] <slangasek> lifeless: apparently I did!
[03:53] <RAOF> slangasek: It's a fair bet that an arbitrary piece of C code has a memory leak.  The language is designed to make it easy.
[03:53] <slangasek> (...assume, that is)
[03:54] <ScottK> slangasek: I was reading Raphael Hertzog's Misc development news today and discovered that our debsign will no longer make legit .changes files for Debian.
[03:54]  * ScottK wonders if we should update or just consider anyone who cares will manage it.
[03:55] <slangasek> ScottK: what's illegitimate about them?
[03:56] <slangasek> oh, right, this is that when you do a separate debsign it doesn't update the sha1 checksums in the .changes to account for the changed .dsc
[03:56] <ScottK> Yes.  That one.
[03:56] <lifeless> wt
[03:56] <lifeless> f
[03:57] <lifeless> why would debsign regress?
[03:57] <slangasek> lifeless: it didn't; debsign never knew about the sha1 fields, which dak in Debian now validates
[03:57] <lifeless> ah
[03:57] <ScottK> Because someone would update the infrastructure in Debian and then worry about the tools.
[03:58] <slangasek> ScottK: I'd be inclined to accept a fix, but not worry overly much if it didn't make it in
[03:58] <ScottK> OK.
[03:58] <slangasek> ScottK: ah, you don't want me to start ranting about dpkg-dev and the current gtk-doc build failure... :P
[03:58] <ScottK> No.
[03:59] <ScottK> I'd just like to have a tool set in the release that works for both Lenny and Intrepid.
[03:59] <slangasek> ScottK: should I goad you into hijacking dpkg in Debian? ;)
[04:00] <ScottK> No.
[04:00] <ScottK> I've seen how that goes.
[04:00] <ScottK> I don't care to experience it personally and directly.
[04:00] <ScottK> At least I saw enough of the public bits of it.
[04:08] <ScottK> I also recognize that my wanting something doesn't mean it's going to happen.
[04:08] <StevenK> Hm.
[04:09] <StevenK> I wonder why bug 181150 didn't get closed
[04:09] <ubotu> Launchpad bug 181150 in moko "[FFe] moko contains a shared library with no soname/dev package handling" [Critical,Confirmed] https://launchpad.net/bugs/181150
[04:18] <ScottK> slangasek: I'm updating our debsign to the 2.10.25 version (without updating the rest of the package).  Assuming it works, are you OK with me uploading that?
[04:27] <slangasek> ScottK: yeppers
[04:31] <ScottK> Somehow using debsign to sign the new devscripts package as a test of the updated debsign seems vaguely incestuous.
[05:00] <StevenK> ScottK: Can I use the same FFe bug for all 3 uploads?
[05:00] <StevenK> ScottK: (Bug 181150, for reference)
[05:00] <ubotu> Launchpad bug 181150 in moko "[FFe] moko contains a shared library with no soname/dev package handling" [Critical,Confirmed] https://launchpad.net/bugs/181150
[05:32] <imbrandon> evening all
[05:36] <StevenK> imbrandon!
[05:37] <StevenK> imbrandon: #ubuntu-wow lives, you need to join
[05:48] <slangasek> ScottK: huh, do you know why the $DEBSIGN_ALWAYS_RESIGN variable is no longer honored in the new debsign?
[06:12] <imbrandon> StevenK: ahhh yea :)
[07:21] <dholbach> good morning
[07:23] <imbrandon> heya dholbach
[07:23] <dholbach> hiya imbrandon
[08:03] <_ruben> is there some 'trick' to turn a "normal" package with stripped binaries into 2 packages, one "normal" and one "dbg" (with non-stripped) binaries?
[08:07] <dholbach> _ruben: install pkg-create-dbgsym and just build the package by running    debuild -us -uc
[08:07] <dholbach> pkg-create-dbgsym then will create a .ddeb
[08:12] <_ruben> dholbach: and when using pbuilder ?
[08:13] <dholbach> _ruben: is it a package in the archive?
[08:13] <_ruben> dholbach: no, well, newer version of one that is in the archives
[08:13] <dholbach> right :/
[08:14] <dholbach> you could try if DEB_BUILD_OPTIONS="noopt nostrip" works
[08:15] <_ruben> but that would make just a non-stripped binary package right? right now i build my package twice, once with, once without dh_strip
[08:21] <soren> _ruben: Why can't you use pkg-create-dbgsym?
[08:21] <\sh> dholbach, we should add pkg-create-dbgsym during devel cycles into the debootstrap templates
[08:23] <\sh> _ruben, pkg-create-dbgsym is installed on our buildds, and if you add them to your pbuilder chroot (pbuilder --save-after login , apt-get install pkg-create-dbgsym, something like this) will give you the very same binary package output as our buildds are creating during devel cycles...
[08:23] <dholbach> \sh: not sure that's desirable - especially since we have .ddeb files at http://ddebs.ubuntu.com anyway
[08:24] <soren> _ruben: "pbuilder --update --extrapackages pkg-create-dbgsym" seems like the right approach.
[08:24] <dholbach> https://wiki.ubuntu.com/DebuggingProgramCrash
[08:24] <_ruben> soren: its the first time i hear about that package, playing with it now
[08:24] <_ruben> i guess i shouldnt have dh_strip in my debian/rules file then or what?
[08:25] <soren> _ruben: Just add pkg-create-dbgsym to your chroot, and you'll be fine.
[08:25] <soren> That's it. Really.
[08:25] <\sh> dholbach, well, building the package with the same build infrastructure is sometimes better, then building a package with success and then seeing it ftbfsing on the buildds ;)
[08:25] <_ruben> soren: ok, updating chroot
[08:25] <dholbach> \sh: ?
[08:26] <\sh> dholbach, I had some packages which failed just because of this package in our buildd...(wine e.g.)
[08:26] <dholbach> \sh: a package is very unlikely to fail building in the pkg-create-dbgsym step
[08:26] <dholbach> right, but those bugs have been fixed
[08:26] <\sh> dholbach, pkg-create-dbgsym tweaks dh_strip afaiks...
[08:26] <dholbach> I'm not sure people should have .ddebs lying around they're not going to need :)
[08:27] <dholbach> just because pkg-create-dbgsym might fail in 0.xxx% of the cases :)
[08:27] <soren> \sh: Why would wine fail because of pkg-create-dbgsym?
[08:30] <\sh> soren, actually we don't know..but the magic behind pkg-create-dbgsym and the changed dh_strip call, made some binaries unsuable and failed building the package actually on amd64...first we just ignored the dh_strip result then (-dh_strip) but that gave us huge packages, and then excluding special binaries helped for that...but if there is a difference between "dh_strip" without the magic, and dh_strip with our magic, I would like to know before I u
[08:30] <\sh> pload to the buildd
[08:30] <\sh> meeting...bbl
[08:38] <_ruben> ahh .. pkg-create-dbgsym creates a suplemental package which has non-stripped binaries stored in a 'special' directory .. kinda nice solution ;-)
[09:00] <afflux> gah. I'm blind. May someone unsubscribe motu-release from bug 195508? It's a main package :(
[09:00] <ubotu> Launchpad bug 195508 in system-config-printer "applet.py crashed with AttributeError in check_for_jobs()" [Undecided,Triaged] https://launchpad.net/bugs/195508
[09:08] <TheMuso> afflux: I'll take care of it.
[09:10] <afflux> thanks
[09:12] <TheMuso> afflux: done.
[10:14] <HighNo> /join #okko
[10:14] <HighNo> doh
[11:58] <jeromeg> hello
[11:58] <jeromeg> could someone of motu release team review bug 216698 ?
[11:59] <\sh> bug #216698
[11:59] <ubotu> Launchpad bug 216698 in xpad "xpad 100% CPU bug" [Medium,Triaged] https://launchpad.net/bugs/216698
[12:00] <jeromeg> oh it seems that thu guy forgot to attach a diffstat
[12:00] <jeromeg> i'll attach one
[12:02] <TheMuso> jeromeg: Diffstats aren't usually needed.
[12:02] <jeromeg> ok
[12:03] <jeromeg> TheMuso: 2.14 only fixes this bug anyway
[12:03] <jeromeg> and it's already in debian
[12:28] <elmargol_> I search a documentation for bazaar or git for maintaining ubuntu packages
[12:28] <elmargol_> Any advise?
[12:28] <broonie> elmargol_: Look at git-buildpackage for git.
[12:30] <broonie> elmargol_: bzr-builddeb for bzr
[12:38] <doko> hi motu, please comment on bug #218133
[12:38] <ubotu> Launchpad bug 218133 in sun-java6 "UVF exception for hardy" [Undecided,New] https://launchpad.net/bugs/218133
[12:41] <sistpoty|work> hi folks
[12:43] <james_w> hi sistpoty|work
[12:43] <sistpoty|work> hi james_w
[13:02] <RainCT> Hey
[13:07] <Iulian> Hey
[13:08] <RainCT> Hi Iulian
[13:10] <Iulian> Hello RainCT
[13:20] <ScottK> slangasek: Re debsign and $DEBSIGN_ALWAYS_RESIGN - no I don't.
[13:21] <ScottK> StevenK: My recollection is that I thougt it applied to all three.  I'm not going to look again to see if that's incorrect.
[13:21] <StevenK> ScottK: Fair enough
[13:28] <ScottK> slangasek: debian/changelog is silent on the issue.
[13:40] <slomo> superm1: ping?
[14:32] <elmargol_> Someone knows a tool like meld to visually merge 2 bazaar revisions?
[14:35] <james_w> elmargol_: I think http://erik.bagfors.nu/bzr-plugins/extmerge is what you want
[14:35] <james_w> though #bzr would be a better place to ask.
[14:36] <elmargol_> thx
[14:42] <afflux> Riddell: someone wants to contact you about some broken dependency in your ppa (see bug 217709)
[14:42] <ubotu> Launchpad bug 217709 in network-manager "Hardy beta network manager cant upgrade" [Undecided,Invalid] https://launchpad.net/bugs/217709
[14:43] <Riddell> afflux: he should stop using the ppa then
[14:44] <superm1> hi slomo
[14:44] <superm1> what's up?
[14:44] <afflux> that's why I set this to invalid. But as he asked how to contact you, I just pinged you ;)
[14:51] <smallfoot-> hardy is on 8 days, please hurry up and fix the pink shadows & window decoration bug in the nvidia-utils drivers package
[14:51] <smallfoot-> also please in repo - codeblocks, jahshaka, etc
[14:52] <danielm> Hi all. g'morning..
[14:54] <smallfoot-> hiya
[14:55] <danielm> i'm building a package using cdbs. I need to add some example files, so i use: DEB_INSTALL_EXAMPLES_mypack-name1 = example.conf
[14:55] <danielm> The file example.conf is in debian/ but when i build the package always get this error: http://rafb.net/p/ugsQSq87.html
[14:55] <danielm> i need to set a path to file? I can't figure out what is wrong :/
[14:56] <\sh> danielm, what about debian/example.conf ?
[14:56] <\sh> danielm, because dh_installexamples is working from $(CURDIR)
[14:56] <\sh> that's why I hate cdbs..it hides things from people
[14:58] <danielm> yes, the file is in debian/example.conf.. $(CURDIR)? mm i'll check the log again
[15:01] <\sh> danielm, $(CURDIR) is the directory where the buildprocess extracts the source packages...which means something like: $TMP/foo/source-pkg-name-version/ <-- $(CURDIR) your example is in debian/ which is relative to curdir, so you need to set DEB_INSTALL_EXAMPLES_mypack-name1= debian/example.conf to let dh_installexamples know where to find this file
[15:01] <\sh> danielm, you should really forget about cdbs an start at least with debhelper packaging provided by dh_make as templatemaker
[15:01] <\sh> danielm, so you actually understand what's happening inside deep black cdbs magic
[15:02] <emgent> heya
[15:04] <danielm> hehe... ok \sh .. thanks a lot.
[15:13] <ScottK> jdong: Do we want Bug #218182?
[15:13] <ubotu> Launchpad bug 218182 in deluge-torrent "Please sync deluge-torrent <IP_ADDRESS>-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/218182
[15:17] <jdong> ScottK: that one looks trivial probably low-risk to drag in, but what is the relation between the debian and upstream changelogs?
[15:17] <jdong> they are for very different versions
[15:18] <ScottK> jdong: I didn't look at it in detail.  That's why I pinged you.
[15:18] <jdong> and I'm far more interested at the claimed bugfixes in the <IP_ADDRESS> release...
[15:18] <ScottK> dholbach: I'd like to suggest you send a mail to the MOTU list saying nevermind on single ack uploads for New packages so we can stop writing mails and move on to other things.
[15:18] <ScottK> RainCT: I think you and jdong should talk about what we want to do with deluge-torrent.
[15:19] <jdong> ScottK: but yeah, it's +1 from me for the requested sync for sure, but the fixes in .8.9 should be looked at, backported, uupdated to that version, etc
[15:19] <jdong> as the fixes are much more important (read: crashers)
[15:19] <jdong> RainCT: ^^
[15:20] <ScottK> jdong: If you want to just straight to .9, let's just do it and not bug the archive with a sync.
[15:20] <jdong> ScottK: that sounds like a plan
[15:20] <jdong> though I'm quite busy and probably won't be able to get to it ( RainCT, it's all yours? :D)
[15:23] <ScottK> jdong: Thanks.  I added that discussion to the bug too.
[15:25] <ScottK> DktrKranz2: Would you please have a look at Bug #206469 and make a recommendation.
[15:25] <ubotu> Launchpad bug 206469 in firebird2.0 "sync firebird2.0 from debian " [Undecided,Fix committed] https://launchpad.net/bugs/206469
[15:26] <dholbach> ScottK: The discussion should probably change in its form - I never wanted to stop anybody from doing their work, I do care about the topic though and a lot of the feedback was very useful
[15:27] <Hobbsee> do i want to read it?
[15:27] <ScottK> dholbach: I'm not saying you did, it's just that time replying to the thread is time not spent fixing stuff and I think it's pretty well run it's course.
[15:27] <ScottK> Hobbsee: No.  You don't.
[15:27] <Hobbsee> ScottK: what's the short version?
[15:28] <ScottK> Short version is having to get two MOTU sponsors is two hard for new packages.  We should make it just one.
[15:30] <ScottK> two/too on the second one.
[15:30] <Hobbsee> ah right
[15:30] <Hobbsee> and people said no?
[15:30] <ScottK> Yes.
[15:30] <Hobbsee> go tit
[15:35] <Hobbsee> ScottK: i appear to be reading anyway.
[15:35]  * ScottK hands Hobbsee some Valium.
[15:35] <Hobbsee> ScottK: i still think that it woudl be more helpful to focus on getting bugs fixed, etc, than putting new stuff into the archive, and watching it go out of date.
[15:35] <ScottK> Agreed.
[15:35] <ScottK> "Fix me 5 bugs and I'll upload your package."
[15:35] <sistpoty|work> anyone mind revu going down again? (I'm about to reboot spooky for new kernel, not too sure if it'll come back up)
[15:36] <Hobbsee> 2) why do we deem
[15:36] <Hobbsee> the reviewing of new packages different than uploading for example new
[15:36] <Hobbsee> packages versions, etc.?
[15:36] <Hobbsee> heh.  because there's a hell of a lot of difference in the amount of work involved, which tends to mean a lot of potential to get it wrong!
[15:37] <sistpoty|work> yeah, and imho reviewing is even more difficult than producing a new sourcepackage
[15:38]  * Hobbsee doesn't tend to do either, so...
[15:38]  * Hobbsee clubs cody-somerville
[15:38] <Hobbsee> cody-somerville: please don't quote an entire very long mail to only write a paragraph relating to a small amount of it.  Quote for context, not because you can quote the entire thing.
[15:38]  * ScottK really thinks we ought to require MOTUs to get one other MOTU to ack a new package.
[15:39]  * cody-somerville incurs concussion.
[15:39] <Hobbsee> ScottK: do you really think the other motu is not going to go "ack", just because you're a MOTU yourself, and they trust you?
[15:39] <sistpoty|work> ScottK: I beg to differ. I believe that MOTUs should know when to ask, so I would leave it as is
[15:39] <Hobbsee> cody-somerville: i didn't say  in the head.
[15:39] <ScottK> Hobbsee: When I've asked for reviews and gotten them, they've found stuff.
[15:39] <Hobbsee> ScottK: right
[15:39] <ScottK> sistpoty|work: I agree they should know, but not that they do.
[15:40] <ScottK> I think the smart ones are already asking, but the rule is needed for the ones that don't know as much as they think they do.
[15:40] <sistpoty|work> ScottK: hm... then we should fix that, maybe with a long and pointy stick (TM) ;)
[15:41] <Hobbsee> sistpoty|work: you'll have to find a mega-positive way to put it all first, if you want to use the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[15:41] <Hobbsee> sistpoty|work: ie, you can't say that people are screwing up, etc.
[15:41] <Hobbsee> sistpoty|work: so good luck to you
[15:41] <Hobbsee> ScottK: of course, thsi will all become very interesting with the new addons
[15:41] <sistpoty|work> Hobbsee: you just need to phrase it in positive words, so rather the use the pink stick of happiness :P
[15:42] <Hobbsee> sistpoty|work: ahhh.  is that the problem.  with ponies.
[15:42] <sistpoty|work> and sugar on the top *g*
[15:42] <ScottK> Dropping a pony on someone might work.
[15:42] <sistpoty|work> heh
[15:42] <\sh> there is a difference between new packages and new packages...
[15:43] <\sh> new packages from MOTUs (e.g. with upload rights) and those packages are wrong, the uploader == packager needs to fix it asap, or he/she's doomed
[15:43] <Pici> New packages and new packages?
[15:43] <\sh> new packages from "outsiders" who are not intending to become a motu, are mostly "buggy package, damn, I'm outta here"
[15:43] <zul> thats what the development cycle is for
[15:43] <Pici>  ah.
[15:43] <sistpoty|work> \sh: agreed
[15:44] <Hobbsee> \sh: i find it interestnig the number of people who never comment on why their package is missing from the web UI.
[15:44] <ScottK> zul: Only if there are developers to work on it.
[15:44] <Hobbsee> at all.
[15:44] <Hobbsee> \sh: or who managed to get it uploaded in another way, but never bothered to actually notify revu
[15:44] <zul> ScottK: well if you sponsor an upload then you should keep an eye on it
[15:44] <Hobbsee> now, as to whether it has a working email address, i'm unsure, but...
[15:45] <ScottK> zul: Maybe the solution is that the uploader has to sign up for bugmail.
[15:45] <zul> ScottK: thats a given
[15:45] <\sh> zul, that's a problem actually, because the whole motu team is responsible when the NEW package hits the archives
[15:45] <ScottK> zul: Is it?  Where is that written down?
[15:45] <zul> ScottK: common sense
[15:46] <ScottK> zul: First rule of common sense is that it isn't common.
[15:46]  * sistpoty|work admits that he usually doesn't keep an eye after sponsoring an upload, but rather makes sure that the upload is ok
[15:46] <\sh> zul, just because we don't have a single person maintainership policy for packages like debian has (even if the maitnainer could be a team)
[15:47] <Hobbsee> \sh: persuade people to go thru debian too then :P
[15:47] <Hobbsee> well, isntead.
[15:47] <\sh> Hobbsee, honestly, I don't push people to debian, just because they will be more annoyed sometimes ;) it's even easier for us, when the package already is in ubuntu...to be picked up by some fellow motu which is also a DD or DM
[15:48] <Hobbsee> true
[15:48]  * Hobbsee just doesn't deal in new packages, in most cases.
[15:48] <Hobbsee> makes it all much easier and, for the most part, enjoyable.
[15:48] <Hobbsee> if it's something interesting, debian usually has it packaged.
[15:48] <sistpoty|work> seems like the whole discussion has made spooky unhappy...
[15:48] <Hobbsee> if not, then i'll look at asking a clued contributor to package it, *then* i'll look at reviewing it
[15:51] <\sh> Hobbsee, I'm only reviewing packages from known people where I know, too, that they're staying with ubuntu for around 6 months ;)
[15:51] <Hobbsee> \sh: oh yeah.  that helps.
[15:51] <Hobbsee> i'll review effie_jayx's stuff, for eg, and rexbron's.  That's about it.
[15:52] <\sh> TBH, many packages which rottens on revu, there is no one who cares about, because most people think: "Hey packaging is simple and easy...let's play" upload to revu and after the first "dude, you made a mistake here there and ..." statement, they leave without a trace...
[15:53] <Hobbsee> yeah
[15:53] <Hobbsee> who knows how much of the advertising is actually causing that
[15:53] <Hobbsee> people seem to think it's a caes of checkinstall-style packaging
[15:53] <DktrKranz2> ScottK: re bug 206469, I'm fine with the sync, given Damyan explanation. I'll prepare information for the FFe later this evening.
[15:53] <ubotu> Launchpad bug 206469 in firebird2.0 "sync firebird2.0 from debian " [Undecided,Fix committed] https://launchpad.net/bugs/206469
[15:54] <ScottK> DktrKranz2: Great.  Please comment to that effect in the bug.
[15:54] <\sh> therefore it makes no sense ... and only a minority of serious contributors are appreciating our reviews and fixing the stuff and taking care..this makes me happy...but you know, 100 packages on revu, 90% are getting rotten and 10% are candidates for serious upload
[15:55] <Hobbsee> so you pretty much have to make a whitelist.
[15:55] <\sh> Hobbsee, indeed
[15:55] <Hobbsee> would it make sense to make the new focus bugfixing?
[15:55] <Hobbsee> seeing as they can be mostly drive-by?
[15:56] <Hobbsee> although i *did* see a UVFe yesterday for rsync, whcih had comments to the effect of "why hasn't anyone done anything about this yet?" when they hadn't subscribed the relevant teams
[15:56] <\sh> Hobbsee, I took care yesterday...
[15:56] <Hobbsee> \sh: i meant before that.
[15:56] <Hobbsee> \sh: was 2 unknowns
[15:57] <\sh> Hobbsee, well, the problem here is: nobody from main took care about it
[15:57] <Hobbsee> \sh: main doesn't have maintainers either
[15:57] <\sh> Hobbsee, it's a maintained and supported package and people should have it on their radar...
[15:57] <\sh> Hobbsee, I meant "support by canonical", tbh
[15:58] <Hobbsee> \sh: oh right.  yes, well.
[15:58] <\sh> Hobbsee, we need to review our workflows regarding packages in general, that's for main/restricted and universe/multiverse as well...there are too many tasks now, where people need to focus on...and not all or nothing
[15:58] <Hobbsee> \sh: if you go down that path, youv'e got absolutely no need for core devs who are not employed to work on ubuntu
[15:59] <\sh> Hobbsee, the opposite is better...
[15:59] <\sh> Hobbsee, we need more community core-devs which are not involved in coding for the distro
[15:59] <Hobbsee> \sh: i know.  which is why i was pointing out that the "supported by canonical" path is a bad one
[16:00] <Hobbsee> This change would, I believe, have a significant impact on archive admin
[16:00] <Hobbsee> workload.  They'd get a lot more packages and have to deal with more
[16:00] <Hobbsee> rejections and multiple reviews.  In effect this would shift work from MOTU
[16:00] <\sh> Hobbsee, we need more serious community people to get packages into the devel cycle while it's fresh, but with serious views (e.g. testing before upload, and not only build testing ;))
[16:00] <bddebian> Heya gang
[16:00] <Hobbsee> to the archive.  I don't think it's a good idea.
[16:00] <Hobbsee> ScottK: then again, if only trusted MOTU's were the archive admins, you *should* be fine.
[16:01] <Hobbsee> but that would mean they couldn't be the first reviewers.
[16:01] <geser> Hi bddebian
[16:01] <Hobbsee> hey bddebian
[16:01] <bddebian> Hi geser
[16:01] <bddebian> Hi Hobbsee
[16:01] <Hobbsee> \sh: true
[16:01] <ScottK> Hobbsee: Sure, but your list and mine may not be the same.
[16:01] <sistpoty|work> hi bddebian
[16:01] <bddebian> Hi sistpoty|work
[16:01] <ScottK> heya bddebian
[16:01] <bddebian> Heya ScottK :_)
[16:01] <Hobbsee> \sh: good luck in getting that implemented, without getting shot down for saying people get things wrong.  But yes, that's the idea.
[16:02] <Hobbsee> ScottK: i presume the archive admins would need some comprehensive list
[16:02] <Hobbsee> ScottK: (a combinatino of all the lists)
[16:02] <ScottK> Yeah.  Not sure how to go about it.
[16:02] <\sh> ScottK, Hobbsee : we had this discussion when we discussed core-app of till...archive admins should review some serious things, like legal issues (licenseing etc.) but not simple QA things, which has to be catched before the package even hits the NEW queue
[16:03] <ScottK> Agreed.
[16:03] <ScottK> In his case there was an unfortunate overlap in the roles that made it look worse than it was.
[16:03] <\sh> and that's why we invented REVU in the first place...the one and only first contact of a package is Universe  which means: fight the motu reviews, and move on
[16:03] <ScottK> Agreed.
[16:04] <Hobbsee> \sh: but it's not unfeasible that at least some of the MOTU's will become archive admins.
[16:04] <Hobbsee> trust me on this one.
[16:05] <Hobbsee> \sh: heck, we already have one.
[16:06] <Hobbsee> there's no reason to expect that would not expand
[16:07] <\sh> Hobbsee, I don't say, that it's not feasable to have community archive admins...I would like to see universe/multiverse NEW queue processing in MOTU hands, and not going through the time limited resources of archive admin of the day
[16:07] <Hobbsee> \sh: so, in the event that that happens, how would you deal with the problem then?
[16:08] <\sh> Hobbsee, but I, too, have objections dealing and playing with infrastructure systems of a company, without having a written permission: yes you are invited to do stupid things, because you learn it now
[16:09] <Hobbsee> \sh: i don't think a company would really be silly enough to give away stuff like that, without making sure it couldn't blow up other areas.  that doesn't make sense
[16:09] <\sh> Hobbsee, universe/multiverse is community driven, so give the motu community the right to establish processes the way the motu community wants..
[16:10] <Hobbsee> \sh: so, in the event that they do that, what would MOTU do then?
[16:10] <Hobbsee> this is my question to you.
[16:10] <\sh> Hobbsee, we will become a structured team with responsibilities
[16:10] <Hobbsee> magically, of course.  with fairies.
[16:11] <sistpoty|work> heh, mok0: I find the "service check" thingy in your mail quite funny, because accidentally revu is down right now *g*
[16:11] <\sh> Hobbsee, not magically...we will see some drop outs, at least, because we will have more pressure sometimes, but it's natural selection
[16:11] <mok0> sistpoty|work: hah
[16:14] <\sh> Hobbsee, the whole point comes out to "do I trust people who are working on my property?" (property here: server, infrastructure etc.)
[16:14] <Hobbsee> \sh: no, my point comes down to "in the likely event that that happens, what will MOTU do, and should we discuss that now, rather than another round of the same old discussions)
[16:14] <Hobbsee> s/)/"/
[16:17] <johan> Hi, is this a good place to ask ubuntu packaging questions?
[16:17] <sistpoty|work> johan: yes, it is
[16:17] <jpatrick> johan: yep :)
[16:17] <mok0> johan: yes
[16:18] <johan> Okay, so I am currently trying to package a project using autotools and I use cdbs and the class/gnome.mk makefile to simplify that
[16:18] <johan> I just uploaded the package to my ppa and it says the following when trying to build the package:
[16:18] <johan> configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."
[16:18] <johan> the full build log can be found here, if anyone wants to take a look; http://launchpadlibrarian.net/13506321/buildlog_ubuntu-hardy-lpia.flumotion_<IP_ADDRESS>-0flu2_FAILEDTOBUILD.txt.gz
[16:18] <\sh> Hobbsee, honestly, the last time in motu space there was too much political discussions...and that's tiring me, and eventually others
[16:19]  * Hobbsee decides to shut up, and wait for the annoucement.  And then watch the great "oh my goodness, what should we do?"
[16:19] <\sh> Hobbsee, i don't know if it's important, but let's discuss it now, and then never again
[16:20] <\sh> Hobbsee, but not during an UDS...because not all people are attending...and I want to know, that all "active" motus are involved...
[16:21] <Hobbsee> When the board game changes, the player adapts.  No point trying to suggest they adapt prior to the event.
[16:21] <\sh> Hobbsee, I don't want to have sabdfl-decisions from non-sabdfls
[16:22] <johan> perhaps I am doing something wrong when uploading directly from an svn checkout
[16:22] <\sh> let's say it like that...it's important to have a common consense, a democratic decision ... that makes everyone happy
[16:22] <geser> johan: looking into your tar.gz install-sh is a symlink (but I didn't check where it points to and if the target exists)
[16:23] <geser> johan: does it point to a file which exists during the build?
[16:23] <sistpoty|work> johan: looks like you'll need to call autotools stuff (aclocal, autoconf, automake) beforehand... not too sure if there's a cdbs class that does taht
[16:23] <\sh> sistpoty|work, there is
[16:23] <johan> geser: oh, that must be, I could change to do automake -c -a instead of just automake -a
[16:24] <sistpoty|work> \sh: then I take everything back and claim the contrary :P
[16:24] <\sh> https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528414
[16:24] <\sh> CDBS can be asked to update libtool, autoconf, and automake files, but this behavior is likely to break the build system and is '''STRONGLY''' discouraged.
[16:24] <\sh> 				Nevertheless, if you still want this feature, set the following variables :
[16:24] <\sh>
[16:24] <\sh>     * DEB_AUTO_UPDATE_LIBTOOL
[16:24] <\sh>     * DEB_AUTO_UPDATE_AUTOCONF
[16:24] <\sh>     * DEB_AUTO_UPDATE_AUTOMAKE
[16:24] <\sh> damn..
[16:24] <\sh> sry
[16:25] <\sh> so you do it "before using debuild -S -sa" and not "inside debian/rules" (debhelper or cdbs wise)
[16:25] <\sh> "before" means, do it manually
[16:26] <johan> I think just replacing the symlinks with copies should work in my case
[16:27] <\sh> johan, automake does this for you...
[16:27] <\sh> johan, read the man automake part about --force-missing and rethink the usage of --copy while calling automake
[16:28] <\sh> automake --add-missing --force-missing --copy is what you want when I puzzle all statements together, without even knowing about what you and sistpoty|work are talking ;)
[16:29] <johan> \sh: oh, let me try
[16:39] <\sh> did anyone receive my mails to ubuntu-motu actually? I have a strange feeling that something is borked on my mail site
[16:39] <jdong> \sh: I think I just got one from you
[16:39] <jdong> \sh: yeah you're coming through
[16:40] <jdong> at least for me ;-)
[16:40] <\sh> jdong, hmm...ok...then something is wrong on the mail server of a friend of mine...great...:) thx
[16:51] <ScottK> \sh: If you look in the archive you'll see mails from you there.  Mailman does have an option not to get your own posts (IIRC).  Maybe that's set.
[16:52] <\sh> ScottK, no...I got my mails now...too many spam mails error imho
[16:53] <ScottK> Ah.  OK.
[16:53]  * \sh needs a new server
[17:41] <RainCT> blueyed: ping
[17:41] <blueyed> RainCT: pong
[17:44] <RainCT> blueyed: two things about ubuntu-dev-tools... first, you should be able to push into the trunk yourself
[17:45] <blueyed> RainCT: ah, of course.
[17:46] <johan> warning, `debian/flumotion/DEBIAN/control' contains user-defined field `Python-Version'
[17:46] <johan> dpkg-genchanges: warning: unknown information field 'Xb-Python-Version' in input data in package's section of control info file
[17:46] <johan> what can I replace that with?
[17:46] <blueyed> johan: AFAIK just remove the "Xb-", but I'm not sure..
[17:46] <RainCT> johan: that's normal, just ignore the warning
[17:47] <RainCT> I think Xb-Python-Version is right.. perhaps ScottK can confirm that?
[17:47] <blueyed> yes, according to http://wiki.debian.org/DebianPython/NewPolicy it is
[17:48] <ScottK> johan: dpkg-genchanges just hasn't been taught about that field.  You can ignore that warning.
[17:48] <johan> ScottK: okay, thanks
[17:48] <RainCT> blueyed: and the other thing, when I saw that it now looks for cookies in .mozilla/*/* I wondered if it wouldn't be better to only look in the profile that's being used (now I'm not that sure about that anymore but wanted to let you know anyway so that you can think about it :P)
[17:49] <blueyed> RainCT: it was looking in .mozilla before, didn't it?
[17:49] <RainCT> blueyed: uhm.. I think it didn't, let me check
[17:50] <blueyed> RainCT: IIRC I've only extended it for FF3 and ~/.lpcookie.txt.
[17:51] <blueyed> IMHO this should be generalized in python-launchpad-bugs anyway..
[17:51] <geser> blueyed: since when does python-lp-bugs support the FF3 cookie file?
[17:51] <blueyed> geser: not sure, I've seen that in the code however..
[17:52] <RainCT> blueyed: ah yes, it did
[17:52] <blueyed> geser: I've not tested it, probably, using ~/.lpcookie.txt myself.
[17:52] <geser> all I know is that it supports FF2 cookies and passing username/password
[17:53] <RainCT> geser: I haven't tried myself but I've also heard that it has FF3 support now (although perhaps that's not yet in the repos)
[17:53] <RainCT> or perhaps I've heard wrong.. :)
[17:54] <geser> it would really be good if python-lp-bugs has a common file for auth data
[17:54] <geser> I've taken the .mozilla/*/* code from some other script
[17:54]  * RainCT agrees
[17:55] <blueyed> Search in /usr/share/pyshared/launchpadbugs/http_connection.py for sqlite, looks like it should work.
[17:55] <RainCT> but I'm not sure if they would want to have that in there.. it isn't really the same but I asked them to accept '~/cookie_file' as a name (instead of having to pass '/home/username/cookie_file') and they said no -.-
[17:57] <geser> blueyed: nice, it extract the cookie data and stores it in a temporary file in FF2 cookie format
[18:02] <RainCT> jdong: I'm looking at deluge ;)
[18:02] <jdong> RainCT: alright, let the flood gates open :D
[18:03] <jdong> don't get flooded over your head
[18:03] <jdong> more deluge puns go here...
[18:24] <RainCT> ScottK: can I consider bug #218182 as acked or do you want a debdiff once it's ready?
[18:24] <ubotu> Launchpad bug 218182 in deluge-torrent "deluge-torrent: new upstream version <IP_ADDRESS>" [Wishlist,New] https://launchpad.net/bugs/218182
[18:26] <jdong> RainCT: I'd expect a debdiff to be unimportant unless you find yourself needing to make nontrivial changes to make the packaging work
[18:28] <ScottK> RainCT: You and jdong conspire.  Once you've tested it and jdong agrees it's good, then go ahead and upload.
[18:31] <jdong> ScottK: haha nicely worded :)
[18:31] <ScottK> ;-)
[18:32] <laga> hello. i'm not sure if we're in milestone freeze yet or not.. but i'd appreciate if someone could take a look at https://bugs.launchpad.net/ubuntu/+source/mythbuntu-diskless/+bug/218262 - small bug fix for something which needs to end up on the mythbuntu alternate disk :)
[18:32] <ubotu> Launchpad bug 218262 in mythbuntu-diskless "various failures in mythbuntu-diskless-client-builder.postinst on alt disk" [Undecided,New]
[18:32] <RainCT> ScottK: heh. OK, thanks
[18:33] <ScottK> laga: Ack from motu-release.  Just ask superm1 to upload it.
[18:33] <laga> ScottK: yay. superm1, please upload 218262.. or upload the latest from the bzr branch
[18:34] <ScottK> superm1: Sponsor's review is up to you.
[18:42] <crimsun> asac: did you mean "intrepid" in https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/192888/comments/56 ?
[18:42] <ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed]
[18:45]  * ScottK had the same question.
[18:45] <ScottK> I assumed he did.
[18:47] <RainCT> jdong: ok, package should be ready (pbuilding and test installing now). what do you want to see?
[18:49] <jdahlin> I get this error message each time I run debuild:
[18:49] <jdahlin> This package has a Debian revision number but there does not seem to be
[18:49] <jdahlin> an appropriate original tar file or .orig directory in the parent directory;
[18:49] <jdahlin> (expected flumotion_<IP_ADDRESS>.orig.tar.gz or svn.orig)
[18:49] <jdahlin> Is there a way to get around that, without renaming the directory?
[18:50] <james_w> jdahlin: it's asking you to create "flumotion_<IP_ADDRESS>.orig.tar.gz" in the parent directory
[18:51]  * sistpoty|work heads home
[18:51] <sistpoty|work> cya
[18:51] <jdahlin> james_w: hmm
[18:51] <james_w> either by renaming the upstream tarball, or repacking it if it's .bz2 or something
[18:51] <jdahlin> perhaps I should just create a svn.orig.tar.gz
[18:51] <james_w> that svn.orig bit is weird.
[18:52] <james_w> the package name is "flumotion" correct? What's the version number?
[18:52] <jdahlin> <IP_ADDRESS> is correct
[18:52] <james_w> in debian/changelog?
[18:52] <james_w> <IP_ADDRESS>-1?
[18:52] <jdahlin> <IP_ADDRESS>-0flu5
[18:53] <james_w> ok, that looks like a bug then
[18:53] <james_w> it should work if you create the desired tarball.
[18:53] <james_w> are you on hardy?
[18:54] <jdahlin> yes I am
[18:54] <jdahlin> well, I didn't create the tarball
[18:54] <jdahlin> but I'll do is, a make dist should be fine
[18:55] <james_w> jdahlin: ah, you're in a directory called "svn"
[18:55] <james_w> does that have both your code and the "debian/" directory?
[18:57] <jdahlin> james_w: exactly
[18:58] <LucidFox> Hmm
[18:58] <LucidFox> I just upgraded to hardy...
[18:58] <james_w> jdahlin: ah, ok. So, what it wants to do is have a tarball/directory of the "upstream" code, which it can then compare with the combined code to produce the .diff.gz part of the source package
[18:58] <LucidFox> sikon@lucidfox:~$ nautilus
[18:58] <LucidFox> nautilus: symbol lookup error: nautilus: undefined symbol: eel_art_irect_empty
[18:58] <LucidFox> any ideas?
[18:58] <jdahlin> LucidFox: missing dependency on latest eel?
[18:59] <jdahlin> james_w: oh, I'll do that, a make dist before should solve that
[18:59] <james_w> you can do this in 3 ways I think, produce a tarball/directory without debian/ and use that, use the same code to get an empty diff, or make a native package.
[18:59] <james_w> the preferred way for upload to Ubuntu is the first, but it sounds like you are not aiming for that
[19:00] <jdahlin> but where should I put the debian/ directory then?
[19:00] <jdahlin> I was actually planing to include the debian/ directory in the tarball
[19:01] <james_w> yeah, that's a native package
[19:02] <james_w> it's not liked for upload to Debian/Ubuntu, as it means that if there is a packaging mistake it will require a new upstream release, and NMUs of those packages are a strange thing
[19:02] <james_w> however, it's still a perfectly good package
[19:02] <jdahlin> this is not really intended to be uploaded to debian or ubuntu
[19:02] <ScottK> jdahlin: If you include the debian dir in the tarball, the first thing that will happen if you submit it to Debian/Ubuntu is you'll be asked to remove it.
[19:03] <jdahlin> we're rather going to distribute it separately
[19:03] <james_w> to do this you just need to change the version number and remove "-".
[19:03] <jdahlin> ScottK: I'll check with the ubuntu maintainer
[19:04] <jdahlin> okay, I have a flumotion-<IP_ADDRESS>.tar.bz2 now, but debuild apparently expects a flumotion-<IP_ADDRESS>.orig.tar.bz2
[19:05] <james_w> yup
[19:07] <LucidFox> I have the latest nautilus and libeel installed, and nautilus references some eel_art_* functions, which are not in libeel
[19:07] <LucidFox> according to readelf
[19:08] <jdahlin> check upstream if they are available
[19:08] <jdahlin> otherwise they might have been removed, because I think nautilus uses cairo in favor of libart these days (assumg eel_art are convencience functions on top of libart)
[19:08] <asac> crimsun: obviously!
[19:09] <crimsun> asac: ok
[19:09] <asac> :)
[19:09] <asac> sorry for confusino
[19:10] <LucidFox> but why would an upgrade to default Hardy versions of nautilus and libeel break it?
[19:10] <LucidFox> I'm really lost here
[19:20] <pochu> LucidFox: I guess you have libeel2-2 2.22.1-0ubuntu1 installed, right?
[19:20] <LucidFox> yes
[19:21] <LucidFox> do I need to rollback to a previous version?
[19:21] <pochu> emilio@saturno:~$ readelf -a /usr/bin/nautilus | grep eel_art
[19:21] <pochu> emilio@saturno:~$
[19:21] <pochu> what version of nautilus do you have?
[19:23] <LucidFox> hmmm
[19:23] <LucidFox> 1:2.22.2-0ubuntu3
[19:24] <LucidFox> but that's strange
[19:24] <LucidFox> http://paste.ubuntu.com/7220/
[19:25] <pochu> LucidFox: indeed... what arch?
[19:25] <LucidFox> i386
[19:25] <pochu> same here
[19:25] <pochu> and same version
[19:25]  * LucidFox tries removing and installing nautilus again
[19:25] <pochu> LucidFox: can you bring that to #ubuntu-bugs?
[19:25] <LucidFox> wait!
[19:26] <LucidFox> I got it
[19:26] <LucidFox> I added a dpkg-divert previously
[19:26] <pochu> have you rebooted after upgrading to hardy?
[19:26] <pochu> I don't know that :)
[19:26] <LucidFox> so /usr/bin/nautilus wasn't affected by the upgrade
[19:26] <pochu> ah
[19:26] <LucidFox> and it remained even after unintasll
[19:28] <LucidFox> It works!
[19:28] <LucidFox> Thanks everyone
[19:29] <ScottK> pochu: Remember the spe changes you made to simplify dpatch integration?
[19:30] <ScottK> pochu: I think the dpatch man page could benifit from an example using your method.  I'd suggest it'd be cool if you could make a patch to the man page to add an additional example and send it to Debian.
[19:30] <pochu> ScottK: ok, let me have a look at the manpage
[19:32] <ScottK> pochu: Thanks.  I always did it the long way following the man page and didn't know any other.
[19:33] <pochu> ScottK: right. I'm going to make one now. I didn't know it was in the manpage. I learnt it directly from POX_
[19:33]  * pochu hugs POX_ :)
[19:33] <pochu> ScottK: thanks
[19:36] <jeromeg> hello
[19:36] <jeromeg> anyone of motu release team for bug 216698 ?
[19:36] <ubotu> Launchpad bug 216698 in xpad "xpad 100% CPU bug" [Medium,Triaged] https://launchpad.net/bugs/216698
[19:36] <DktrKranz> ScottK, current firebird2.0 in sid doesn't add any new features (only translations), could you please review bug 206469 and eventually ACK it?
[19:36]  * ScottK had that on his list to look at.
[19:36] <ubotu> Launchpad bug 206469 in firebird2.0 "sync firebird2.0 from debian " [Wishlist,New] https://launchpad.net/bugs/206469
[19:37] <ScottK> DktrKranz: SUre.
[19:37] <DktrKranz> thanls
[19:37] <DktrKranz> s/l/k/
[19:43] <ScottK> DktrKranz: Do we no longer need "Replace libicu36-dev with libicu-dev"?
[19:43] <DktrKranz> already in debian
[19:43] <POX_> heh, pochu: what did you learn from me? (sorry, no time to read backlog)
[19:44] <azeem> slangasek: uh, probably multisync0.90 should've been updated as well, but I forgot
[19:44] <azeem> same for multisync-tools
[19:44] <ScottK> DktrKranz: Sync bug needs to say why it's OK to over-write an Ubuntu change.  Add that and then subscribe the archive.  Ack from me for after it's fixed.
[19:45] <DktrKranz> sure, I'll adjust description
[19:46] <pochu> POX_: many things? :) (it was about dpatch in debian/rules, dpatch(1) shows how to do it, but it looks h4ck!sh)
[19:49] <pochu> ScottK: http://pastebin.com/fe5d0967, do you think the wording should be changed too?
[19:49]  * ScottK looks
[19:49] <pochu> "       Let  us  look  at  an  example!  First,  let  us  look  at  the relevant parts of the original
[19:49] <pochu>        debian/rules of our imaginary package:
[19:50] <pochu> that stuff...
[19:50] <ScottK> pochu: I'd suggest adding it as an additional example, not instead of the current one.
[19:50] <ScottK> pochu: with text something like, "Alternatively, you can use dpatch.make and do it this way:"
[19:51] <pochu> ScottK: sounds good, gonna do that
[19:51] <ScottK> Great.
[19:57] <slangasek> azeem: oh. those packages seem to work, though?
[19:59] <POX_> pochu: you know what my price is, right?
[19:59] <pochu> POX_: keeping PAPT without RC bugs? :-)
[20:00] <POX_> yup
[20:01] <POX_> PAPT or DPMT
[20:01] <pochu> I'm not on DPMT
[20:01] <pochu> and PAPT is clean :)
[20:01] <POX_> so you're lucky, there are RC bugs there
[20:01] <pochu> I think I'll leave them to ScottK who is a member of the team ;)
[20:02] <jeromeg> what does PAPT and DPMT mean ?
[20:02]  * ScottK hands jeromeg https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam
[20:03] <cody-somerville> I'm a member of PAPT too :) \o/
[20:03] <pochu> :)
[20:03] <pochu> ScottK: round 2, http://pastebin.org/30215
[20:03]  * jeromeg thanks ScottK
[20:04] <ScottK> pochu: You teach clamav to have two different versions on the signatures database so libclamav3 and libclamav4 can be co-installed and I'll be glad to go look at PAPT bugs.
[20:04] <jeromeg> ScottK: thank you for the xpad ack
[20:05] <pochu> ScottK: thanks, but I already went over PAPT RC bugs :)
[20:05] <ScottK> jeromeg: No problem.  Thanks for contributing.
[20:05] <pochu> and I have no idea how clamav works...
[20:05] <jeromeg> ScottK: I found a blog post of Philip Newborough
[20:05] <jeromeg> about this
[20:06] <jeromeg> so I just wanted to get this fixed :)
[20:06] <ScottK> Great.
[20:08] <ScottK> pochu: I'd make your new example the 2nd one, but otherwise I think it looks good.
[20:08] <pochu> ScottK: I added it first on purpose as it's simpler and it will be updated with dpatch
[20:09] <pochu> so I think people should use that one instead of the other
[20:09] <ScottK> Your call.  Not that I disagree, but I think getting the patch accepted will be easier with it 2nd.
[20:32] <pochu> ScottK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476457
[20:32] <ubotu> Debian bug 476457 in dpatch "Improve dpatch(1) example of modifying debian/rules" [Minor,Open]
[20:33] <ScottK> pochu: Great.  Thanks.  If it's still not it when Intrepid starts, it might be good to add it to Ubuntu.
[20:39] <Adri2000> ScottK: in bug #216698, afaiuc you acked the debian version. so my guess is that the package should be synced. but are syncs still possible at this point?
[20:39] <ubotu> Launchpad bug 216698 in xpad "xpad 100% CPU bug" [Medium,Triaged] https://launchpad.net/bugs/216698
[20:40] <ScottK> Adri2000: I acked an upload to fix the bug.  Sync's are still possible, AFAIK.
[20:41] <Adri2000> I thought motu-release is supposed to ack diffs to be uploaded
[20:41] <ScottK> That's the sponsor's job.
[20:54]  * norsetto wonders who acked the latest envyNG upload
[20:56] <slangasek> norsetto: TheMuso
[20:56] <ScottK> norsetto: Not me.
[21:08] <DktrKranz> ScottK, firebird bug adjusted (sorry for the loooooong delay)
[21:08] <ScottK> No problem.  Go ahead then.
[21:09] <DktrKranz> thanks
[21:14] <ScottK> norsetto: How many days did envyNG make it without a new upload?
[21:16] <norsetto> scottk: oh well, alberto is doing his best, thats what it counts
[21:18] <ScottK> norsetto: I still don't think the package has the kind of history of stability that we'd want for an LTS release.  I also don't like the idea of a package that will install whatever he feels like uploading to his PPA.
[21:18] <ScottK> But the decision is made.
[21:18] <laga> tut es nicht
[21:18] <laga> wunderbar
[21:18] <laga> sorry.
[21:21] <norsetto> scottk: yes
[21:21] <ScottK> That completely leaves aside the question of encouraging the least open source friendly video manufacturer that there's no need to change their ways.
[21:22] <ScottK> Another reason I don't like it.
[21:24] <ScottK> pochu: Would you have time to look into uploading Bug #206958?
[21:24] <ubotu> Launchpad bug 206958 in mnemosyne "mnemosyne crashed with AttributeError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/206958
[21:30] <soren> REVU is running on a Sparc machine, is that correct?
[21:32] <mok0> soren: yes
[21:33] <soren> mok0: Thanks.
[21:33] <mok0> soren: np :-)
[21:37] <sistpoty> heh, REVU up again :)
[21:50] <TheMuso> slangasek: You pinged me earlier?
[21:51] <slangasek> TheMuso: no, I pointed norsetto at you :)
[21:53] <ScottK> TheMuso: We were wondering who ack'ed the envy upload and rehashing how thrilled some of us are to have it in the archive.
[22:08] <norsetto> sistpoty: I think you will find bug 202869 interesting
[22:08] <ubotu> Launchpad bug 202869 in blas "ICAMAX/IZAMAX tests" [Undecided,New] https://launchpad.net/bugs/202869
[22:11] <sistpoty> norsetto: so that's the needle in the haystack I was trying to find :)
[22:11] <mok0> I've never looked at the atlas packaging myself, but I'm curious to know how it's built. IIRC, the whole idea with atlas is that it will be optimized for the specific machine it is being built on
[22:12] <norsetto> sistpoty: I have also seen that doko made some changes to the debian package
[22:12] <sistpoty> well, I've looked at atlas packaging quite a while, and I still have no clue how it actually is built *g*
[22:12] <mok0> sistpoty: :-D
[22:12]  * norsetto doesn't even dare to look ....
[22:13] <sistpoty> norsetto: if we could get the blas change in and then the atlas change for hardy, that would be optimal imho... others than that, I guess we should try to get it into hardy via SRUs
[22:13] <norsetto> sistpoty: what blas change?
[22:13] <DktrKranz> motu-release guys, python-omniorb2 needs a rebuild for libomniorb transition, but it FTBFS due to API changes in omniorb (see debian 453164). New upstream in debian fixed it, but it's rewritten from scratch, is it worth a FFe so late in the game?
[22:13] <ubotu> Debian bug 453164 in python-omniorb2 "python-omniorb2: FTBFS: ../../modules/pyObjectRef.cc:434: error: no matching function for call to 'omniIOR::omniIOR(const char*&, const _CORBA_Octet*, int)'" [Serious,Fixed] http://bugs.debian.org/453164
[22:14] <ScottK> DktrKranz: Does the current package work at all?
[22:15] <DktrKranz> ScottK, it builds and runs, I'm not one of its users to see if it works as expected, though
[22:15] <ScottK> DktrKranz: Why do you think it needs a rebuild?
[22:15] <DktrKranz> http://people.ubuntu.com/~ubuntu-archive/NBS/libomniorb4c2
[22:16] <ScottK> Ah.  So works until the old binary gets tossed.
[22:16] <ScottK> DktrKranz: I'd say go for it, but get another ack first.
[22:17] <DktrKranz> if you want, I can gather all informations needed, but it's really a rewrite (from C to C++, IIRC)
[22:17] <DktrKranz> so, it changes almost everything
[22:18] <mok0> sistpoty: your mail arrived!
[22:18] <sistpoty> :)
[22:20] <RainCT> good night
[22:20] <sebner> gn8 folks
[22:20] <norsetto> DktrKranz: do you know what actually this is?
[22:21] <mlind> any universe sponsors around?
[22:21] <DktrKranz> norsetto, TBH no, it's on my radar due to my desire to clean off NBS before release day
[22:22]  * sistpoty needs to go to bed now
[22:22] <sistpoty> gn8 everyone
[22:24] <norsetto> DktrKranz: so this will be an update to the 4.1 series?
[22:24] <DktrKranz> 3.2, actually
[22:25] <ScottK> mlind: What are you after?
[22:28] <norsetto> DktrKranz: if the current package is unusable, I'd say go for it, it can't get worse, just check that the transition is not broken
[22:29] <DktrKranz> norsetto, I'll do some more tests, but at least transition is safe
[22:30] <mlind> ScottK: asac asked me to find a motu to sponsor the fix in bug #202343 yesterday in #ubuntu-mozillateam
[22:30] <ubotu> Launchpad bug 202343 in opensc "mozilla-opensc firefox plugin not visible in FF3 (bad install directory)" [Undecided,Fix committed] https://launchpad.net/bugs/202343
[22:30] <jdahlin> bzr has the following version number: 1.4rc1-1~bazaar1~hardy1
[22:30] <jdahlin> how can I tell that to debchange if I want to use something similar?
[22:31] <norsetto> bug 218245: yes, Firefox is evil ....
[22:31] <ubotu> Launchpad bug 218245 in firefox "Recommends Proprietary Software" [Undecided,New] https://launchpad.net/bugs/218245
[22:31] <ScottK> mlind: I'm about out of time now.  If you don't find a sponsor in the next ~4 hours.  Ping me again.
[22:33] <mlind> ScottK: I'm about to head to bed myself. I'll check it tomorrow, if it's still fix committed, I'll ping you or asac.
[22:34] <norsetto> jdahlin: uh?
[22:34] <lifeless> jdahlin: what do you mean?
[22:35] <jdahlin> norsetto: I want to include a custom part of the version number (eg, flu, or fluendo) and one for the dist (gutsy, hardy etc)
[22:35] <asac> mlind: if its not uploaded tomorrow morning i can do that
[22:35] <jdahlin> eg <IP_ADDRESS>-0~flu1~hardy1 I guess?
[22:35] <asac> mlind: i have almost managed to reduce my overload to a level that i can bear ;)
[22:35] <asac> mlind: night!
[22:35] <mlind> asac: heh, thanks!
[22:35] <norsetto> jdahlin: yes, and?
[22:35] <lifeless> jdahlin: the ~hardy etc are a bit bong; its an attempt to deal with different version namespaces by the bzr ppa folk
[22:36] <lifeless> jdahlin: ~ sorts before other chars in dpkg
[22:36] <jdahlin> norsetto: debchange --distributor flu1~hardy1 is not quite working
[22:36] <lifeless> jdahlin: we don't set --distributor
[22:36] <lifeless> jdahlin: we just set the version
[22:37] <ScottK> jdahlin: The easiest way to do it is just edit debian/changelog to have the version you want.
[22:37] <norsetto> jdahlin: I guess what you are looking for is -v
[22:38] <jdahlin> I really like dch -i though
[22:39] <norsetto> jdahlin: like it or not thats what you should use to specify the version number explicitely ....
[22:39] <seb128> hi
[22:39] <norsetto> hi seb128
[22:39] <seb128> do I need to open a bug etc if I want to update gnome-user-share in universe? ;-)
[22:40] <norsetto> seb128: aren't you the delegate for gnome FFe !?
[22:41] <seb128> right, that's why I'm asking
[22:41] <seb128> I'm not sure if that's good taste to accept my own exceptions requests ;-)
[22:42] <ScottK> seb128: I do it all the time.  If we delegated to you, we figure you know what you're doing.
[22:42] <ScottK> Go for it.
[22:42] <seb128> ok, thanks
[22:58] <norsetto> allright, I'm off to bed
[23:02] <mbt> The REAL truth about the REAL ID Act <http://feeds.feedburner.com/~r/ILikeEllipses/~3/271188530/>
[23:03] <mbt> Crap, sorry, wrong window
[23:20] <kees> can someone from motu-release review (and hopefully ACK) bug 218417 when you get a chance?
[23:20] <ubotu> Launchpad bug 218417 in hardening-wrapper "Please sync hardening-wrapper 1.11 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/218417
[23:20] <azeem> slangasek: if they do, then cool; I probably didn't try the old ones with the new plugins
[23:20] <slangasek> :)
[23:37] <pochu> ScottK: I'm looking at it
[23:44] <ScottK> pochu: Thanks.
[23:45] <ScottK> kees: Ack'ed
[23:45] <kees> ScottK: thanks
[23:50] <soren> Aw... Isn't that nice. There's a little old lady who on her death bed wants to donate six and half million pounds to charity through ubuntu-motu.
[23:50] <soren> Sounds plausible enough to me?
[23:51] <ScottK> Heh.
[23:52] <ScottK> asac: Are you going to update firefox to Firefox <IP_ADDRESS> before release?
[23:53] <Fujitsu> I hope so.
[23:54] <asac> ScottK: when was it officially released?
[23:55] <ScottK> asac: I just got a release announcement in the mail.
[23:55] <asac> sorry, but i know that it should have happened by now, but i haven't seen any announcement
[23:55] <asac> ok ... so right now ;)
[23:55] <asac> thanks
[23:55] <asac> ScottK: its not anywhere right now
[23:55] <asac> mozilla.com, mozilla.org, mozillazine.org
[23:55] <asac> ScottK: maybe thats another prenotice?
[23:56] <ScottK> asac: Subject is "Firefox <IP_ADDRESS> available for download"
[23:56] <ScottK> asac: http://groups.google.com/group/mozilla.announce/browse_thread/thread/e3c471743c98fe5f#
[23:57] <ScottK> I don't think that's a pre-notice.
[23:59] <asac> ScottK: i should rework my mail setup ;) ... i get all the prenotices, but not the final announcement. fun :-D


[09:00] <nikolam> this multi monitor thing is seriously buggy. I have lefte machine locked and then turned left monitor off. Woke up , turned left monitor on and I ended up login screen not accepting keyboard input for unlocking
[09:01] <nikolam> Switch user did log it in, but I ended up with mirrored monitors and messed up location of them.
[10:18] <brainwash> nikolam: I've seen a bug report for this
[10:19] <nikolam> ok brainwash
[10:19] <brainwash> let me find it
[23:00] <jarnos_> For some reason 30 can not find channels provided by other provider. There are two providers here for terrestrial DVB TV.
[23:57] <jarnos_> And if I enter the transport editor, it tells sorry, it can only be used to edit transports which are connected to a card input. What is that supposed to mean? I have USB device tor DVB.


[01:55] <LPCIBot> Project db-devel build (105): SUCCESS in 4 hr 0 min: https://hudson.wedontsleep.org/job/db-devel/105/
[02:36] <wallyworld> anyone running launchpad and storm 0.18, psycopg2 2.2 successfully? release notes for storm 0.18 implies this should work now?
[02:36] <wallyworld> i still get the famous ProgrammingError: operator does not exist: text = bytea
[02:37] <wallyworld> oh well, back to  psycopg 2.1.3
[02:38] <wgrant> wallyworld: It's not a Storm bug.
[02:38] <wgrant> It's a Launchpad one.
[02:38] <wgrant> Storm has been 2.2-compatible for a while now, IIRC.
[02:39] <wallyworld> yeah, but i thought that it could also be fixed in the storm layer as well? clearly i was wrong :-)
[02:39] <LPCIBot> Project devel build (161): FAILURE in 3 hr 58 min: https://hudson.wedontsleep.org/job/devel/161/
[02:40] <wallyworld> i just saw in the storm 0.18 release notes that "- Make storm compatible with psycopg2 2.2 " assumed :-)
[05:26]  * mwhudson waves
[05:47]  * thumper waves at mwhudson
[05:47]  * thumper EODs
[06:09] <LPCIBot> Project devel build (162): STILL FAILING in 3 hr 29 min: https://hudson.wedontsleep.org/job/devel/162/
[06:09] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][ui=none][no-qa] Improved tests for
[06:09] <LPCIBot> translations.ProductSeriesView and ProductSeriesLanguagesView.
[06:09] <LPCIBot> LaunchpadObjectFactory does not require a language code for
[06:09] <LPCIBot> POFiles and such anymore.
[06:09] <LPCIBot> * Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=664060] Allow bug supervisors to
[06:09] <LPCIBot> configure the bug tracker section of their project.
[06:11] <jtv> bye thumper
[06:15] <henninge> I wonder how to get check_permission working in a unit test (a view test).
[06:16] <henninge> I thought "login_person" would do the trick but it seems not.
[06:16] <henninge> It always returns "True"
[06:34] <henninge> It may be a layer thing.
[08:38] <adeuring> good morning
[09:27] <mrevell> Hi
[10:16] <thumper> mrevell: morning
[10:16] <thumper> mrevell: thanks for the bug reports, I'll get on to it :)
[10:19] <mrevell> thanks thumper :) I'll probably file a couple more later and also reply to poolie's comments
[10:19] <thumper> mrevell: I've got some ideas, and jml suggested just getting something going so you can then suggest improvements
[10:20] <mrevell> Cool, I'd be happy to do that, yeah
[12:31] <lifeless> jml: around?
[12:42] <jml> lifeless: sort of
[12:42] <lifeless> jml: could I get your stamp on the layers patch
[12:42] <lifeless> for ec2land
[12:42] <jml> lifeless: sure
[12:42] <lifeless> thank you
[12:48] <lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/zope.testing/+merge/39423 for easy reference
[13:04] <lifeless> jml: thank you
[13:13] <lifeless> Ursinha: we might want to run the stuff that does 'fixed by a commit' at high frequency - or is it the tagger?
[13:13] <matsubara> bac, around?
[13:53] <LPCIBot> Project devel build (163): STILL FAILING in 3 hr 57 min: https://hudson.wedontsleep.org/job/devel/163/
[13:59] <lifeless> flacoste: ping
[14:02] <StevenK> leonardr: Hi, are you around?
[14:03] <leonardr> StevenK: yes
[14:03] <StevenK> leonardr: There seems to be a change made recently with launchpadlib that it wants to write to /root/.launchpadlib during the test suite
[14:04] <leonardr> StevenK: this is when you're testing launchpad, or are you using launchpadlib trunk?
[14:04] <StevenK> leonardr: So the slaves are connected to as root, and then I sudo to a hudon user.
[14:04] <StevenK> leonardr: Sorry, this is when Hudson is running the full test suite on its build slaves
[14:05] <StevenK> lifeless: Speaking of Hudson, you wanted a module enabled
[14:05] <lifeless> no, I was saying we might need to
[14:06] <lifeless> I need to talk with ops
[14:06] <StevenK> lifeless: Sorry, this was like 3 weeks ago when you said you wanted the Chuck Norris plugin :-P
[14:06] <lifeless> and it would be 'write a module' (either python or java) to do the devel->stable push.
[14:06] <leonardr> ok. /root/.launchpadlib is the default location when you run as root. we ran into this problem before and changed the launchpadlib constructor used by launchpad so that it would use a temporary directory
[14:06] <lifeless> StevenK: oh yes. JFDI
[14:06] <StevenK> lifeless: Why!?
[14:09] <StevenK> leonardr: Has this code recently changed, then?
[14:09] <leonardr> StevenK: no, but if someone wrote a test that created a Launchpad object without going through lp.testing.launchpadlib_for, you'd get the old behavior back
[14:10] <leonardr> can you pinpoint when the directory is created? what gets put in that directory?
[14:11] <flacoste> lifeless: i'm back, sorry, family start-up got stalled this morning
[14:11] <StevenK> leonardr: Certainly: https://hudson.wedontsleep.org/job/devel/163/consoleText
[14:12] <StevenK> leonardr: If you search for '/root/.launchpadlib'
[14:16] <Ursinha> lifeless, it's tagger
[14:17] <jam> it looks like the build machine iridium is hung trying to build a webkit build, can anyone confirm?
[14:18] <wgrant> jam: Indeed. lamont ^^
[14:18] <leonardr> StevenK: so, these errors are in places that don't use lp.testing.launchpadlib_for -- the launchpadlib tests themselves, which are outside of launchpad, and a launchpad test that uses login_with
[14:19] <leonardr> as to why this is a problem now, i couldn't speculate--the code on my end hasn't changed
[14:19] <leonardr> i think the best solution would be to change all those calls to use a temporary directory, as launchpadlib_for
[14:19] <leonardr> does
[14:27] <StevenK> leonardr: I have to admit, I am curious as to why it's only occuring now
[14:27] <lamont> meh
[14:27] <LPCIBot> Project db-devel build (106): FAILURE in 4 hr 1 min: https://hudson.wedontsleep.org/job/db-devel/106/
[14:27] <lamont> jam: and what I can tell you is what we all can see from the web ui in launchpad
[14:28] <poolie> how cute: https://bugs.edge.launchpad.net/bzr-explorer/+bug/667782
[14:28] <StevenK> Rargh, it just impacted db-devel too
[14:28] <jam> lamont: I'm sitting here with shadeslayer (Rohan), who is trying to understand what is going on. Any chance we can just kick it?
[14:29] <lamont> I just stabbed it in the face
[14:29] <jam> wgrant: is abentley the right person to poke to see if we can understand what is failing here?
[14:29] <jam> It looks like it is failing during the branch update
[14:30] <jam> but it seems an odd place to get hung
[14:30] <lifeless> Ursinha: ok cool.
[14:30] <lifeless> Ursinha: and its running how often now ?
[14:30] <jam> (I wonder if it just isn't reporting the 'next' thing.)
[14:30] <Ursinha> lifeless, every 5 mins
[14:30] <lifeless> awesome
[14:30] <lifeless> abentley: hi; can I help you QA 638637 in some way?
[14:30] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[14:31] <leonardr> StevenK: is it possible that /root/.launchpadlib existed before and has been removed? the error is in trying to create the directory
[14:31] <jam> abentley: I'm sure deployment-stable takes precedence over the webkit stuff :)
[14:31] <wgrant> jam: It could have been bzr hanging there, or the builder could have had a seizure and exploded.
[14:31] <StevenK> leonardr: Let me see if a slave is still up
[14:31] <abentley> lifeless: You can push a branch, and see if it gets scanned and stuff, I guess.
[14:32] <wgrant> lamont: You can't get a shell in a virt builder?
[14:32] <jam> wgrant: sure, but both are pretty unlikely
[14:32] <wgrant> jam: The latter isn't particularly unlikely.
[14:34] <Ursinha> lifeless, you are not reusing branches anymore?
[14:34] <StevenK> leonardr: There is no /root/.launchpadlib
[14:35] <leonardr> StevenK: my speculation was that there might have been one earlier (preventing this problem) and that its removal caused this problem
[14:35] <jam> lamont: it seems that stabbing it in the face leaves it in the "currently building" state?
[14:37] <lifeless> Ursinha: Its always been adhoc :)
[14:37] <lifeless> Ursinha: sometimes I will, sometimes I won't.
[14:37] <Ursinha> :)
[14:37] <lifeless> abentley: qa staging codehosting is not working yet; am going to get it working with losa
[14:37] <jam> wgrant: any way to change the status from "it is currently building and should have finished 12hours ago" into some sort of "the build has failed" state?
[14:38] <jam> It is a bit confusing to figure out what is going on.
[14:39] <abentley> lifeless: I'd normally qa it on staging, anyhow.
[14:41] <wgrant> jam: The builder facestab should have done that.
[14:41] <wgrant> I suspect it needs harder stabbing.
[14:42] <wgrant> Or buildd-manager is broken.
[14:46] <jam> lifeless: what is the issue with codehosting on staging? (I'm concerned it might be my stuff, though comments from yesterday said that it wasn't)
[14:48] <lifeless> jam: staging is working, qastaging isn't
[14:50] <jam> lifeless: k, I guess i'm not fully aware of what the differences are
[14:51] <noodles775> mars: Hi! Have you had a chance to look at gmb's issue (launchpad-dev mailing list, 'Problems with FeatureFlags and test isolation')?
[14:52] <jam> wgrant: well, atm I suspect buildd-manager, because webkit has 2 jobs that were killed but are now listed as "currently building"
[14:53] <mars> noodles775, no, I have not looked at it.  I think deryck said he would have a look
[14:54] <noodles775> mars: ok, thanks. I'll check with deryck when he's available.
[14:54] <mars> noodles775, I asked gary_poster about someone in our team picking that up, but then deryck offered to help
[14:54] <gary_poster> y
[15:22] <flacoste> bigjools: are you sure you wanted to land the new async build manager? it will be rolled-out soon
[15:33] <lifeless> abentley: ok, so it scanned my new branch and an incremetnal push ok
[15:33] <lifeless> abentley: is that sufficient, do you think ?
[15:33] <abentley> lifeless: Well, merge detection also needed to be tested, but I've done that, and marked it qa-ok.
[15:33] <lifeless> awesome
[15:42] <lifeless> Edwin-afk: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - whats up with 11762
[15:53] <bigjools> flacoste: yes, it's QA-OK.
[15:54] <bigjools> I need to mark the bugs.
[15:55] <bigjools> jml: around?
[15:56] <flacoste> bigjools: that's great!
[15:57] <bigjools> flacoste: I need to land one more branch though, but it won't block rollout.  The new process seems to hammer the database harder than I want, so I need to back off the polling intervals.
[15:57] <flacoste> ok
[16:07] <lifeless> sinzui: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - whats up with 11762
[16:08] <lifeless> mwhudson: http://launchpad.net/bugs/660264 is ok right, in the absence of config changes?
[16:10]  * mwhudson looks
[16:11] <mwhudson> lifeless: it's ok in the sense of 'do no harm' indeed
[16:19] <lifeless> StevenK: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html rev 11778 bug 664380
[16:20] <StevenK> lifeless: Er? It says edwin for me
[16:20] <lifeless> StevenK: yes, look at the bottom
[16:20] <StevenK> Abh
[16:20] <StevenK> s/b//
[16:21] <StevenK> lifeless: I will look at doing that after I've emptied my plate
[16:22] <lifeless> StevenK: is it lunchtime?
[16:22] <StevenK> lifeless: Sigh
[16:22] <StevenK> I'm in the middle of two things. Mental plate
[16:22] <lifeless> mwhudson: jam: so forking server for bzr+ssh - can you describe somewhere what needs to be changed to test it? bazaar.qastaging is now working with the 'normal' service, so its ready to reconfigure to test.
[16:22] <lifeless> StevenK: cool, great and thanks.
[16:23] <mwhudson> lifeless: i believe jam has written at least one email containing the needed steps
[16:23] <mwhudson> lifeless: Subject: Re: QAing the forking codehosting server
[16:24] <lifeless> mwhudson: not in my mail
[16:24] <mwhudson> bah
[16:24]  * mwhudson forwards
[16:25] <mwhudson> lifeless: it would be good to time bzr ping bzr+ssh://bazaar.qastaging.launchpad.net/ a few times before we test it i guess
[16:26] <lifeless> bah, I don't have that plugged in
[16:26] <lifeless> but yes
[16:26] <mwhudson> i guess doing in from somewhere where ssh setup latency is not the dominant factor would be a good idea too...
[16:26] <jam> echo hello | ssh bazaar.qastaging.launchpad.net bzr serve --inet --directory=/ --allow-writes
[16:27] <jcsackett> leonardr: ping.
[16:27] <leonardr> jcsackett, hi
[16:27] <jam> a bit long, but always works, and doesn't need to have extra code installed :)
[16:28] <mwhudson> it tells me permission denied in just 0.7s!
[16:28]  * mwhudson fiddles
[16:28] <jcsackett> leonardr: hi. i just read your review note. do you want me to add notice in the 1.7.0 block or add a new one?
[16:29] <jcsackett> (in NEWS.txt)
[16:29] <jam> mwhudson: it lets me in with a proper ssh-key
[16:29] <mwhudson> yeah
[16:29] <leonardr> jcsackett: add it to 1.7.0, it's not out yet
[16:30] <jam> with my password cached, it is 3.3s from a machine in France
[16:30] <jam> interestingly, bazaar.staging denies me
[16:30] <EdwinGrubbs> lifeless: why does https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html list my bug as qa-bad, when it is tagged qa-ok? I didn't think I was supposed to remove the bad-commit-N tag.
[16:30] <jam> though I have a different key on that machine
[16:31] <jam> non-staging is 3-7s for me
[16:31] <jam> (3, 7.1, 4.6, ...)
[16:31] <lifeless> EdwinGrubbs: you're not
[16:31] <jcsackett> leonardr: dig. and what's the landing policy for launchpadlib? looks like all the landings on trunk have been by you? or feel free to point me to docs if they're around for this.
[16:31] <lifeless> EdwinGrubbs: you're meant to have landed a commit with [rollback=xxxxx] where xxxxx is the bad commit
[16:31] <lifeless> EdwinGrubbs: until thats landed the qa tagger ignores the qa-* tags.
[16:32] <leonardr> jcsackett: bzr co the trunk, then merge and commit
[16:32] <lifeless> EdwinGrubbs: this is because we have to pair the bad commit with the fixed commit.
[16:32] <EdwinGrubbs> lifeless: but what if I fix the bug instead of rolling it back. Should I still tag it with [rollback=xxxx]?
[16:32] <jcsackett> leonardr: dig. thanks!
[16:32] <lifeless> EdwinGrubbs: yes, sadly.
[16:32] <lifeless> EdwinGrubbs: is that what happened here?
[16:32] <EdwinGrubbs> yes
[16:33] <lifeless> EdwinGrubbs: what commit fixed it ?
[16:34] <jam> shadeslayer: ATM, it looks like we're disabling your daily build, until we can figure out why it is crashing.
[16:34] <EdwinGrubbs> lifeless: if you look at revision 11763, it has the same info, since I had tried to get a losa to cancel the previous pqm run. I thought the cancelling had succeeded, which is why I landed it again with the same message.
[16:34] <shadeslayer> jam: feel free to :)
[16:35] <EdwinGrubbs> lifeless: I guess I should just land an empty branch with [rollback=xxxx] in it then.
[16:36] <lifeless> EdwinGrubbs: no need
[16:36] <lifeless> EdwinGrubbs: I'll explicitly call it out
[16:36] <EdwinGrubbs> ok, thansk
[16:47] <StevenK> lifeless: 11778 QA'd
[16:56] <jml> bigjools: hi
[16:57] <bigjools> jml: hi - just wanted to tell you that I tracked down why the b-m was using so much CPU
[16:58] <bigjools> probably best to explain in person
[16:58] <flacoste> jml: if you have time, i'd like your opinion on the new release schedule proposed by henninge, especially its impact on the bug jam
[17:02] <lifeless> flacoste: I need to talk with you about a) storm and b) my leave (which is still darn vague)
[17:08] <jml> flacoste: I'll try to look at it today.
[17:11] <lifeless> mwhudson: I forwarded that mail to losas@
[17:11] <jam> lifeless: you don't ever get to leave. I thought you knew that
[17:12] <lifeless> jam: hah
[17:12] <lifeless> ;p
[19:10] <LPCIBot> Project db-devel build (107): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/db-devel/107/
[19:12] <lifeless> flacoste: calling
[19:37] <lifeless> is it really still week 1?
[19:39] <LPCIBot> Project devel build (164): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/devel/164/
[19:47] <rockstar> abentley, yo.
[19:47] <abentley> rockstar: yo.
[19:48] <rockstar> abentley, I'm having a hard time writing a test that will reproduce what Chex did today.
[19:48] <abentley> rockstar: have you tried it out locally?
[19:48] <rockstar> abentley, I wonder if you might have a better idea what's going on there.
[19:48] <rockstar> abentley, I have.  I also wrote a test that will do exactly the same thing.
[19:50] <rockstar> abentley, I just thought you might have a cursory "oh yeah, I think that problem might be in X"  If you don't, don't worry about it.  I'll sort it out.
[19:52] <abentley> rockstar: Nothing strikes me.  I'd look at whether updateContextFromData is doing badness.
[19:52] <rockstar> abentley, I suspect there's something admin specific here.
[20:21] <jam> rockstar: you mean accidentally reassigning to himself?
[20:21] <jam> mwhudson explained what happened in a different (but similar) page
[20:22] <rockstar> jam, if I see him, I will ask.
[20:22] <jam> he explained it to me
[20:22] <jam> said that there is a dropdown which contains a list of your id + groups you are in
[20:22] <jam> and tries to select the current group which matches the owner
[20:23] <jam> but if it can't find that group, it just selects the first line
[20:23] <jam> which is you
[20:23] <jam> but for admins
[20:23] <jam> they aren't in the existing group
[20:23] <jam> so it always selects themselves
[20:23] <jam> ideally, admins would just have a text-entry box
[20:23] <jam> since they can set it to anyone
[20:23] <jam> otherwise you have to play a game of "find the common group", set it to that, then have the user set it back to themselves
[20:23] <lifeless> jam: so, I've forwarded your instructions to losas; but if you wanted to drive the testing of the forking service that wuld be best
[20:24] <lifeless> jam: the code is deployed
[20:24] <jam> lifeless: I'm happy to do the testing, but what about startup scripts, etc?
[20:24] <lifeless> hop into launchpad-ops
[20:24] <lifeless> ask losa there
[20:25] <rockstar> jam, huh.  I have a test that would indicate that's not what's happening, but what you say makes sense.
[20:26] <jam> rockstar: I don't know specifically what is happening. Just that mwh said it was happening on another page, and they fixed it somehow
[20:26] <rockstar> jam, yeah, I just talked to sinzui about it.
[20:26] <jam> ls
[20:26] <jam> sorry, mt
[20:28] <jam> rockstar, is poolie near you? vila would like to chat with him in #bzr
[20:28] <rockstar> jam, poolie is not here.  Just deryck and I.
[20:29] <jam> np
[20:35] <rockstar> jam, actually, turns out that's EXACTLY what's wrong.
[20:35] <rockstar> jam, also, I apparently already had a test that CLAIMED to be testing it, but it wasn't.
[20:36] <jam> rockstar: I'm glad I could be proxy-help for mwh
[20:37] <rockstar> jam, :)  Thanks.
[20:42] <lifeless> deryck: hi
[20:43] <deryck> hi lifeless
[20:43] <lifeless> if you're in the main hall, I'm just qaing a bugs patch
[20:43] <lifeless> would like your input
[20:43] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[20:43] <deryck> lifeless, sure, be right there.
[20:49] <thumper> morning
[20:51] <thumper> abentley: ping
[20:51] <abentley> thumper: pong
[20:51] <thumper> abentley: quick call?
[20:51] <abentley> thumper: sure.
[20:59] <lifeless> gary_poster: hi
[20:59] <gary_poster> hey lifeless
[20:59] <lifeless> gary_poster: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html rev 11792
[21:00] <gary_poster> lifeless, just changed it
[21:00] <gary_poster> like, seconds ago :-)
[21:00] <lifeless> sweet
[21:03] <lifeless> deryck: https://bugs.edge.launchpad.net/malone/+bug/659085
[21:03]  * deryck looks
[21:08] <deryck> lifeless, so I'm 85% sure that one is qa-ok.  But I cannot know for sure without pinging allenap about it.
[21:09] <deryck> allenap, around?
[21:09] <allenap> deryck: Whassup?
[21:10] <deryck> allenap, see the bug lifeless pointed me at above... is it qa-ok?
[21:10] <thumper> abentley: https://edge.launchpad.net/ubuntu/+source/gstreamer0.10
[21:11] <allenap> deryck: I have tried a few times to test this in staging/qastaging but it keeps timing out, so qa-untestable I'd say.
[21:12] <deryck> allenap, there's nothing changed in functionality?  Just moving code around?
[21:13] <allenap> deryck: The implementation has changed quite a bit, but the tests didn't much.
[21:13] <deryck> allenap, hmmmm
[21:13] <deryck> allenap, what should I look at to qa this on staging?
[21:14]  * allenap tries to remember
[21:19] <abentley> thumper: https://code.edge.launchpad.net/~abentley/+archive/ppa/+builds
[21:19] <allenap> deryck: Okay. Calculating structural subscribers has been refactored, but the code changed little. The difference is that the bug change notification code now uses the new structural subscriber code (getStructuralSubscribers) instead of getBugNotificationsRecipients.
[21:20] <allenap> deryck: So we need to change some bugs and check that structural subscribers are notified.
[21:20] <bigjools> abentley: I have bad news for you.  Backing out the buildd revision has cured our build farm ills.  There's not much chance of it going back in.
[21:20] <allenap> deryck: I *think* that if it's wrong we will send too little bug mail.
[21:20] <allenap> deryck: Well, or too much.
[21:21] <deryck> allenap, ah, ok.  I can poke at that then and see what happens.
[21:21] <bigjools> abentley: but I would like us to analyse the  changes and how they could have caused buildds to become slow to respond to probes
[21:22] <abentley> bigjools: okay.  Do you have any logs?
[21:23] <bigjools> abentley: sort of.  It looks like it's eating memory which causes the machine to slow down too much (swapping)
[21:24] <bigjools> abentley: we have got strace logs, tcp dumps but no buildd logs since they are virtual
[21:24] <bigjools> abentley: what changes did that buildd revision have?
[21:28] <abentley> bigjools: It has an updated version of bzr-builder, it builds outside the chroot, and it uses xen-detect to ensure it doesn't build in an unvirtualized situation.
[21:29] <bigjools> abentley: I wonder if bzr-builder regressed somehow then
[21:29] <thumper> bigjools: ok, so where to from here?
[21:30] <bigjools> thumper: we need to re-create this problem on dogfood
[21:30] <thumper> bigjools: ok, do it! :)
[21:30] <bigjools> then we can start to diagnose it outside of production
[21:31]  * bigjools stares at thumper
[21:31]  * thumper deflects the stare with a cunning mirror like shield
[21:32] <allenap> deryck: It's still timing out all the time for me.
[21:32] <bigjools> thumper: are you batfink in disguise!
[21:32] <deryck> allenap, every bug is timing out?  Or trying to do something times out?
[21:33] <allenap> deryck: Trying to create a structural subscription (I don't have any) is timing out.
[21:33] <deryck> ah
[21:33] <allenap> deryck: Ah. If I go to +subscribe directly it works. I can't get any project pages to work.
[21:33] <deryck> allenap, do you think it's related to your work?  Or just qa/staging?
[21:33] <deryck> ah right
[21:34] <lifeless> allenap: what project did you try?
[21:34] <allenap> lifeless: malone and scriptify (one of mine with no artifacts apart from a single trunk branch)
[21:35] <lifeless> allenap: also we can raise the timout on qastaging instantly if needed (via a feature flag)
[21:35] <allenap> Ah yes.
[21:35] <lifeless> we should look at the timeout you got though, it may be a problem for prod too
[21:37] <allenap> lifeless: Okay, I'll file a bug for it.
[21:38] <lifeless> allenap: got an OOPS ID ?
[21:38] <lifeless> allenap: so, do we think this change is ok ?
[21:39] <allenap> lifeless: I think it's fairly safe, but I haven't been able to QA it so far. I also (or someone) needs to look in the shared catch-all mailbox.
[21:40] <allenap> Chex: Did you find a shared mailbox for qastaging?
[21:40] <lifeless> allenap: launchpad-ops, ping the losa :)
[21:43] <allenap> lifeless: OOPS-1762QS22
[21:43] <jcsackett> bzr uncommit and bzr shelve may be the two best commands ever.
[21:43] <lifeless> :)
[21:43] <StevenK> bzr needs a 'bzr moo'
[21:44] <lifeless> garh
[21:44] <jcsackett> 'bzr garh' might actually work. :-P
[21:44] <jcsackett> "This version control tool doesn't have cow powers. It does however have a pained `lifeless`."
[21:45] <StevenK> jcsackett: It's super cow powers :-P
[21:45] <allenap> lifeless: I think it might be a cold cache kind of problem, because it's now snappy on staging, having timed out consistently 10-20 minutes ago.
[21:45] <lifeless> allenap: or load, ok.
[21:46] <StevenK> lifeless, jcsackett: http://paste.ubuntu.com/521648/
[21:48] <jcsackett> StevenK: that's terrible. and hilarious.
[21:55] <wgrant> bigjools: Why can't we get logs?
[21:55] <wgrant> bigjools: Surely someone has access to the host...
[21:55] <bigjools> securitai
[21:55] <bigjools> it's a VM
[21:55] <wgrant> Yes.
[21:55] <wgrant> But there is a host.
[21:55] <wgrant> Host can poke at VM FS.
[21:55] <bigjools> which does not have any logs
[21:55] <bigjools> no, it can't
[21:56] <bigjools> securitai
[21:56] <wgrant> !?
[21:56] <lifeless> allenap: https://lp-oops.canonical.com/oops.py/?oopsid=1762QS22 - 11seconds of sql
[21:57] <wgrant> bigjools: Have you checked the bzr versions on the VMs?
[21:57] <bigjools> I've not checked anything
[21:57] <mwhudson> build-dependcies: ... package-that-adds-lamonts-ssh-key-in-postinst ...
[21:58] <wgrant> Unless you are running a very strangely mangled Xen, I don't see how the host can't poke around in the VM's filesystem and grab logs.
[21:58] <allenap> lifeless: That query has some EXISTS smells in it too. I'll file a bug for it now.
[21:58] <lifeless> allenap: exists isn't necessarily bad, but I agree that it would benefit from eyeballing.
[21:58] <lifeless> allenap: - so +1 on that
[22:03] <wallyworld_> abentley: thumper: standup?
[22:05] <allenap> lifeless, deryck: I have to go now. There's still no word on the qastaging mailbox. I am also away tomorrow, but I can probably find an hour in the morning if necessary.
[22:07] <lifeless> allenap: how can I help
[22:07] <lifeless> allenap: e.g. if the mail is in the mailbox, its ok ?
[22:07] <abentley> wallyworld_: thumper is having a call with flacoste.
[22:08] <wallyworld_> abentley: ok. i'llbe here when he's done
[22:08] <allenap> lifeless: Mail for bug changes should be sent to structural subscribers. If, say, a bug task is assigned to a milestone to which someone is subscribed, they should also get bug mail. Also distro subscribers should get source package bug mail.
[22:09] <lifeless> ok and in this case we shouls expect ...?
[22:12] <allenap> lifeless: The same bug mail as everyone else, but with a rationale that explains that they're subscribed to a milestone, or the distro.
[22:13] <lifeless> kk
[22:16] <allenap> lifeless: Just to check, r11794 is not-ok, but everything else can be pushed out?
[22:16] <allenap> So it's not blocking lots of stuff yet.
[22:18] <lifeless> allenap: its blocking 20 revs
[22:19] <allenap> lifeless: Ah, okay, deployment-stable.html doesn't show the subsequent revs that are prevented from rolling out.
[22:19] <thumper> abentley, wallyworld_: standup now?
[22:19] <wallyworld_> yep
[22:21] <thumper> http://www.shopwithmaverick.com/wp-content/uploads/wpsc/product_images/meerkats%20wall%20back%20-4.jpg :-)
[22:25] <lifeless> allenap: yes
[22:26] <mars> allenap, fwiw, we're working on that
[22:30] <lifeless> Ursinha: hey
[22:31] <lifeless> Ursinha: what did you think of my qatagger improvement requests
[22:33] <flacoste> lifeless: https://code.edge.launchpad.net/~flacoste/launchpad/ppr-constant-memory/+merge/39578 if you have some time
[22:35] <lifeless> how much memory is it taking now ?
[22:36] <flacoste> lifeless: i'd say something like 800M, but that's because of the 400M cache size
[22:36] <flacoste> lifeless: i didn't get that locally (since 300k are using 56M of storage)
[22:36] <Ursinha> lifeless, I'm implementing the "codebrowse url on reports" now, which is fairly simple
[22:36] <lifeless> \o/
[22:37] <Ursinha> the other one I'll have to take a deeper look
[22:37] <flacoste> lifeless: i'm it's using now 576M on sodium (still only inserting)
[22:37] <Ursinha> I'm fixing the bug that shows all revisions instead of all until the not-ok one
[22:37] <Ursinha> that flacoste reported
[22:37] <flacoste> with over 5M requests inserted
[22:38] <flacoste> i think it will think up to ~5h to generate a daily though
[22:38] <flacoste> since it took 2h last time
[22:40] <thumper> bzr missing --mine-only ../db-devel
[22:47]  * wallyworld_ afk briefly to do school dropoff
[22:51] <rockstar> thumper, do you know much about custom widgets in forms?
[22:51] <rockstar> (sinzui was supposed to help me, but I think he forgot)
[22:51] <thumper> rockstar: some
[22:51] <thumper> whazzup?
[22:52] <rockstar> thumper, I need to use a different widget in the form in the user has launchpad.Admin on the form.
[22:52] <rockstar> thumper, we discovered a bug today where the select box for choosing on owner for a recipe re-assigns ownership of the recipe if an admin edits it.
[22:52] <thumper> rockstar: take a look at the branch edit form
[22:52] <thumper> rockstar: we do exactly that
[22:52] <thumper> rockstar: for admins editing branches
[22:53] <rockstar> I looked around, but couldn't see anything.
[22:53]  * rockstar looks
[22:53] <thumper> rockstar: around line 1000 of code.browser.branch.py
[22:55] <rockstar> Oh crap.  I think I figured it out...
[22:55] <rockstar> I was on the right track, just forgot to call the setUpFields on the superclass...  :/
[23:12] <LPCIBot> Project devel build (165): STILL FAILING in 3 hr 33 min: https://hudson.wedontsleep.org/job/devel/165/
[23:12] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] [r=jml]Fix layers to teardown always not just
[23:12] <LPCIBot> sometimes,
[23:12] <LPCIBot> fixing teardown in our code base and freeing us from the tyranny of
[23:12] <LPCIBot> atexit.
[23:12] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=667687] Fix deactivateAccount to handle
[23:12] <LPCIBot> drivers correctly.
[23:27] <gary_poster> wallyworld_: back?
[23:27] <wallyworld_> gary_poster: yes. thanks for the great email. i was going to respond this morning
[23:28] <wallyworld_> i'll do the stuff you outlined
[23:28] <gary_poster> wallyworld_: great.  happy to help
[23:28] <gary_poster> (all I was going to do was see if there was anything we ought to talk about before I ran away)
[23:29] <gary_poster> so I'm running away then :-)
[23:29] <gary_poster> bye
[23:29] <wallyworld_> gary_poster: np. the email spelt it all out extremely well. bye
[23:43] <thumper> :)
[23:43] <thumper> Done. 9470605 items in 949 iterations
[23:43] <thumper> CodeImportEventPruner
[23:44] <lifeless> \o/
[23:44] <lifeless> is that 9.4M items? how long did it take?
[23:52] <thumper> lifeless: a while, but not too long
[23:52] <thumper> lifeless: and yes it is 9.4M items
[23:52] <lifeless> thumper: how long, do you know?
[23:53] <thumper> 9.4 mostly useless items
[23:53] <thumper> lifeless: I can check
[23:53] <lifeless> please, I'm very curious
[23:53] <thumper> lifeless: it won't be as long with the next run time though
[23:53] <thumper> lifeless: as it'll only be deleting around 30k items
[23:53] <thumper> nah, 20k items
[23:54] <thumper> lifeless: 3778.052 seconds,
[23:54] <thumper> average size 9979.563215 (2506.74270824/s)
[23:55] <thumper> so based on the time there, daily garbo for this should take around 4s
[23:55] <lifeless> 1 hour?! wow. Was it multiple transactions ?
[23:55] <thumper> lifeless: yes, 949 of them
[23:55] <lifeless> whew :)
[23:55] <thumper> lifeless: written the garbo way
[23:55] <lifeless> yeah
[23:55] <lifeless> I trusted
[23:55] <lifeless> I'm just happy it panned out
[23:55] <thumper> it did
[23:55] <thumper> now to see if it makes a difference at all
[23:56] <thumper> hopefully with that and the fix I've done for mailing lists we should see a difference
[23:56] <thumper> on the private xmlrpc server
[23:58]  * thumper closes up for lunch


[09:00] <alkisg> Hi, https://wiki.ubuntu.com/Security/Features#Built_as_PIE says that it has 5-10% performance penalty
[09:00] <alkisg> Does that mean that if I run `echo 0 > /proc/sys/kernel/randomize_va_space` on a pentium 4, it'll run Ubuntu 16.04 faster?
[09:05] <alkisg> Or compiling with PIE enabled will result in performance loss anyway?
[10:21] <apw> compiling as PIE will alter the emitted code
[10:22] <alkisg> apw: I mean, does PIE mean a syscall that can be disabled in the kernel at runtime, avoiding the extra overhead, or is it a compiler time thing only, which cannot be disabled after compilation?
[10:23] <apw> pie is a compilation option which changes the code to not assume its location, which has a cost associated with it
[10:24] <alkisg> apw, thank you, so the only way to measure that overhead would be to recompile, which isn't really an option if one wants to use a recent Ubuntu version :)
[10:24] <apw> right, you'd need to turn it off and rebuild the kernel
[10:24] <alkisg> The kernel or the apps?
[10:25] <alkisg> I thought that was about the apps...
[10:25] <apw> both indeed, depends what you are trying to measure
[10:25] <alkisg> Well in general how much slower a "desktop feels", maybe that would be 80% userspace and 20% kernel...
[10:26] <apw> hard to say indeed, and humans are immensly sensitive to that kind of thing
[10:26] <alkisg> E.g. a few years ago it was possible to watch youtube with a p4 1.7 ghz, now it's not even with p4 at 2.4 ghz
[10:26] <apw> a few % and you can tell often
[10:26] <apw> are the videos at the same resolution i wonder
[10:26] <alkisg> Yes, but I'm not sure about the players
[10:27] <apw> but it doesn't supprise me entierly, old h/w does get left behind over time
[10:27] <apw> i wonder how old a pentium-4 mbased mchine could be at its youngest now
[10:27] <alkisg> I used the same video back then and now, and tried with flash now as well as then when html5 didn't exist, but I don't know if flash or youtube added unrelated code that made them slower
[10:29] <apw> browsers are more tightly controlled now days too
[10:29] <apw> and video playback is one of those things where your computer is either fast enough or not
[10:29] <alkisg> And there's compositing even in the legacy desktops, adding to delays... https too...
[10:29] <alkisg> Ah, playing with vlc is fast now too
[10:29] <apw> it might have been 1% faster than needed before and be 2% slower now and ... you lose
[10:30] <alkisg> The browsers make it like 4 times slower
[10:30] <apw> so it is ok in vlc ?
[10:30] <alkisg> Yeah
[10:30] <apw> so not inherantly unplayable then
[10:30] <alkisg> Ubuntu 16.04 i386 is still fast enough to play an e.g. 1024x768 full screen movie without dropped frames
[10:31] <alkisg> Indeed, but there's no way to convince youtube/firefox etc etc to make them more efficient for older machines, so I was looking to gain that 10% performance in case it makes things barely more functional
[10:33] <alkisg> apw: so with regards to aslr/pie, we're not expecting any performance differences between e.g. 12.04 and 18.04, since all "major" programs like the kernel or firefox were already using them, correct?
[10:33] <apw> that'd be my feeling
[10:34] <alkisg> Thank you, I was worried that I would have to hold those machines with 16.04
[10:34] <alkisg> Let them work with 18.04 as long as they have a bit of life in them
[10:40] <apw> alkisg, as with all things, testing it out is a good plan
[10:41] <alkisg> Indeed... hmm I'll actually do a larger comparison, 10.04/12.04/18.04 live cds, and watching the same youtube video...
[10:42] <apw> sounds like "fun"