[00:02] <stgraber> barry: another thing blowing up in the archive after the new python landed: https://bugs.launchpad.net/juju/+bug/1048864
[00:03] <stgraber> SpamapS: the same python fixes also caused https://bugs.launchpad.net/ubuntu/+bug/1048710
[00:04] <SpamapS> stgraber: ah, so perhaps this is really just a dupe and the python regression will be fixed?
[00:09] <stgraber> SpamapS: well, it's certainly a change of behaviour on the python side, now it's not completely clear whether it was intended or not and if it was, the doc is not reflecting that properly
[00:10] <SpamapS> stgraber: for now I'll leave it in a holding pattern until folks smarter than I figure it out.
[00:33] <slangasek> stgraber, SpamapS: should we be reverting this change to python if it's causing serious regressions?
[00:34] <slangasek> (revert, and wait for a better fix)
[00:35] <slangasek> doko: has anyone brought bug #1048710 to your attention?
[00:37] <doko> slangasek, stgraber: handled for now by barry. I'm not that sure that this exposes regressions in many existing builds. but quantal will see a resolution for all pythonx.y packages
[00:38] <slangasek> doko: ok
[00:38] <slangasek> doko: sorry, just assigned the bug to you; feel free to reassign it to barry, or just take the credit for the bugfix when it's closed ;)
[00:43] <stgraber> slangasek: so far juju and arkose are the only two that I'm aware of, it's apparently limited to pretty specific (weird) uses of argparse, so as it's, I think we can wait a few days. I worked around it in arkose for now (by removing the unnecessary type=str).
[00:44] <stgraber> I see it's being looked at/discussed upstream, so hopefully we'll know more soon
[03:35] <pitti> Good morning
[03:36] <pitti> infinity: ntfs-3g> sure, will do; should have checked myself, thanks for pointing out
[03:46] <RAOF> How good is errors.ubuntu.com at verifying that a precise-proposed package fixes a crasher bug that's not trivially reproducible?
[03:49] <lifeless> RAOF: perfect
[03:49] <lifeless> RAOF: it measures 'fixed' by 'not happening any more'
[03:50] <lifeless> RAOF: which of course depends on a) reproduction and b) users reporting it
[03:51] <pitti> infinity: done
[03:52] <pitti> infinity: I rejected my previous upload
[03:53] <lifeless> RAOF: the 'perfect' was sarcasm btw
[03:53] <lifeless> RAOF: we don't (AFAIK) have any machine learning in there yet
[03:53] <lifeless> RAOF: but it should be fairly goof
[03:54] <RAOF> lifeless: People seem to be reasonably good at randomly hitting the crash, so not finding any crashes in the proposed version would be a reasonable herustic
[03:54] <RAOF> *heurstic
[03:54] <lifeless> ...
[03:55] <lifeless> RAOF: heuristic ?
[03:56] <RAOF> Heh.
[03:57] <RAOF> I am *terrible* at spelling that.
[03:58] <lifeless> RAOF: you need a better engrish heuristic :)
[03:59] <RAOF> :P

