[00:03] <slangasek> broder: did you have a graph you want us to use for upload ordering?
[00:04] <broder> slangasek: oh, sorry - got distracted. let me see if i can pull that together now
[00:04] <slangasek> it's not a big deal if you don't have it, I know where the 'retry' button is :)
[00:04] <broder> it's probably not worth the effort, since i'd have to go parsing binary packages and build-deps and so forth. retry button is probably easier :)
[00:05] <broder> (i was originally planning to just grep apt-get dotty for the packages you list, but in hindsight not actually what you need)
[00:06] <slangasek> yep :)
[02:19] <psusi> must... annihilate... patches applied in bzr....
[02:32] <cjwatson> psusi: any chance of recognising differences of opinion?
[02:33] <cjwatson> rather than just ranting?
[02:33] <psusi> cjwatson, if they have a good rationale... but it's causing me a great deal of pain
[02:33] <cjwatson> yes, I have a good rationale for doing it that way in my packages.
[02:33] <psusi> and besides, I thought you agreed with this one? ;)
[02:33] <cjwatson> no, I disagree.
[02:34] <cjwatson> it permits unified 'bzr blame' and 'bzr log', regardless of whether a change happened upstream or in the distribution
[02:34] <cjwatson> (yes, parted etc. is done differently, that's 'cos I'm not sole maintainer)
[02:34] <psusi> that's true... but it screws bzr merge
[02:34] <cjwatson> it can be handled
[02:34] <psusi> and makes bzr diff reviewing a royal PITA
[02:35] <cjwatson> quilt pop -a; bzr merge --force; then quilt push and quilt refresh your way up the stack
[02:35] <cjwatson> it's different, but it's straightforward once you get the hang of it
[02:35] <cjwatson> you have to refresh all the patches anyway, so it's not that big an imposition
[02:36] <cjwatson> all it really does is change the order of operations
[02:36] <cjwatson> I concede that it is somewhat easy to get confused in the middle; in my packages I accept that trade-off for what I see as bigger benefits
[02:39] <psusi> does that work?  I would think that would break quilt since the merge would want to mark quilt patches as applied that aren't
[02:46] <cjwatson> psusi: you quilt pop -a if you're merging from upstream, which has no patches applied; if you're merging from some other branch with quilt patches applied, you pop down to the base at the branchpoint, basically
[02:46] <cjwatson> but more generally, I do this quite a lot, I'm not making it up
[03:05] <YokoZar> cjwatson: or you merge all patches upstream and sidestep the problem :)
[03:13] <lifeless> YokoZar: that creates new isues
[03:14] <lifeless> like high latency on fixes
[04:59] <bbigras> Looks like bug 590564 and bug 479741 are duplicates. I'm not sure which one to close as there more subscriber to the newest one.
[05:05] <micahg> bbigras: you can mark the older one a dupe of the newer one, further bug triage help can be found in #ubuntu-bugs
[05:05] <bbigras> micahg: ok thanks
[05:32] <micahg> YokoZar: ia32-libs broke flash
[05:33] <YokoZar> micahg: it tends to do that.  Do you know the particulars as to how?
[05:37] <stgraber> YokoZar: not sure how the whole nspluginwrapper stuff works but a ldd on the .so shows some missing libs: http://paste.ubuntu.com/587209/
[05:38] <stgraber> that might be "normal", would have to compare with a system using the previous ia32-libs
[05:39] <stgraber> http://paste.ubuntu.com/587211/
[05:40] <stgraber> that's the same ldd on a weblive server that's still using the old version
[05:40] <YokoZar> stgraber: which file are you ldding there?
[05:40] <stgraber>  /usr/lib/flashplugin-installer/libflashplayer.so
[05:41] <YokoZar> http://paste.ubuntu.com/587212/ <-- maverick
[05:43] <ScottK> It would be deeply ironic if flash didn't work with multi-arch.
[05:45] <YokoZar> ScottK: nah, turns out it's just libnss3-1d being only a symlink package now and the real files are back in libnss3
[05:46] <ScottK> Ah.  Not nearly so fun.
[05:50] <YokoZar> man I've spent all day cleaning up ia32-libs
[05:50] <YokoZar> and the greater part of yesterday
[05:51] <YokoZar> each time I'm ready to start another major upload I find something new broken and have to rerun the script that takes about 45 minutes
[06:03] <micahg> YokoZar: I downgraded to the maverick version and that was fine
[06:04] <YokoZar> micahg: figured out the problem, uploading fix
[06:04] <YokoZar> which will take a long time
[06:04] <micahg> YokoZar: awesome, thanks
[06:31] <slangasek> micahg: ia32-libs broke flash> clearly you should enable my ppa then, it works fine with multiarch ;D
[06:34] <micahg> slangasek: heh, I took the easy out and downgraded to the maverick version
[06:34] <slangasek> awww
[07:03] <pitti> Good morning
[07:23] <ohsix> hm, ViTE is packaged but i can't see that any of the tools that generate traces are
[07:26] <cdbs> gnome-cups maintainer here?
[07:27] <cdbs> oops, that's not a package
[07:49] <dholbach> good morning
[07:51] <broder> morning, dholbach
[07:52] <dholbach> hi broder
[08:08] <didrocks> good morning
[08:24] <hrw> morning
[08:25] <abhinav-> dholbach, good morning.
[08:25] <dholbach> hey abhinav-
[08:26] <abhinav-> dholbach, I did the session in my college 2 days back. Used your blog posts as reference (with citation), a lot of students are now using Ubuntu :)
[08:27] <dholbach> NICE
[08:27] <dholbach> abhinav-, that's awesome!
[08:27] <dholbach> how did it go?
[08:27] <ohsix> anyone running natty & unity/compiz w/classic desktop that can install and try running visual-regexp? expect compiz to crash if doing so, and let me know if it in fact does
[08:28] <abhinav-> dholbach, it was awesome, I tried to show to fix a bug as well, but internet speed wasn't good. But it was good.
[08:28] <dholbach> abhinav-, so the docs were understandable enough?
[08:29] <abhinav-> dholbach, yes, I they are in a very simple and plain language. quite easy to follow
[08:29] <dholbach> sweet
[08:30] <abhinav-> dholbach, I have something to ask, maybe email would be a better place to ask. Which email id you check more frequently ?
[08:32] <dholbach> I check all of them frequently - just use dholbach at ubuntu..com
[08:32] <abhinav-> ok thanks :)
[08:39] <mr_pouit> slangasek: yup, I don't know why it does that =]
[08:58] <pitti> @pilot in
[09:47] <cjwatson> Riddell: can you look at bug 745446?
[09:49] <pitti> dholbach: if I apply a patch in bzr, but don't upload it yet because of the freeze, should I unsubscribe ubuntu-sponsors? Or will that skew the stats?
[09:49] <doko> pitti: did you merge your eglibc changes with mine before uploading to maverick-proposed?
[09:50] <pitti> doko: ? I didn't upload eglibc to maverick-proposed, at least not recently?
[09:50] <pitti> doko: I only see your upload in http://launchpadlibrarian.net/67426105/eglibc_2.12.1-0ubuntu10.3_source.changes
[09:50] <doko> just got an email about
[09:51] <doko> 672177
[09:51] <pitti> doko: ah, I sponsored the sysvinit part of it
[09:51] <pitti> (jhunt's patch)
[09:54] <Daviey> doko, Early results of your archive rebuild are scaring me :(
[09:55] <Daviey> Is this all more multipath fallout?
[09:55] <Daviey> err, multiarch
[09:55] <doko> Daviey: heh, you'r the tech-lead ;)
[09:56] <doko> I didn't look yet at the build failures yet
[09:57] <Daviey> pitti, apport on i386 looks odd... "error: /build/buildd/apport-1.20/debian/tmp/usr/share/icons/hicolor/scalable/mimetypes/text-x-apport.svg: No such file or directory"
[09:58] <pitti> Daviey: argh, that again; it's a transient issue, a rebuild usually fixes it
[09:58] <pitti> unfortunately I was never able to reproduce it locally :(
[09:58] <Daviey> ahh
[10:02] <dholbach> pitti, feel free to unsubscribe - if you're subscribed and don't forget about it ... :)
[10:03] <pitti> dholbach: I assigned it to me, so I won't forget about it; I just wondered whether the stats look at the ubuntnu-sponsors subscribed bugs, or look at the actual uploads
[10:03] <Daviey> doko, I'm scratching my head over some of these build failures... kubuntu-docs looks odd aswell.
[10:03] <dholbach> I mean... it's reviewed, no?
[10:04] <dholbach> so it can get off the list - there's nothing that needs to be done about it from a sponsors perspective
[10:04] <pitti> dholbach: yes, I ported it to upstream git master, reported it upstream, and applied in our packaging bzr -- that's about as far as I can get it right now
[10:04] <pitti> dholbach: ack, thanks
[10:04] <dholbach> great
[10:05] <doko> Daviey: now, before everybody starts scratching heads ... could you file bug reports for these which don't look multiarch related?
[10:07] <Daviey> doko, TBH, i'm questioning if it's an issue with the packages or the build environment.  Going to rebuild the packages i need to be concerned about on that list locally.
[10:08] <doko> I think slangasek will take care of the multiarch stuff
[10:34] <Riddell> Daviey: where is this kubuntu-docs build failure?
[10:35] <Daviey> Riddell, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html
[10:38] <Cheery> I've got design in mind for a new windowing API
[10:39] <Cheery> you think you'd be interested if I would write it up somewhere?
[11:25] <geser> pitti: re the apport FTBFS: which filesystem did you use when trying to reproduce it? it seems to depend on the file system as I could reproduce it with pbuilder and tmpfs the last time I looked at it (pbuilder with ext4 is fine IIRC) (see also http://lists.debian.org/debian-devel/2010/12/msg00149.html). I don't know if lucas_ found out what's causing this.
[11:26] <pitti> geser: ext4, yes
[11:26] <tseliot> pitti: shall I push this commit for Jockey? https://pastebin.canonical.com/45432/
[11:27] <pitti> tseliot: please remove the code altogether; the abi check should take care of it now
[11:27] <pitti> tseliot: (and please add it to the changelog)
[11:28] <pitti> tseliot: I bounced your abi problem mail to bryceh, FYI; any idea what's causing this?
[11:28] <tseliot> pitti: do you mean the whole available() method or just what I commented out?
[11:28] <pitti> tseliot: just the top two lines that you commented out; the second hunk just looks like whitespace change
[11:29] <tseliot> pitti: right, that would be good to figure out before Natty's release
[11:29] <tseliot> pitti: yes, I replaced a tab with whitespaces
[11:29] <pitti> tseliot: ah, thanks; that's good
[11:29] <tseliot> ok
[11:57] <doko> hrm, rebuilding language packs during the test rebuild :-/
[12:01] <doko> chrisccoulson: are the language pack builds urgent?
[12:01] <chrisccoulson> doko - not really, but they'll be finished in about 5 minutes ;)
[12:02] <geser> who wins the buildd? the language packs or the test rebuild?
[12:04] <geser> the armel buildds are busy for the next 3 weeks?
[12:43] <GunnarHj> Ridell: Hi Jonathan, can we talk?
[12:43] <seb128> GunnarHj, you mean Riddell?
[12:43] <seb128> GunnarHj, you want to use tab to complete nicknames ;-)
[12:44] <GunnarHj> seb128: Indeed I do. Thanks!
[12:44] <seb128> yw
[12:45] <Riddell> hi GunnarHj
[12:45] <GunnarHj> Riddell: Hi, so you noticed anyway. :)
[12:46] <Riddell> yes, because seb128 highlighted me
[12:46] <GunnarHj> Riddell: Saw you are a member of ubuntu-core-doc.
[12:46] <GunnarHj> Riddell: I have written an i18n document for ubuntu-docs. Branch linked to bug 742857.
[12:46] <GunnarHj> Riddell: Asked a couple of questions in a comment on the merge proposal, and would appreciate if we could talk about them.
[12:47] <Riddell> GunnarHj: I don't have anything to do with ubuntu docs, I'm there to help kubuntu doc writers
[12:48] <GunnarHj> Riddell: Ok, I see. Any idea of who to contact?
[12:48] <Riddell> GunnarHj: https://wiki.ubuntu.com/DocumentationTeam/Contact seems to be the page with that information
[12:52] <GunnarHj> Riddell: Yeah, I know. The first item on that page suggests #ubuntu-doc, but that room seems to be very quiet.
[12:53] <GunnarHj> Riddell: Anyway, I won't bother you more about it. Thanks for quick reply!
[12:53] <seb128> GunnarHj, try pinging mdke
[12:55] <GunnarHj> seb128: Already did that, actually. Think I'll wait a couple of hours and see what happens.
[12:55] <GunnarHj> seb128: Thanks again for helping out!
[12:58] <seb128> ok
[13:07] <pitti> hey GunnarHj, how are you?
[13:07] <ev> mvo: where is software center grabbing the category icons from? I thought they would be in app-install-data, but they don't appear to be.
[13:08] <GunnarHj> pitti: Hello, I'm fine. Thx for the gdm approval.
[13:11] <pitti> GunnarHj: thanks for working on it!
[13:11] <mvo> ev: it uses the icon theme mostly, e.g. applications-versioncontrol and similar
[13:11] <GunnarHj> pitti: I agree that the .xsession-errors.old test is a little hackish, but that's as far as I got on my own. Did you have anything better in mind?
[13:12] <ev> mvo: ahhh, Humanity provides that
[13:12] <ev> I was looking elsewhere
[13:12] <ev> thanks a bunch
[13:13] <mvo> ev yw
[13:15] <pitti> GunnarHj: there's no real housekeeping when an user installs the first time or upgrades from an earlier release, I'm afraid
[13:15] <doko> tkamppeter: please could you have a look at the ijs build failure (printing package)? https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2396040
[13:16] <doko> pitti, seb128: two gnome build failures, one multiarch related: libgtop2 and gnome-games
[13:18] <pitti> doko: say hello to Sweetshark  :)
[13:19] <pitti> doko: do you have an URL to the log?
[13:21] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html
[13:21] <doko> pitti: glib-networking too
[13:21] <doko> Sweetshark: does 3.3.2 build on lucid?
[13:21] <GunnarHj> pitti: That's what I thought. And, after all, it's not a critical test. Sun will rise tomorrow even if it fails. :)
[13:22] <pitti> doko: yep, queueing; thanks
[13:22] <pitti> GunnarHj: let's hope :)
[13:22] <ev> slangasek: in ubiquity we generate a sample hostname off dmi data, so Evan-MacBookPro.  This can get a bit long and apparently breaks NETBIOS. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/735072 http://support.microsoft.com/kb/909264
[13:23] <ev> slangasek: what are your thoughts on us generating a stub smb.conf with the netbios name set to the hostname truncated at 15 characters
[13:23] <ev> or rather, can we modify the samba package to do this
[13:25] <doko> pitti: bamf looks desktopish too
[13:26] <Sweetshark> doko: It does now in pbuilder it seems. pbuilder didnt like the gcj-native-helper dependency, although that was there in the last release too. So I am wondering more why it did build before.
[13:26] <doko> Sweetshark: I think gcj-native-helper was not in lucid
[13:27] <doko> mvo: could you look at the apturl build failure?
[13:27] <mvo> doko: sure
[13:28] <Sweetshark> doko: it wasnt, so i wonder why it did build with such a dep.
[13:30] <tkamppeter> doko, thanks for the hint, I will check and upload a fixed package today.
[13:31] <doko> Daviey, libdbd-sqlite3-perl libcompress-raw-zlib-perl bind9 look serverish ... could the server team look at the build failures?
[13:33] <Cheery> http://paste.pocoo.org/show/362614 <- here's a specification draft.
[13:33] <Cheery> it's that windowing library I told you about.
[13:34] <Daviey> doko, bind9 we already have a fix for.
[13:34] <doko> thanks
[13:35] <Daviey> doko, looking into the other two now.. thanks
[13:38] <geser> Sweetshark: have you check if perhaps it was provided by one package in lucid?
[13:38] <wolfe> ^_^
[13:39] <wolfe> can't remember, are there other channels besides #ubuntu-motu for packaging?
[13:40] <geser> wolfe: #ubuntu-packaging but it's mostly pretty quiet
[13:41] <wolfe> ah okay
[13:42]  * wolfe loves all the dev channels anyway. One of the ubuntu was extremely helpful to talk me through step by step in patching, attributing, creating and sending a package update for a serious memory leak :)
[13:42] <wolfe> *one of the ubuntu devs
[13:43] <ari-tczew> wolfe: who is it?
[13:45] <wolfe> I can't remember, but I do have it in my logs :)
[13:45] <tkamppeter> doco, uploaded ijs_0.35-7ubuntu1, this should solve the build problem.
[13:46] <wolfe> Definitely one of the great appraisals of Ubuntu, some of the devs are nice to go out of their way to help possible future contributors.
[13:47] <tkamppeter> doko, uploaded ijs_0.35-7ubuntu1, this should solve the build problem.
[13:49] <doko> Daviey: libuuid-perl too? this all looks like a systematic problem
[13:51] <tkamppeter> doko, my upload was rejected, as ijs is new in Ubuntu in this cycle and I did not ask the technical board yet to give me the upload permission. I asked now, but it depends on how quickly they answer until I can re-upload. If it is urgent (to get it into beta1), I can send you the debdiff by e-mail.
[13:52] <rickspencer3> mvo, for bug #671016, shall I just finalize the copy myself and beg the web team to put it somewhere and give me url?
[13:52] <rickspencer3> will that help you finish it?
[13:53] <doko> tkamppeter: I don't understand ... https://launchpad.net/ubuntu/+source/ijs
[13:54] <tkamppeter> doko, what is wrong there?
[13:55] <tkamppeter> doko, I do not see ijs_0.35-7ubuntu1.
[13:55] <doko> tkamppeter: well, send me the debdiff, and I'll upload
[13:55] <mvo> rickspencer3: I just send a mail to them, let me forward you what I wrote
[13:58] <pitti> doko, tkamppeter: hang on, I can add ijs for Till
[13:58] <pitti> Added:
[13:58] <pitti> Archive Upload Rights for till-kamppeter: archive 'primary', source package 'ijs'
[13:58] <pitti> tkamppeter: try again, please
[13:58] <Daviey> doko, oh joy...  i wonder how much of perl is broken
[14:00] <tkamppeter> pitti, thanks, package re-uploaded.
[14:01] <tkamppeter> doko, the debdiff is in your mail now, but most probably we will not need it any more.
[14:01] <tkamppeter> pitti, upload worked, is in wait-for-approval state due to beta freeze.
[14:01] <pitti> cool
[14:06] <BlackZ> pitti: good afternoon. Could you please have a look at bug #742598 ? thanks
[14:08] <pitti> hey BlackZ
[14:08] <pitti> BlackZ: yes, will do in a minute, just sponsoring xdg-utils
[14:10] <doko> hmm, libssh build failure is not reproducible
[14:11] <mdeslaur> slangasek: do you have an autoconf example for getting the equivalent of $DEB_HOST_MULTIARCH?
[14:12] <mdeslaur> slangasek: (I need it without setting --libdir)
[14:14] <pitti> BlackZ: looks fine, thanks!
[14:15] <BlackZ> pitti: thank you for the sponsoring! :)
[14:19] <mdeslaur> slangasek: ah, never mind, found it...thanks
[14:24] <seb128> can someone reject https://code.launchpad.net/~dstansby/gnome-control-center/bugfix-lp-572025/+merge/25087
[14:29] <pitti> I can't, it's an upstream branch
[14:43] <pitti> @pilot out
[14:46] <SpamapS> pitti: good (morning|afternoon|evening)!
[14:46] <pitti> hey SpamapS, how are you?
[14:46] <pitti> SpamapS: do you feel SRUey? :-)
[14:47] <SpamapS> pitti: I do, however we will need to do IRC only for the time being, as family is still asleep. :)
[14:47] <pitti> ah, sure
[14:51] <mterry> @pilot in
[15:32] <slangasek> ev: where do you intend to put this stub smb.conf?  that will play havoc with the sama package when installed
[15:37] <ev> slangasek: well, I thought through it more as I typed that.  Would it not be better to just do this in the samba package itself
[15:38] <ev> if the hostname is already greater than the maximum allowed by netbios, set the netbios name to a truncated version
[15:39] <doko> slangasek: I asked Daviey about the lib-*-perl failures, seems to be something systematic
[15:39] <doko> librra seems to have an issue with .la files
[15:39] <slangasek> ev: yes, that seems better
[15:40] <ev> slangasek: okay
[15:42] <doko> cjwatson: gcj-4.4 built, please accept gnat-4.4
[15:42] <ev> I've updated bug 735072 accordingly
[15:43] <cjwatson> doko: done
[15:43] <juliank> Where should I complain if one user files 6 duplicates, after I told him 3 times to stop?
[15:44] <juliank> https://bugs.launchpad.net/~steinhauserchristian/+reportedbugs?field.omit_dupes.used=&field.searchtext=ndiswrapper-dkms
[15:49] <cjwatson> juliank: #launchpad perhaps
[15:50] <slangasek> doko: so we have the new 'svammel' tool for filing bug reports for build failures; by default it's set up to file bugs for armel regressions, but if it checks out I could also set it to filing bugs for the x86 build failures.  Should I?  Are there particular tags we should use for the bugs (to avoid filing duplicates)?
[15:54] <doko> slangasek: well, why not. but maybe not for the ones which are already superseded, and not for emacs23 and ecj
[15:55] <Ampelbein> juliank: I think the problem lies more in apport than in the user. If there is a package installation failure, a box comes up asking the user if the problem should be reported. Apport should remember when it already reported the same error for the same package instead of asking the user to file the report again.
[15:55] <slangasek> doko: the tool knows when they're already superseded by checking the main archive
[15:55] <slangasek> doko: so, what tags should we use to avoid duplicates? :)
[15:56] <juliank> Ampelbein: If I tell the user three times to stop reporting duplicates, the user should remember to not click on the button again.
[15:56] <doko> ftbfs ? I think we can't be more specific
[15:57] <slangasek> doko: could just be 'ftbfs' + 'natty'
[15:57] <doko> ok, better
[15:57] <slangasek> cool
[15:58] <slangasek> I'm currently doing a test run to prove the tool works for filing armel bugs without blowing up
[15:58] <slangasek> if that checks out, I can tweak it and do the x86 ones
[15:59] <Ampelbein> juliank: yes, that's the second part of the problem (user's just clicking report problem instead of thinking first)
[15:59] <doko> slangasek: and not for m17-lib ijs lintian
[15:59] <ScottK> slangasek: Is this the tool that was earlier reporting bugs on armel FTBFS that had already been fixed?
[15:59] <juliank> Ampelbein: Locking the account for a month would help in such cases
[15:59] <slangasek> doko: because those are false positives or already diagnosed?
[15:59] <slangasek> ScottK: yes, but that was operator error while it was being developed
[16:00] <doko> slangasek: already diagnosed, sync requested, or bugs already filed
[16:00] <slangasek> doko: if you tag the bugs 'ftbfs' 'natty', no need to manually exclude them
[16:00] <ScottK> slangasek: How's avogadro coming?
[16:00] <ScottK> (speaking of armel FTBFS)
[16:01] <doko> slangasek: can you targed these for the release and set a milestone?
[16:01] <slangasek> ScottK: kunal is continuing to look at it, I believe he was going to be talking to folks on #kubuntu-devel overnight
[16:01] <ScottK> Great.
[16:02] <slangasek> ScottK: it's a tricky one, there's a lot of code in there that's non-optional and completely dependent on libGL; it didn't show up in an emulated i386 build test, because of course libqt4-opengl-dev on i386 *does* pull in GL instead of GLES2
[16:02] <ScottK> Right.
[16:05] <pitti> doko: do you know if the main packages on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html are already complete?
[16:06] <doko> pitti: no. i386 at m, amd64 at libx
[16:06] <pitti> ah, ok
[16:09] <bdmurray> pitti: wrt to bug 551809 how could we have written a pattern for it?
[16:10] <pitti> bdmurray: we recently moved to a single global pattern list, so we can now write patterns which are independent of a particular package
[16:11] <bdmurray> pitti: right but it seems to me that the Stacktrace is vague until it is retraced
[16:11] <pitti> yeah, unfortunately
[16:11] <pitti> so I'm afraid I have no good idea either
[16:13] <bdmurray> well maybe the retracer could be improved to consolidate duplicates across packages?
[16:14] <pitti> bdmurray: that's a bit blurry -- for some crashes we actually don't want to unify similar crashes on different packages
[16:15] <pitti> there might be some middle ground, like unifying them if we have at least 5 levels of stack trace, and they have "enough" entropy in the names (for a to-be-defined treshold)
[16:16] <bdmurray> pitti: I think it is something worth investigating as there are likely quite duplicates of this still hiding (unconsolidated) in Launchpad.
[16:16] <slangasek> doko: target, milestone> I guess svammel doesn't currently implement that; do you consider that a blocker for getting the bugs filed, or can we go through and bump them up afterwards (scriptable, again)?
[16:16] <pitti> I agree
[16:17] <doko> slacker_nl: sure
[16:17] <doko> slangasek: sure
[16:17] <slangasek> ok
[16:22] <pitti> doko: I have my little packaging army working on the four desktopish FTBFS now
[16:24] <Sarvatt> doko: this fixes the linphone ftbs for me, if it's correct on the other hand I'm not sure.. - http://sarvatt.com/downloads/patches/mediastreamer2-v4l1-ftbs.patch
[16:27] <doko> pitti: ^^^ is linphone desktopish too? ;)
[16:27] <pitti> doko: kubuntuish, but yes, desktop arena
[16:40] <Vi0L0> hi, anybody's using fglrx 8.840? if so - does vaapi works for you?
[16:40] <didrocks> slangasek: thanks for the bamf fix! (of course, I just realized that when I bzr push the fix)
[16:41] <slangasek> didrocks: no problem - I broke it, so I owed you a fix :)
[16:41] <didrocks> :-)
[16:41] <seb128> slangasek, do you look at libgtop as well? before I start on it ;-)
[16:41] <slangasek> didrocks: I noticed only after upload that my rationale in the changelog was wrong... unity depends on it, which is far from "nothing", apparently I need to pay closer attention to my checkrdepends commandline... but I did rebuild testing of all the reverse-deps, nothing else breaks
[16:42] <slangasek> seb128: I have not - that hadn't ftbfs yet by the time I went to bed :)
[16:43] <seb128> slangasek, ok
[16:43] <didrocks> slangasek: excellent and thanks for answering on my second remark just before I ask it :-)
[16:43] <slangasek> :-)
[16:46] <seb128> slangasek, urg, does it mean we will need to patch every single lib to set a --libdir=... or?
[16:47] <slangasek> seb128: for actual multiarch conversions, yes.  to fix build failures, no
[16:47] <cjwatson> seb128: smart helpers deal with it; http://wiki.debian.org/Multiarch/Implementation
[16:48] <cjwatson> well, by which I mean dh(1) compat 9 :)
[16:48] <directhex> 9!!?!
[16:48] <seb128> hum ok
[16:48] <cjwatson> yep, it's the one between 8 and 10
[16:49] <seb128> can we make cdbs be smart? ;-)
[16:49] <directhex> seb128, sounds like an oxymoron
[16:49] <slangasek> seb128: how can you, cdbs has no equivalent to dh compat levels
[16:51] <seb128> slangasek, I guess I should read the wiki before asking extra questions, I just assumed it could be default for any build ;-)
[16:52] <seb128> but anyway libgtop which is unapproved builds fine there, I guess it's the "90_autotools.patch: - Dropped, using dh-autoreconf instead" which did it
[16:52] <seb128> doko, pitti: ^
[16:53] <slangasek> seb128: switching it on by default breaks your .install and .links files... has to be a controlled conversion, package-by-package :/
[16:53] <seb128> hum, seems logic
[16:54] <seb128> slangasek, thanks
[17:08] <slangasek> ScottK: do you want to seed a spec for bug #745004?
[17:08] <ScottK> slangasek: Want, no, but I will.
[17:08] <slangasek> thanks ;)
[17:21] <ScottK> slangasek: Done.
[17:22] <pitti>  SpamapS: https://wiki.ubuntu.com/Bugs/HowToFilter
[17:27] <slangasek> ScottK: blueprint name?
[17:27] <jelmer> slangasek: hi
[17:27] <jelmer> slangasek: would it be reasonable to (ab)use multi-arch to do cross compilation for Windows using mingw32 ?
[17:27] <slangasek> jelmer: hey there :)
[17:27] <ScottK> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-pam-restarts
[17:28] <ScottK> Already fixed to use jcastro's just announced naming conventions.
[17:28] <jcastro> sorry about that, normally I send that email along with the announcement
[17:29] <slangasek> jelmer: yes and no - yes because there's certainly room in the namespace for windows, no because we don't have a win32 Debian architecture anywhere that you could actually ship such libraries as part of
[17:29] <ScottK> jcastro: : No problem.  It was just ironic I read that mail 5 minutes after registering my first O bluepring.
[17:29] <ScottK> pring/print
[17:29] <slangasek> ScottK: looks good, thanks :)
[17:29] <jcastro> ScottK: continuing the tradition of Foundations being done 5 weeks before everyone else. :)
[17:29] <ScottK> slangasek: You're welcome.
[17:44] <MadCow108> o_O ia32libs ubuntu11 doubled its size since ubuntu9
[17:52] <ScottK> pitti: You're OK with any archive admin pressing the buttons for SpamapS or do you want to do it?
[17:54] <pitti> ScottK: I'm ok with other AAs doing it, as long as they also run sru-accept.py
[17:54] <ScottK> OK.
[17:54] <pitti> https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing%20procedure%20and%20tools explains queuediff and sru-accept.py
[17:54] <ScottK> I've done the for jdong before.
[17:54] <ScottK> Yep.
[17:54] <ScottK> the/that
[17:55] <pitti> queuediff will generate an appropriate sru-accept.py (without -b, to avoid opening the bugs)
[17:55] <pitti> thanks
[18:09] <jelmer> slangasek: That's good enough for what I need, I'll give it a try.
[18:14] <slangasek> ScottK: is the current kdeedu ftbfs caused by avogadro?
[18:14] <Riddell> slangasek: that and other bits of opengl
[18:14] <ScottK> As Riddell says.
[18:14] <Riddell> I have a compiled package in ~canonical-arm-dev ppa
[18:15] <slangasek> ok, so I should mark bug #745846 as a duplicate of bug #707794 then
[18:15] <ScottK> I'm expecting once kdeedu is done, kdeplasma-addons will be quite tractable.
[18:15] <ScottK> slangasek: Same for whatever the kdeplasma-addons bug is.
[18:16]  * slangasek nods
[18:18] <smoser> seb128, around ?
[18:18] <seb128> smoser, hi
[18:18] <smoser> regarding bug 740972
[18:19] <smoser> i really dont' even know the answer to "does it make the decorator crash or compiz crash?". i'm not familiar enough to know.
[18:19] <smoser> i suspect its the "window decorator".. it gets replaced by metacity
[18:19] <seb128> no
[18:19] <smoser> but i think the easiest thing to do is for you (or someone who *would* know) to try it
[18:19] <smoser> it literally takes 30 seconds to reproduce
[18:19] <seb128> the decorator is what display the titlebar etc
[18:20] <seb128> without it you get no bar with the close button etc
[18:20] <seb128> but you can still switch between workspaces on dialogs, etc
[18:20] <smoser> so this is a good example of why asking me is of no value, and reproducing it woudl be useful.
[18:21] <seb128> well my comment was rather to give the reference to the other bug
[18:21]  * slangasek hammers on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue until lifeless takes note of the timeouts and fixes ;)
[18:21] <seb128> I don't care enough to crash my current session
[18:22] <seb128> smoser, but I will forward the comment to lamalex who set the bug as incomplete
[18:22] <smoser> sure. i just get frustrated when bugs get marked as incomplete when they're easily reproducible.
[18:24] <seb128> smoser, yeah, it's understandable
[18:24] <smoser> seb128, i'm almost certain its the 'compiz' process that dies.
[18:24] <smoser> well, not dies, but exits successfully
[18:24] <smoser> (and then a 'metacity' process is spawned)
[18:28] <slangasek> fta: thanks for the info on bug #745854 - should I assign this to you?
[18:32] <mterry> @pilot out
[18:37] <slangasek> ScottK, Riddell: bug #745892, another opengl qt revdep that didn't get caught earlier (not in main, not in kubuntu)
[18:37] <ScottK> Sigh.
[18:38] <fta> slangasek, the ftbfs, sure. the other one, no. my part has been done.
[18:39] <slangasek> fta: done, thanks :)
[18:40] <doko> dear nfs-utils, this is *NO* configury, this just sucks
[18:43] <slangasek> ScottK: ah, though janimo already filed this bug; marking as a duplicate then
[19:09] <bambee> evening, are you planning to get the firefox 4 (release) into archives ?
[19:09] <bambee> s/the//
[19:30] <fta> slangasek, fix uploaded 30min ago, waiting for approval now
[19:31] <slangasek> fta: cheers :)
[19:44] <pitti> kirkland: thanks for the offer to help SpamapS with SRU buttons
[20:03] <ScottK> slangasek and fta: I just accepted it.
[20:03] <ScottK> (assuming "it" is Chromium
[20:03] <ScottK> )
[20:05] <chrisccoulson> bambee, it's already in the archive
[20:06] <bambee> chrisccoulson: I just see 4.0~rc2+build3+nobinonly-0ubuntu1
[20:06] <chrisccoulson> bambee, that *is* final
[20:06] <bambee> ohhh
[20:07] <chrisccoulson> rc2 became the final build
[20:07] <chrisccoulson> it's identical ;)
[20:07] <bambee> ok ;)
[20:08] <fta> ScottK, thanks!
[20:08] <ScottK> You're welcome.
[20:35] <kirkland> pitti: sure thing
[20:35] <pitti> slangasek, doko: glib-networking FTBFS uploaded, FYI
[20:36] <slangasek> pitti: cheers
[21:04] <pitti> SpamapS: oh, I noticed a gotcha: e. g. you responded to bug 687501 with an SRU ack, but that bug doesn't have ubuntu-sru subscribed yet, so the mail landed in a different folder (and only because I actually get bug mail for oem-priority); I might not see other bug responses from you at all
[21:04] <pitti> SpamapS: I'll still see them when I actually review packages in the queue, but response time will be much slower
[21:30] <SpamapS> pitti: gotchya, will make sure ubuntu-sru is subscribed before acking them. :)
[22:06] <cyphermox> anyone got a moment to look over https://code.launchpad.net/~mathieu-tl/ubuntu/natty/ubuntu-mono/icon-cache/+merge/55629 and sponsor it ? :)
[22:09] <pitti> SpamapS: there, all SRU queues empty \o/
[22:09] <pitti> ... speaking of which
[22:10] <pitti> Daviey: what was the outcome for the bind SRU?
[22:47] <cellardoor> I am going to build a .deb installer as part of a Computing project for Uni... I did it before a few years ago but can barely remember how to go about it, any good manuals or links?
[23:07] <doko> does anybody have an idea about build failures like for srtp?
[23:13] <slangasek> doko: hrrrm, I have seen that before
[23:14] <slangasek> well, maybe not that exactly, I guess the ultimate failure message is generic
[23:14] <slangasek> you would think a TeX formatting program would output prettier errors
[23:15] <doko> the thing is that xolor.sty is present and even included
[23:15] <doko> xolour,sty even
[23:15] <doko> bah
[23:20] <broder> TeX formatting program would output prettier errors> it's clearly been a long time since you tried to write (La)TeX, hasn't it, slangasek?
[23:22] <slangasek> broder: not so long :)
[23:23] <broder> i feel like i remember TeX errors ranking up there with C++/STL errors
[23:23] <doko> broder: any *new* insight would be nice