[01:22] <psusi> kees, re: bug #556167 when you say "actual disk files" what are you referring to?  a block device?
[02:07] <bryceh> @pilot out
[02:19] <cjwatson> could somebody (a Kubuntu person perhaps) merge libkipi and kde-baseapps?  The lack of those merges is causing gwenview to fail to build
[03:08] <slangasek> ev: has bug #542310 been a problem lately?  the change apparently got dropped in a console-setup merge in maverick
[03:14] <adam_g> is there anything that needs to be added to bug #885998 to expedite release of the regression fix? i can't seem to nominate it for series, but the proposed branches have been merged into -proposed earlier today. awaiting upload
[03:22] <slangasek> cjwatson: lp:~ubuntu-core-dev/console-setup/ubuntu/ updated and ready for review
[03:22] <slangasek> adam_g: looking
[03:25] <slangasek> adam_g: since I don't speak ruby so I'm not sure what this does; what's 'rescue'?
[03:26] <slangasek> (accepting, anyway)
[03:26] <adam_g> slangasek: it catches an exception. ive run it by jacob (upstream) and he confirms the fix
[03:27] <adam_g> gah. i need to run
[03:27] <adam_g> slangasek: thanks for checking that
[03:27] <slangasek> adam_g: well, that would've been my first guess; I think I'm confused that explicitly catching the one exception, but returning the same value as in the common case, is semantically significant :)
[03:31] <slangasek> adam_g: packages accepted for lucid/maverick/natty; as soon as someone confirms that the package fixes the regression, one of the SRU team members can push to -updates
[05:17] <slangasek> cjwatson: do we apply the same policy as Debian regarding including translations in udebs (i.e., only when translation percentage is high enough)?
[05:17] <slangasek> cjwatson: user-setup has wo, cy translations dropped upstream, but there are local Ubuntu translations
[06:30] <pitti> Good morning
[06:31] <pitti> roaksoax: I am now, what's up?
[06:31] <pitti> roaksoax: rh-cluster is not in the queue, I suppose someone already did
[06:32] <pitti> broder: I'm not actually sure; can I please refer you to cjohnston about this?
[06:33] <pitti> broder: but NB that it doesn't yet produce precise charts; you might just turn up automatically if you get precise WIs
[06:33] <broder> pitti: sure, no problem. i might alternatively get bored and go source diving
[06:34] <manish> pitti: can you review my review request for software-properties?
[06:35] <pitti> manish: sure, in a bit; I need to do some firefighting right now
[06:35] <pitti> manish: can you toss me the link, and I'll review it ASAP?
[06:37] <manish> pitti: sure https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/887249
[06:37] <manish> yeah sure, look at it when you are free. No hurry
[08:04] <dholbach> good morning
[08:42] <Laibsch> Can somebody please accept the nomination for LTS for bug 807545?
[08:43] <Laibsch> it really is too easy for SRU work to be ignored because the main task is already fixed (which is a prerequisite for an SRU, mind you!).  I don't think I need to tell you that this is very frustrating for a contributor.
[08:43] <pitti> Laibsch: done
[08:43] <Laibsch> pitti: thanks!!
[09:27] <smb> jhunt_, morning, are you around?
[09:28] <jhunt_> smb: hi
[09:29] <smb> jhunt_, Just wanted to let you know that I "fixed" the battery info problem in hardware (seems it needed a battery removal for a bit). Still I think it would be good if we could get udev fixed in a way not to repeat something till eternity that fails (and in turn setting the machine on fire, sort of)
[09:35] <jhunt_> smb: interesting. However, I believe kay's view is that upstart-udev-bridge should be tweaked to handle this rather than changing udev. My concern is that *if* any hardware already exposes data via utf-8, fixing this problem at any level will potentially cause a change in system behaviour since before dbus added this new assert, utf-8 data may have been propagating into userspace.
[09:37] <jhunt_> smb: I'll take a look at this today.
[09:39] <smb> jhunt_, I agree. I think what the contents of the data are is a different problem and finding that it just was crappy hw makes it a much less important thing to fix. The lesson learned here would rather be that upstart-udev-bridge needs a way to handle this in a way of knowing that the invalid characters error won't go away by sending them again to dbus.
[09:44] <chrisccoulson> hmmm, does anybody have any idea what's going on with https://launchpadlibrarian.net/84686467/buildlog_ubuntu-natty-powerpc.firefox_8.0%2Bbuild1-0ubuntu0.11.04.1_FAILEDTOBUILD.txt.gz ?
[09:45] <chrisccoulson> it fails because of a missing file, despite the fact that this source is identical to one which already built successfully
[09:45] <chrisccoulson> i can't reproduce it on the ppc porter box
[09:45] <chrisccoulson> and there's lots of "rm: cannot remove directory `chroot-autobuild/build/buildd/*" after it fails too
[09:50] <ev> slangasek: huh, I haven't noticed any further reports like that
[09:50] <pitti> chrisccoulson: looks like someone interrupted the build
[09:50] <pitti> chrisccoulson: the standard way of cancelling a build is to rm -rf its build tree
[09:50] <chrisccoulson> pitti - hmmm, they've interrupted all of the builds then. all the firefox builds failed in the same way
[09:51] <pitti> chrisccoulson: perhaps they needed the powerpc builds for an urgent security update?
[09:51] <chrisccoulson> pitti - this was a security update ;)
[09:52] <pitti> chrisccoulson: so, no idea I'm afraid; lamont might know more
[09:52] <chrisccoulson> thanks
[10:33] <pitti> slangasek: I set you as reviewer of https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption; is that ok for you or want me to find someone else?
[11:13] <cjwatson> @pilot in
[11:18]  * dholbach hugs cjwatson
[11:25] <iceroot> cjwatson: hi
[11:26] <tkamppeter> pitti, hi
[11:27] <pitti> hey tkamppeter
[11:28] <tkamppeter> pitti, it is about bug 877793. Some people use the upstreanm source HPLIP instead of the Ubuntu one because they want the newest for some reason (and there is no LSB package of HPLIP).
[11:29] <iceroot> cjwatson: if i am correct, you help people getting there patches in ubuntu and/or upstream?
[11:29] <tkamppeter> The upstream HPLIP installs certain libraries to /usr/lib64 on 64-bit systems. This was no problem until Natty, as there /usr/lib64 was a softlink to /usr/lib. This got dropped in Oneiric. Why?
[11:30] <cjwatson> iceroot: that's the theory anyway
[11:31] <iceroot> cjwatson: :) may  i steal some of your time?
[11:32] <cjwatson> iceroot: sure
[11:32] <pitti> tkamppeter: I don't know really; presumably because of the multiarch transition
[11:32] <tkamppeter> pitti, who should I ask?
[11:32] <pitti> tkamppeter: slangasek is probably the best person
[11:33] <tkamppeter> slangasek, hi
[11:33] <iceroot> cjwatson: https://bugs.launchpad.net/ubuntu/+source/kwalletcli/+bug/802274  is there a way instead of this debdiff-thing that i can build and upload! the package myself to some proposed repos?
[11:34] <cjwatson> iceroot: you can certainly use a PPA (https://help.launchpad.net/Packaging/PPA); that may be useful to you to have a fixed version in the meantime, although it won't help it get into the security repository
[11:35] <iceroot> cjwatson: so the correct way to get it in the sec-repos is waiting for a review of the debdiff?
[11:36] <iceroot> cjwatson: so the steps i did were correctly and nothing more to do for me
[11:38] <cjwatson> right, that's the only way.  there are a couple of improvements you could make though; the version number would be more obviously correct for a security update if it were 2.03-1ubuntu1.1 rather than 2.03-1ubuntu2; the upload target should be "natty-security", not "natty"; and if I were you I would use 'quilt rename' to rename the debian/patches/ file to something more descriptive, and fill out the patch header template
[11:39] <cjwatson> (I would help, but I don't have access to upload to -security myself; you did the right thing in subscribing ubuntu-security-sponsors)
[11:39] <cjwatson> thanks for your patch, sorry it seems to have taken a while for people to look at it
[11:41] <iceroot> cjwatson: thanks for the feedback sounds good. for the version-numer is was just using dch -i, the upload target "natty-security" is the "tag" where also the tag "patch" is? and what do you mean with "patch header template"?
[11:42] <iceroot> cjwatson: ah ok, i see what you mean with patch header
[11:44] <iceroot> cjwatson: but +Reviewed-By: <name and email of someone who approved the patch>  should not be filled from me?
[11:44] <cjwatson> iceroot: version number - right, but dch -i isn't always the best thing to use for security updates, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[11:44] <cjwatson> iceroot: upload target - where it currently says "natty" on the first line of debian/changelog
[11:44] <cjwatson> iceroot: patch header - leave out fields you can't fill in, don't just leave them as the template
[11:45] <iceroot> cjwatson: ok then i only will use +Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber>
[11:46] <iceroot> cjwatson: thank you very much for your feedback and your time. i will no recreate my debdiff and upload it again
[11:46] <cjwatson> it should also have Description and either Author or Origin
[11:46] <cjwatson> at minimum
[11:46] <iceroot> cjwatson: already set
[11:47] <cjwatson> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/openssh/precise/view/head:/debian/patches/auth-log-verbosity.patch for example
[11:48] <cjwatson> iceroot: true, though it's best to trim down the Description from the one that was automatically created there.  "Description: tty I/O now properly disables echoing input when asking for a passphrase" for instance
[11:48] <cjwatson> anyway, this is relatively minor, just helps the person reviewing it to see that you know what you're doing and thus process it faster :)
[11:52] <iceroot> cjwatson: i will do so. a patchpilot is a good "thing" to help people with things like that :) good work
[11:52] <cjwatson> ok, glad to help
[12:02] <dupondje> Hi, could somebody look @ https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887481 ?
[12:02] <dupondje> seems like alot of people are affected
[12:21] <apw> pitti, do we have a precise work-items db as yet ?
[12:21] <pitti> apw: status.u.c. has been switched apparently
[12:22] <apw> pitti, are we maintaining our own bot for that or dropping it
[12:22] <apw> (the one in ~platform)
[12:22] <pitti> apw: well, it is our's
[12:22] <pitti> apw: no, the one on people is gone
[12:22] <pitti> it just retains the old charts for hysteric raisins
[12:23] <apw> and does the one on status maintain db we can snarf?
[12:23] <pitti> james_w: ^ do you know?
[12:24]  * pitti checks on cranberry
[12:25] <pitti> apw: http://status.ubuntu.com/ubuntu-precise/ubuntu-precise.db
[12:25] <pitti> james_w: unping
[12:25] <apw> pitti, thanks
[12:28] <sebner> cjwatson: thanks for syncing flightgear and related stuff :)
[12:29] <apw> pitti, so i assume james_w is the one to hastle about issues on status ... seems its importer isn't well as it sees 2 WIs on https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review which has about 20
[12:33] <cjwatson> sebner: np
[12:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349 and anoher one :( bugfix seems to be already upstream
[12:41] <zyga> mvo, hi
[12:41] <zyga> mvo, quick question: is aptitude supposed to work well with multiarch?
[12:41] <zyga> mvo, I keep getting odd behaviour, some of which smells like bugs
[12:44] <mvo> zyga: its not working well, but not totally broken. i would suggest to use apt-get for now
[12:45] <zyga> mvo, ah, ok so this is expected
[12:45] <mvo> yeah, at least currently
[12:45] <zyga> mvo, I mainly see 'new packages' going crazy (resetting to ~18K) and spurious remove frenzy when I accidentally try to install i386 library
[12:46] <herton> pitti: launchpad.net/bugs/871899 is waiting to be copied to -updates/-security for some time, can you take a look? (I want to push a new update this week to -proposed)
[12:47] <pitti> herton: oh, I thought I caught them all last Friday
[12:47] <pitti> herton: doing
[12:47] <herton> thanks
[12:50] <pitti> herton: done
[12:51] <pitti> herton: ah, I remember -- I skipped this on Friday
[12:51] <pitti> herton: releaseing a new major kernel to -updates on a Friday before everyone hopped into planes seemed a bit bold
[12:52] <herton> hehe ok, np. thanks
[13:00] <dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[13:00] <dupondje> attached debdiff
[13:00] <dupondje> could somebody check please?
[13:06] <dupondje> barry: are you there ?
[13:51] <tkamppeter> slangasek, hi
[14:13] <cjwatson> @pilot out
[14:16] <dupondje> its silent here :(
[14:17]  * dupondje looks nice to some people to review patch in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349 :)
[14:17] <lamont> chrisccoulson: that looks for all the world like someone stabbed a build... wasn't me
[14:18] <chrisccoulson> lamont, it's ok. someone killed it because the builds hang. i was confused because the same person must have killed the precise build, which is the only one without the problem
[14:18] <chrisccoulson> i uploaded a fix for all the other releases now
[14:19] <m4n1sh> mvo: as I see you are the uploader of software-properties, can you look into this merge request when you have time https://code.launchpad.net/~manishsinha/software-properties/fix-887249-handle-404-error/+merge/81488
[14:20] <lamont> chrisccoulson: it is sad when we're overly thorough. :(
[14:20] <chrisccoulson> lamont, that's ok :)
[14:20] <lamont> cool
[14:20] <chrisccoulson> lamont, would you mind killing the builds on ross, buttercup and cushaw though? :-)
[14:20] <lamont> bah
[14:20] <lamont> sure, why not.
[14:20] <chrisccoulson> those all have the same problem
[14:21] <dupondje> kenvandine: I see you also did uploads for papyon. Could you check the bug above please? Nobody is able to connect to msn anymore with empathy ... :)
[14:21] <lamont> chrisccoulson: terminating now
[14:22] <chrisccoulson> lamont, cool, thanks
[14:22] <lamont> chrisccoulson: in the classic manner:  rm -rf ../chroot-autobuild/build/buildd/*
[14:22] <kenvandine> dupondje, sure
[14:23] <lamont> well, .../chroot....
[14:23] <chrisccoulson> lamont, excellent, thanks :)
[14:23] <lamont> the idea being that when you look at a build and go "wtf, looks like the source tree just disappeared from under the build", you know it was terminated with prejudice
[14:24] <chrisccoulson> lamont, yeah, i'll remember that in future :)
[14:24] <kenvandine> dupondje, cool... i'll sponsor that
[14:24] <dupondje> sweet :D
[14:24] <dupondje> at least we can msn again then :D
[14:25]  * kenvandine doesn't use msn, but glad to help others :)
[14:26] <dupondje> well its the only way to communicate with girls online ;) except facebook :P
[14:26] <kenvandine> hehe
[14:32] <mvo> m4n1sh: sure, I have a look now
[14:33] <m4n1sh> mvo: another clarification. I have some ideas in mind on how to improve adding PPA - both by command line and via GUI
[14:33] <m4n1sh> it it would need launchpadlib as a dependency
[14:34] <m4n1sh> would it be okay to have it as a dependency? AFAIK launchpadlib is in main
[14:37] <mvo> m4n1sh: yes, adding LPlib is fine
[14:38] <mvo> m4n1sh: hm, hold on a sec, I need to check how much this adds to the CD, but in general it should be fine .)
[14:38] <m4n1sh> isn't python-launchpad installed by default?
[14:38] <m4n1sh> mvo: where can I get the list of packaged on the CD? IIRC a URL had some  iso seeds or something like that
[14:38] <mvo> I don't think so, but let me double check
[14:39] <m4n1sh> sure
[14:40] <cjwatson> python-launchpadlib is already on pretty much all our images
[14:40] <mvo> m4n1sh: the seed output is here http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/ but I'm lazy and just boot the livecd in a vm. aha, it appears that python-launchpadlib is installed already
[14:41] <cjwatson> if you're just checking whether it's on the CD it's usually quicker to check the .manifest and .list files at http://releases.ubuntu.com/oneiric/ or http://cdimage.ubuntu.com/daily-live/current/ or whatever's appropriate
[14:41] <pitti> I usually use apt-cache show and look at Task:
[14:41] <pitti> Package: python-launchpadlib
[14:41] <pitti> Task: cloud-image, ubuntu-desktop, server, ubuntu-usb, [..]
[14:41] <cjwatson> yeah, me too, but that requires a bit more interpretation
[14:42] <cjwatson> $ curl -s http://releases.ubuntu.com/oneiric/ubuntu-11.10-desktop-i386.manifest | grep python-launchpadlib
[14:42] <cjwatson> python-launchpadlib     1.9.8-2
[14:42] <pitti> mvo: if nothing else, then apport depends on it
[14:42] <m4n1sh> another question is whether this same application is present in debian too
[14:42] <pitti> but launchpad-integration, too
[14:42] <m4n1sh> in this case care has to be taken to make sure that if launchpadlib is not present
[14:42] <m4n1sh> then it should now throw an error
[14:43] <m4n1sh> software-properties is also used in debian?
[14:43] <mvo> cjwatson, pitti: thanks, both solutions are good to keep in mind :)
[14:43] <m4n1sh> *not throw an error
[14:44] <mvo> m4n1sh: yeah, indeed
[14:44] <m4n1sh> my plan was to provide a section in software-properties-gtk
[14:45] <m4n1sh> when you click add
[14:45] <m4n1sh> instead of just providing a line for adding deb
[14:45] <m4n1sh> I was thinking adding a PPA section too
[14:46] <mvo> m4n1sh: patch looks fine, I will merge now
[14:46] <m4n1sh> thanks
[14:52] <dupondje> kenvandine: could you SRU that also ? :)
[14:52] <kenvandine> dupondje, already did :)
[14:52] <dupondje> aight :D
[14:52] <dupondje> thx
[14:53] <kenvandine> np
[14:58] <roaksoax> pitti: howdy! it seems that rh-cluster is in -proposed still (at lesat that's what lp says), is there a way to unapprove that upload?
[15:04] <pitti> roaksoax: oh, I misunderstood you
[15:05] <pitti> roaksoax: I thought you meant "reject from the queue"
[15:05] <pitti> roaksoax: yes, we can remove the pacakge from -proposed, the question is why
[15:05] <pitti> roaksoax: if we remove it, that won't magically uninstall/downgrade it for people who already installed the -proposed update
[15:05] <pitti> roaksoax: if we are going to fix it harder, there should just be a new -proposed upload
[15:07] <roaksoax> pitti: yes that's the plan. Reject the upload and upload a new ubuntu5.1 package with more fixes or should I go ahead an upload a ubuntu5.2?
[15:08] <pitti> roaksoax: you can't reupload ubuntu5.1, the version number is taken
[15:08] <pitti> roaksoax: just upload 5.2
[15:08] <pitti> with a fix for the fix :)
[15:08] <pitti> but we are not exactly short of natural numbers
[15:08] <pitti> I heard there's quite a lot of them :)
[15:09] <roaksoax> hehe will do
[15:09] <roaksoax> thanks
[15:27] <dupondje> kenvandine: the patch will prolly needed to be SRU'ed in lucid etc also.
[15:28] <kenvandine> dupondje, can you create a debdiff for lucid as well?
[15:28] <kenvandine> i suspect the patch won't apply cleanly as is
[15:29] <dupondje> I make one
[15:29] <kenvandine> dupondje, thx
[15:36] <dupondje> kenvandine: attached patch in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[15:43] <kenvandine> dupondje, thx
[15:46] <kenvandine> dupondje, can you do natty and maverick as well?
[15:47] <dupondje> sure, give me some minutes :)
[15:47] <kenvandine> thx
[15:47] <kenvandine> :)
[15:55] <dupondje> kenvandine: attached
[15:55] <kenvandine> dupondje, thx
[16:01] <slangasek> pitti: happy to be reviewer for desktop-p-power-consumption
[16:02] <slangasek> ev: alright, if there are no reports of that regression I'll not worry about it further and leave it to you to decide if the patch should be reapplied or if it's obsolete
[16:02] <ev> I'm happy to drop it and see what breaks, knowing that everything is safely tucked away in version control
[16:03] <slangasek> tkamppeter: /usr/lib64> this directory is disallowed as an installation target by Debian plicy
[16:03] <slangasek> policy
[16:03] <slangasek> tkamppeter: why does the upstream build not auto-create this directory when installing?
[16:42]  * JLuc is away: Occupé
[16:43] <Pici> JLuc: We'd appreciate if you disabled those messages in Ubuntu channels.
[16:43] <Laney> occupy #ubuntu-devel
[16:43]  * Laney sits down
[16:44] <nigelb> heh
[17:09] <lynxman> Laney: want some cookies?
[17:09]  * lynxman distributes cookies and milk amongst the occupiers
[17:10] <chrisccoulson> Laney, did you see https://twitter.com/#!/search/%23occupyhtml5 ?
[17:10] <chrisccoulson> i found that last week at UDS. made me laugh ;)
[17:32] <cr3> is there a way I could some of the steps during the installation of a package, like configure for example, from within the source of a project with a debian/ subdirectory? I'm not sure if that even makes sense though, I'm just hoping someone got tired of the debuild/pbuilder, then install, to work on the installation scripts
[17:33] <cr3> s/I could some/I could run some/
[17:35] <cjwatson> cr3: you could dpkg --unpack an earlier build of the package, edit the postinst in-place in /var/lib/dpkg/info/ to match how you want it to look, then dpkg --configure $package
[17:36] <cr3> cjwatson: I wasn't familiar with --unpack, thanks!
[17:44] <infinity> @pilot in
[17:45] <infinity> <-- coughing, sniffing, pilot of exploding sinus doom.
[17:47] <SpamapS> ahh lovely, offlineimap has decide today is the day it should delete and re-download all of my email
[17:47]  * SpamapS gets coffee :-P
[17:51] <infinity> SpamapS: Maybe it got bored?
[17:52] <SpamapS> yeah, its like my 2 year old.. if it can't figure things out, it just screams and sets it all on fire
[17:52] <cjwatson> wow, your house must be fun to live in
[17:53] <infinity> Warm, at any rate.
[18:46] <m4n1sh> mvo: is software-properties under CLA?
[18:48] <glatzor> m4n1sh, right. it is.
[18:49] <m4n1sh> glatzor: really? wans't it created before CLA came into existance?
[18:49] <m4n1sh> I remember software-properties-gtk in 6.06 too
[18:51] <glatzor> m4n1sh, you are free to distribute, fork or modify it. the code is released under GPL
[18:51] <m4n1sh> well, that is not a solution anyway
[18:51] <m4n1sh> never mind, just wanted to know
[18:51] <glatzor> m4n1sh, but if you want to make a larger contribution to the software-center hosted and deployed by ubuntu you have to sign
[18:51] <glatzor> the cla
[18:52] <m4n1sh> hmm
[18:52] <glatzor> m4n1sh, the cla "only" affects the canonical source code repository
[18:52] <m4n1sh> glatzor: I am changing lp:software-properties
[18:54] <glatzor> m4n1sh, why?
[18:54] <m4n1sh> for making apt-add-repository more friendly
[18:55] <m4n1sh> now noticed it is under CLA
[18:57] <tkamppeter> slangasek, still there?
[18:58] <tkamppeter> slangasek, as I understand, the upstream package creates /usr/lib64 because it is missing and then installs libs into it. The system then searches them in /usr/lib.
[18:59] <slangasek> tkamppeter: right - saw the bug you assigned, understand the problem now
[19:00] <tkamppeter> If Debian policy forbids installing stuff in /usr/lib64 this directory would stay empty if it exists or not exist, so I see no problem to keep it a symlink simply to make badly done third-party software happy.
[19:00] <slangasek> tkamppeter: not something that we can straightforwardly solve in the distribution, however; /usr/lib64 was never a part of the FHS/LSB that Debian and Ubuntu accepted
[19:02] <tkamppeter> So as /usr/lib64 has no meaning at all, why not simply keep the symlink?
[19:03] <tkamppeter> slangasek, ^^
[19:04] <slangasek> because in multiarch, package unpacks that follow that symlink can lead to incorrect overwrites of the system libraries
[19:04] <slangasek> breaking the entire system
[19:04] <infinity> tkamppeter: Libraries should be installed to the correct locations.  Why it this problematic?
[19:04] <slangasek> infinity: it's problematic because upstream is following the FHS, and getting bitten by it
[19:04] <slangasek> because /usr/lib64 isn't on the path
[19:04] <infinity> slangasek: Sure, but that becomes a non-issue when we package things sanely, surely?
[19:05] <slangasek> infinity: the issue here is with unpackaged upstream stuff
[19:05] <infinity> (I realise this all fails with third-party binaries, and that's a problem we've been dealing with for far too long)
[19:05]  * slangasek nods
[19:05] <infinity> Speaking of.  How goes the multiarch-versus-FHS battle?
[19:06] <slangasek> ETOOMANYIRONS
[19:07] <slangasek> the revived FHS process suffers in general from a deplorable amount of LSBitis
[19:07]  * infinity gets vorlon a bigger forge.
[19:07] <slangasek> which is kinda something that should be addressed, not simply taken advantage of :P
[19:08] <tkamppeter> slangasek, infinity, so the bug is solely in HPLIP and in no part of Ubuntu?
[19:09]  * infinity is hoping that, shortly after we get concensus that m-a paths are the way and the light, we then convince everyone that Debian's triplets are the right ones...
[19:09] <slangasek> tkamppeter: it's a standards dispute; I think the right thing for hplip to do on Debian and Ubuntu is to use /usr/lib instead of /usr/lib64, because that's how we define our system
[19:09] <infinity> tkamppeter: The bug is standards diverging from practice, and then some practice following new standards.
[19:10] <infinity> tkamppeter: For packaged software, this is a non-issue.  For people who want to ship a single binary for "Linux amd64", it gets probelmatic if they have libraries involved.
[19:10] <infinity> tkamppeter: That said, if they distributed with a tiny shell script instead of just a tarball, it fixes itself readily by just installing to the correct path.
[19:11] <slangasek> we could theoretically have /usr/lib64 put on the linker path, but that still doesn't help if things like python modules get installed to /usr/lib64
[19:12] <slangasek> (and from the bug report, I gather that python modules are involved)
[19:16] <tkamppeter> slangasek, infinity, HP's installer is a script, it even compiles from source instead of shipping binaries. So it could for example check the absence of /usr/lib64 and then install in /usr/lib, or check the libs in /usr/lib with "file", see that they are 64-bit and then drop its own libs there too.
[19:17] <tkamppeter> slangasek, infinity, am I right that SUSE does something different here, like /usr/lib/ being 32-bit-only and /usr/lib64 being the place for all 64-bit libs and executables?
[19:22] <slangasek> tkamppeter: correct; that's the current FHS/LSB directory for amd64 libraries, which was driven by SuSE and Red Hat and never adopted by Debian and Ubuntu
[19:23] <infinity> tkamppeter: Checking things with file would hackishly work.  They could also make their installer script depend on the existance of lsb_release and DTRT depending on the target OS.
[19:24] <slangasek> or even check for the existence of /etc/debian_version, really
[19:24] <infinity> tkamppeter: And yeah, the problem is that Debian was doing 64-bit for ages (on sparc, power, parisc, etc) before RH/SUSE decided to standardize on doing the inverse with ia64 and amd64.
[19:24] <infinity> slangasek: Fair point, I suppose we're the only oddballs here, despite being the trailblazers.
[19:31] <slangasek> infinity: whether or not we are, debian_version guarantees that we'll DTRT on all Debian derivatives even if lsb-base isn't installed
[19:32]  * slangasek upgrades to precise and sighs as his terminal fonts immediately become squat and ugly.  I guess I need to try to do something about that freetype regression.
[19:32] <slangasek> preferably before I go blind
[19:33]  * highvoltage is reminded to complete his half-way upgrade to precise
[19:40] <infinity> slangasek: Sure, it would work for us, I was trying to come up with a sane solution for upstream.  But then again, I suppose LFS and other whacky distros might not even have lsb_release available, so it's a lose-lose.
[19:44] <SpamapS> slangasek: Do you think you will have time to take a look at uploading MySQL 5.5 to Debian for me today?
[19:44] <slangasek> SpamapS: hmm, conceivably
[19:44] <slangasek> SpamapS: where is it?
[19:45] <SpamapS> svnURL: svn+ssh://svn.debian.org/svn/pkg-mysql/mysql-5.5/branches/experimental
[19:45] <SpamapS> slangasek: sorry, unintentinaly raw paste.. but.. um.. ^^
[19:45] <slangasek> the svn, it hurts us
[19:45] <SpamapS> Agreed
[19:45] <SpamapS> not sure why it ended up there and not in bzr
[19:45] <infinity> That might be my fault.
[19:45] <slangasek> I think that svn repo predates bzr :)
[19:46] <SpamapS> possibly Norbert not having time to learn bzr. :)
[19:46] <infinity> But yes, if it was my fault, it would have been long before bzr and git.
[19:46] <slangasek> augh all my 1s look like pipes
[19:46] <slangasek> seriously need to punch freetype
[19:47] <slangasek> why is no one else screaming at me about this? :)
[19:47] <SpamapS> slangasek: clearly we're all waiting for you to fix it before we upgrade
[19:47] <slangasek> that's backwards
[19:47] <slangasek> :P
[19:51] <Chipzz> so you actually want more ppl to upgrade so you can get yelled at? that's novel :)
[19:51] <slangasek> yelling is easier on my eyes
[19:51] <Chipzz> true that :)
[19:51] <slangasek> but no, I'm concerned at why I'm not hearing more complaints from those who have already upgraded
[19:51] <broder> because they don't know to yell at you? :)
[19:52] <slangasek> yeah, probably
[19:52] <Chipzz> they're probably blogging "UBUNTU SUCKS" instead :P
[19:52] <slangasek> SpamapS: ok, where's my upstream tarball? :)
[19:52] <slangasek> will uscan dtrt?
[19:53] <SpamapS> http://dev.mysql.com/get/Downloads/MySQL-5.5/mysql-5.5.17.tar.gz/from/http://mysql.he.net/
[19:53] <slangasek> uscan> nope
[19:53] <slangasek> SpamapS: you might want to fix debian/watch when you get a chance
[19:53] <SpamapS> there is a get-orig-source .. but it looks.. scary
[19:53] <slangasek> does upstream distribute signatures for that trojaned payload?
[19:53] <SpamapS> whoa the watch looks.. kind of crazy
[19:54] <SpamapS> http://dev.mysql.com/downloads/gpg.php?file=mysql-5.5.17.tar.gz
[19:55] <slangasek> thanks
[19:56] <slangasek> and of course it's only signed by the GPG Global Directory Verification Keys
[19:56] <slangasek> s/GPG/PGP/
[19:56] <slangasek> ahwell, better than nothing :/
[19:57] <SpamapS> pub   1024D/5072E1F5 2003-02-03 [expires: 2013-09-18]
[19:57] <SpamapS> sad
[19:57] <SpamapS> Oracle can't afford computers that can do 2k keys
[19:57] <slangasek> SpamapS: http://paste.ubuntu.com/732351/
[19:58] <hallyn> (/me prepares to feel stupid)  what does this mean exactly:  W: lxc source: debhelper-overrides-need-versioned-build-depends (>= 7.0.50~) ?
[19:58] <SpamapS> I did not refresh the patches, oops
[19:58] <SpamapS> slangasek: will do some test builds and such with 5.5.17 ..
[19:58] <SpamapS> slangasek: thanks for taking a first crack.
[19:58] <slangasek> n/p
[19:59] <slangasek> yeah, this is the kind of thing you generally only catch when you try to actually generate the source package :)
[19:59] <slangasek> hallyn: it means your debian/rules file is using features of debhelper first introduced in that version, so the package should have a versioned build-dependency
[20:00] <SpamapS> slangasek: I kind of expected you to say "no I'm busy today, lets do it tomorrow" ... ;)
[20:00] <slangasek> heh
[20:00] <SpamapS> my own test build just failed identically.. started before I pinged you (mk-sbuild hadn't been run on my new box yet)
[20:15] <dupondje> How long does it take before a SRU gets accepted in the queue ?
[20:17] <nikolam> hi, I am just experiencing some random X lockup/problem with radeo driver. X stays up frozen, console is availble and spitting radeon driver messages.
[20:17] <nikolam> Hardware is Amd 690G chipset with z1250 graphics, XUbuntu 10.04 LTS amd64
[20:18] <nikolam> How do I catch errors and provide enoug info for a bug report?
[20:20] <nikolam> Or it is just interesting to report it on old LTS, but not important, since there are newer drivers and x both supported and in development?
[20:20] <nikolam> besides, i dont have quite idea how to reproduce it.
[20:20] <nikolam> But would like to learn reporting such X bug
[20:20] <nikolam> driver bug etc.
[20:37] <slangasek> SpamapS: btw, is libmysqlclient multiarchied in 5.5? :)
[20:38] <SpamapS> slangasek: guessing it might not be.. cmake may complicate the matter. :-/
[20:38] <SpamapS> usr/lib/libmysqlclient*.so.*
[20:38] <broder> hmm...how do people send patches to mailing lists with bzr? i can't figure out how to get bzr-send do the git-send-email-style mailings i've been seeing on, e.g., upstart-devel
[20:38] <SpamapS> broder: bzr diff ?
[20:39] <SpamapS> Thats what I usually do anyway.. just bzr diff into a text file
[20:39]  * broder nods
[20:39] <slangasek> broder: bzr send -o $file and attach to mailer?
[20:40]  * slangasek has a strong personal preference for the bzr bundles, since they show up as a merge later on my side
[20:40] <broder> slangasek: preference over merge proposals? i was mostly submitting this to the mailing list as a paper trail for the MP
[20:41] <SpamapS> slangasek: mysql still uses .files and a lot of explicit stuff in debian/rules .. guessing a multiarch transition will be painful, but necessary
[20:42] <slangasek> broder: I sometimes send them places that don't support LP merge proposals :)
[20:42] <slangasek> broder: if there's an MP, that's of course fine
[20:42] <broder> slangasek: this is for setuid/setgid in upstart
[20:43] <lousygarua> i think this should go to #ubuntu-app-devel but there are not as many people there as in here, so i will give it a try.
[20:43] <lousygarua>  hello, i have a n00b c/c++ packaging question. i used to write my own Makefiles but I got tired of adding each new source/header file manually (i also tried some *.cpp pattern function but that's not the way to do that). I though automake/autoconf will save me the trouble of adding files manually but after reading a bit it seems that it does not do what i though it would have done. how do REAL hardcore people like you devel
[20:43] <lousygarua> op c/c++ projects?
[20:44] <hallyn> slangasek, no way to have lintian say which features (are newer than the debhelper version needed) I assume?
[20:44] <SpamapS> lousygarua: automake and autoconf are still the gold standard. You can get a fair headstart with 'autoscan'
[20:44] <broder> hallyn: http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html suggests that it's override_*
[20:45] <slangasek> hallyn: the original error message actually did already... it's the override_dh_* targets that are the feature in question :)
[20:45] <slangasek> hallyn: lintian -i will probably be helpful
[20:45] <slangasek> broder: yeah, for upstart, an MP + bzr diff should be fine :)
[20:46] <slangasek> SpamapS: so cmake shouldn't be that much of a problem for multiarching; I'm sure there are others that have been converted already, let me do a quick peek
[20:46] <slangasek> SpamapS: the .files stuff is harder, and I would suggest going all the way to dh compat 9 in the process
[20:46] <hallyn> d'oh, i see
[20:47] <hallyn> so there's no way to use a debian/rules with override_* in a lucid build?
[20:47] <slangasek> hallyn: sure there is, lucid has 7.4.15ubuntu1
[20:47] <hallyn> oh, sweet
[20:47] <hallyn> thanks :)
[20:47] <slangasek> hallyn: but you're supposed to declare the versioned build-dependency on 7.0.50~ all the same
[20:47] <hallyn> I'll just use >= 7.0.50~
[20:47]  * slangasek nods
[20:47] <hallyn> slangasek, oh, ok
[20:47] <hallyn> thanks
[20:48] <hallyn> yay, no warnings :)
[20:51] <slangasek> SpamapS: cmake-using libs that are multiarched in precise: alure apiextractor cuneiform generatorrunner gtk2-engines-oxygen kvirc libdbusmenu-qt libechonest libgooglepinyin... and a few others :)
[20:52] <SpamapS> slangasek: what should be the starting point for multiarching a package then?
[20:53] <slangasek> SpamapS: http://wiki.debian.org/Multiarch/Implementation
[20:53] <slangasek> currently it has no advice about cmake
[20:53] <slangasek> that could be fixed :)
[21:02] <ScottK> SpamapS: If you're looking at cmake, you might want to talk with debfx as I believe he's worked on it some before.
[21:03] <bjsnider> if you declare the versioned build-dep then it breaks the build because of a lack of a new enough version of debhelper, even though it will work anyway
[21:03] <bjsnider> so then you have to make an adjustment just for lucid
[21:03] <slangasek> SpamapS, ScottK: OdyX seems to have done a bit of this as wel
[21:03] <slangasek> well
[21:04] <slangasek> bjsnider: no, it *won't* work anyway
[21:04] <ScottK> slangasek: Yes.  Him too.
[21:04] <slangasek> it's a versioned build-dependency because you need that version of debhelper for the build to succeed correctly
[21:05] <slangasek> right, now how do I trigger gnome-terminal to see the new libfreetype
[21:09] <broder> PSA: http://lintian.ubuntuwire.org/ is now live, thanks to some help from ajmitch. i'll be sending mail shortly, but feedback on what i can do to make it more useful for you would be appreciated
[21:10] <ajmitch> \o/ :)
[21:11] <kenvandine> dupondje, papyon uploaded for {lucid,maverick,natty,onerick}-proposed
[21:13] <dupondje> kenvandine: cool
[21:13] <bjsnider> slangasek, what i mean is if you use dh_make right now it will version depend debhelper to >= 8, but i think it would still work with >= 7.0.50
[21:14] <lousygarua> SpamapS, thanks for the reply, i will have a look on autoscan
[21:15] <lousygarua> SpamapS, or 'at autoscan', i don't know english
[21:18] <slangasek> bjsnider: I haven't looked at dh_make's output recently, so I can't speak to that.
[21:18] <slangasek> oho, so it's not a libfreetype issue at all
[21:18] <slangasek> well, maybe that's why people aren't yelling at me
[21:18] <bjsnider> ran it a few days ago on oneiric
[21:26] <dupondje> kenvandine: but still some people seem to have issues even with the patch :(
[21:27] <kenvandine> saw that... no idea
[21:27] <kenvandine> i confirmed it failed before the update, and worked with the update on each release
[21:27] <kenvandine> at least for me
[21:28] <infinity> slangasek: Oh?  Local issue?  Cataracts perhaps?
[21:28] <kenvandine> dupondje, perhaps they didn't make sure telepathy-butterfly restarted
[21:28] <slangasek> infinity: well, I know that it's not a freetype issue, because downgrading freetype didn't help :)
[21:29] <slangasek> infinity: but it may be a font regression somewhere... so hard to tell given that there's no straightforward way to map a font name to a file AFAIK
[21:29] <slangasek> I was using monospace 9pt though, which is not the default
[21:29] <slangasek> so others' mileage likely varies
[21:29] <infinity> slangasek: Fiddle with font sizes.
[21:30] <slangasek> I don't want it bigger, I just want it !ugly
[21:30] <slangasek> DejaVu Sans Mono seems better
[21:30] <infinity> slangasek: I had awful visual issues with Ubuntu Mono at my preferred size, turns out they just need better kerning at some point sizes.
[21:30] <SpamapS> slangasek: don't fall into the same trap I did.. where my monitor was just in analog mode accidentally. ;)
[21:30] <dupondje> kenvandine: could be, but I talked to upstream, and they prepared some additional patch now ...
[21:30] <infinity> slangasek: (I switched back to Lucida, I think?  I can never remember what's what anymore)
[21:30] <slangasek> infinity: I wasn't even using Ubuntu Mono; switching to Ubuntu Mono is also an improvement
[21:30] <slangasek> SpamapS: LVDS
[21:31] <slangasek> and only VGA output on the laptop, so it has to be analog for the external monitor :-P
[21:32] <slangasek> anyway, I can read again, so moving on
[21:33] <slangasek> chrisccoulson: I see that ubufox is being disabled for me on upgrade; is there a procedure to make sure that gets updated in a timely manner?
[21:34] <chrisccoulson> slangasek, which version? i thought that was already fixed...
[21:34] <chrisccoulson> micahg ^^ (may affect oneiric too)
[21:35] <micahg> ugh, we'll I'm still 6 hours out at least from publishing natty+oneiric, so if you've got a fix...
[21:35] <chrisccoulson> micahg, have you tested a straight 7.0.1 -> 8.0 upgrade yet?
[21:35] <micahg> not yet
[21:35] <chrisccoulson> slangasek, where is ubufox installed for you?
[21:36] <dupondje> kenvandine: uploaded a .deb in the bugreport with the improved patch. Lets see if it fixes the issue for them.
[21:36] <chrisccoulson> (in /usr/lib/firefox-addons/extensions, or somewhere in /usr/share/mozilla/extensions)?
[21:36] <chrisccoulson> and was that the only extension which got disabled?
[21:37] <broder> Laney: looks like (debian's) udd is already importing (debian) lintian logs. think you could look into importing ubuntu's as well?
[21:38] <slangasek> chrisccoulson: xul-ext-ubufox 1.0.1-0ubuntu1, /usr/lib/firefox-addons/extensions/ubufox@ubuntu.com ?
[21:39] <slangasek> chrisccoulson: it also wants to disable "Global Menu Bar integration"
[21:39] <chrisccoulson> g'ah, ffs
[21:39] <chrisccoulson> i hate this stupid feature
[21:39] <chrisccoulson> thanks for letting me know though :)
[21:39] <slangasek> y/w :)
[21:39] <slangasek> want a bug report for any of this?
[21:39] <chrisccoulson> micahg, you'll need to hold fire on the oneiric and natty upgrades then
[21:40] <micahg> chrisccoulson: aye
[21:40] <chrisccoulson> it sucks that they changed the behaviour of this feature the week before UDS
[21:40] <chrisccoulson> i'm not particularly happy about that
[21:42] <chrisccoulson> slangasek, is extensions.autoDisableScopes set to "11" in about:config?
[21:45] <slangasek> chrisccoulson: yes
[21:45] <chrisccoulson> slangasek, thanks
[21:47] <slangasek> chrisccoulson: and apparently firefox throws up a prompt in a random tab asking me if I want to enable ubufox, prompting me to restart if I say yes
[21:48] <chrisccoulson> slangasek, yeah, i was hoping i'd managed to disable this mis-feature for our extensions
[21:48]  * slangasek nods
[21:49]  * SpamapS waits for the massive mysql test suite to finish
[21:50] <slangasek> broder: so one thing I'd like lintian.u.c to give us is a report of packages that use dpkg-maintscript-helper in preinst without pre-depending on dpkg (>= fwibble)
[21:51] <slangasek> I suspect there isn't currently a lintian check for this
[21:52] <broder> slangasek: that sounds like a good place to start :)
[21:52] <slangasek> broder: you mean creating the lintian check?
[21:53] <broder> slangasek: yeah. i believe that lintian upstream can accept checks that only run in an ubuntu context. and if not, patching it into our package seems reasonable (might want to check with bdrung - i know he's done a lot of work on lintian)
[21:53] <micahg> yes, lintian now has a concept of profiles with Ubuntu having one
[21:53] <broder> but lintian.uw.o does do per-tag reports (e.g. http://lintian.ubuntuwire.org/tags/binary-compiled-with-profiling-enabled.html)
[21:53] <slangasek> broder: right - well, you asked for feedback about things you can do to make it more useful, so I was proposing one ;)
[21:54] <broder> haha, ok :-P
[21:55] <broder> right now i'm using our lintian source package, and only modifying it to adjust the templates. i'd like to keep it that way, and in fact i'll probably just push the templating changes into our package
[21:55]  * slangasek nods
[21:56] <broder> but i'll see what i can do
[21:56] <bdrung> broder: nthykier did a lot of work on lintian. we have a ubuntu profile, where we can add or remove checks
[21:57] <slangasek> broder: thanks :)
[21:59] <broder> slangasek: by the way, if i said "caps lock" and "plymouth logo splash" in the same sentence, i'd get laughed at, right?
[21:59] <slangasek> broder: why would you get laughed at?
[21:59] <broder> is it expected to wokr?
[21:59] <slangasek> I would think so
[22:00] <broder> hmm...i wonder if my theme is broken or something
[22:00] <slangasek> I'm not sure why the theme should even affect it
[22:00] <slangasek> mind you, I may be showing my naivete again where consoles are concerned
[22:00] <slangasek> but I thought capslock happens at a lower level than anything plymouth touches
[22:01] <broder> possible. i had filed it away with "arrow keys" as being sufficiently high-level concepts that plymouth didn't care about them, but i'll take another look :)
[22:03] <broder> aha. the caps lock works, but the caps lock light does not
[22:03]  * broder sighs
[22:07] <slangasek> heh
[22:08] <broder> hmm, that actually seems to be generally true for non-X ttys
[22:36] <slangasek> SpamapS: fwiw, libmysqlclient is one of two packages blocking me from being able to cross-build
[22:36] <slangasek> SpamapS: ... cross-build qt4 in a multiarch env :)
[22:36] <infinity> And the other?
[22:37] <slangasek> libpopt
[22:37] <slangasek> I may finish that one off this afternoon
[22:37]  * infinity wonders why libbz2 still isn't multiarched...
[22:37] <slangasek> it is in Debian
[22:37] <slangasek> have we not merged that?
[22:37] <infinity> Oh, we might have for precise.  This laptop's still oneiric.
[22:37] <slangasek> yeah
[22:37] <infinity> In which case, yay.
[22:38] <slangasek> was gonna say, thought I merged that earlier
[22:38] <slangasek> so that means the only package blocking a cross-grade is libapt ;D
[22:39] <angelo_> Good evening to all!
[22:39]  * slangasek waves
[22:39] <angelo_> I'm new in ubuntu development (not in development in general). I'm trying to get a patch accepted, can anyoune help me?
[22:41] <slangasek> angelo_: certainly.  where are you stuck?
[22:41]  * infinity looks at the topic.
[22:41] <infinity> slangasek: This might be my job today. :P
[22:41] <slangasek> :)
[22:41] <angelo_> I filed the bug number 881695, made a patch, made a branch of the package and made a merge proposal
[22:41] <SpamapS> slangasek: I'll try to take a look at it ASAP.. still running through the test build of 5.5.17.
[22:41] <infinity> angelo_: Let me have a look.
[22:41] <slangasek> SpamapS: ok :)
[22:41] <SpamapS> slangasek: should not be too complicated even w/ cmake
[22:42] <slangasek> SpamapS: it shouldn't, but it could be :)
[22:42] <angelo_> I'm really intrested became an ubuntu contributor, I'll be really proud!
[22:42] <SpamapS> the libmysqlclient bits of the package are actually quite straightforward. Its all the other stuff that is a bit bonkers. :-P
[22:42] <slangasek> heh
[22:43] <SpamapS> @pilot in
[22:43] <SpamapS> time to do my duty :)
[22:45] <broder> that should get us enough characters to support 2 patch pilots :)
[22:45] <slangasek> grabbing a bit more.. last month's release is yesterday's news ;)
[22:53] <slangasek> SpamapS: btw, please run this command against the mysql svn repo: svn propset mergeWithUpstream 1 debian
[22:55] <angelo-c> infinity: any news?
[22:55] <Beret> should apparmor related issues go in the apparmor project or the app in which they occur?
[22:55] <infinity> angelo-c: I'm digging to see if your patch just trades unportable code for unportable code.
[22:56] <SpamapS> slangasek: ok, what does that do?
[22:56] <slangasek> Beret: if it relates to an existing apparmor profile, then to the package which ships the profile; otherwise apparmor itself as a starting point
[22:56] <infinity> angelo-c: I have a sneaking suspicion that the second argument to ioctl() is prototyped differently on every arch.
[22:56] <slangasek> SpamapS: it's a property to set on the directory which tells svn-buildpackage how the svn repo relates to the upstream source
[22:57] <slangasek> so that I can build with 'svn-buildpackage'
[22:57] <Beret> Nov  8 16:53:58 courage kernel: [ 1065.398974] type=1400 audit(1320792838.439:23): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/telepathy-*" name="/etc/apt/apt.conf.d/" pid=2969 comm="telepathy-butte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[22:57] <Beret> looks like I should send to the package there in that case
[22:57] <SpamapS> slangasek: AHHH I was wondering why svn-buildpackage didn't work. :)
[22:58]  * slangasek grins
[22:58] <infinity> angelo-c: As for the second half of your patch.  Does this need ESD to work correctly, or is that just a personal preference?  I realise the current state of sound on Linux is messy, but I'm not sure making it messier is the answer. ;)
[22:58] <micahg> Beret: telepathy-mission-control-5 most likely
[22:58] <Beret> micahg, OK, thanks
[22:59] <angelo-c> infinity: could be possible, the patch works for sure in x86-64, how I may help you in finding confirmation? I read the padsp source code and there the ioctl has an unsigned int as a second argument
[22:59]  * micahg wonders why Microsoft wants to see one's apt configuration
[22:59] <Beret> micahg, apt and /etc/default/apport
[23:00] <infinity> angelo-c: If using a uint seems to be common practice, I suppose I can live with that.  I was actually walking headers to see if I could find opposite examples.
[23:00] <infinity> angelo-c: But if padsp fails, people would/should notice. :P
[23:00] <Beret> micahg, http://pastebin.ubuntu.com/732560/
[23:00] <angelo-c> infinity: xoscope was written for esd and pulseaudio is a drop in replacement for esd. The fallback mechanism was to use raw /dev/dsp, but it's not present in the latest releases of ubuntu
[23:01] <micahg> Beret: idk, file the bug and tag apparmor
[23:01] <angelo-c> infinity: the problem is that with the esd support disabled at compile time the software simply doesn't work!
[23:01] <Beret> micahg, idk?
[23:01] <micahg> Beret: I don't know
[23:01] <Beret> ah got it
[23:01] <infinity> angelo-c: Obviously, you've spent more time on this than I ever care to. ;)
[23:01] <slangasek> "pulseaudio is a drop-in replacement for esd" - really?  I wasn't aware there was any protocol compatibility
[23:01] <infinity> angelo-c: I'll take your word for it, and close my eyes and "la la la" over 17 sound thingees on my system that all seem to do remarkably similar things. ;)
[23:02] <angelo-c> welll, yes, I'm using the software in previous releases of ubuntu because I'm passionate about electronics and cannot afford an oscilloscope!
[23:03] <ion> pulseaudi 2209  ion   45u  unix 0x0000000000000000      0t0   12723 /tmp/.esd-1000/socket
[23:03] <infinity> angelo-c: Though, it's worth noting that on my system, the only thing that depends on libesd0 is mplayer.  Not a rousing recommendation for it being a sane solution.
[23:03] <slangasek> ion: oh, quite - neato
[23:03] <ion> /usr/lib/pulse-1.0/modules/libprotocol-esound.so
[23:03] <infinity> Anyhow...
[23:04] <angelo-c> infinity: I personally tested the patch, and for me it works. I think that from an audio point of view, there is no problem, because it is simply a client. Pulseaudio recongnise the client as it was a really pulseaudio software written for!
[23:04] <infinity> angelo-c: Care to update your branch with a debian/changelog and such?  I'm doing nothing here but reviewing, I'd rather you get the credit for the upload when I sponsor it.
[23:05] <infinity> angelo-c: And were you hoping to target this same fix at oneiric (that brings us to more red tape and fun), or happy with getting it fixed in precise?
[23:07] <Chipzz> angelo-c: don't know if anyone mentioned this already, but as an aside: most ppl prefer patches in unified diff format. so create patches with diff -u in the future ;)
[23:07] <infinity> Chipzz: He made a merge proposal.
[23:07] <infinity> Chipzz: Seems reasonable enough to me.
[23:07] <Chipzz> infinity: there's also a patch attached to the bug
[23:07] <Chipzz> https://launchpadlibrarian.net/84216243/uiioctl.patch
[23:08] <infinity> Chipzz: Yes, the MP came after the patch.
[23:08] <infinity> Chipzz: As in, you're preaching to the choir. :P
[23:08] <infinity> (Also, as a side note, unless a patch is literally unreadable, I find complaining about how people help fix software to be pretty offputting)
[23:08] <angelo-c> ok ok, sorry, i'm confused! I think I messed up something
[23:08] <ion> You can convert patches to -u format with filterdiff.
[23:08] <infinity> (Side, side note, I hate LP merge proposals, but I don't care)
[23:09] <infinity> angelo-c: You didn't mess anything up. ;)
[23:09] <ion> filterdiff -v --format-unified foo.patch
[23:09] <ion> --format=unified
[23:09] <angelo-c> so, the best is to make a unified diff or a merge proposal? In the doubt I made both!
[23:09] <StevenK> infinity: You prefer Github PRs? Which mostly look like LP's MPs anyway?
[23:10] <Chipzz> infinity: I wasn't complaining. but I have seen it happen multiple times that ppl submit a patch in normal format and get told to resubmit in unified format.
[23:10] <infinity> StevenK: I just prefere patches, usually.  At least, for Debian packages.
[23:10] <angelo-c> for the sake of completeness, from the pulseaudio website: Make sure to load the module-protocol-esound-unix PulseAudio module for optimal support for ESOUND clients. Since this is the default you shouldn't need to change anything.
[23:10] <angelo-c> the module is default also on ubuntu
[23:11] <infinity> angelo-c: Yep, yep.  From your explanations (and a quick gander at the padsp source), your patch seems sane to me.
[23:11] <infinity> Well, as sane as software scopes can be.
[23:11] <infinity> I applaud your frugality. :)
[23:11] <angelo-c> infinity: Yeah! big news!
[23:11] <Chipzz> angelo-c: I think in general (although taste differs, like you can see from infinity's response) ppl prefer branches
[23:12] <Chipzz> (easier to merge)
[23:12] <chrisccoulson> slangasek, any chance you could send me the extensions.sqlite from your firefox profile? i'm having a really hard time trying to recreate this :(
[23:12] <angelo-c> Chippzz: it was my tought also
[23:12] <ion> Oh, filterdiff doesn’t support the default diff format.
[23:13] <angelo-c> so, I have to update debian/changelog and push my branch, ok?
[23:13] <slangasek> chrisccoulson: emailed
[23:13] <infinity> ion: Well, without the original source, converting a diff to a udiff would be impossible.
[23:13] <infinity> ion: It's CSI-style enhancement.
[23:13] <chrisccoulson> slangasek, thanks
[23:13] <infinity> angelo-c: Ideally, yes.  "dch -i", make sure the version number is sane, target it at precise.
[23:14] <Chipzz> angelo-c: and wrt to -u format, in my experience I've seen lots of ppl (including project maintainers) say that they find unified diffs easier to read. It's not wrong per se, more like a "generally preferred" format
[23:14] <infinity> angelo-c: Or if you were hoping to get this fix into oneiric, we need to talk more about process there. ;)
[23:14] <angelo-c> infinity: wait a minute
[23:15] <infinity> Chipzz: Yeah, I won't disagree that unified diffs are easier to read.  I just tend to be "the guy" who gets annoyed when "your format is wrong" seems to be the first feedback to a contribution. :P
[23:16] <Chipzz> infinity: I wasn't trying to bash the guy, rather give some advice on what is considered "normal" by most ppl. hence the smiley after my first sentence
[23:16] <ion> infinity: The only thing https://launchpadlibrarian.net/84216243/uiioctl.patch seems to lack is a filename, and diff -r seems to include them, too. If you had filenames, i guess you could convert to -u format.
[23:16] <infinity> ion: Filenames and the original source, yeah.
[23:17] <infinity> ion: But filterdiff can work magic without the original source, which is generally its fancypants usecase.
[23:17]  * slangasek snags the multiarch patch for popt from the Debian BTS, yaay suihkulokki
[23:17] <broder> infinity: i think we need more of "those guys"
[23:17] <ion> Does patch crap itself if given a unified diff without context lines? One would think it would still work as well as the default-format contextless diff.
[23:18] <infinity> angelo-c: I'm going to run off for a quick smoke and a drink.  I'll check in with you in a few minutes.
[23:18] <infinity> ion: Try it?  It tends to get right annoyed if you break unified format even a little.
[23:20] <infinity> ion: But I see what you're driving at.  You could make a contextless unified diff from a classic diff.  Of course, the only point would be to turn <> into -+ and make the line position marker more human-readable.  Doesn't seem like a worthwhile exercise. ;)
[23:20] <ion> infinity: diff -U 0 generates unified diffs without context and patch accepts them fine.
[23:22] <ion> Definitely not worthwhile, i was just thinking of what’s possible hypothetically. :-)
[23:22] <Chipzz> ion: well it's not the contect that's annoying in unified diffs IMO
[23:22] <leex> hi
[23:23] <Chipzz> ion: the "location" (line number) tends to be a bigger problem in practice
[23:23] <Chipzz> (if unified diffs cause problems at all)
[23:23] <broder> Chipzz: honestly, i think the normal diff format was perfectly clear in this particular case :)
[23:23]  * slangasek gratuitously cross-builds libpopt, to test its coinstallability before uploading
[23:24] <leex> why do the decnet packages fuck up my mac addresses? resulting in the situation that both my machines at home have the hwaddr aa:00:04:00:0a:04
[23:24] <angelo-c> infinity: ok, i pushed the patc with changelog!
[23:24] <angelo-c> wooow!
[23:25] <Chipzz> broder: in this case yes. but I was trying to point out in a polite matter that if he wanted to submit patches in the future (be it ubuntu or anywhere else) using unified diff is usually a better idea
[23:26] <angelo-c> infinity: can you summirize what I have to do to make patch right for inclusion also in oneiric?
[23:27] <angelo-c> ok, summarizing, using of merge proposal is discouraged, better is a unified diff, ok?
[23:27] <broder> angelo-c: i don't think i would say that. i think the conclusion is unified diff over normal diff
[23:27] <slangasek> leex: you're unlikely to find any decnet support here
[23:27] <broder> but if you're more comfortable with merge proposals, then that's fine - you should use those
[23:27] <slangasek> ... or anywhere except with the upstream author of the software in question
[23:28] <Chipzz> 00:11 < Chipzz> angelo-c: I think in general (although taste differs, like you can see from infinity's response) ppl prefer branches
[23:28] <infinity> angelo-c: No, merge proposals are perfectly fine.
[23:28] <slangasek> SpamapS: popt done.  you're up :P
[23:28] <infinity> angelo-c: The take-home from our side conversation here is "there's no incorrect way to contribute".
[23:29] <leex> slangasek: yeah, i figured it out: http://sourceforge.net/apps/mediawiki/linux-decnet/index.php?title=FAQ4 and rmmod e1000e and modprobing it helped me, but i will never have decnet installed again and I guess this bug should be dealt with
[23:29] <Chipzz> infinity: outside the ubuntu project, I've seen ppl ask to resubmit patches in unified format
[23:29] <slangasek> leex: why in the world did you install it in the first place?
[23:29] <angelo-c> ok, I really like branches and merge proposal, they are very clear form the starting point. If you know where is the source you have to modify, you are on track. For me, it has a very clear workflow
[23:30] <slangasek> do you actually have a network running decnet that you can connect to?
[23:30] <infinity> Chipzz: Yes, it's not a problem unique to us.  It annoys me everywhere. :P
[23:30] <Chipzz> angelo-c: as for most ppl with experience with DVCS's :)
[23:31] <Chipzz> infinity: the point of my initial sentence was not to blow him off, but to avoid him getting blown off in the future.
[23:31] <infinity> Chipzz: I know, I know. :P
[23:31] <SpamapS> sys_vars.collation_database_func         [ pass ]    255
[23:32] <SpamapS> slangasek: still running tests.. 3 hours later.. :-P I need a new hard drive I think
[23:32] <angelo-c> Chipzz: in a previous work the DVCS was simulated with html email sent with outlook!
[23:32] <slangasek> SpamapS: :)
[23:32]  * SpamapS needs to finish writing that script that runs a build in a RAM disk on an EC2 m2.xlarge
[23:32] <leex> slangasek: i did not install it. it came as a dependency or while upgrading to 11.10. otherwise I wouldn't be here an flaming ;)
[23:32] <infinity> angelo-c: So, you might want to have a quick read at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[23:32] <Chipzz> angelo-c: sounds painfull :)
[23:32] <infinity> angelo-c: If you want to see this fix in oneiric, there's a bit of process we need to follow.
[23:32] <SpamapS> $0.50 for a 5 minute build of MySQL is probably worth it. :)
[23:32] <broder> SpamapS: ha! i want that script :)
[23:32] <infinity> angelo-c: (I'll be uploading the precise fix in a second, though)
[23:33] <Chipzz> leex: flaming here about bugs tends to be rather unproductive :P
[23:33] <SpamapS> broder: I actually may just do it in a juju charm.. :)
[23:33] <angelo-c> infinity: thank you for the link, I'm reading greedily
[23:33] <leex> Chipzz: i guess it was ffmpeg (websearch)
[23:33] <SpamapS> with a t1.micro playing the part of persistence.. when the build finishes I'll just rsync the build artifacts and set the m2.xlarge to die 5 minutes before Amazon charges me another $0.50
[23:34] <slangasek> leex: which package was a dependency, precisely?
[23:34] <Chipzz> leex: uh? how does ffmpeg set your mac address? ^^
[23:35] <leex> slangasek: Chipzz http://www.fantaghost.com/2010/06/eth0-mac-address-fixed-on-aa0004000a04/
[23:35] <leex> will research it, but I didn't install the decnet packages. they are some kind of dependency for something, this blog post says ffmpeg
[23:36] <slangasek> leex: that doesn't tell me what package was installed on your system
[23:36] <angelo-c> infinity: it was really a big load! Is really late, I think I can update the bug as in point 2 tomorrow evening.
[23:36] <leex> sorry slangasek libdnet and i guess libdnet-dev
[23:36] <leex> slangasek: let me check again
[23:37] <angelo-c> infinity: another question
[23:37] <infinity> angelo-c: Sure, no problem.  I'm merging and uploading for precise right now, so you can point to that in your update to the bug if/when you target it for an SRU.
[23:38] <leex> slangasek: dnet-common, libdnet, libroar1, xtrans-dev
[23:38] <infinity> angelo-c: Oh, one last thing.  Can you explain the esdrecord change?
[23:38] <Chipzz> why in the name of ** does ffmpeg depend on decnet? ^^ :)
[23:39] <leex> Chipzz: now you do it too ;)
[23:39] <infinity> angelo-c: (I'll also be converting this to a patch in debian/patches, perhaps something for you to look at after I've uploaded and see how that works)
[23:39] <Chipzz> leex: what? :)
[23:40] <leex> the flaming part
[23:40] <Chipzz> I didn't realise that was considered flaming :P
[23:41] <angelo-c> infinity: for the esdrecord, the software works more reliable if the soundcard microphone is used in recording mode (as you are singing at singstar in front of your tv!), but this option is configurable at runtime via the software gui. This is only a default to facilitate new users
[23:42] <leex> Chipzz: hmm aptitude show ffmpeg doesnt mention it
[23:42] <slangasek> leex: have you filed a bug against the dnprogs package?
[23:42] <leex> slangasek: shall I?
[23:42] <slangasek> you should
[23:42] <slangasek> then I can mark it critical
[23:42] <leex> slangasek: here: https://launchpad.net/ubuntu/+bugs
[23:42] <slangasek> I've found the brokenness in dnet-common
[23:43] <slangasek> leex: 'ubuntu-bug dnet-common'
[23:43] <leex> slangasek: but I am not sure which package pulls it in
[23:43] <slangasek> leex: you don't need to worry about that part
[23:43] <angelo-c> infinty: the question: the esd support on oneiric is broken as I stated in the bug report (https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/864071 pulseaudio crashed with SIGABRT)
[23:45] <angelo-c> infinity: working package was released some time ago in oneiric-proposed. My patch doesn't work if this package was not installed. Can you see problems with this?
[23:45] <leex> slangasek: so I created an account, will post it in a second
[23:45] <jasox> Does anyone what should i do to solve this on Launchpad "Keys pending validation", I tried to register openPGP 5 days ago. :S
[23:45] <infinity> angelo-c: Looks like there's a fix for that in oneiric-proposed.  Can you test it and leave feedback on the bug?
[23:45] <infinity> angelo-c: The SRU team likes to see feedback. ;)
[23:46] <infinity> angelo-c: Oh, wait.  Nevermind.
[23:46] <infinity> angelo-c: It's already made it to oneiric-updates.
[23:46] <infinity> angelo-c: And no, no problems with your patch requiring a fixed package in updates.
[23:46] <slangasek> jasox: I have never seen such an error message before and I'm not sure what you mean by "register openPGP".  What is it that you're trying to do?
[23:47] <angelo-c> infinity: ok, you hit my concern
[23:47] <leex> slangasek: nice, didn't know there is a tool for that ;)
[23:48] <slangasek> leex: when you have the bug filed, please post the number here
[23:48] <leex> slangasek: I will
[23:49] <slangasek> infinity: when you have a half hour you would prefer to spend sputtering in disgust, you should look at the dnet-common package
[23:49] <jasox> slangasek, I mean on this http://imageshack.us/photo/my-images/31/screenshotat20111109004.png/, sorry for my bad english
[23:49] <angelo-c> inifinity: ok, so tomorrow I'll begin to make the bug report compliant
[23:50] <infinity> slangasek: Gee, you sure know how to sell it.
[23:50] <slangasek> jasox: ok.  I don't remember for sure, but my guess is that Launchpad wants to verify the key change by email
[23:50] <slangasek> jasox: so it's probably trying to contact you at the email address that's listed as the primary for your launchpad account?
[23:51] <slangasek> jasox: also, #launchpad is a better place to ask for launchpad support
[23:51] <jasox> slangasek, thanks bro
[23:51] <angelo-c> jasox: well yes, you have to decript the email message sent to your mail folder to activate the key, I made it some days ago!
[23:51] <jasox> angelo-c, i didn't get any mail :S
[23:52] <leex> slangasek: https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/887825
[23:53] <angelo-c> jasox: for, it was delivered in seconds, have you a typo in yuor mail address?
[23:54] <angelo-c> jasox: in the same page there is a comprehensive guide
[23:55] <leex> slangasek: thanks for taking care of it ;) and sorry if I was a bit huffy
[23:56] <slangasek> leex: you're well within your rights to be; it's ridiculous that this package got this far
[23:58] <angelo-c> bye guys, I'm really tired, really honored to chat with you, thank you for your support!
[23:58] <leex> slangasek: have had 3 fuck ups since my upgrade, i'm just not used to run into trouble since i left gentoo
[23:58] <slangasek> leex: can you please attach /etc/decnet.conf from your system to the bug report?
[23:58] <slangasek> (if you still have it)
[23:59] <leex> slangasek: sorry purged the package
[23:59] <slangasek> ok, no worries
[23:59] <slangasek> will try to reproduce it here