[04:10] <infinity> pitti: Thanks.
[04:11] <infinity> RAOF: I kinda like "herustic".  Like a log cabin decorated with Master of the Universe toys.
[04:11] <infinity> Masters*
[04:38] <tjaalton> infinity, ScottK: looks like the noise on bug 956071 has been sorted out, the hotkey issue is a separate bug
[04:42] <infinity> tjaalton: Alright, that's good enough for me.
[04:43] <infinity> tjaalton: Released to updates.
[04:43] <infinity> tjaalton: Thanks for digging deeper.
[04:43] <tjaalton> infinity: excellent, thanks
[04:44] <tjaalton> I'll try to search for the hotkey bug, that must be reported
[04:53] <tjaalton> the hotkey bug is in gnome-settings-daemon, hitting the key toggles /org/gnome/settings-daemon/peripherals/touchpad/touchpad-enabled
[04:55] <tjaalton> bug 804109
[05:11] <toabctl> pitti, i'm trying to introspect a p2p dbus connection (for bgo #681093) but get a "TypeError: Argument 1 does not allow None as a value". See example script here: http://paste.ubuntu.com/1198008/
[05:11] <toabctl> pitti, the strange thing is, that "gdbus introspect ..." works well and there is the first parameter null
[05:13] <toabctl> pitti, see http://git.gnome.org/browse/glib/tree/gio/gdbus-tool.c#n1436
[05:24] <pitti> toabctl: answering in #python
[05:41] <pitti> RAOF: the incompatible fglrx keeps breaking the ubuntu-drivers-common test cases; I just checked, and that seems to be right
[05:41] <pitti> RAOF: do you know when we'll get a compatible fglrx?
[05:41] <RAOF> I do not, no.
[05:42] <pitti> ok; at least the tests do what they are supposed to do
[05:42] <RAOF> Sarvatt or tselliot are your best bets for that knowledge; tjaalton is also has a reasonable chance of knowing.
[05:45] <pitti> cyphermox: https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-network-manager/lastFailedBuild/ARCH=i386,label=albali/console -> is that perhaps a missing dependency?
[05:45] <pitti> cyphermox: (dnsmasq)
[05:57] <xnox> good morning =)
[06:06] <tjaalton> pitti, RAOF: my bet is on week 41 or 42..
[07:01] <dholbach> good morning
[07:36] <dholbach> tseliot, do you think you or somebody else could respond to https://twitter.com/marcosbarbosa/status/245228540952473602?
[07:37] <tseliot> dholbach: sure, we don't have an fglrx driver which support's Quantal's xserver ABI yet
[07:38] <dholbach> ok
[08:19] <pitti> jibel: in Jenkins, do we have tests that run under a full desktop session?
[08:20] <pitti> jibel: I have a work item to write UI related suspend/resume tests (indicator integration, inhibition by movie player, low battery, and so on)
[08:20] <pitti> jibel: but these would be full desktop integration tests
[08:24] <jibel> pitti, there are a few to test unity with autopilot. They run on hardware. For example https://jenkins.qa.ubuntu.com/job/dx-autopilot-run/label=00000000-0000-0000-0000-8C89A516023C/
[08:24] <pitti> jibel: ah, I was hoping for a VM (as on real hw it's rather brittle to set up auto-resume)
[08:25] <pitti> jibel: but that shouldn't stop me, I could stub out the actual suspend call somehow
[08:25] <pitti> jibel: I guess it would not be appropriate to stuff them into the daily image testing?
[08:26] <jibel> pitti, we could run them as post-install test
[08:26] <jibel> *tests
[08:26] <pitti> jibel: would that be appropriate for now, until we have real adt-like integration tests?
[08:26] <pitti> jibel: or should I rather try to use adt-*, and just depend on gnome-session etc. and run the stuff under xvfb?
[08:27] <pitti> ah, unity and xvfb might not be that friendly to each other, I fear
[08:27] <tkamppeter_> pitti, hi
[08:27] <pitti> hello tkamppeter_
[08:29] <tkamppeter_> I have some packages which are very close to Debian or even in sync, and they have recommends which we do not have in main, foomatic-db, see bug 1048982 and ghostscript, see bug 1048820
[08:30] <pitti> tkamppeter_: I thought we used foomatic-db-compressed?
[08:30] <jibel> pitti, my concern is that we can shoehorn the tests in the current daily image testing, but it will ported to utah soonish, which means porting the suspend/resume tests too.
[08:30] <jibel> pitti, I'll look to provision a testbed for adt with a full desktop environment
[08:30] <pitti> jibel: yeah, and they don't really fit into iso testing
[08:31] <pitti> jibel: so perhaps we should just wait for UTAH for this?
[08:31] <tkamppeter> Now for us these recommended packages are not really important, how to proceed without breaking sybcs and/or without getting extra delta.
[08:31] <jibel> pitti, maybe but I have no ETA, gema will know
[08:32] <pitti> tkamppeter: I don't understand bug 1048820
[08:32] <pitti> $ apt-cache show ghostscript|grep droid
[08:32] <pitti> $
[08:32] <pitti> ghostscript doesn't recommend fonts-droid
[08:32] <tkamppeter> pitti, we really use foomatic-db-compressed-ppds, but some automatic consistency checker seems to have found this stuff.
[08:33] <tkamppeter> pitti, can one perhaps demote the binary package foomatic-db? Or is it not possible as it is a build dependency for other packages in main?
[08:33] <pitti> tkamppeter: oh, I see -- it's libgs9-common which recommends it
[08:34] <pitti> tkamppeter: yep, see "reverse-depends -b foomatic-db" - b-deps of m2300w and ptouch-driver
[08:34] <tkamppeter> pitti, I did not set this, I even did not know that there is a package named fonts-droid. This probably comes from Debvian.
[08:34] <pitti> tkamppeter: right, so what the bug says -- either we drop it to a suggests, or use a font which we already install
[08:35] <pitti> I'm not that keen on adding YET another font to the default install
[08:35] <pitti> we have plenty already
[08:36] <tkamppeter> pitti, I do not have fonts-droid installed and I nver had problems with Ghostscript, so I would make a suggests out of fonts-droid.
[08:36] <pitti> tkamppeter: sounds fine
[08:37] <tkamppeter> pitti, problem is that we have another delta, as the Debian maintainer has probably some reasons to recommend it in a Debian environment.
[08:37] <pitti> tkamppeter: as for foomatic-db, perhaps m2300w etc. also build with -compressed as a b-dep somehow?
[08:38] <tkamppeter> pitti, problem is that m2300w and ptouch-driver ship Foomatic XML files and no corresponding PPDs, so the build process has to build the PPDs which needs foomatic-db.
[08:41] <pitti> tkamppeter: so you could also drop printer-driver-all recommends to suggests?
[08:42] <tkamppeter> pitti, I am investigating now whether the two driver packages really need foomatic-db to build ...
[08:42] <tkamppeter> pitti, main problem of foomatic-db is that it is synced with Debian.
[08:42] <pitti> tkamppeter: no, it's not -- 20120823-0ubuntu1 here ?
[08:43] <pitti> jibel: ok; let me play around with how much of a session I can get in xvfb and the adt env
[08:44] <tkamppeter> pitti, it is at least identical. Sometimes I update from OpenPrinting, sometimes OdyX. All in the debian/ directory is always the same.
[08:44] <pitti> tkamppeter: ah, so perhaps some syncs are in order to get us to identical versions?
[08:44] <pitti> tkamppeter: so ideally the foomatic-db build deps coudl be dropped
[08:45] <pitti> tkamppeter: if not, we coudl change the foomatic package in Debian to add the recommends only when you build for Debian, but not for Ubuntu
[08:56] <doko> pitti, is ibus-m17n wanted in main? you did add support for it in language-selector (but already in precise), and cjwatson seeded it in June
[08:57] <pitti> hm, not sure -- it fell out of main after lucid apparently
[08:59] <cjwatson> *shrug* I think I was just syncing up with something or other
[08:59] <pitti> why does that only pop up now, hmm; /me reads seed history
[08:59] <cjwatson> Probably with language-selector
[08:59] <pitti> ah
[08:59] <pitti> revno: 1738
[08:59] <pitti>   drop ibus-m17n, it's a very little used package and has far inferior input methods compared to pinyin; use pinyin with small db-android instead; per Aron Xu <happyaron@ubuntu.com>
[08:59] <pitti> timestamp: Fri 2010-08-20 14:33:14 +0200
[08:59] <cjwatson> Yeah, but l-s should match the seeds either way
[08:59] <pitti> so that's what caused it to drop out of main
[09:00] <cjwatson> r2051
[09:00] <pitti> we should drop it from l-s then?
[09:00] <cjwatson> I have no opinion on whether -m17n is any good or not, but if it isn't, it should be dropped from the seeds and l-s in tandem
[09:00] <pitti> ArneGoetje: hey Arne, how are you?
[09:00] <pitti> ArneGoetje: do you know of m17n is still relevant for anything?
[09:01] <pitti> cjwatson: yes, I agree
[09:01] <cjwatson> bug 753476
[09:01] <cjwatson> filed some months after r1738
[09:01] <pitti> ah, there we go
[09:01] <pitti> right, then I guess let's just promote it back?
[09:02] <pitti> . o O { yay for having history for everyting }
[09:03] <cjwatson> This is what it's for ...
[09:04] <pitti> doko: re-promoted then
[09:04] <doko> thanks!
[09:48] <mpt> ev, poppy-dev doesn't have the data point tooltips. Is that deliberate?
[09:49] <ev> mpt: try now
[09:50] <mpt> bueno
[09:50] <mpt> So, what was the spike yesterday?
[09:52] <ev> mpt: not sure yet - firefighting the django openid deployment. Will dig in a bit
[10:18] <jamespage> doko: ceph currently has some binaries which are in universe - rest-bench being one of them which has this dep
[10:49] <davmor2> pitti: I'm going to write a bug for the music player showing up in quantal as a usb driver what commands are you likely to want me to run to help you guys diagnose it?
[10:50] <davmor2> pitti: also I'm assuming the fix you added to precise got pulled in right?
[10:52] <davmor2> pitti: and would a comparison with what precise lists be useful?
[10:57] <doko> jamespage, I assume I'll just have to add rest-bench-dbg to Extra-Excludes
[10:57] <jamespage> doko, yes please - I really don't think the rest-bench packages need to go into main
[10:57] <jamespage> radosgw is another matter
[10:59] <xclaesse> any known bug that could cause gobject-introspection stuff to be commented out in generated Makefile ?
[11:00] <xclaesse> building tp-glib from source does not build .gir, wondering if that could be a bug in ubuntu quantal gobject-introspection package or something like that
[11:04] <bigjools> cjwatson: can I bug you for some help with a quantal upgrade please - it's left my machine in a bit of a state
[11:06] <pitti> davmor2: re (sorry, was at the phone)
[11:06] <pitti> davmor2: an useful piece of information/comparison would be "udevadm info --export-db", this will tell me whether the device was recongized as a player
[11:07] <xclaesse> bah forget my question above, found my error :)
[11:08] <cjwatson> bigjools: well, I may or may not know the answer, but sure
[11:08] <bigjools> cjwatson: ok, I'll just paste some stuff
[11:08] <davmor2> pitti: apparently AlanBell has a similar issue with his android phone too
[11:09] <bigjools> cjwatson: but first problem is that I have two X servers running on different vts
[11:10] <cjwatson> I know nothing of that
[11:10] <bigjools> cjwatson: then this http://pastebin.ubuntu.com/1198419/
[11:10] <cjwatson> bigjools: could you tar up /var/lib/dpkg and put it somewhere for me please?
[11:10] <bigjools> sure
[11:11] <cjwatson> probably not immediately worth debugging your X problem until your package database is in a remotely sane state
[11:11] <bigjools> yeah
[11:11] <cjwatson> but if it persists then you'll want somebody from the desktop team
[11:11] <bigjools> ok
[11:11] <bigjools> is U1 a suitable place for you to pick up files?
[11:12] <bigjools> ah I'll stick it on chinstrap
[11:12] <AlanBell> pitti: http://paste.ubuntu.com/1198424/
[11:12] <cjwatson> U1 would mean I'd have to figure out why my syncdaemon is busted
[11:12] <cjwatson> which I've been merrily ignoring
[11:12] <bigjools> heh
[11:12] <bigjools> I just thought that I'm not sure I can rely on mine in this state
[11:12] <sladen> I think somebody posted me a weblink from U1 recently that no longer required extranous sign-up
[11:15] <davmor2> pitti: udevadm stuff, quantal = http://paste.ubuntu.com/1198425/ and precise = http://paste.ubuntu.com/1198430/ and I just thought I'm not sure what package to write it against :(
[11:20] <ev> mpt: is there anything in the javascript console?
[11:20] <ev> errors, that is
[11:22] <mpt> ev, [12:20:31.651] SyntaxError: JSON.parse: unexpected character @ http://poppy-dev.local/static/js/yui/build/json-parse/json-parse-min.js:7
[11:23] <ev> mpt: does it change if you click on a bucket page and login first?
[11:24] <mpt> ev, there's no buckets to click on
[11:24] <cjwatson> bigjools: right, so this is basically http://lists.debian.org/debian-devel-announce/2012/03/msg00005.html
[11:24] <cjwatson> (that won't especially help immediately, just for background)
[11:24] <bigjools> ok, reading
[11:24] <cjwatson> bigjools: I suspect this won't work, but try 'sudo dpkg -P libao4'
[11:25] <bigjools> cjwatson: same dpkg error
[11:25] <cjwatson> OK, let's edit dpkg's brain
[11:25] <bigjools> \o/
[11:25] <bigjools> trepanning
[11:26] <cjwatson> bigjools: edit /var/lib/dpkg/status.  There are two paragraphs that start with "Package: libao4"; you want the one that also contains "Architecture: amd64".  Delete that paragraph.
[11:26] <bigjools> ok
[11:26] <cjwatson> (It should be "Status: deinstall ok config-files".
[11:26] <cjwatson> The old dpkg incorrectly left this in a half-arsed state on a previous upgrade.
[11:27] <bigjools> it's now an ex-paragraph
[11:27] <cjwatson> Now 'sudo dpkg --configure -a'
[11:28] <bigjools> doing stuff, but reporting dependency problems
[11:28] <cjwatson> Yeah, expected since you were probably interrupted mid-upgrade
[11:28] <bigjools> looks like it :(
[11:28] <cjwatson> But it'll do what it can to start with
[11:28] <cjwatson> Then 'sudo apt-get -f install'
[11:28] <bigjools> ok it's done
[11:28] <cjwatson> And after that I'd run 'sudo apt-get dist-upgrade'
[11:28] <bigjools> zoiks
[11:29] <bigjools> it wants to remove about 100 packages
[11:29] <cjwatson> pastebin?
[11:29] <mpt> ev, http://paste.ubuntu.com/1198449/
[11:30] <cjwatson> bigjools: Out of interest did you use update-manager to do this upgrade - that is, if update-manager happened to have been smart enough to detect this problem earlier, would it have helped?
[11:30] <bigjools> cjwatson: http://paste.ubuntu.com/1198460/
[11:30] <bigjools> I did use update manager yes
[11:30] <bigjools> and I suspect anything would have been better than this :)
[11:31] <bigjools> short of leaving it unbootable
[11:31] <cjwatson> Well, yeah, all I mean is we can't fix the bare apt-get dist-upgrade path so easily
[11:31] <cjwatson> But in principle we can beef up u-m to help people who use it
[11:32] <bigjools> so it wants to remove 238 in fact
[11:32] <cjwatson> So, that's entirely multiarch-related stuff; it could be caused by any one of those packages being out of sync between amd64 and i386, which is a standard multiarch problem while running development releases
[11:33] <cjwatson> If this were my system I would let it remove all of that and worry about putting google-earth-stable, skype, and wine1.4 (which are the application-level packages in there) back later
[11:33] <bigjools> yeah
[11:34] <cjwatson> Oh, with the exception of erlang-docbuilder which has genuinely been removed from quantal
[11:34] <bigjools> well, I hit the button, let's see how it goes :)
[11:35] <cjwatson> This systematic out-of-sync problem will be fixed once we start using -proposed to stage everything in a cycle or two
[11:35] <mpt> ev, if the Launchpad info is effectively just for styling the rows, have you considered displaying them unstyled quickly, and then applying the class= attributes when the Launchpad data arrives?
[11:35] <ev> mpt: yes, I've thought about it, but it requires fetching much of the same data twice
[11:35] <mpt> ev, you changed the error: Timestamp: 11/09/12 12:34:10
[11:35] <mpt> Error: SyntaxError: JSON.parse: unexpected end of data - Source File: http://poppy-dev.local/static/js/yui/build/json-parse/json-parse-min.js Line: 7
[11:35] <ev> hmm
[11:35] <ev> that shouldn't change
[11:35] <ev> but try logging in off a problem page
[11:35] <ev> clicking on a function link
[11:35] <ev> that's what I think I fixed
[11:36] <cjwatson> slangasek: ^- Do you know of a bug that corresponds to bigjools' multiarch upgrade disaster?  We should definitely do something about this in ubuntu-release-upgrader
[11:36] <mpt> ev, success
[11:36] <ev> yay
[11:36] <ev> tuples should suffer an awful death
[11:38] <ev> now to fix your javascript error
[11:42] <ev> mpt: does http://poppy-dev.local/api/1.0/instances-count/?format=json&limit=365 work?
[11:43] <davmor2> ev: that or just don't use them :P
[11:45] <mpt> ev, I'm not going to count parentheses, but it looks right
[11:45] <bigjools> cjwatson: ha, dist-upgrade shows 1988 packages to upgrade.  I am guessing my u-m bailed out very early :(
[11:45] <ev> weird
[11:45] <ev> davmor2: indeed :)
[11:45] <bigjools> cjwatson: the question is, will it have missed important upgrade steps I need to care about?
[11:46] <davmor2> ev: just use lists always see how much havoc that causes instead ;)
[11:47] <cjwatson> bigjools: probably not; I don't think there are many quirks in the precise-to-quantal upgrade as yet
[11:48] <bigjools> righto
[11:48] <cjwatson> bigjools: you might want to ensure that all the PPAs you care about are enabled at the end of the upgrade
[11:48] <bigjools> cjwatson: yeah, done that already, it's one of those automatic things you do after upgrades I guess
[11:49] <cyphermox> pitti, no, dnsmasq-base is pulled in... there is something else; perhaps ifblacklist_migrate.sh isn't doing what it should well enough so the connections never come up; that would explain dnsmasq not starting
[11:51]  * mpt winces at bug 947107
[12:00] <ev> mpt: I've narrowed it down to just happening in Firefox. I'll figure it out after lunch.
[12:09] <barry> doko via slangasek: are you looking at bug #1048710 or should i spend some time on that today?
[12:09] <doko> barry, please go ahead, you already started the upstream issue =)
[12:10] <barry> doko: k!
[12:14] <xnox> mpt: I did add a comment to it, after I did some minimal test. But still needs more time.
[12:47] <roaksoax> doko: lowering javascript-common to Suggests for lp #1020278
[12:47] <roaksoax> would be the fix, is that ok with you?
[13:01] <doko> roaksoax, sure, if it makes sense.
[13:03] <roaksoax> doko: /win 13
[13:03] <roaksoax> err soryr :)
[13:36] <doko> infinity, ogra_ : https://launchpadlibrarian.net/115081690/buildlog_ubuntu-quantal-armel.pdf2djvu_0.7.12-2ubuntu5_FAILEDTOBUILD.txt.gz ??
[13:42] <doko> cjwatson, cat is in the just rebuilt coreutils
[13:46] <cjwatson> doko: what?
[13:46] <cjwatson> Oh geez
[13:47] <doko> but wait, this the pdf2djvu was built on friday, before the upload
[13:47] <cjwatson> doko: Are you sure this isn't a toolchain regression?  I didn't touch cat at all
[13:47] <doko> no, if built on Friday, this was before the binutils and gcc uploads
[13:48] <doko> where does this message come from, kernel printf?
[13:49] <doko> running a 2.6.38 kernel
[13:50] <micahg> aren't some of the builders on precise?
[13:54] <dobey> hrmm, how close to latest 3.6-rc kernel is the current quantal kernel?
[13:54] <micahg> I think quantal is on 3.5.3
[13:55] <cjwatson> Good question; I can't find that text in eglibc, which is where I expected to find it
[13:55] <cjwatson> Oh, libgcc maybe?
[13:56] <dobey> micahg: do you know if 3.6-rc is packaged anywhere for precise?
[13:57]  * micahg just sees quantal in the mainline dir, kernel team would probably know more
[13:57] <cjwatson> doko: src/libgcc/config/arm/linux-atomic-64bit.c
[13:57] <cjwatson> in gcc-4.7
[13:58] <ogra_> lovely
[13:59]  * cjwatson neatly deflects blame
[13:59]  * highvoltage is an expert at deflecting blame
[13:59]  * highvoltage blames the education system for that
[14:00] <doko> cjwatson, ok, fsf 4.7.why do we see this only now?
[14:01] <doko> hmm, that's because we default to v5
[14:03] <ogra_> is it even worth to put time into armel at all ?
[14:04]  * ogra_ thinks we can count its lifetime in weeks anyway
[14:05] <cjwatson> Personally I like ports to die by explicit decision rather than by falling apart
[14:05] <ogra_> heh, true ... and fixing it will likely help debian ...
[14:06] <ogra_> though i wonder why we cant just take that decision instead of wasing time on it :)
[14:06] <SpamapS> barry: any word on that python argparse regression?
[14:06] <barry> SpamapS: not yet, but working on it
[14:07] <SpamapS> barry: ok. I have a slightly different failure case involving FileType.. but I think its basically the same problem.
[14:08] <barry> SpamapS: if you can boil it down, can you add it to the (launchpad) bug report and i'll at least check it?
[14:08] <SpamapS> barry: yeah I am doing that right now
[14:08] <barry> cool
[14:12] <SpamapS> barry: ok, test case posted to bug 1048710
[14:15] <slangasek> smoser: hi, did you see my pings over the weekend about testing the new mountall package in our iscsi cloud environment?
[14:15] <slangasek> (well, cloud-init)
[14:20] <smoser> slangasek, i mean to get to that today.
[14:20] <slangasek> smoser: ok :)
[14:22] <tkamppeter> pitti, I have eliminated the foomatic-db build dependencies in both m2300w and ptouch-driver.
[14:23] <pitti> tkamppeter: nice!
[14:23] <ev> mpt: fixed: http://poppy-dev.local/ops/instances/
[14:23] <ev> so yeah, 3,341 on the 7th. 1,651 on the 6th.
[14:24] <ev> for 12.10
[14:24] <mpt> \o/
[14:24] <mpt> 3341 what?
[14:25] <mpt> Oh, right, the blue line
[14:25] <mpt> So, that's the beta 1 release
[14:26] <mpt> but why would that cause a spike, if we're dividing by the number of machines anyway?
[14:26] <mpt> Maybe there's an influx of people trying previously-untested things?
[14:27] <ev> hm
[14:27] <xnox> mpt: is there a correlation between a spike with # of machines upgrading to quantal?
[14:27] <ev> lets see what the 90 day user count did that day
[14:27] <xnox> ;)
[14:28] <mpt> aha
[14:28] <mpt> I was thinking the division would remove that factor completely
[14:28] <mpt> but it will only completely remove it 90 days later
[14:28] <mpt> The first day, it removes only 1/90 of it
[14:29] <mpt> or does it
[14:29] <mpt> No, we're dividing by the 90-day total, not by the last-90-days average
[14:29] <mpt> hmmmm
[14:29] <ev> mpt: unique systems count for 12.10 was 20596 and 21612 for the 6th and 7th respectively
[14:30] <mpt> A 5% increase
[14:30] <mpt> tiny
[14:31] <smoser> slangasek, to clear my memory... even if i have the moutnal fix, i'll still need some hacks though, right?
[14:31] <mpt> ev, but you know what, the #1 error is in ubiquity. What happens to the error rate if you ignore just that error?
[14:31] <smoser> because i need /run to be mounted (and mountall emitted) before cloud-init runs.
[14:31] <mpt> I'm pretty sure it wasn't ubiquity yesterday, or the day before
[14:31] <smoser> ho. wait, no. that will happen in parallel with your branch.
[14:34] <ev> mpt: 551 and 565 for the 6th and 7th
[14:34] <mpt> So there's the spike explained. It's ubiquity.
[14:34] <xnox> =(
[14:35] <xnox> too many daily iso testers?!
[14:35] <ogra_> milestone testing :)
[14:35] <ogra_> *snap*
[14:36] <ev> I'm not so sure
[14:36] <ev> if you look at http://poppy-dev.local/bucket/?id=%2Fusr%2Flib%2Fubiquity%2Fbin%2Fubiquity%3AValueError%3Awatch_debconf_fd_helper%3Aprocess_input%3Await%3Acleanup%3Apreseed%3A%3Clambda%3E%3Acommand
[14:36] <ev> it's been pretty high for a few days
[14:37] <ev> since the 25th
[14:37] <ev> so surely that would make a longer spike
[14:37] <ogra_> hmm, somehow my .local domain is different from yours :P
[14:38] <mpt> xnox, not nearly as many daily iso testers as beta 1 testers, that's all.
[14:38] <ev> ogra_: :)
[14:38] <ogra_> but milestone testing usually starts somewhere on the weekend and only ends on next thu ...
[14:39] <xnox> ev: what if you exclude ubiquity? (this is fiddling with numbers now)
[14:39] <ev> xnox: exclude all ubiquity crashes?
[14:39] <xnox> yeah.
[14:41] <mpt> ev, the general increase in instances since the 23rd is (mostly) matched by an increase in error rate too, so I think that's just Feature and UI Freezes
[14:41] <xnox> ev: that ValueError was high since forever =) see my last merge proposal to ubiquity, hopefully it will fix that.
[14:41] <ev> yeah, could be
[14:41] <ev> xnox: excellent
[14:42] <ev> ugh, how did I break the date range selection *again*?
[14:42] <mpt> ev, while you're there, use <input type="date"> for the date fields :-)
[14:43] <xnox> ev: open a reverse port forward. There is a juju charm to do that using a cloud instance =)
[14:43] <mpt> oh, you already are
[14:43] <ev> I did
[14:43] <ev> yeah
[14:43] <mpt> I wonder why it isn't showing a calendar
[14:43] <ev> because Firefox is a pile of rusted bolts
[14:43] <doko> infinity, will you still merge clang and llvm-defaultgs?
[14:44] <ev> xnox: will do
[14:44] <ev> though it'd probably be more helpful to just deploy to canonistack
[14:44] <ev> so bdmurray can see trunk
[14:44] <ev> and whomever else wants to hack on this
[14:44] <xnox> true it can has public IP =)
[14:49] <slangasek> smoser: shouldn't need any hacks that I can recall
[14:50] <bdmurray> How can I reset my compiz / unity settings back to default?  I think some setting is causing compiz to crash and respawn repeatedly
[14:51] <ogra_> bdmurray, unity --reset ?
[14:51] <ogra_> (not sure that still exists)
[14:51] <bdmurray> ogra_: I think it does but wasn't sufficient
[15:01] <xnox> rumour has it --reset is broken
[15:01] <didrocks> t's removed from trunk btw
[15:02] <didrocks> yeah, it's useless since the gsettings migration
[15:12] <bdrung> what's the preferred way to ping an archive admin to accept a package in -proposed?
[15:13] <cjwatson> For preference, ping one of ~ubuntu-sru instead
[15:13] <cjwatson> (I don't know)
[15:14] <bdrung> cjwatson: ping. can you accept ncurses in oneiric-proposed?
[15:14] <bdrung> it in the queue for 10 days
[15:14] <bdrung> s/it/it's/
[15:15] <cjwatson> I suppose I asked for that, but I'd rather one of the more regular SRU folks did it
[15:15] <cjwatson> hm, though it's easy
[15:16] <bdrung> cjwatson: who belongs to the more regular SRU folks?
[15:16] <ogra_> ubuntu-sru ?
[15:16] <cjwatson> bdrung: done now
[15:17] <bdmurray> I think there is a daily schedule somewhere for the ubuntu-sru team
[15:17] <bdrung> ogra_: the question was, who of the nine ubuntu-sru members are the more active ones.
[15:18] <bdrung> cjwatson: thanks
[15:18] <ogra_> bdrung, indeed the one with the highest karma *g*
[15:19] <bdrung> ogra_: the karma just tell you how active someone is, but not how active in one specific team ;)
[15:19] <ogra_> details :P
[15:22] <bdmurray> bdrung: here it is https://wiki.ubuntu.com/SRUTeamProcess
[15:22] <bdrung> skaet added a section about publishing the uploaded packages just some weeks ago.
[15:23] <bdrung> bdmurray: thanks. that list appeared on https://wiki.ubuntu.com/StableReleaseUpdates too. rechecking wiki pages for updates sometimes help. ;)
[15:26] <doko> mvo, cjwatson: see bug #1048566, i386 only
[15:27] <cjwatson> doko: Thanks, I'll sort that out
[15:28] <doko> cjwatson, just curious, whats the reason for that?
[15:29] <cjwatson> Breaks: libhwloc0 in libc6, added with the following changelog entry:
[15:29] <cjwatson>   * Remove the /etc/ld.so.conf.d/i486-linux-gnu.conf conffile on upgrade on
[15:29] <cjwatson>     i386, since it's no longer shipped and we should give consistent results
[15:29] <cjwatson>     on upgrade and install; and add a Breaks on the three library packages
[15:29] <cjwatson>     in lucid that used this path.
[15:29] <cjwatson> But libhwloc5 Provides: libhwloc0
[15:29] <doko> ahh, ok
[15:29] <cjwatson> The fix is probably just to drop that Provides since nothing cares
[15:30] <cjwatson> Or possibly actually to version the Breaks in libc6
[15:30] <cjwatson> That might be nicer
[15:30] <doko> ok, I can do that,
[15:30] <doko> removing the provides
[15:30] <cjwatson> No, on reflection I'd rather version the Breaks
[15:30] <cjwatson> That's more correct anyway I feel
[15:30] <cjwatson> I'll just look up the right versions and such
[15:31] <doko> thanks
[15:43] <smoser> slangasek, lp:ubuntu/mountall installed into a quantal "ephemeral image", then the 'start networking' hack removed from cloud-init-nonet.
[15:43] <smoser> kern.log at http://paste.ubuntu.com/1198891/
[15:44] <micahg> @pilot in
[15:44] <smoser> virtual-fileysstems seems to have blocked until after cloud-init-nonet
[15:45]  * mlankhorst is having fun bisecting nfs rootfs failures ;s
[15:48] <barry> SpamapS: i have a proposed patch in the upstream tracker, but there is a semantic issue that needs clarification before i can apply it upstream.  if others on python-dev agree with my analysis, i'll get this into the upstream branches, and patch the ubuntu packages.
[15:50] <SpamapS> barry: \o/ thanks.. was not looking forward to working around it.
[16:10] <needhelp1>  Hello all, im helping to pull some data for Ubuntu Beta releases and have a very short survey up on google documents found here. https://docs.google.com/spreadsheet/viewform?formkey=dFdSTUgzREoyeFZNSWRHSjlXMGYteGc6MQ    Anyone interested please take the survey and feel free to share the link. The results will be published in two weeks to the public domain.
[16:20] <micahg> can someone please mark the following as WIP: https://code.launchpad.net/~alessandro-menti/ubuntu/precise/kile/fix-for-994498/+merge/118919 https://code.launchpad.net/~geoubuntu/ubuntu/precise/xmltv/1018756/+merge/118935
[16:36] <infinity> doko: Yeah, I should do the clang merge, despite FF.
[16:36] <doko> infinity, I'd like to start a test rebuild this week. so ...
[16:37] <micahg> infinity: there's an open FFe request on it
[16:38]  * micahg wonders if powerpc will catch up by the time the rebuild is  done :-/
[16:38] <infinity> doko: Almost nothing build-deps on clang, I don't see that as a blocker.
[16:39] <infinity> micahg: The rebuilds tend not to include PPC for capacity reasons.
[16:39] <micahg> infinity: I know, was making a point still :)
[16:40] <doko> infinity, but llvm-defaults ...
[16:40]  * micahg thinks PPC has been chugging for a week straight
[16:40] <infinity> doko: Oh, yeah, there's that.  I'll poke at it today.
[16:47] <micahg> stgraber: could you mark the MPs above for me please?
[16:49] <stgraber> micahg: sure
[16:49] <stgraber> micahg: done
[16:49] <micahg> stgraber: thanks
[16:49] <highvoltage> =/win last
[16:49] <micahg> cjwatson: can I leave Bug #433897 in your hands and unsubscribe sponsors?
[16:50] <cjwatson> micahg: Yes
[16:50] <micahg> cjwatson: thanks
[16:54] <micahg> rsalveti: since you're core-dev now, can I unsubscribe sponsors from Bug #1034734 and leave you to file any needed paperwork and/or upload?
[16:56] <rsalveti> micahg: sure, thanks
[16:56] <micahg> rsalveti: thanks
[17:46] <slangasek> smoser: virtual-filesystems blocked> interesting; will look
[17:46] <smoser> thanks. i should point out that that boot was with a kernel/initramfs from precise.
[17:47] <smoser> and that currently my iscis root seems busted in quantal using quantal initramfs and kenrel (i think open-iscsi changed somehow)
[17:47] <smoser> debugging that.
[17:47] <smoser> but i doubt kernel/initramfs affected you
[17:49] <adam_g> http://paste.ubuntu.com/1199108/ <- is this error obvious to anyone? the same package installs fine and dandy on quantal, but often borks on precise
[17:55] <cjwatson> adam_g: File collision between those two packages.  Either quantum-plugin-openvswitch-agent is supposed to be taking over a file from quantum-plugin-openvswitch in precise (in which case it needs a Replaces field and probably Breaks too; not Conflicts) or else this is an accident in which case remove the file from quantum-plugin-openvswitch-agent.
[17:55] <cjwatson> Since those two packages have the same version I suspect you're accidentally installing it in both.
[17:56] <infinity> Somewhat telling that it appears to be a directory in one of the packages.
[17:57] <infinity> When the path certainly implies that it should be a binary.
[17:57] <adam_g> cjwatson: the only reference to that file is in quantum-plugin-openvswitch-agent.install: bin/quantum-openvswitch-agent usr/bin. but at some point somehow, a directory is created @ /usr/bin/quantum-openvswitch-agent/
[17:57] <cjwatson> Point me to the whole source package and I'll have a look.
[17:58] <cjwatson> The error message suggests that the bogus directory is in quantum-plugin-openvswitch, not in quantum-plugin-openvswitch-agent.
[17:58] <cjwatson> So I doubt quantum-plugin-openvswitch-agent.install is relevant.
[17:59] <adam_g> wsure
[18:00] <trism> in the precise package quantum-plugin-openvswitch package: ./usr/bin/quantum-openvswitch-agent/quantum-openvswitch-agent but in quantum-plugin-openvswitch-agent it is in /usr/sbin/quantum-openvswitch-agent
[18:01] <adam_g> theres a packaging branch at lp:~openstack-ubuntu-testing/quantum/quantal-folsom-proposed and a src pkg @ https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing/+files/quantum_2012.2%2Bgit201209102130~precise-0ubuntu1.dsc
[18:01]  * cjwatson branches
[18:02] <infinity> bin/quantum-openvswitch-agent usr/bin/quantum-openvswitch-agent
[18:02] <infinity> From debian/quantum-plugin-openvswitch.install
[18:02] <cjwatson> Your source package does not match your branch
[18:02] <infinity> That's almost certainly not what you want.
[18:02] <cjwatson> The source package has the file infinity quotes
[18:03] <cjwatson> Or rather that line in it
[18:03] <cjwatson> The branch does not
[18:05] <adam_g> wow, thanks
[18:07] <adam_g> it was an issue of two packaging branches diverging on that one .install file, is all. thanks much
[18:13] <slangasek> smoser: can you get a mountall --verbose log from this?
[18:18] <smoser> slangasek, yeah.
[18:28] <smoser> slangasek, well, second attempt got http://paste.ubuntu.com/1199190/ to kern.log
[18:28] <smoser> (and apparent "working".)
[18:30] <smoser> mountall --verbose output seems to not get to my serial log when i do 'console=/dev/ttyS0' and '--verbose' added to the mountall job (exec mountall --verbose --daemon $force_fsck $fsck_fix)
[18:30] <slangasek> smoser: ah, this doesn't seem to include the output from mountall itself though :)  maybe capture that output to /run/mountall.log and capture that file?
[18:31] <smoser> is /run guaranteed mounted ?
[18:31] <slangasek> smoser: er... do you have an initramfs?
[18:31] <smoser> yes
[18:31] <smoser> so, yeah.
[18:31] <smoser> k.
[18:31] <slangasek> smoser: yep. alternatively, comment out the 'console output' and pick it up from /var/log/upstart/mountall.log after boot (upstart will buffer)
[18:34] <smoser> slangasek, so is this not a bug that 'console output' does not infact get to console= kenrel param ?
[18:34] <slangasek> smoser: probably
[18:36] <smoser> slangasek, well this stinks.
[18:37] <smoser> i can't make it fail like that original log i sent.
[18:37] <slangasek> \o/
[18:37] <slangasek> NOTABUG ;)
[18:37] <smoser> do you see anything in that log that would indicate i just did something wrong ?
[18:38] <smoser> i guess th emountall changes did make this more potentially racey
[18:38] <smoser> but previously it was always fail or pass
[18:39] <smoser> ok. well i think the thing to do here, as this seems to be "fixed" is to go on, assuming i made a mistake originally.
[18:40] <smoser> and see if i cant get more clean reproducing of it.
[18:43] <slangasek> smoser: I didn't see anything in the log that pointed to a problem; if you *can* reproduce it again, and only intermittently, I think it's probably a bug in my mountall code
[18:44] <slangasek> smoser: so... I would like to know if it's reproducible; maybe only reproducible with mountall --verbose disabled :/
[18:44] <smoser> nah. thats not it.
[18:44] <smoser> cause i can't reproduce it at all
[18:44] <slangasek> ok
[18:44] <smoser> but ther eis a bug in console output
[18:45] <smoser> upstart definitely stops writing to /dev/console at some point in boot
[18:45] <smoser> which makes collecting output like this difficult
[18:51] <doko> Laney, were you caring about mono, and could have a look at https://launchpad.net/ubuntu/quantal/+source/banshee-community-extensions/2.4.0-1ubuntu2 ?
[18:51] <doko> NBS issue
[18:51] <smoser> sbeattie, you have a minute? or jdstrand it seems like my http://paste.ubuntu.com/1199239/ isn't right.
[18:52] <smoser> as it results in dmesg like: http://paste.ubuntu.com/1199242/
[18:54] <micahg> why does pkgbinarymangler copy Enhances lines?
[18:55] <alexbligh1> what is the approved way to produce an autoconf/automake package that also builds on (e.g.) Lucid where there is no dh_autoreconf, assuming the products of autoreconfig are not in the source package?
[18:56] <micahg> alexbligh1: in archive or PPA?
[18:56] <alexbligh1> micahg, currently for me, but would like to be in universe (guacamole)
[18:56] <alexbligh1> (does not build on Lucid)
[18:57] <micahg> alexbligh1: unless you're pushing to the lucid main archive (-updates/-security), dh-autoreconf is in lucid-backports
[18:57] <alexbligh1> micahg, oh sorry, I want it to build without the user having to install dh-autoreconf etc. if possible.
[18:58] <micahg> alexbligh1: hrm?  it's a build time dependency
[18:58] <alexbligh1> what I'm asking is 'how did this used to work?'
[18:58] <alexbligh1> yeah I want to make it not a build time dependency :-)
[18:59] <tumbleweed> alexbligh1: why should the usres care about build time dependencies?
[18:59] <micahg> you can read the manpage to see what it does, but I don't see why it matters
[18:59] <tumbleweed> how it used to work involved a fair amount of pain (if you want to be able to clean up again)
[18:59] <doko> roaksoax, see component-mismatches again, now zui3 pops up recommending javascript-common ...
[18:59] <doko> yui3
[19:00] <sbeattie> smoser: hrm, not sure. what happens when you run the apparmor_parser on /etc/apparmor.d/usr.sbin.dhcpd directly (e.g. sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.dhcpd)?
[19:01] <Laney> doko: weird. hyperair: ^^^ ?
[19:01] <alexbligh1> tumbleweed, micahg hmmm, just trying to make it easy to build from source but maybe lucid-backports is the way to go. I am taking it that then 'dh --with autoreconf' will work without also having to use debhelper >= 8.0? (I had assumed these were liked)
[19:01] <alexbligh1> s/liked/linked/
[19:01] <tumbleweed> they aren't linked
[19:01] <smoser> sbeattie, it exits zero
[19:01] <doko> Laney, hyperair? I did make the rebuild because of the updated libtaglib-cil
[19:02] <roaksoax> doko: taking care of it now
[19:02] <alexbligh1> tumbleweed, fair enough, sounds like lucid-backports is the way to go then.
[19:02] <smoser> and
[19:02] <smoser> [  994.961021] type=1400 audit(1347390084.089:18): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/dhcpd" pid=666 comm="apparmor_parser
[19:03] <sbeattie> smoser: yep, that's cool, just making sure it didn't report an error
[19:03] <smoser> yeah.
[19:03] <smoser> ok so it seems maybe ijust *thought* it was complaining.
[19:03] <smoser> sbeattie, what do you think about  my selection of '#include' filename there?
[19:04] <smoser> is there a better conventional name than usr.sbin.dhcpd.d ?
[19:05] <sbeattie> smoser: I think the name itself is okay, was just trying to determine if there was a better location (subdir) for that directory
[19:06] <sbeattie> smoser: though I guess apache2.d is top level as well.
[19:07] <sbeattie> smoser: I guess you could just call it dhcpd.d based on the apache2.d precedent
[19:08] <smoser> that is what jdstrand suggested
[19:08] <smoser> but it seemed strange to me to have a 'usr.sbin.dhcp', local/usr.sbin.dhcp, and then just 'dhcpd.d'
[19:08] <smoser> but i'm good with that.
[19:08] <smoser> i'll test that it seems to do what i think it does. thanks.
[19:11] <sbeattie> smoser: yeah, that inconsistency bugs me a little, having them in the toplevel /etc/apparmor.d/ directory bugs me as well.
[19:17] <bdrung> cjwatson: ncurses still appears on https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
[19:28] <infinity> bdrung: Accepted.
[19:28] <infinity> bdrung: Looks like Colin ran the fancy "tell the bug about it" script, but forgot to actually accept.
[19:28] <infinity> cjwatson: ^
[19:29] <bdrung> infinity: thanks
[19:30] <smoser> stgraber, https://code.launchpad.net/~smoser/ubuntu/quantal/isc-dhcp/maas-lp1049177/+merge/123815 is my isc-dhcp changes.
[19:30] <stgraber> smoser: thanks
[19:35] <cjwatson> infinity: er, that's confusing.  I definitely typed the queue command ...
[19:35] <cjwatson> but I no longer have that terminal open.
[19:35] <infinity> cjwatson: Curious.
[19:35] <smoser> slangasek, so are you thinking you're going to upload mountall?
[19:35] <cjwatson> should probably make sru-accept do it all.
[19:36] <smoser> i'll give it a quick test here in lxc container too, which would be a nice fix.
[19:36] <infinity> cjwatson: And yeah, sru-accept should do it all.  Which would have the advantage of being able to remove the silliness about versions and bugs.
[19:36] <infinity> cjwatson: Since we could examine the .changes in the queue and pull those two things.
[19:36] <cjwatson> indeed.
[19:38] <infinity> And it could helpfully error the heck out if it finds multiple copies of $source in $queue.
[19:38] <infinity> I'd probably pay beer for that feature.
[19:38] <infinity> Good beer.
[19:38] <infinity> Fancy stuff, made by monks.
[19:38] <stgraber> smoser: I'm still in the middle of regression testing my next bridge-utils upload, but I think I'll have enough time left to start poking at isc-dhcp today (maybe even upload it if I'm lucky)
[19:44] <micahg> @pilot out
[19:47] <micahg> fabo: so the qemu-linaro stuff doesn't get lost, I unsubscribed sponsors since we can't upload yet, but you'll need to fill out the FFe paperwork since we're past feature freeze
[19:47] <micahg> fabo: and then subscribe ubuntu-release
[19:59] <Laney> doko: wtf, it built fine locally and then on the buildd when given back
[19:59]  * Laney plays the x-files theme
[19:59] <Laney> skew with banshee?
[20:01] <smoser> stgraber, i moved https://code.launchpad.net/~smoser/ubuntu/quantal/isc-dhcp/maas-lp1049177/+merge/123815 from ubuntu-devel to you
[20:02] <smoser> to avoid the chance that someone just thinks its easy andthey'll take it
[20:02] <stgraber> smoser: cool, thanks
[20:05] <stgraber> smoser: branch looks good, merged
[20:05] <doko> Laney, maybe, that was uploaded before
[21:00] <mlankhorst> cjwatson: can you remove nomodeset in recovery from grub-common? :-)
[21:04] <smoser> slangasek, more info in bug 1031065 on mountall fix
[21:06] <stgraber> mlankhorst: it's there on purpose
[21:07] <stgraber> mlankhorst: IIRC I even added a warning saying that the resume option won't quite work for these using kms and that a full reboot would be required in such case
[21:08] <mlankhorst> stgraber: yes and right now it will be even more harmful to keep the nomodeset since no driver really tests that path any more and we could always force a fallback to modesetting driver before vesa
[21:09] <stgraber> mlankhorst: maybe slangasek or cjwatson will remember better than I do, but I believe the problem was that on some systems you couldn't get to friendly-recovery unless you were in text mode
[21:10] <stgraber> mlankhorst: so it was decided that having friendly-recovery working was more important than having the resume boot function working
[21:11] <mlankhorst> well maybe drm could be taught to pick up on noaccel instead
[21:17] <cjwatson> mlankhorst: I've got an idea, how about the X team agree on this? :-)  It's there because bryceh and RAOF asked for it
[21:17] <cjwatson> Now admittedly that predates the modesetting driver, but still, sort it out among yourselves ;-)
[21:18] <stgraber> ;)
[21:19] <mlankhorst> oh should be easy then
[21:19] <mlankhorst> too tired, ill try tomorrow
[21:22] <cjwatson> it was two UDSes ago I think
[21:52] <dobey> anyone around who knows about langpacks and translations?
[21:54] <dobey> infinity: do you? :)
[21:59] <dobey> so upstream has translations included, which weren't before, and i want to make sure i'm doing the dh_translations and packaging correctly for something where the translations end up in the langpacks
[22:12] <hyperair> hmm it doesn't look like bce actually requires taglib-sharp.
[22:12] <hyperair> on the other hand, i broke the pc files in taglib-sharp
[22:13] <hyperair> ah hang on, -2 should be right
[22:13] <Laney> it does, but it's fixed
[22:13] <Laney> apart from armel
[22:13] <hyperair> weird
[22:13] <hyperair> looks like a mono bug.
[22:13] <hyperair> it says internal mono exception.
[22:14] <Laney> yes
[22:14] <hyperair> sorry, internal compiler error
[22:14] <hyperair> hmm
[22:16] <dobey> hi jbicha
[22:17] <jbicha> dobey: hi
[22:17] <hyperair> ah, bce doesn't really require new taglib, but banshee's .pc requires it.
[22:18] <hyperair> hence the builddep.
[22:18] <dobey> jbicha: did you see my new mail to ubuntu-doc today? wondering what you think of that
[22:18] <hyperair> doko: are you handling the rest of the taglib-sharp rebuilds?
[22:21] <dobey> hrmm, wonder if i should just upload this now as i have it, or wait for someone more knowledgeable about how langpacks/translations work in ubuntu to come along so i can bug them
[22:23] <jbicha> dobey: I +1'd the logo tweak if it'll land soon :)
[22:24] <dobey> jbicha: yeah. it's a new source package so will be a little bit more than a simple upload. but should have it uploaded in the morning. thanks
[22:25] <dobey> it is unfortunately past my EOD at this point, so i really need to go right now though. :(
[22:26] <jbicha> that's fine
[22:28] <hyperair> Laney: so now that we've gotten the gconf issues out of the way, i can has banshee FFe?
[22:28] <Laney> if you forward it to gconf upstream then I will upload it and then yes
[22:45] <doko> hyperair, Laney: I don't think there are any more
[22:45] <hyperair> doko: there aren't? okay then
[22:45] <doko> not according to http://people.canonical.com/~ubuntu-archive/nbs.html
[22:46] <hyperair> ok
[23:00] <hyperair> Laney: honestly this bug looks like it should be marked as high priority. could we just upload the patch while waiting for upstream to ack it?
[23:00] <hyperair> (i've forwarded it already)
[23:00] <Laney> i didn't ask for them to ack it
[23:01]  * hyperair doesn't want to see more duplicates of this bug report.
[23:01] <hyperair> ah
[23:01] <Laney> "if you forward it"
[23:01] <hyperair> okay i've forwarded it, so hurry up and upload it already. =D
[23:01] <Laney> i'll look at it tomorrow.
[23:01] <Laney> (or get someone else here to do it now)
[23:01] <hyperair> ...
[23:01]  * hyperair goes back to sleep
[23:01] <Laney> ajmitch is around :-)
[23:01]  * hyperair grumbles.
[23:02] <hyperair> i've got another half an hour of sleep to catch before i have to get to work
[23:02] <ajmitch> Laney: ajmitch is working in between commenting on irc :)
[23:02] <infinity> Laney: Where are you seeing armel/mono issues?
[23:03] <Laney> infinity: on the banshee-community-extensions build
[23:03] <Laney> hyperair: alright I'll do it now, just for you
[23:03] <infinity> Laney: I'd give good odds that rebuilding the sad packages on a machine with a precise kernel will work.
[23:03]  * infinity looks.
[23:03] <Laney> infinity: Did they not all get upgraded already?
[23:03] <Laney> going go to with 'no'
[23:03] <infinity> Laney: No.  I'm harassing people harder to get it done.
[23:05] <Laney> do we know which ones are good, then?
[23:05] <infinity> Laney: caph, iara, sigbin.
[23:05] <infinity> Laney: Retrying right now.
[23:05] <Laney> caph got it, so fingers crossed
[23:05] <infinity> Yes, that was intentional. :P
[23:06] <infinity> Laney: We do output uname at the top of the build logs, so no need to guess.
[23:07] <infinity> Laney: With either weird compiler confusion, or the lovely "this kernel is too old" message, checking the log for the kernel used and blaming natty if it's not 3.2.0 is always a good first step. :P
[23:07] <infinity> Laney: (But I really do hope they all get upgraded by the end of the week and I can stop caring)
[23:07] <infinity> Laney: Or, anything that vaguely relates to atomics.
[23:07] <Laney> Not caring would be good
[23:07] <Laney> hyperair: it is up
[23:07] <infinity> Laney: (Which is actually what mono fails on more than not
[23:07] <infinity> )
[23:08] <Laney> now where's that FFe?
[23:08] <infinity> Laney: Debian armel is going to have this exact same issue when they move to gcc-4.7 without updating all the buildd kernels, I really hope we can get all our ducks in a row on that.
[23:09] <infinity> Laney: (Basically, gcc-4.7 or, in our case, 4.6+ (because we use some backported pathces) use kernel helpers to emulate some armv7 bits for homogenous atomic fun, so both armel ports explode miserably on this if the kernel is too old (>>3.1) to support that)
[23:10] <infinity> s/>>/<</
[23:10] <infinity> armhf, luckily, is fine, since it's armv7 by default, so doesn't invoke the helpers.
[23:11] <infinity> Laney: Of course, this build failure could just be mono being generally sad, but I'm betting not.
[23:11] <Laney> No, I think we had it with something else before
[23:12] <Laney> looks like wheezy will have a good enough kernel, so Debian should (be able to be) alright
[23:12] <infinity> Yeah, I didn't bother to read the log, I'm just assuming it's atomics.
[23:12] <infinity> If it fails on caph, I'll look more closely.
[23:12] <infinity> Laney: wheezy's kernels are fine, but the buildds may well not all be running them.
[23:12] <infinity> Laney: But we'll cross that bridge when we get to it, it only starts mattering in jessie.
[23:13] <Laney> will armel matter for that long?
[23:13] <infinity> Given that Debian would like to suppose pre-v7 hardware, I'd say so.
[23:13] <infinity> support, too.
[23:13] <infinity> Stupid fingers.
[23:14] <infinity> I'm sure we'll drop armel in Debian "some day", but that day's certainly not now, there's a ton of v5 and v6 stuff with retail availability still.
[23:22] <infinity> Laney: Yep, looks like that fixed it.