[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!  You have foiled me for the last time!
[02:36] <bddebian> heh
[02:37] <RAOF> Or probably it hasn't; I'm not enough of a 3d ninja to fix/complete nv4x gallium :)
[02:37] <bddebian> heh
[02:38] <protonchris> Hey bddebian
[02:38] <RAOF> We should totally pay someone to hack on nouveau, though.
[02:38] <bddebian> Hello protonchris
[02:38] <bddebian> RAOF: nouveau?
[02:39] <RAOF> !nouveau
[02:39] <ubotu> Nouveau is an experimental open-source nVidia driver, aiming for full 3d support.  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 0.5.8.7-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 0.5.8.9 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_0.5.1.1-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 0.5.8.9" [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_0.5.1.1.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_0.5.1.1.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> 0.5.1.1 is correct
[18:52] <james_w> in debian/changelog?
[18:52] <james_w> 0.5.1.1-1?
[18:52] <jdahlin> 0.5.1.1-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-0.5.1.1.tar.bz2 now, but debuild apparently expects a flumotion-0.5.1.1.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 0.5.1.1-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 2.0.0.14 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 2.0.0.14 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