[00:32] <bdmurray> @pilot out
[01:41] <chilicuil> hi, I'm trying to add a patch to package without a patch system, what should I do?, add a patch system? (quilt) or modify the upstream files?
[01:46] <mdeslaur_> chilicuil: if it's for a stable release, modify the files. If it's for the dev release, it depends. If some files are already modified, please modify the files. If no files are already modified outside of the debian directory, then yeah, use quilt ie: source format 3.0
[01:46] <mdeslaur_> chilicuil: what package?
[01:47] <chilicuil> mdeslaur_: rcconf it only have 1 change, but it was made on /debian so, no patch system was necessary
[01:48] <chilicuil> mdeslaur_: and it's to go to the dev release and then if possible request sru for quantal / precise
[01:49] <mdeslaur_> if it's in the debian directory, then your problem is solved, no patch system necessary
[01:50] <chilicuil> mdeslaur_: the change I'm going to do is on upstream files, but then AFAIK no other changes where made to upstream files.., so I suppose I'll go with the quilt format
[01:52] <mdeslaur_> chilicuil: actually, looks like it's a native package, so you're better off just changing the files
[01:52] <chilicuil> mdeslaur_: ohh, how did u know it was a native package?, I'm gonna change just the files
[01:53] <mdeslaur_> it only has a single source tarball, and the version number doesn't have a '-' in it
[01:53] <mdeslaur_> is 2.5ubuntu1 instead of something like 2.5-0ubuntu1
[01:54] <chilicuil> I'll remember that, thanks for your time
[02:45]  * achiang pokes infinity during non-work hours re: valgrind :)
[03:06] <scientes> what happened to #debian-multiarch?
[03:07] <micahg> scientes: you mean #multiarch on OFTC?
[03:19] <scientes> micahg, yep, i just got it wrong, my bad
[06:34] <pitti> Good morning
[06:35] <pitti> tkamppeter_: no, cups-pk-helper doesn't sound like something which should be seeded; it should be a dependency of all packages that talk to it, such as gnome-control-center and/or s-c-p (if that uses it)
[06:35] <pitti> ah, what seb128 said
[08:02] <dholbach> good morning
[08:02] <mitya57> guten morgen dholbach
[08:02] <dholbach> hey mitya57
[08:03] <dholbach> mitya57, did you see that Russian get lots of translations updates in the packaging guide? :)
[08:04] <mitya57> wow, it's 61%!
[08:04] <didrocks> hey dholbach!
[08:04] <dholbach> mitya57, exactly :)
[08:04] <dholbach> salut didrocks :)
[08:06] <mitya57> dholbach: can you please investigate what happens with http://developer.ubuntu.com/packaging/es/singlehtml/_static/translations.js?
[08:06] <mitya57> it is installed by the package, I've just verified
[08:07] <dholbach> mitya57, will do
[08:07] <mitya57> thanks
[08:08] <mitya57> btw:
[08:08] <mitya57> -rw-r--r-- 1 root root 357 Дек  7 17:05 /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
[08:08] <mitya57> $ dpkg-query -S /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
[08:08] <mitya57> ubuntu-packaging-guide-html-es: /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
[09:36] <pitti> apw: how annoying -- our tests find crashes in the kernel!
[09:41] <apw> pitti, heh nice
[09:41] <pitti> apw: I filed bug 1089818 with a minimal CLI test case
[09:41] <pitti> fortunately this works in kvm, so no need to crash my workstation all the time
[09:42] <pitti> apw: I attached a screenshot of the oops, but unfortuantely it cuts off the upper end (and as it's a hard crash there is no Shift+PageUp)
[09:42] <pitti> is there a trick to see the full one? like configuring the console to be bigger or so?
[09:42] <apw> yeah... thats too normal
[09:42] <apw> you used to be able to go to a higher resolution, but not so much now i think
[09:43] <pitti> yeah, those days with real svga modes
[10:11] <Sweetshark> doko, pitti: fyi, I enabled the libmerged configury and there seem to be no issues. I havent tried if is speeds things up on slow hardware, but it does save ~8MB in package size for libreoffice-core and up to 150MB on libreoffice-dbg (unless something else essential changed between alpha/beta and quantal/raring there)
[10:16] <pitti> \o/
[10:28] <apw> pitti, on this luks bug, as it reproduces in KVM you ought to be able to configure a serial console and get the full dump i recon
[10:45] <chrisccoulson> where does python get its search paths from when you don't import site.py (ie, with -S)?
[10:53] <chrisccoulson> nm, figured it out
[11:25] <tkamppeter> pitti, hi
[11:27] <bdrung_> dholbach: please don't forget to unsubscribe the sponsors team
[11:27] <Laney> how do I find out the UUID whoopsie is using?
[11:28] <ev> Laney: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
[11:28] <Laney> ev: that doesn't exist on this system
[11:28] <ev> Laney: then it's the sha512 sum of your mac address
[11:29] <Laney> ah ok
[11:32] <Laney> hm, nothing showing
[11:32] <Laney> I was hoping whoopsie could tell me itself to reduce the chance of me calculating it differently
[11:33] <Laney> I suppose there is probably some lag after submission
[11:34] <ev> Laney: lag?
[11:35] <Laney> before it would show up on errors.u.c - time to be retraced and such?
[11:35] <xnox> Laney: did you just submit your first ever crash from that machine?
[11:35] <Laney> yeah
[11:38] <ev> Laney: it doesn't retrace every crash. All your reports should be instantly available off errors.ubuntu.com/user/$your_id
[11:38] <ev> the whoopsie binary doesn't print out the identifier it users (yet - feel free to file a bug against the upstream project for that)
[11:39] <Laney> ev: Is there a log file that shows whether submissions were successfully made?
[11:39] <ev> Laney: do make sure you're not including a newline in whatever you're feeding into sha512sum
[11:39] <Laney> oh, yeah, that could be it
[11:40] <ev> Laney: a successful submission will result in a .uploaded file being written to /var/crash
[11:40] <Laney> OK good, I see two of those there
[11:42] <Laney> Still can't get the UUID right, but the presence of those files reassures me somewhat
[11:42] <Laney> context is that I enabled core dumps on the nexus 7 and want to see if they are making it up to errors.u.c correctly
[11:43] <ev> Laney: do you have an eth0 device?
[11:43] <Laney> no, just wlan0
[11:44] <ev> hm, it should still use that
[11:45] <ev> it only avoids the loopback device
[11:46] <ev> Laney: so as a quick workaround, you could build whoopsie from source with a printf("ident: %s\n", whoopsie_identifier); on line 895
[11:46] <ev> then make and sudo LD_LIBRARY_PATH=src CRASH_DB_URL=https://daisy.ubuntu.com ./src/whoopsie -f
[11:47] <ev> err line 895 in src/whoopsie.c
[11:47] <Laney> ev: http://paste.ubuntu.com/1429511/ - that's how I'm getting the UUID
[11:47] <Laney> let me try that
[11:47] <ev> ah, that wont work
[11:48] <ev> err nevermind. It should do
[11:52] <Laney> yeah that's the same one whoopsie tells me it gets
[11:52] <Laney> hmm
[13:22] <pitti> ev: reviewed https://code.launchpad.net/~ev/daisy/optional_s3/+merge/139532
[13:32] <ev> pitti: thanks; I'll fix those :)
[13:54] <bdrung_> tumbleweed: can we get #1088565 fixed in Debian testing?
[13:57] <tumbleweed> bdrung_: yeah that was on my radar somewhere...
[13:58] <bdrung_> tumbleweed: do you know what causes that crash?
[14:05] <pitti> tseliot: ah, the u-d-common autopkgtest fails, it seems bcmwl-kernel-source has lost its Modaliases: header; I'm looking into this
[14:05] <tseliot> pitti: oh, I hadn't noticed
[14:06] <pitti> tseliot: yeah, and the debdiff doesn't show an obvious bug
[14:06] <pitti> tseliot: but thanks to having tests :)
[14:06] <tseliot> pitti: yes, it's great to have them :)
[14:20] <tumbleweed> bdrung_: well "Not permitted to upload directly to raring; try raring-proposed instead." is kind of self explanatory
[14:20] <tumbleweed> as to python-keyring and dbus, NAFC
[14:27] <tseliot> pitti: it seems that they have removed struct pci_device_id wl_id_table[] from wl_linux.c
[14:27] <apachelogger> tkamppeter: is there a way to set a custom printer test page at runtime?
[14:27] <pitti> tseliot: or rather, replaced it with { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
[14:27] <pitti> which is quite pointless
[14:28] <tseliot> pitti: right
[14:28] <pitti> I'm keeping notes in bug 1089943 FYI
[14:29] <pitti> so if that effing module itself doesn't know which devices it can talk to, how is userspace supposed to know?
[14:29] <pitti> thanks broadcom. not.
[14:30] <tseliot> pitti: heh, right...
[14:35] <tseliot> pitti: here's the output of modinfo: http://paste.ubuntu.com/1429785/
[14:36] <tseliot> pitti: we should probably use that as the alias
[14:36] <pitti> tseliot: ok, so I guess I'll drop the parsing script, and just add a static alias for vendor == broadcom and class == network
[14:36] <tseliot> pitti: right
[14:36] <pitti> tseliot: that's too wide, though; we don't want it to match on all vendors
[14:37] <pitti> tseliot: thanks
[14:37] <tseliot> pitti: thanks to you
[14:38] <pitti> hmm, I wonder if that's actually right
[14:38] <pitti> unfortunately my mini 10 is away for the week
[14:38] <pitti> seb128: you still have your mini 10, right?
[14:40] <seb128> pitti, I do
[14:40] <seb128> pitti, do you need anything tested on it?
[14:40] <pitti> seb128: yes, if you could
[14:40] <seb128> pitti, sure can
[14:40] <seb128> tell me
[14:40] <pitti> seb128: I need the output of "ubuntu-drivers debug" on that thing
[14:40] <seb128> what ubuntu version?
[14:40] <pitti> seb128: or, if it's running precise, run jockey and give me the log
[14:41] <pitti> seb128: doesn't matter
[14:41] <pitti> seb128: I'm just interested in the vendor/product/device class/device subclass of the broadcom wifi
[14:41] <seb128> ok, let me boot it, I'm unsure what version is on it, I use it as a testbox mainly nowadays so that keeps changing :p
[14:41] <pitti> seb128: or, regardless of the ubuntu version: cat /sys/class/net/*/device/uevent
[14:42] <pitti> seb128: ^ that'll work everywhere and is enough
[14:42] <ScottK> lamont: Can haz postfix 2.9.5?  Raring or experimental as you prefer.
[14:45] <seb128> pitti, http://paste.ubuntu.com/1429801/
[14:45] <seb128> pitti, that's the cat output
[14:45] <pitti> hah!
[14:45] <pitti> tseliot: ^ so current wl is broken
[14:46] <pitti> tseliot: as it only matches on sc80, while a real card uses sc00
[14:46] <tseliot> pitti: oh, we should report that to broadcom then
[14:46] <pitti> oh, ignore me
[14:47] <pitti> seb128: weird, that doesn't look like a broadcom card
[14:47] <tseliot> false positive?
[14:47] <pitti> vendor 10EC
[14:47] <pitti> DRIVER=r8169
[14:47] <tseliot> oh
[14:47] <pitti> seb128: is that not using the bcmwl driver then?
[14:47] <pitti> seb128: my mini 10 has a broadcom wifi chip
[14:48] <seb128> pitti, it is, but I think that's a stock install of precise without the driver enabled (wifi seems to not be working)
[14:48] <seb128> pitti, let me run jockey
[14:48] <smoser> slangasek, bug 1070345 failed verification, what is the path to getting that fixed in proposed?
[14:49] <smoser> i upload a 0.6.3-0ubuntu1.3 (previous was 1.2) ?
[14:54] <seb128> tseliot, pitti: http://paste.ubuntu.com/1429819/
[14:54] <seb128> better
[14:55] <pitti> seb128: ah, très bien, merci pour ton aide!
[14:55] <pitti> "ta aide"
[14:55] <seb128> pitti, de rien !
[14:55] <seb128> "ton aide"
[14:56] <pitti> aide c'est masculine?
[14:56] <pitti> bah
[14:56] <pitti> seb128: ISTR "ton aide", then twiched because that looks feminine
[14:56] <tseliot> :)
[14:56] <pitti> tseliot: anyway, that alias looks right
[14:56] <seb128> pitti, it is féminin
[14:57] <tseliot> pitti: the one from modinfo?
[14:57] <pitti> tseliot: from http://paste.ubuntu.com/1429819/
[14:57] <pitti> tseliot: no, the one from modinfo is definitvely broken
[14:57] <pitti> tseliot: as it matches far too liberally, i. e. on _any_ network card
[14:57] <tseliot> pitti: ok
[14:58] <pitti> tseliot: I'll upload "pci:v000014E4d*sv*sd*bc02sc80i*", that should do
[14:59] <tseliot> pitti: right, thanks
[14:59] <tseliot> pitti: also, if you can reject my upload from precise-proposed I can integrate your change
[15:00] <pitti> tseliot: oh, then I'll add the package name, too (this was only necessary for jockey)
[15:00] <tseliot> ah, good
[15:00] <pitti> actually, I don't think so, but I'll add it anyway
[15:27] <smoser> looking for an answer...
[15:28] <smoser> i uploaded cloud-init 0.6.3-0ubuntu1.2 to precise-proposed, got accepted. bug 1070345 failed verification.
[15:29] <smoser> is it ok to upload to -proposed a fix? do i need to open a new bug ? or just re-reference that in changelog.
[15:29] <cjwatson> upload incremented version to -proposed, use -v<version in -updates or failing that in release pocket> when generating source package, just re-reference the same bug
[15:35] <pitti> tseliot: oh, and rejected your bcmwl precise upload
[15:35] <tseliot> pitti: thanks again
[15:40] <cyphermox> who looks at SRUs today?
[16:04] <tkamppeter> pitti, hi
[16:05] <pitti> hey tkamppeter
[16:06] <tkamppeter> pitti, it is about CUPS in Quantal. It crashes for me like once in two days, not related to jobs.
[16:07] <tkamppeter> pitti, it seems to be caused by the forward port of the CUPS Broadcasting/Browsing. If I remove the mega patch CUPS gets stable.
[16:07] <tkamppeter> pitti, I have tried to fix it but with the fix applied CUPS gets stuck instead of crashing.
[16:08] <lamont> ScottK: I'll toss it at sid, if that works for you?  prolly this weekend, unless there's a pressing need...
[16:08] <tkamppeter> pitti, this is even worse as if CUPS crashes, Upstart restarts it and so for most users there is no problem.
[16:09] <ScottK> lamont: This weekend is fine.
[16:09] <ScottK> Thanks.
[16:09] <tkamppeter> pitti, as the forward port is intended to be removed in Raring I am thinking about not to try to fix the crash but simply to suppress the Apport pop-up, then users will not perceive it and Quantal will work well for them.
[16:09] <tkamppeter> pitti, how can I suppress the Apport pop-ups for CUPS.
[16:10] <pitti> tkamppeter: well, we certainly don't want to suppress all crashes, just this one
[16:10] <tkamppeter> pitti, is there a way to do so?
[16:11] <pitti> tkamppeter: not that easy to completely avoid the popup
[16:34] <tkamppeter> pitti, any suggestion what to do?
[16:34] <pitti> tkamppeter: sorry, busy with the testing hackfest
[16:34] <pitti> tkamppeter: not immediately, I'm afraid; I need to think about this
[16:35] <tkamppeter> pitti, I do not need a solution urgently today, but it would be great if I could make a CUPS SRU to stop user complaints about this problem. So think about it and tell me in the next days.
[16:36] <pitti> tkamppeter: do you already know where the crash happens in the code?
[16:37] <tkamppeter> pitti, yes, there are bug reports with an appropriate backtrace. Unfortunately, trhe actual crash happens somewhere in Avahi/D-Bus and not in CUPS itself.
[16:38] <tkamppeter> pitti, it is an Avahi threaded poll.
[16:44] <pitti> xnox: did you notice the upstart autopkgtest failure? it fails a test, and has some stuff on stderr
[16:45] <xnox> pitti: yes, bug 1089159
[16:45] <pitti> ah, thanks
[16:45]  * pitti subscribes
[16:46] <xnox> pitti: basically want to consult with jodh about it, but didn't get around to doing so yet.
[16:46] <tkamppeter> pitti, see bug 1086019
[16:49] <cjwatson> bdmurray,StevenK: uh, I'm not sure I buy bug 1085844.  subprocess.Popen honours PATH
[16:50] <cjwatson> it doesn't make sense that dpkg would need to be invoked with its full path there
[16:51] <cjwatson> if it does, it seems to me that something else must be wrong which might cause other failures, and it would be better to find that than play incorrect whack-a-mole adding full paths to things (which is often a problematic route later)
[17:00] <christoffer> Does launchpad have any Jenkins or Hudson running that will automatically run full test suite on new commits?
[17:01] <christoffer> runt unit tests for python code that is
[17:01] <christoffer> *run
[17:06] <cjwatson> christoffer: probably better asked on #launchpad
[17:06] <christoffer> ok
[17:06] <christoffer> thanks cjwatson
[17:10] <tkamppeter> pitti, I have added a comment to bug 1086019.
[17:16] <pitti> barry, doko: /usr/bin/python2.7-config now being a shell script instead of a python script breaks waf (and thus e. g. the samba4 build); in Debian it is still a python script, so we'll need to introduce deltas
[17:17] <pitti> barry, doko: was that intended; will that be changed in Debian as well, so that the patches can be forwarded?
[17:17] <barry> pitti: doko changed that, i'm not sure why
[17:18] <barry> pitti: how does it break?
[17:19] <doko> barry, to run it for a cross build
[17:19] <pitti> barry: waf tries to call $PYTHON /usr/bin/python2.7-config
[17:19] <pitti> which now fails wiht a syntax error
[17:19] <doko> neat
[17:19] <pitti> barry: see current samba4 build log
[17:19] <smoser> slangasek, i just uploaded another cloud-init to precise-proposed. i'd appreciate your review of the delta from cloud-init_0.6.3-0ubuntu1.2 to cloud-init_0.6.3-0ubuntu1.3
[17:20] <pitti> admittedly that looks wrong, but if upstream's python-config is python it might be harder to argue
[17:20] <doko> pitti, I was going to change that upstream
[17:20] <pitti> doko: ah, good
[17:21] <barry> pitti: awesome :)
[17:21] <pitti> -               for incstr in Utils.cmd_output("%s %s --includes" % (python, python_config)).strip().split():
[17:21] <pitti> +               for incstr in Utils.cmd_output("%s --includes" % python_config).strip().split():
[17:21] <pitti> that ought to do
[17:22] <barry> doko: well, you might not be able to change that in upstream 2.7 or 3.3 stable releases
[17:23] <doko> barry, I know ...
[17:23] <doko> pitti, which package needs the fixing?
[17:23] <pitti> doko: I'm currently doing samba4
[17:24] <pitti> I don't know which others break (i. e. how many use waf)
[17:24] <doko> pitti, ugh, do you know about more?
[17:24] <pitti> no, I don't
[17:25] <pitti> I just happened to see the samba4 FTBFS, which I didn't get with my slightly older raring yet
[17:26] <pitti> good night everyone
[17:27] <didrocks> good night pitti!
[17:28] <xnox> pitti: doko: well samba's waf is special - it's almost a fork / a build system based on top of waf.
[17:28] <pitti> ah, so hopefully it's not that widespread then :)
[17:28] <xnox> I wouldn't worry that much. Since by default waf executes *-config scripts as executables found on path, without making assumptions whether it's interpreted or not.
[17:30] <jelmer> pitti: patches to upstream this issue welcome :-)
[17:30] <jelmer> ehm, the *fix* for the issue
[17:32] <pitti> jelmer: yep, will send tomorrow; I need to run now
[17:32] <jelmer> pitti: thanks :)
[17:40] <blami_> hi, what's the ubuntu decision on merged /usr?
[17:41] <bobweaver> what ? blami
[17:41] <bobweaver> can you give us more details blami_
[17:42] <bobweaver> maybe I missed something sorry
[17:44] <superm1> bobweaver: probably http://fedoraproject.org/wiki/Features/UsrMove
[17:46] <blami_> bobweaver: I mean merging /bin /sbin /lib to /usr. It is considered 'upstream' and invented by Fedora :)
[17:46] <blami_> bobweaver: I found some resources on doing so in Ubuntu as well: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge
[17:46] <infinity> blami_: It's not really up to us, to be fair.  We've decided to be pragmatic and support mounting /usr from the initramfs, so that software that breaks due to the assumption that all systems are Fedora/RH will continue working.
[17:47] <infinity> Which reminds me, I should do something about that initramfs-tools bug upstream this month.
[17:49] <slangasek> smoser: a reupload to -proposed is the right thing to do; did you build your upload with -v$(last_version_in_updates)?
[17:49] <blami_> infinity: sounds reasonable to me ... so there's no need to fix possible conflicts in packages (dupes in symlinked /bin vs /usr/bin) like fedora did, right?
[17:52] <infinity> blami_: There's a need to do that at anyway (it's a bug regardless), but we're not merging them tomorrow or anything, no.
[17:52] <infinity> s/that at/that/
[17:53] <infinity> blami_: Err, that is, it's a bug if two packages ship a conflict on PATH.  Arguably not a bug if it's one package shipping migration symlinks, but those should all go away some day anywhow.
[18:01] <blami_> infinity: ah, thanks
[18:04] <smoser> slangasek, i did.
[18:04] <slangasek> smoser: perfect, thanks
[18:59] <dobey> why does do-release-upgrade on quantal tell me "No new releases found" still?
[18:59] <slangasek> because raring isn't released
[18:59] <slangasek> 'do-release-upgrade -d'?
[19:00] <dobey> oh right. update-manager -d wasn't working; just gave me normal q updates
[19:00] <dobey> thanks
[19:27] <SpamapS> slangasek: Note that I just commented on but 1089771
[19:28] <SpamapS> slangasek: I'm pretty sure that is not in network-manager.. I changed it to ifupdown
[19:28] <SpamapS> stgraber: ^^
[19:29] <stgraber> bug 1089771
[19:30] <slangasek> SpamapS: ok.  I knew it wasn't upstart, anyway :)
[19:30] <SpamapS> slangasek: yeah for sure not upstart's fault
[19:35] <slangasek> SpamapS: interestingly enough, only after we've gotten upstart in unstable have I gotten a report about dhclient writing to /var/lib; I would've thought someone would have noticed this in Ubuntu before now: Debian bug #694963
[19:39] <SpamapS> slangasek: separate var partitions are sooooo 1999
[19:39]  * slangasek shrugs :)
[22:46] <blami> why telepathy development package is called -devel and not -dev which seems to be sort of standard on .deb based systems?
[22:56] <RAOF> blami: Because it's a meta-package (ie: it doesn't contain anything itself, it just depends on other packages)
[22:56] <bdrung> blami: meta-telepathy is the source package. It seems that the package name is there since the beginning.
[22:57] <bdrung> blami: i suggest to ask dholbach when he comes online in around eight hours (UTC+1 buddy)
[22:57] <blami> RAOF: aha
[22:58] <RAOF> All of the *actual* development packages are named $FOO-dev, as is policy.
[22:58] <blami> bdrung: thanks, will do. Unfortunately I am UTC+1 too :>
[22:58] <RAOF> See also: gnome-devel
[22:59] <bdrung> blami: where do you come from?
[22:59] <blami> RAOF: I got the point, it does not hold any headers nor development tools, just pulls other -dev packages, right?
[22:59] <blami> bdrung: Praha PRG,CZ
[23:00] <bdrung> RAOF: I called packaging-dev packaging-dev even though it is a meta package
[23:00] <RAOF> blami: Right. And some development tools which aren't headers - telepathy-inspector, for example.
[23:00] <RAOF> bdrung: Which is not wrong either ☺
[23:09] <bdrung> blami: Praha is a nice city (i visited it 10 years ago)
[23:10] <bdrung> good night
[23:33] <infinity> Laney: What did you do to webkit to make it take twice as long to build?  Is it accidentally relinking during make install now?