[02:36] <slangasek> Logan_: fwiw you really shouldn't file bugs at severity: serious in Debian for build failures only reproduced in Ubuntu (Debian bug #704572). :)
[02:37] <Logan_> slangasek: Ooops. :P What's the appropriate priority?
[02:38] <StevenK> important
[02:39] <StevenK> Justification being it might well bite Debian soonish
[02:41] <slangasek> right - or if it's reproducible with a toolchain in experimental, serious+tags: experimental is ok, preferably with a usertag we can use to find it again later
[04:22] <pitti> Good morning
[04:23] <sarnold> good morning pitti :) I just found fatrace today. awesome. thanks. :D
[04:23] <vibhav> good morning
[04:27] <pitti> sarnold: :)
[06:45] <dholbach> good morning
[06:45] <didrocks> hey dholbach!
[06:45] <didrocks> @pilot in
[06:45] <dholbach> salut didrocks
[06:45]  * dholbach hugs didrocks
[06:45]  * didrocks hugs dholbach back
[06:46] <doko> infinity, could you forward 1154599? is this change intended?
[07:43] <jibel> pitti, could you have a look at bug 985049 ? the obvious fix is to re.escape the gecos bits but I am not sure that it will not break the replacement.
[07:44] <pitti> jibel: merci, will do
[07:44] <pitti> jibel: that's covered by tests, I'll add a new one for RE chars in gecos
[08:01] <ev> slangasek: ha!
[08:23] <doko> achiang, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442990 ?
[08:28] <geser> xnox: is the compat tclConfig.sh 'transitional' (till most packages got fixed) or is it going to stay for a long time?
[08:31] <doko> geser, I'd like to see a plan for Debian ...
[08:36] <xnox> geser: what doko said really. I will forward it to Debian.
[08:36] <xnox> it's up to them to decide.
[08:37] <doko> xnox, see my comment in the report, and maybe cc wookey
[08:37] <doko> dobey, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4448145 ?
[08:38] <xnox> doko: what report?! =)
[08:38] <doko> xnox, bug 1122120
[08:40] <xnox> doko: saw that. I tend to agree with colin. Separate bug + low priority. I will not work on that at the moment. Maybe debian folks can do that =)
[08:46] <doko> pitti, could you have a look at bug 1163786, gir related ftbfs
[08:47] <pitti> doko: ack
[08:50] <seb128> pitti, there are quite a bunch of those (though some already got fixed)
[08:51] <doko> right, bamf is another one
[08:51] <seb128> pitti, somewhat it shows that updating the "stack" component and not updating GNOME on top creates issues as well
[08:51] <seb128> not that it's specific to GNOME, but when we update the whole we get a good part of the build fixes with it
[08:54] <xnox> doko: seb128: bamf is fixed in lp:bamf, and for some reason it's not autolanding....
[08:54] <xnox> didrocks: why is bamf not autolanding? we want the FTBFS fixes from lp:bamf =)
[08:55] <didrocks> xnox: unity integration tests failed
[08:56] <didrocks> ah sorry, it's in the indicator stack
[08:56] <didrocks> xnox: cyphermox needs to publish manually the indicator stacks
[08:56] <didrocks> because there are packaging changes
[08:56] <didrocks> and see the posts on autolanding, we don't land stuff automatically when there are packaging changes
[08:56] <didrocks> we need someone with upload rights "acking" for the changes
[08:56] <didrocks> see https://jenkins.qa.ubuntu.com/view/cu2d/view/Raring/view/Indicators/job/cu2d-indicators-raring-3.0publish/
[08:57] <xnox> didrocks: to be honest, I read the first one and skimmed through the rest =)
[08:59] <didrocks> xnox: so ensure cyphermox is reviewing the change today and publish
[09:10] <pitti> jibel: I fixed that apport crash, and added new tests for this
[09:10]  * pitti looks at gcr
[09:10] <pitti> seb128: yeah, GLib.Object doesn't make any sense
[09:11] <pitti> looks like https://git.gnome.org/browse/gcr/commit/?id=0b8893 will fix it, checking
[09:11] <jibel> pitti, thanks
[09:14] <seb128> pitti, ah, that issue is different from the lightdm/bamf ones
[09:15] <cjwatson> didrocks: the nvidia-cuda-toolkit you sponsored has a typo ("nvdidia" in one place in debian/control).  Do you think you could do a quick reupload with that fixed?
[09:16] <didrocks> cjwatson: oh sure, didn't notice, sorry about it, doing now
[09:16] <cjwatson> didrocks: thanks, I thought it'd be better this way than cycling round with the sponsoree
[09:17] <didrocks> cjwatson: agreed ;) and especially for downloading a source of 900+MB ;)
[09:18] <alkisg> Hi, just to verify that this isn't a regression: it's still true that one cannot use fuse filesystems like sshfs and ltspfs if he's not in the fuse group, right?
[09:18] <doko> hmm, I remember I did want remove mozilla-gnome-keyring, but I can't remember anymore why ...
[09:19] <didrocks> cjwatson: done
[09:20] <OdyX> tkamppeter_: I have uploaded cups-filters 1.0.31-1 to Debian experimental, including all the Ubuntu changes + some more cleanup (move to debian-printing team, section/prio cleanup, symbols for libfontembed, …). You probably need to wait some hours if you want to sync that version.
[09:22] <didrocks> @pilot out
[09:29] <pitti> doko: ah, gcr fix caught in unapproved, but I guess it'll get accepted soon
[09:30] <doko> cjwatson, still ok to accept the ftbfs fixes in main?
[09:30] <cjwatson> doko: since beta's in preparation, check with infinity before touching anything on images
[09:31] <cjwatson> (and if he isn't around, please wait)
[09:31] <doko> ok
[10:00] <pitti> xnox: are you on bug 1163293? your last comment sounds like it
[10:00] <xnox> pitti: i thought i uploaded that.... let me check
[10:01] <pitti> not in unapproved
[10:03] <xnox> pitti: added a comment. I did fix it for 3.9.4, but I'd rather get it fixed for "real", e.g. parse & find out the latest standards version and use that in the templates always, by default.
[10:03] <pitti> ah, ok
[10:03] <xnox> bug 1163293
[10:03] <xnox> =) much better now.
[10:06] <doko> pitti, https://launchpad.net/ubuntu/+source/libgda5/5.0.3-2/+build/3936951 (universe, however)
[10:06] <pitti> didrocks: would you know what "python unityquantal.py" would be?
[10:07] <pitti> didrocks: looking at bug 1160448
[10:07] <didrocks> pitti: I have never seen that file :)
[10:07] <didrocks> let me look at the bug
[10:07] <pitti> didrocks: ok, thanks
[10:07] <pitti> didrocks: there's not much in it, nevermind
[10:07] <didrocks> pitti: ok, yeah, I can just say it's not something we ship by default
[10:09] <pitti> didrocks: I updated the bug, thanks!
[10:10] <didrocks> yw :)
[10:48] <doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4424035 and https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4424038
[10:49] <doko> these use the versioned tcl/tk packages explicitly
[10:49] <xnox> dbarth: mterry (who is not here) barry: bug 1119279 either StringIO stopped accepting bytes, or PyCurl switched to writting bytes (from previously writting py3 strings) which is a bug or a bugfix, and hence thin-client-config-agent is at the moment broken in raring.
[10:50] <xnox> imho switching to bytes over-the-wire explicitly is the right solution here.... as proposed in https://code.launchpad.net/~xnox/ubuntu/raring/thin-client-config-agent/fix-1152222/+merge/156801
[11:00] <xnox> doko: ok. but why? =) can't they just use a default one....
[11:00] <xnox> oh, no, it's tied to versions. ok.
[11:03] <xnox> i guess it also needs multiarching...
[11:05] <xnox> infinity: doko: also pidgin upload was not necessary as the compat tcltk scripts got uploaded by then already.
[11:32] <doko> does somebody know the nick of Logan Rosen?
[11:33] <cjwatson> LoganCloud_ I think
[11:33] <doko> LoganCloud_, your xf86-video-msm upload
[11:33] <doko> xf86-video-msm (1.0.1+git20100122.5f7df591-3ubuntu1) raring; urgency=low
[11:33] <doko>   * No-change rebuild for Ubuntu.
[11:33] <doko>  -- Logan Rosen <logan@ubuntu.com>  Wed, 27 Mar 2013 20:31:51 -0400
[11:34] <doko> maybe No-change, but not merging the ubuntu patches is bad
[11:34]  * cjwatson defeats haskell-cipher-aes/powerpc, woo
[12:18] <dbarth> xnox: ok
[12:28] <sunweaver> dbarth: hi
[12:28]  * sunweaver 's real name is Mike Gabriel from X2Go upstream
[12:29] <sunweaver> dbarth: I have today started on a patch for remote-login-service that adds protocol type "x2go" to the remote-login-service code.
[12:30] <sunweaver> dbarth: I guess X2Go for raring has been postponed to later, are you still interested in including X2Go into UCCS?
[12:30] <xnox> sunweaver: it is best to be included in the S-series once it opens.
[12:32] <sunweaver> xnox: great.
[12:32] <xnox> sunweaver: very early on, to allow extensive testing =)
[12:32] <dbarth> sunweaver: hi Mike
[12:32] <sunweaver> xnox: testing can already start, ppa:x2go/stable
[12:33] <sunweaver> dbarth: hi David! Hope you are doing well!
[12:33] <dbarth> yup, same
[12:33] <dbarth> so uccs is frozen right now
[12:34] <sunweaver> the X2Go project just got contracted for writing a web frontend that is compatible with the way UCCS communicats with the remote-login-service.
[12:34] <dbarth> as a test drive service, not so much activity on it this cycle
[12:35] <sunweaver> you mean UCCS as a concept is frozen?
[12:35] <dbarth> sunweaver: the changes you made into remote-login seem a better way to enable x2go access
[12:35] <dbarth> sunweaver: yup; i'm keeping it as a test drive, but no code change really; can't be on all fronts
[12:36] <sunweaver> dbarth: yeah, but they hack X2Go sessions into the freerdp protocol type of remote-login-services.
[12:36] <sunweaver> dbarth: sure.
[12:36] <sunweaver> what X2Go is working on atm is: X2Go Session Broker
[12:36] <sunweaver> the session broker of X2Go shall have a UCCS like communication protocol, so that lightdm can talk to the X2Go Session Broker
[12:37] <sunweaver> thus, companies can use remote-login in LightDM, but have their own session broker (for X2Go and RDP atm).
[12:38] <sunweaver> as I want to do that in a clean way, I am currently implementing a patch against the remote-login-service that makes remote-login-service aware of JSON objects of type x2go
[12:38] <dbarth> sunweaver: i think that's the way to go indeed
[12:38] <dbarth> xnox: just testing your fix
[12:39] <sunweaver> once that is done, I will change our remote-login hack (lightdm-remote-session-x2go) to use x2go instead of freerdp as JSON object type.
[12:39] <dbarth> xnox: what's the next step to land that? can i just use the bug as a way to get past the release freeze?
[12:40] <sunweaver> dbarth: thanks for this short chat, I will ping you (and xnox?) once I have valid patches to propose.
[12:42] <xnox> dbarth: yeah, just an upload needs to be done with that bug mentioned in the debian/changelog. If you are happy with my change, I can upload it & ping people to accept it into raring.
[12:42] <dbarth> sunweaver: np, thanks for the contrib
[12:42] <xnox> dbarth: that issue got raise on foundations radar to fix for raring release ;-)
[12:42] <dbarth> xnox: cool
[12:49] <doko> seb128, glib2.0 now built successfully on cetan
[12:49] <seb128> doko, ok, do you know if there any hardware difference between the builders?
[12:49] <seb128> it could also just be a flacky test
[12:50] <seb128> it's weird we never hit any such issue on the archive builders though
[12:50] <doko> enoclue
[12:53] <dbarth> xnox: were the unit tests passing in your branch? i'm still pulling updates to verify if that's due to my system being too far behind
[12:54] <xnox> dbarth: I did not run the unit-tests, I only ran the command to make sure we are not getting a traceback any more. I'd think unittests might need adjustment as well, if we are asserting PyCurl's behaviour as intended.
[12:58] <pitti> apw: hey Andy, how are you?
[12:59] <xnox> pitti: ev: I have a crash file generated on an offline machine. Issuing approt-cli file.crash  (a) requiried permissions to read logs (b) overwrote the report with a new one (c) upload the new report, where I was expecting it to upload the existing report.
[12:59] <pitti> apw: do you know what needs to happen that a device in sysfs gets a proper driver symlink?
[12:59] <pitti> apw: I'm trying to fix that in the mac80211_hwsim module, so that network-manager accepts it
[13:01] <pitti> xnox: did you actually run the crash through the UI (or -cli) once on the original machine?
[13:01] <pitti> xnox: it sounds like the .crash file you copied didn't have all the data collected
[13:02] <xnox> pitti: I generated the crash with "apport-cli --save ubiquity.crash ubiquity
[13:02] <xnox> "
[13:02] <dobey> doko: did you give me the wrong build link? that i386 ubuntuone-client was a successful build. what am i supposed to be looking at?
[13:02] <doko> dobey, no, retried, and then it did succeed :-/
[13:03] <dobey> doko: oh. do you have a link to the failed build log?
[13:03] <xnox> pitti: crash that I meant to upload is attached to bug 1163902
[13:03] <apw> pitti, most of the symlinks come as a result of registering things with the right busses
[13:03] <doko> dobey, no, it's removed with a new build
[13:04] <pitti> xnox: odd, something is very wrong there -- no Dependencies: field
[13:05] <xnox> pitti: it's a ~fresh VM install with "odd" sizing (RAM >> HDD) the installation went "odd" since the partitioning was not the default. That crash is unreportable & to top things off firefox does not start.
[13:05] <pitti> xnox: oh, because it's not installed
[13:05] <xnox> pitti: as it is usually the case for the ubiquity hook, hence it's shipped in apport and not ubiquity package.
[13:06] <pitti> xnox: so you found a corner case with uninstalled packages and saving reports
[13:06] <pitti> apw: that's what I thought, as I don't see anything in other drivers that explicitly sets the "driver" symlink
[13:06]  * xnox realises now, why I haven't gotten any reports from installed system after I was asking people to use apport-cli to save the report & upload it later.
[13:06] <dobey> doko: ok
[13:06] <xnox> pitti: so, should I open a bug against apport then?
[13:07] <pitti> xnox: yes, please
[13:08] <xnox> pitti: what might be even more unusual is that I do have ubiquity package installed. But nonetheless the foreign report should be uploaded verbantim.
[13:15] <pitti> xnox: I think apport uses the Dependencies: field to check whether or not it needs to collect data
[13:15] <dobey> xnox: btw, did we get the u1 sign-in bits into ubiquity (and enabled in raring)?
[13:15] <pitti> xnox: for this special case we need some other test
[13:15] <xnox> dobey: no. FFe not granted.
[13:16] <xnox> dobey: not merged, not on raring CD.
[13:16] <xnox> dobey: I shall be doing it early in S-series. Are the in-dash payments landing?
[13:17] <dobey> i don't think so, but i know basically nothing about that. i think it might if the rebasing on unity trunk is done/tested/working
[13:18] <dbarth> xnox: the fix works on my raring instance, but i'm still trying to fix the test suite as well; may take a while; i'll ping back
[13:18] <xnox> dbarth: ack.
[13:19] <xnox> dobey: well ubiquity plugin does not have Credit Card details input either, so some setup on the installed system will be needed upon first using the U1 in-dash features.
[13:20] <dobey> xnox: well, but less work. and i don't think the ubiquity bit and the in-dash bits should be considered directly related or one dependant upon the other
[13:49]  * ogra_ wonders if pitti has an idea what triggers the mount in bug 1160847 every minute 
[13:49] <ogra_> it seems to be some lower level
[13:52] <pitti> ogra_: I think running an "udevadm monitor -e --udev" during that will be interesting, to see whether there actually is a corresponding stream of added/removed/changed MTP devices or not
[13:52] <ogra_> ah, good idea
[13:52] <ogra_> i'll test that later today ...
[13:53] <ogra_> pitti, thanks !
[14:00] <dholbach> mhall119, seb128: do you have an idea who is using the sound indicators in libunity?
[14:01] <mhall119> every music player
[14:02] <mhall119> several webapps
[14:02] <dholbach> mhall119, do you know if there's a list?
[14:02] <mhall119> I don't think there is
[14:03] <seb128> dholbach, mhall119: I don't know of any
[14:03] <barry> xnox, doko yeah bug 1163609 is a nasty one
[14:04] <dholbach> seb128, list you mean?
[14:04] <seb128> dholbach, mhall119: most player just do mpris over dbus (rhythmbox for example)
[14:04] <seb128> dholbach, I don't know of anything using libunity for sound indicator integration
[14:04] <dholbach> ah ok
[14:04] <seb128> dholbach, if that was your question
[14:04] <dholbach> yes it was
[14:05] <xnox> barry: does that mean you fixed it half an hour ago, since you have finalised your opinion of its ugliness =) ?! =)
[14:06] <barry> xnox: ask me that in a half hour :)
[14:19] <dbarth> xnox: https://code.launchpad.net/~dbarth/ubuntu/raring/thin-client-config-agent/further-fix-1152222/+merge/156860 should work now
[14:23] <xnox> dbarth: looks good. I'll merge and upload today.
[14:23] <xnox> dbarth: thanks a lot for your help!
[14:23] <barry> xnox: are you still looking for a review of your thing-client mp?
[14:33] <xnox> barry: for sanity, yes. https://launchpad.net/ubuntu/+source/pycurl/+changelog lists a few uploads related to str/bytes handing inside pycrypto.
[14:34] <xnox> barry: but I cannot figure out what is the declared expected API for the passed write functions. bytes or strings. In quantal it was strings, in raring it is now bytes (and make sense to me)
[14:35] <xnox> barry: but I don't want us to be bitten by this badly. E.g. what was the intent in pycurl and what is correct for python3-pycurl.
[14:36] <barry> xnox: yeah, it certainly makes sense to pass bytes on the wire.  i don't know the api but it could accept bytes or utf-8 strings (if no encoding is available)
[14:36] <barry> xnox: the latter would be for convenience
[14:37] <barry> xnox: of course, if i can't figure out why pycurl crashes, it's all moot anyway ;)
[14:37] <xnox> barry: it's "web" and potentially we could receive broken / half responses and thus encoding "none"
[14:37] <barry> xnox: in which case, bytes is the only thing that makes sense
[14:37] <xnox> ok. so I'm not that crazy =)
[14:39] <barry> well, no guarantees that pycurl won't *make* you so ;)
[15:10] <didrocks> xnox: hey, around? tried to catch you yesterday on #ubuntu-desktop (you were answering on #ubuntu-devel, not on that channel), and now on #ubuntu-unity ;)
[15:20] <doko> rbasak, may I reject your ntp upload? see bug 1163768
[15:21] <rbasak> infinity: ^^
[15:24] <rbasak> doko: I guess, if you're doing it. Not sure what I'm supposed to do though, if everything I do gets trumped.
[15:24] <rbasak> This is exactly the concern I had yesterday, and it's happened on the first package I've touched.
[15:25] <doko> rbasak, sorry, but I mentioned yesterday: please leave a note what you're working on
[15:25] <doko> and I did file the report ...
[15:25] <rbasak> doko: leave a note where?
[15:25] <rbasak> In the topic?
[15:26] <doko> rbasak, on #ubuntu+1-maint for example
[15:26] <rbasak> doko: in the topic or in the channel?
[15:26] <doko> I don't care
[15:26] <infinity> In the channel is fine.  But sometimes stepping on toes happens.
[15:29] <xnox> rbasak: fixing haskell-conduit/armhf FTBFS will resolve a fair chunk in the ghc transition, see http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[15:31] <infinity> pitti: Did you do the langpack uploads in the queue?  Seems a bit premature.
[15:32] <pitti> infinity: no, they are from the automatic cronjob I guess
[15:32] <halfie> hi, does the linker in ubuntu automatically ignores the incorrect "-pie" flag when applied to DSOs ?
[15:32] <pitti> infinity: I suggest to either leave them in the queue until after the beta, or just reject them and take the next set
[15:32] <pitti> infinity: as we currently have empty update packs and thus minimal size
[15:32] <halfie>  I am talking about "export DEB_BUILD_HARDENING=1" stuff
[15:33] <infinity> pitti: Leaving them in the queue is fine, just makes it a bit unreadable. :)
[15:33] <pitti> infinity: they aren't precious, so feel free to mass-reject
[15:33] <infinity> pitti: And I assume we want a final langpack upload in ~2w anyway.
[15:35] <pitti> the cron job uploads twice a week
[15:35] <pitti> infinity: right
[15:36] <infinity> pitti: I'll reject the lot for now, then.
[15:37] <cjwatson> xnox: please, as I said yesterday, I don't think this is a good target
[15:37] <cjwatson> rbasak: haskell-conduit/armhf is an epic rathole.  I advise against touching it.  It's actually a ghc bug which I've been working on with upstream
[15:38] <rbasak> cjwatson, xnox: OK, I'll leave that then
[15:38] <cjwatson> (both because I've been working on it - and have said so - and because it will take days of your time)
[15:38] <xnox> cjwatson: sorry, I missed your comment yesterday about it.
[15:39] <cjwatson> there are bits of the ghc transition that somebody familiar with haskell could productively attack, but I think there's probably a limit on how many Ubuntu developers should be trying to teach themselves that on the fly in order to resolve it :-)
[15:41] <cjwatson> rbasak: it's generally easier to avoid getting trumped in universe, FWIW; it's less valuable than the fixes in main, but it's still within the scope of +1 maint and it does need to get done ...
[15:43] <rbasak> cjwatson: sure, I can work in universe. My difficulty is picking something to work on - because there are issues that presumably people have left because they're not worth working on (too hard, or root cause somewhere else), and I can't easily tell those apart from the ones that can be worked on or would have a greater impact to work on, since they're all bundled together.
[15:44] <cjwatson> I think it's probably inevitable that a lot of the initial work is analysis
[15:44] <infinity> Sometimes, all of the work is analysis.
[15:44] <infinity> In fact, in main, all of the work is sometimes pinging the TIL "maintainer" and asking if/when they're fixing it, before moving on. :P
[15:45] <cjwatson> You can probably tell the difference between ready-to-attack and needs-analysis by whether there's a bug filed with description/comments that let you understand what's going on
[15:45] <sladen> rbasak: is there any software you already use that you have perhaps noticed an issue with?  Or which a friend/colleague has mentioned.  You could look into tracking such as issue down, and it would be rewarding for both you and them.
[15:45] <cjwatson> At least as a first-pass filter
[15:45] <infinity> sladen: This is specifically in the context of +1maint, not scratching itches (though it's nice when they overlap, sure).
[15:46] <rbasak> OK, so I should create a bug with analysis for every package I touch and decide not to try and fix?
[15:46] <infinity> rbasak: If you get enough analysis to be helpful to the next person, it certainly doesn't hurt to file a bug to share that.
[15:47] <rbasak> Is there a script that can create a bug from an ftbfs for me?
[15:47] <infinity> Sometimes, the analysis is just "argh, too hard" or "I don't speak LangFoo, this is gibberish", and you just move on quickly. :P
[15:47] <rbasak> (if not I might write one)
[15:47] <rbasak> :)
[15:47] <cjwatson> I've not found it worth the effort, since it's generally selective copy-and-paste
[15:47] <rbasak> OK
[15:48] <infinity> If the analysis is "I reduced this to a small test-case, and here's an example of how that fails, and now I'm stuck because I can't unwind the actual bug", that's valuable to share.
[15:48] <infinity> But yeah, copy-and-pasting build log snippets isn't all that helpful.
[15:50] <cjwatson> It can save time if somebody is looking for something to fix that's known to be easy
[15:50] <cjwatson> Or at least not horribly intractable
[15:53] <cjwatson> Same way as I think it's worth uploading Haskell transition rebuilds even if they're known to fail, just so that the build log's right there on LP
[15:55] <Daviey> A while ago, i did a full rebuild of lots of packages that (generally) server cares for.  I tagged them as part of the process, and beated a drum of excitement. Within a week, the 20 or so FTBFS were all fixed.  (Many of them from new contributors.)
[15:56] <Daviey> Which is why i thing that a large part of +1 maint should be coordination
[15:56] <Daviey> Adding into a channel topic of random packages to touch isn't decent coordination
[15:57] <Daviey> let alone outreaching to new contributors
[15:57] <cjwatson> Things like the transition tracker are very useful, though need explanation
[15:58] <xnox> not sure how far +1 maint scope reaches. For example S-series will open with boost1.53 by default and there are still 81 unfixed packages that fail with boost1.53 as listed here: http://people.canonical.com/~xnox/boost1.53/
[15:58] <xnox> I didn't file bugs or anything....
[15:59] <Daviey> One example is, bug 687976 .. in 2010, i had no idea who xnox was :)
[15:59] <ScottK> The best way to get those fixed is fix RC bugs in Debian so 1.53 is default there too (due to Wheezy being released)
[15:59] <infinity> xnox: I don't mind +1-maint being proactive, though I'd like to see people who are pushing a transition be the first ones to take a crack at it before they just dump the problem on us. :P
[16:00] <xnox> Daviey: those were the days =)
[16:01] <rbasak> I'd love to just be given something to work on together with some confidence that I'll be left to it for a day or two without being trumped, but also for it to be something that'll have a real impact. Picking something like this turns out to be quite hard.
[16:01] <cjwatson> Yeah, I can understand that
[16:01]  * cjwatson has a glance at the list
[16:02] <rbasak> I spotted a gnash armhf failure that I think would be useful to fix since gnash is more relevant on !intel.
[16:02] <rbasak> I'll look into it. But it's also nice to have two or three on the go at once, since builds take a while
[16:04] <CheezeMonkey> Does anyone know what could be going wrong if my ubuntu installation always hangs at the "preparing to install ubuntu" stage?
[16:04] <infinity> rbasak: The seeded-but-not-in-main stuff at the bottom of the ftbfs list could be worth looking at.
[16:04] <CheezeMonkey> I had once, a little over a year ago, installed ubuntu 10.10 without any issues
[16:05] <infinity> rbasak: openimageio, libgda5, etc.
[16:05] <xnox> CheezeMonkey: bug 1080701
[16:06] <cjwatson> rbasak: One thing that comes to mind is digging up the remaining qemu BIOSes and the like that need to be converted to use cross-compilers to build now that we have them
[16:06] <cjwatson> openhackware and the like - I did slof not that long ago if you want an example
[16:07] <infinity> Do we still have ppc-only and arm-only ones that need crossing?
[16:07] <infinity> (We're a bit short on other cross-toolchains)
[16:07] <cjwatson> I think there are one or two, yes
[16:07] <cjwatson> openhackware is one such
[16:07] <cjwatson> forked-daapd might be worth looking at earlier rather than later - a cycle or two ago that was the end of a chain that had infinity and I working on llvm/clang at the last minute
[16:07] <CheezeMonkey> xnox: any way that i can workaround/ solve the problem for my case?
[16:08]  * rbasak looks
[16:08] <infinity> Hah, looks like openhackware has everything it needs in debian/rules already.
[16:08] <cjwatson> and it'd be nice to chase down anything in universe that's failing on all architectures
[16:08] <cjwatson> infinity: don't steal it :)
[16:08] <infinity> But.  But.
[16:08] <infinity> But.
[16:09] <cjwatson> the point of this was to suggest things that were interesting but not intractable
[16:09] <infinity> rbasak: If you take openhackware, be sure to revert the Ubuntu delta before you start.
[16:09] <infinity> (And happy to review when you're done)
[16:10] <xnox> CheezeMonkey: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080701/comments/86
[16:10] <rbasak> $ chdist apt-cache raring search hackware
[16:10] <rbasak> $
[16:10] <rbasak> What am I missing?
[16:10] <infinity> rbasak: pull-lp-source openhackware
[16:10] <infinity> rbasak: You're missing that apt-cache search searches binaries.  Of which there are none.  Cause it's FTBFS.
[16:11] <rbasak> Oh. OK
[16:11] <infinity> rbasak: Actually, since the current Ubuntu delta wants to go away anyway, pull-debian-source openhackware might be more appropriate. :P
[16:11] <rbasak> OK, I'll look at forked-daapd, openhackware and gnash. Thanks!
[16:12] <CheezeMonkey> xnox: thankyou, i'll give it a shot
[16:12] <cjwatson> I usually start with both pull-debian-source -d and pull-lp-source -d when investigating this kind of thing
[16:12] <infinity> cjwatson: Finally trained your fingers to do that?  Took me ages.
[16:12] <infinity> cjwatson: And not sure how I lived without pull* now...
[16:13] <cjwatson> Yeah, the benefit function was high enough ...
[16:13] <cjwatson> Pretty sure I was evangelising it to you for a while :)
[16:13] <infinity> Now, I just need to teach them about apt proxies.
[16:13] <xnox> infinity:++
[16:13] <infinity> Irks me that pull* doesn't hit (or seed) my local cache.
[16:14] <rbasak> So slof was Arch: all but Debian was making it happen to be a powerpc so that the build would work?
[16:14] <infinity> rbasak: Right.  Same with openbios-ppc or whatever it was I fixed.
[16:14] <rbasak> OK, got it. I understand the fix then.
[16:14] <cjwatson> rbasak: in Debian, binaries for the first architecture are uploaded by the developer
[16:14] <infinity> rbasak: Debian builds arch:all on maintainer machines, not on buildds, so the maintainer just builds where they work. :P
[16:14] <cjwatson> i.e. all uploads are source + >=1 binary
[16:14] <rbasak> I see
[16:15] <cjwatson> And over the years we've been hammering out "arch all fails to build on buildds" problems
[16:15] <infinity> rbasak: Anyhow, we build arch:all on i386, so that's where it falls apart a bit.
[16:15] <cjwatson> It's an excellent approximation, but it's not 100%
[16:16] <cjwatson> And we don't have a way to say "please build arch all on some other architecture" - that's quite hard infrastructure work
[16:16] <infinity> And, to be fair, our cross fixes are just as "wrong" as the Debian upstream, from the POV that we don't have cross toolchains from/to every arch.  But at least ours will fail with missing build-deps on the wrong arch, instead of later with some weirdness.
[16:16] <cjwatson> Hence, cross-compilers save the day
[16:16] <rbasak> Would a new "Build-Arch" control field be a clean answer? I imagine that requires the same difficult infrastructure work though
[16:16] <cjwatson> Exactly the same
[16:17] <infinity> rbasak: Bikeshedding about the field name is the easy part.
[16:17] <rbasak> :)
[16:17] <cjwatson> And I think we'd determined it was better to put it in Packages-arch-specific, possibly
[16:17] <infinity> rbasak: But the implementation details (in both DAK and Soyuz) are something I've been trying to find the time to look at.
[16:17] <cjwatson> Or at least that was what I heard last time I talked to Debian ftpmasters about this
[16:17] <infinity> cjwatson: Ew.  Debian's been trying to phase out P-a-s, not make it more relevant.
[16:17] <cjwatson> Just the messenger
[16:17] <infinity> cjwatson: Did someone lose the plot there?
[16:17] <infinity> Hrmph.
[16:17] <cjwatson> This was from Mark Hymers but it was at Debconf in Bosnia
[16:17] <cjwatson> So could be out of date
[16:18] <infinity> Personally, I think it's information that belongs in debian/control, but meh.
[16:18] <cjwatson> You may well be right
[16:18] <infinity> Packages should know what they need to be built, without external infrastructure to supplement that.
[16:19] <infinity> (Same reason we got rid of the hideous sourcedeps mess, and made porters push changes to packages directly, or not be allowed to play if they couldn't play nicely)
[16:19] <infinity> I suppose that dates me a bit.  I doubt many people remember that Debian buildds used to patch source packages on the fly for arch-specific madness.
[16:20] <infinity> Well, and sourcedeps also filled in the missing blanks from Build-Depends, also a thing of the past.
[16:21] <infinity> So, yeah.  Regressing on that firm "source packages should be self-contained" thing is silly.
[16:26] <rbasak> So openhackware and forked-daapd both fail on power due to something related to __stack_chk_fail
[16:27] <rbasak> SO does have solutions for this. But is this expected?
[16:29] <cjwatson> Without having looked at them, the situations are probably different
[16:29] <cjwatson> I suspect that openhackware is trying to build code that runs in an environment where libc isn't available (i.e. a firmware image), and the right fix there is probably to build with -ffreestanding
[16:30] <cjwatson> forked-daapd is probably llvm/clang-related madness of some kind
[16:30] <cjwatson> it's one of the very few packages in the archive that uses clang to build - indeed it uses features specific to it
[16:31] <rbasak> OK, thanks
[16:40] <halfie> hi, does the linker/compiler in ubuntu automatically ignores the "-pie" flag when applied to DSOs ?
[16:42] <bschaefer> doko, ping
[16:43] <doko> ?
[16:44] <bschaefer> doko, hello, I was looking at libgcc1s changelog and saw it was updated recently, and was wondering if there was any chance of ABI breaks from it?
[16:44] <bschaefer> doko, as Im getting some crashes in libfontconfig and pango and recompiling them seems to fix my problem
[16:45] <doko> I'm not aware of any
[16:45] <bschaefer> doko, alright thanks! (didrocks pointed me to talk to you)
[16:46] <didrocks> bschaefer: so it's something else, and I think, you will to dig on what broke it :)
[16:47] <bschaefer> didrocks, yeah, I checked through all the dependencies of libfontconfig and libgcc1 gcc-4.7-base were the only things changed recently
[16:47] <bschaefer> didrocks, but I could have missed something
[16:49] <CheezeMonkey> xnox: no luck :/
[17:31] <rbasak> Does anyone else feel that the first two parameters of chdist are the wrong way round? I'm tempted to write a wrapper for myself. Every time I want to change the command I have to step over the dist. And it seems logically wrong, too.
[17:34] <MrAnderson_> Hi, I just saw that precise comes with GNU make 3.81 (3.82 has been released in 2010). packages.ubuntu.com also shows some 3.81* version number. Is raring really still using a make 3.81 branch? Is this intended?
[17:35] <sarnold> MrAnderson_: note that debian unstable is still on 3.81 as well: http://packages.debian.org/search?keywords=make
[17:36] <MrAnderson_> sarnold: So, the real question is: "why is Debian still shipping make 3.81" and should go to the Debian maintainers?
[17:37] <cjwatson> IIRC there was some incompatibility that was a problem
[17:37] <sarnold> MrAnderson_: yeah; it's in experimental, so presumably someone is interested in getting 3.82 into newer releases..
[17:38] <cjwatson> cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618661
[17:38] <MrAnderson_> cjwatson: indeed, there are quite some incompatibilities. That is why I wondered why some old Makefiles are working fine on Ubuntu while they are failing on Gentoo.
[17:38] <cjwatson> and a bunch of open problems which you can see at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=make-dfsg
[17:39] <cjwatson> We like to keep our development release as working as we can; although I think in this case it's more just that nobody's decided to take ownership of pulling that from experimental and fixing everything up
[17:40] <sarnold> ouch. that doesn't seem like a .81 to .82 version number bump :(
[17:40] <xnox> rbasak: I wonder why are you using chdist in the first place =)
[17:40] <rbasak> xnox: what do you do instead?
[17:41] <xnox> rbasak: pull-lp-source hello precise-security (gives me hello source package from precise) or pull-debian-source hello 3.2-1 (gives me exactly that version from debian) and vise versa.
[17:41] <xnox> rbasak: rmadison hello prints all the version across all releases, or just browse http://pad.lv/u/hello
[17:42] <xnox> rbasak: for builds, I use mk-sbuild and thus it's just "sbuild -d raring foo.dsc" to build in raring's sbuild.
[17:42] <rbasak> xnox: I use chdist for apt-cache show, search, bin2src and src2bin. rmadison doesn't give me all of that and is painfully slow
[17:42] <cjwatson> chdist is useful for simulating apt-get install/build-dep against an arbitrary release
[17:42] <cjwatson> I guess I find the parameter ordering a bit annoying but have got used to it
[17:43] <xnox> rbasak: ok. My host is raring. Are you on a stable release?
[17:43] <rbasak> I'm still on quantal :-/
[17:43] <rbasak> Just haven't got round to upgrading yet
[17:44] <xnox> rbasak: right so for me it's easy =) apt-cache search works as expected against devel-series, and for past releases everything is static hence one only needs to sru things....
[17:44] <rbasak> Right. I see now. I really should just upgrade to raring.
[17:45] <rbasak> I have periods of time when my full disk backup system is unavailable, like right now.
[17:45] <cjwatson> xnox: I'm not aware of any sane non-chdist substitute for the install/build-dep simulation; it's very useful when working on transitions, and is why we have a bunch of pre-canned chdist environments in lillypilly:~ubuntu-archive/
[17:45] <rbasak> Or I'm about to travel. I really should just sort it out and upgrade
[17:45] <cjwatson> (Especially when you want to simulate against raring-proposed or on some arch you don't conveniently have to hand)
[17:46] <rbasak> Examining sid is handy with chdist too actually. I just used it as a reference in preparing a bug report to Debian
[17:46] <cjwatson> Yeah
[17:46] <cjwatson> You can do it with full chroots of course but it's much slower
[17:47] <rbasak> I'm also planning on cronning chdist apt-get --download-only to prime the cache that I haven't quite got round to setting up yet
[17:47] <xnox> cjwatson: well none of the ubuntu-dev-tools and things mention chdist, so it's the first time I hear about it. When I need the usecases you list, I tend to just schroot -c sid for example.
[17:47]  * xnox should look into chdist and what it can do.
[17:47] <cjwatson> xnox: You know now :)
[17:48] <rbasak> I've discovered most dev tools by seeing references of them from others over the years
[17:48] <rbasak> Knowing about dget saved me time copying and pasting three urls all the time for example
[17:49] <rbasak> I think the dev documentation does lack quite a bit. Most people seem to find debian packaging a black art, whereas I find it really elegant tidy (for the most part).
[17:49] <rbasak> I think the difference is caused by a shortcoming in the docs
[17:50] <cjwatson> rbasak: A lot of this is caused by trying to document all the alternatives.
[17:50] <cjwatson> "Hey look we have this incredibly powerful system that can do anything" vs. "Here is a sane simple way to do what you need"
[17:51] <rbasak> Agreed. I think some docs dedicated to simple use cases would be useful
[17:51] <cjwatson> (I share your general feeling, of course)
[18:44] <GunnarHj> slangasek: Hi Steve, did you see my idea at bug 1155327?
[18:44] <tkamppeter> OdyX, hi
[18:51] <tkamppeter> OdyX, I have released cups-filters 1.0.32, which should also get into Raring (important fixes for CUPS browsing, bug 1163764 and more). Can you quickly get it into Debian? Thanks.
[19:00] <seb128> cjwatson, xnox: not sure if you guys are subscribe to ubiquity-slideshow-ubuntu or who is tracking it, but there is a trademark issue on the skype logo shipped there that would be good to solve for raring: 1163504
[19:00] <seb128> bug 1163504
[19:00] <seb128> it seems to be used by lubuntu only at the moment
[19:01] <seb128> I checked with John (who reported the bug) and he said it would be good to fix the packages in main at least (we have some others in universe/multiverse like pidgin-skype)
[19:02] <xnox> seb128: we are not going to respin quantal CDs, so the quantal bug task is a bit moot for ubiquity-slideshow-ubuntu.
[19:02] <seb128> xnox, yeah, feel free to wontfix that one
[19:02] <seb128> xnox, it would still be good to fix for raring
[19:03] <seb128> xnox, we didn't get a specific request about the slideshow, but the email they sent suggested it would be better to just stop using their logo without permission
[19:04] <xnox> seb128: I can tweak and commit the change in the slideshow.
[19:04] <seb128> xnox, thanks
[19:04] <rbasak> infinity: http://people.canonical.com/~rbasak/upload/openhackware/ please
[19:08] <infinity> rbasak: Cool, I'll poke it after I lunch.
[19:08] <rbasak> Thanks. Lunch away! I'm EOD now.
[19:09] <xnox> seb128: done. "* Drop references to Skype™ and its logo. (LP: #1163504)" assigned stgraber to actually upload the change.
[19:09] <infinity> rbasak: Diff looks plausibly sane though, thanks.
[19:09] <seb128> xnox, \o/, thanks for the quick fix
[19:12] <rbasak> infinity: I didn't bother with the case of a powerpc host buildling it. Then we'd want CROSS_PREFIX to be empty. I assumed that it's not worth it since we use i386.
[19:12] <rbasak> (also it's a pain for me to test that)
[19:12] <infinity> rbasak: You could have made the build-dep be [!powerpc] and left the ifeq logic in (though, they reversed BUILD and HOST, so that would have still needed fixing), but meh.
[19:12] <rbasak> Right
[19:13] <rbasak> I followed cjwatson's lead with slof there
[19:13] <infinity> Yeah, I didn't make openbios-ppc buildable on powerpc either.
[19:14] <infinity> I'm now considering revisiting that, so I can push the change to Debian, but carefactor's low.
[19:14] <rbasak> I sent the -ffreestanding to Debian, but not the cross compile stuff
[19:14] <infinity> rbasak: *nod*
[19:15] <infinity> Right, lunch time.
[19:15] <rbasak> Dinner time for me. I'll actually leave now. Enjoy lunch!
[19:16] <seb128> bdmurray, ev, slangasek: do you know why https://errors.ubuntu.com/ just got a spike in 13.04 reports?
[19:17] <infinity> seb128: Beta testing?
[19:18] <seb128> infinity, that should increase the frequency?
[19:18] <seb128> if 1% of users hit a but, having 10 times users should still give you 1%
[19:18] <seb128> but->bug
[19:18] <infinity> Except that every fresh install is a new "user".
[19:19] <infinity> So, if one person has problematic hardware or something they specifically always do differently from others that triggers a bug, and then reinstall 10 times, that would skew things.
[19:19] <seb128> do we have any idea what issue those users are hitting?
[19:19] <slangasek> seb128: also, installs that never see any bugs don't get included in the count because we don't phone home, so new installs (beta testing or otherwise) increase the overall percentage of users hitting bugs
[19:19] <seb128> like what bug is contributing most to the increasE?
[19:20] <infinity> Yeah, that I don't know.  I'm just throwing out wild guesses for the spike.
[19:20] <seb128> k
[19:20] <seb128> so we don't really know if that means that we let a new bug slip through
[19:20] <seb128> or if there is an issue we should focus on
[19:21] <slangasek> seb128: if there is a new bug that's slipped through, it should show up in the crash rankings
[19:21] <seb128> slangasek, nothing "new" in there
[19:21] <ev> so https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Aaptdaemon.errors.AptDaemonError%3A_convert_dbus_exception%3Acancel%3A__call__%3Acall_blocking%3A_on_clicked%3A_deferable%3A_convert_dbus_exception has spiked
[19:21] <ev> but following the beta testing theory, https://bugs.launchpad.net/errors/+bug/1069827
[19:22] <seb128> bug #1026149 is by far the most ranked
[19:22] <seb128> but it's not "new"
[19:22] <ev> https://bugs.launchpad.net/errors/+bug/1077122 is one attempt at fixing this, and it's waiting on a deployment from webops
[19:22] <ev> seb128: it's not new, but it's showing more instances than in recent days prior
[19:22]  * ev goes back to his tea
[19:22] <seb128> ev, thanks
[19:22] <slangasek> this one shows a sudden spike, not sure why that would be except for the beta testing. https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Findicator-weather%3AAttributeError%3Aon_apply%3Aexport_location_details
[19:23] <seb128> slangasek, do you have anyone who could look at this one?
[19:23] <seb128> "this one" being the update-manager one
[19:23] <seb128> not indicator-weather
[19:25] <slangasek> seb128: hmm, the indicator-weather one looks *much* more frequent than the update-manager one, but doesn't rank when looking just at 13.04, strange
[19:26] <seb128> slangasek, the indicator-weather was also much more frequent in december-january
[19:26] <seb128> that's weird as well
[19:26] <slangasek> ev: there seems to be an inconsistency between https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Findicator-weather%3AAttributeError%3Aon_apply%3Aexport_location_details and the main page regarding this crash's frequency in 13.04
[19:27] <slangasek> ev: the per-crash graph shows a clear spike on the 13.04 line, but when viewing crashes for 13.04 on the main page, it claims there've only been 9 reports today
[19:28] <seb128> slangasek, the "by version" table seems to suggest very low raring reports as well
[19:28] <seb128> >= 12.07.30-0ubuntu2 is = 5+1+18=24
[19:29] <seb128> 12.07.30-0ubuntu5 has 18 reports total
[19:29] <seb128> which is the current version for some weeks
[19:29] <seb128> the spike is a 0.00 to 0.04 increase on the graph
[19:30] <seb128> seems like it's a "we had no report and just got 9", which is an big increase...
[19:31] <seb128> but I'm not sure how useful the raring stats are for "common issues", it seems we don't have enough raring users for that
[19:31] <seb128> we were just looking at a compiz bug with the unity guys and the most frequent issue got 11 reports, then we fall to 2
[19:31] <seb128> in a day
[19:32] <seb128> compared to 12.10 which scores 6 issues over 100
[19:34] <xnox> part of the problem the small % of users running raring at the moment. There will be a spike on the release day =/
[19:35] <slangasek> seb128: looks like that u-m bug is a repeat of bug #628104; so it's already on our list
[19:35] <seb128> slangasek, ok, thanks
[19:45] <slangasek> GunnarHj: I'm with jdstrand on this one; we need to get to the bottom of the qtwebkit regression
[19:50] <GunnarHj> slangasek: I'm not of another opinion. Just think a temporary fix would be good for the case the root fix doesn't make it before the release.
[19:52] <GunnarHj> slangasek: But I noticed an issue with my hack, probably because I rename the binary. I'd be happy to modify the fix, but it would be pointless if nobody uploads it anyway...
[21:55] <smoser> slangasek, i added lxc recreate instructions at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1124384
[21:55] <slangasek> smoser: thanks
[21:55] <smoser> which should be very straight forward.