slangasekLogan_: fwiw you really shouldn't file bugs at severity: serious in Debian for build failures only reproduced in Ubuntu (Debian bug #704572). :)02:36
ubottuDebian bug 704572 in freetds "freetds: Add -lgcrypt to LDFLAGS to fix underlinking" [Serious,Open] http://bugs.debian.org/70457202:36
Logan_slangasek: Ooops. :P What's the appropriate priority?02:37
StevenKJustification being it might well bite Debian soonish02:39
slangasekright - 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 later02:41
pittiGood morning04:22
sarnoldgood morning pitti :) I just found fatrace today. awesome. thanks. :D04:23
vibhavgood morning04:23
pittisarnold: :)04:27
dholbachgood morning06:45
didrockshey dholbach!06:45
didrocks@pilot in06:45
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
dholbachsalut didrocks06:45
* dholbach hugs didrocks06:45
* didrocks hugs dholbach back06:45
=== doko_ is now known as doko
dokoinfinity, could you forward 1154599? is this change intended?06:46
=== amitk is now known as amitk-afk
jibelpitti, 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:43
ubottubug 985049 in apport (Ubuntu) "apport crashed with error in report.py in anonymize(): nothing to repeat - if GECOS field contains regular expression metacharacters" [High,Triaged] https://launchpad.net/bugs/98504907:43
pittijibel: merci, will do07:44
pittijibel: that's covered by tests, I'll add a new one for RE chars in gecos07:44
=== lynxman_ is now known as lynxman
evslangasek: ha!08:01
=== amitk-afk is now known as amitk
dokoachiang, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442990 ?08:23
geserxnox: is the compat tclConfig.sh 'transitional' (till most packages got fixed) or is it going to stay for a long time?08:28
dokogeser, I'd like to see a plan for Debian ...08:31
xnoxgeser: what doko said really. I will forward it to Debian.08:36
xnoxit's up to them to decide.08:36
dokoxnox, see my comment in the report, and maybe cc wookey08:37
dokodobey, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4448145 ?08:37
xnoxdoko: what report?! =)08:38
dokoxnox, bug 112212008:38
ubottubug 1122120 in tk8.6 (Ubuntu) "Multiarchify tcl8.5" [Low,Triaged] https://launchpad.net/bugs/112212008:38
xnoxdoko: 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:40
dokopitti, could you have a look at bug 1163786, gir related ftbfs08:46
ubottubug 1163786 in gcr (Ubuntu Raring) "gcr ftbfs in raring" [High,Confirmed] https://launchpad.net/bugs/116378608:46
pittidoko: ack08:47
seb128pitti, there are quite a bunch of those (though some already got fixed)08:50
dokoright, bamf is another one08:51
seb128pitti, somewhat it shows that updating the "stack" component and not updating GNOME on top creates issues as well08:51
seb128not that it's specific to GNOME, but when we update the whole we get a good part of the build fixes with it08:51
xnoxdoko: seb128: bamf is fixed in lp:bamf, and for some reason it's not autolanding....08:54
xnoxdidrocks: why is bamf not autolanding? we want the FTBFS fixes from lp:bamf =)08:54
didrocksxnox: unity integration tests failed08:55
didrocksah sorry, it's in the indicator stack08:56
didrocksxnox: cyphermox needs to publish manually the indicator stacks08:56
didrocksbecause there are packaging changes08:56
didrocksand see the posts on autolanding, we don't land stuff automatically when there are packaging changes08:56
didrockswe need someone with upload rights "acking" for the changes08:56
didrockssee https://jenkins.qa.ubuntu.com/view/cu2d/view/Raring/view/Indicators/job/cu2d-indicators-raring-3.0publish/08:56
xnoxdidrocks: to be honest, I read the first one and skimmed through the rest =)08:57
didrocksxnox: so ensure cyphermox is reviewing the change today and publish08:59
pittijibel: I fixed that apport crash, and added new tests for this09:10
* pitti looks at gcr09:10
pittiseb128: yeah, GLib.Object doesn't make any sense09:10
pittilooks like https://git.gnome.org/browse/gcr/commit/?id=0b8893 will fix it, checking09:11
jibelpitti, thanks09:11
seb128pitti, ah, that issue is different from the lightdm/bamf ones09:14
cjwatsondidrocks: 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:15
didrockscjwatson: oh sure, didn't notice, sorry about it, doing now09:16
cjwatsondidrocks: thanks, I thought it'd be better this way than cycling round with the sponsoree09:16
didrockscjwatson: agreed ;) and especially for downloading a source of 900+MB ;)09:17
alkisgHi, 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
dokohmm, I remember I did want remove mozilla-gnome-keyring, but I can't remember anymore why ...09:18
didrockscjwatson: done09:19
OdyXtkamppeter_: 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:20
didrocks@pilot out09:22
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== tkamppeter_ is now known as tkamppeter
pittidoko: ah, gcr fix caught in unapproved, but I guess it'll get accepted soon09:29
dokocjwatson, still ok to accept the ftbfs fixes in main?09:30
cjwatsondoko: since beta's in preparation, check with infinity before touching anything on images09:30
cjwatson(and if he isn't around, please wait)09:31
pittixnox: are you on bug 1163293? your last comment sounds like it10:00
ubottubug 1163293 in ubuntu-defaults-builder (Ubuntu) "FTBFS due to obsolete standards version" [Wishlist,Confirmed] https://launchpad.net/bugs/116329310:00
xnoxpitti: i thought i uploaded that.... let me check10:00
pittinot in unapproved10:01
xnoxpitti: 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
pittiah, ok10:03
xnoxbug 116329310:03
ubottubug 1163293 in ubuntu-defaults-builder (Ubuntu) "Should always use latest standards version in the template, instead of hard-coding it." [Wishlist,Confirmed] https://launchpad.net/bugs/116329310:03
xnox=) much better now.10:03
dokopitti, https://launchpad.net/ubuntu/+source/libgda5/5.0.3-2/+build/3936951 (universe, however)10:06
pittididrocks: would you know what "python unityquantal.py" would be?10:06
pittididrocks: looking at bug 116044810:07
ubottubug 1160448 in pygobject (Ubuntu) "python2.7 crashed with signal 5 in g_object_newv()" [Undecided,New] https://launchpad.net/bugs/116044810:07
didrockspitti: I have never seen that file :)10:07
didrockslet me look at the bug10:07
pittididrocks: ok, thanks10:07
pittididrocks: there's not much in it, nevermind10:07
didrockspitti: ok, yeah, I can just say it's not something we ship by default10:07
pittididrocks: I updated the bug, thanks!10:09
didrocksyw :)10:10
=== mmrazik is now known as mmrazik|lunch
dokoxnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4424035 and https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/442403810:48
dokothese use the versioned tcl/tk packages explicitly10:49
xnoxdbarth: 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:49
ubottubug 1152222 in thin-client-config-agent (Ubuntu) "duplicate for #1119279 thin-client-config-agent fails in pycurl with TypeError: string argument expected, got 'bytes'" [High,Confirmed] https://launchpad.net/bugs/115222210:49
xnoximho 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/15680110:50
xnoxdoko: ok. but why? =) can't they just use a default one....11:00
xnoxoh, no, it's tied to versions. ok.11:00
xnoxi guess it also needs multiarching...11:03
xnoxinfinity: doko: also pidgin upload was not necessary as the compat tcltk scripts got uploaded by then already.11:05
=== MacSlow is now known as MacSlow|lunch
=== mmrazik|lunch is now known as mmrazik
=== amitk is now known as amitk-afk
dokodoes somebody know the nick of Logan Rosen?11:32
cjwatsonLoganCloud_ I think11:33
dokoLoganCloud_, your xf86-video-msm upload11:33
=== ckpringle_ is now known as ckpringle
dokoxf86-video-msm (1.0.1+git20100122.5f7df591-3ubuntu1) raring; urgency=low11:33
doko  * No-change rebuild for Ubuntu.11:33
doko -- Logan Rosen <logan@ubuntu.com>  Wed, 27 Mar 2013 20:31:51 -040011:33
dokomaybe No-change, but not merging the ubuntu patches is bad11:34
* cjwatson defeats haskell-cipher-aes/powerpc, woo11:34
=== wedgwood_away is now known as wedgwood
=== wedgwood is now known as Guest65596
dbarthxnox: ok12:18
sunweaverdbarth: hi12:28
* sunweaver 's real name is Mike Gabriel from X2Go upstream12:28
sunweaverdbarth: I have today started on a patch for remote-login-service that adds protocol type "x2go" to the remote-login-service code.12:29
sunweaverdbarth: I guess X2Go for raring has been postponed to later, are you still interested in including X2Go into UCCS?12:30
xnoxsunweaver: it is best to be included in the S-series once it opens.12:30
sunweaverxnox: great.12:32
=== MacSlow|lunch is now known as MacSlow
xnoxsunweaver: very early on, to allow extensive testing =)12:32
dbarthsunweaver: hi Mike12:32
sunweaverxnox: testing can already start, ppa:x2go/stable12:32
sunweaverdbarth: hi David! Hope you are doing well!12:33
dbarthyup, same12:33
dbarthso uccs is frozen right now12:33
sunweaverthe 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
dbarthas a test drive service, not so much activity on it this cycle12:34
sunweaveryou mean UCCS as a concept is frozen?12:35
dbarthsunweaver: the changes you made into remote-login seem a better way to enable x2go access12:35
dbarthsunweaver: yup; i'm keeping it as a test drive, but no code change really; can't be on all fronts12:35
=== wedgwood is now known as Guest36969
sunweaverdbarth: yeah, but they hack X2Go sessions into the freerdp protocol type of remote-login-services.12:36
sunweaverdbarth: sure.12:36
sunweaverwhat X2Go is working on atm is: X2Go Session Broker12:36
sunweaverthe session broker of X2Go shall have a UCCS like communication protocol, so that lightdm can talk to the X2Go Session Broker12:36
sunweaverthus, companies can use remote-login in LightDM, but have their own session broker (for X2Go and RDP atm).12:37
sunweaveras 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 x2go12:38
dbarthsunweaver: i think that's the way to go indeed12:38
dbarthxnox: just testing your fix12:38
sunweaveronce 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
dbarthxnox: what's the next step to land that? can i just use the bug as a way to get past the release freeze?12:39
sunweaverdbarth: thanks for this short chat, I will ping you (and xnox?) once I have valid patches to propose.12:40
xnoxdbarth: 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
dbarthsunweaver: np, thanks for the contrib12:42
xnoxdbarth: that issue got raise on foundations radar to fix for raring release ;-)12:42
dbarthxnox: cool12:42
dokoseb128, glib2.0 now built successfully on cetan12:49
seb128doko, ok, do you know if there any hardware difference between the builders?12:49
seb128it could also just be a flacky test12:49
seb128it's weird we never hit any such issue on the archive builders though12:50
=== amitk-afk is now known as amitk
dbarthxnox: 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 behind12:53
xnoxdbarth: 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:54
=== _salem is now known as salem_
pittiapw: hey Andy, how are you?12:58
xnoxpitti: 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
pittiapw: do you know what needs to happen that a device in sysfs gets a proper driver symlink?12:59
pittiapw: I'm trying to fix that in the mac80211_hwsim module, so that network-manager accepts it12:59
pittixnox: did you actually run the crash through the UI (or -cli) once on the original machine?13:01
pittixnox: it sounds like the .crash file you copied didn't have all the data collected13:01
xnoxpitti: I generated the crash with "apport-cli --save ubiquity.crash ubiquity13:02
dobeydoko: 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
dokodobey, no, retried, and then it did succeed :-/13:02
dobeydoko: oh. do you have a link to the failed build log?13:03
xnoxpitti: crash that I meant to upload is attached to bug 116390213:03
ubottubug 1163902 in ubiquity (Ubuntu) "odly sized machines get odd partitioning" [Undecided,New] https://launchpad.net/bugs/116390213:03
apwpitti, most of the symlinks come as a result of registering things with the right busses13:03
dokodobey, no, it's removed with a new build13:03
pittixnox: odd, something is very wrong there -- no Dependencies: field13:04
xnoxpitti: 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
pittixnox: oh, because it's not installed13:05
xnoxpitti: as it is usually the case for the ubiquity hook, hence it's shipped in apport and not ubiquity package.13:05
pittixnox: so you found a corner case with uninstalled packages and saving reports13:06
pittiapw: that's what I thought, as I don't see anything in other drivers that explicitly sets the "driver" symlink13: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
dobeydoko: ok13:06
xnoxpitti: so, should I open a bug against apport then?13:06
pittixnox: yes, please13:07
xnoxpitti: what might be even more unusual is that I do have ubiquity package installed. But nonetheless the foreign report should be uploaded verbantim.13:08
pittixnox: I think apport uses the Dependencies: field to check whether or not it needs to collect data13:15
dobeyxnox: btw, did we get the u1 sign-in bits into ubiquity (and enabled in raring)?13:15
pittixnox: for this special case we need some other test13:15
xnoxdobey: no. FFe not granted.13:15
xnoxdobey: not merged, not on raring CD.13:16
xnoxdobey: I shall be doing it early in S-series. Are the in-dash payments landing?13:16
dobeyi don't think so, but i know basically nothing about that. i think it might if the rebasing on unity trunk is done/tested/working13:17
dbarthxnox: 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 back13:18
xnoxdbarth: ack.13:18
xnoxdobey: 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:19
dobeyxnox: 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 other13:20
* ogra_ wonders if pitti has an idea what triggers the mount in bug 1160847 every minute 13:49
ubottubug 1160847 in gvfs (Ubuntu) "gvfs should not attempt to mount MTP devices in an endless loop (cluttering your desktop with messages)" [High,Confirmed] https://launchpad.net/bugs/116084713:49
ogra_it seems to be some lower level13:49
pittiogra_: 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 not13:52
ogra_ah, good idea13:52
ogra_i'll test that later today ...13:52
ogra_pitti, thanks !13:53
dholbachmhall119, seb128: do you have an idea who is using the sound indicators in libunity?14:00
mhall119every music player14:01
mhall119several webapps14:02
dholbachmhall119, do you know if there's a list?14:02
mhall119I don't think there is14:02
seb128dholbach, mhall119: I don't know of any14:03
barryxnox, doko yeah bug 1163609 is a nasty one14:03
ubottubug 1163609 in pycurl (Ubuntu Raring) "pycurl FTBFS due to segfault in test suite" [High,Triaged] https://launchpad.net/bugs/116360914:03
dholbachseb128, list you mean?14:04
seb128dholbach, mhall119: most player just do mpris over dbus (rhythmbox for example)14:04
seb128dholbach, I don't know of anything using libunity for sound indicator integration14:04
dholbachah ok14:04
seb128dholbach, if that was your question14:04
dholbachyes it was14:04
xnoxbarry: does that mean you fixed it half an hour ago, since you have finalised your opinion of its ugliness =) ?! =)14:05
barryxnox: ask me that in a half hour :)14:06
dbarthxnox: https://code.launchpad.net/~dbarth/ubuntu/raring/thin-client-config-agent/further-fix-1152222/+merge/156860 should work now14:19
=== mmrazik is now known as mmrazik|afk
xnoxdbarth: looks good. I'll merge and upload today.14:23
xnoxdbarth: thanks a lot for your help!14:23
barryxnox: are you still looking for a review of your thing-client mp?14:23
=== mmrazik|afk is now known as mmrazik
xnoxbarry: for sanity, yes. https://launchpad.net/ubuntu/+source/pycurl/+changelog lists a few uploads related to str/bytes handing inside pycrypto.14:33
xnoxbarry: 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:34
xnoxbarry: 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:35
barryxnox: 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
barryxnox: the latter would be for convenience14:36
barryxnox: of course, if i can't figure out why pycurl crashes, it's all moot anyway ;)14:37
xnoxbarry: it's "web" and potentially we could receive broken / half responses and thus encoding "none"14:37
barryxnox: in which case, bytes is the only thing that makes sense14:37
xnoxok. so I'm not that crazy =)14:37
barrywell, no guarantees that pycurl won't *make* you so ;)14:39
=== ckpringle_ is now known as ckpringle
=== wedgwood is now known as wedgwood_away
didrocksxnox: 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:10
=== wedgwood_away is now known as wedgwood
dokorbasak, may I reject your ntp upload? see bug 116376815:20
ubottubug 1163768 in ntp (Ubuntu Raring) "ntp ftbfs in raring" [High,In progress] https://launchpad.net/bugs/116376815:20
rbasakinfinity: ^^15:21
rbasakdoko: I guess, if you're doing it. Not sure what I'm supposed to do though, if everything I do gets trumped.15:24
rbasakThis is exactly the concern I had yesterday, and it's happened on the first package I've touched.15:24
dokorbasak, sorry, but I mentioned yesterday: please leave a note what you're working on15:25
dokoand I did file the report ...15:25
rbasakdoko: leave a note where?15:25
rbasakIn the topic?15:25
dokorbasak, on #ubuntu+1-maint for example15:26
rbasakdoko: in the topic or in the channel?15:26
dokoI don't care15:26
infinityIn the channel is fine.  But sometimes stepping on toes happens.15:26
xnoxrbasak: fixing haskell-conduit/armhf FTBFS will resolve a fair chunk in the ghc transition, see http://people.canonical.com/~ubuntu-archive/transitions/ghc.html15:29
infinitypitti: Did you do the langpack uploads in the queue?  Seems a bit premature.15:31
pittiinfinity: no, they are from the automatic cronjob I guess15:32
halfiehi, does the linker in ubuntu automatically ignores the incorrect "-pie" flag when applied to DSOs ?15:32
pittiinfinity: I suggest to either leave them in the queue until after the beta, or just reject them and take the next set15:32
pittiinfinity: as we currently have empty update packs and thus minimal size15:32
halfie I am talking about "export DEB_BUILD_HARDENING=1" stuff15:32
infinitypitti: Leaving them in the queue is fine, just makes it a bit unreadable. :)15:33
pittiinfinity: they aren't precious, so feel free to mass-reject15:33
infinitypitti: And I assume we want a final langpack upload in ~2w anyway.15:33
pittithe cron job uploads twice a week15:35
pittiinfinity: right15:35
infinitypitti: I'll reject the lot for now, then.15:36
cjwatsonxnox: please, as I said yesterday, I don't think this is a good target15:37
cjwatsonrbasak: 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 upstream15:37
rbasakcjwatson, xnox: OK, I'll leave that then15: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
xnoxcjwatson: sorry, I missed your comment yesterday about it.15:38
cjwatsonthere 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:39
cjwatsonrbasak: 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:41
rbasakcjwatson: 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:43
cjwatsonI think it's probably inevitable that a lot of the initial work is analysis15:44
infinitySometimes, all of the work is analysis.15:44
infinityIn fact, in main, all of the work is sometimes pinging the TIL "maintainer" and asking if/when they're fixing it, before moving on. :P15:44
cjwatsonYou 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 on15:45
sladenrbasak: 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
cjwatsonAt least as a first-pass filter15:45
infinitysladen: This is specifically in the context of +1maint, not scratching itches (though it's nice when they overlap, sure).15:45
rbasakOK, so I should create a bug with analysis for every package I touch and decide not to try and fix?15:46
infinityrbasak: 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:46
rbasakIs there a script that can create a bug from an ftbfs for me?15:47
infinitySometimes, the analysis is just "argh, too hard" or "I don't speak LangFoo, this is gibberish", and you just move on quickly. :P15:47
rbasak(if not I might write one)15:47
cjwatsonI've not found it worth the effort, since it's generally selective copy-and-paste15:47
infinityIf 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
infinityBut yeah, copy-and-pasting build log snippets isn't all that helpful.15:48
cjwatsonIt can save time if somebody is looking for something to fix that's known to be easy15:50
cjwatsonOr at least not horribly intractable15:50
cjwatsonSame 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 LP15:53
DavieyA 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:55
DavieyWhich is why i thing that a large part of +1 maint should be coordination15:56
DavieyAdding into a channel topic of random packages to touch isn't decent coordination15:56
Davieylet alone outreaching to new contributors15:57
cjwatsonThings like the transition tracker are very useful, though need explanation15:57
xnoxnot 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
xnoxI didn't file bugs or anything....15:58
DavieyOne example is, bug 687976 .. in 2010, i had no idea who xnox was :)15:59
ubottubug 687976 in htmldoc (Ubuntu) "[FTBFS] 'htmldoc' (1.8.27-4.1)" [Undecided,Fix released] https://launchpad.net/bugs/68797615:59
ScottKThe 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
infinityxnox: 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. :P15:59
xnoxDaviey: those were the days =)16:00
rbasakI'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
cjwatsonYeah, I can understand that16:01
* cjwatson has a glance at the list16:01
rbasakI spotted a gnash armhf failure that I think would be useful to fix since gnash is more relevant on !intel.16:02
rbasakI'll look into it. But it's also nice to have two or three on the go at once, since builds take a while16:02
CheezeMonkeyDoes anyone know what could be going wrong if my ubuntu installation always hangs at the "preparing to install ubuntu" stage?16:04
infinityrbasak: The seeded-but-not-in-main stuff at the bottom of the ftbfs list could be worth looking at.16:04
CheezeMonkeyI had once, a little over a year ago, installed ubuntu 10.10 without any issues16:04
infinityrbasak: openimageio, libgda5, etc.16:05
xnoxCheezeMonkey: bug 108070116:05
ubottubug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/108070116:05
cjwatsonrbasak: 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 them16:06
cjwatsonopenhackware and the like - I did slof not that long ago if you want an example16:06
infinityDo 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
cjwatsonI think there are one or two, yes16:07
cjwatsonopenhackware is one such16:07
cjwatsonforked-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 minute16:07
CheezeMonkeyxnox: any way that i can workaround/ solve the problem for my case?16:07
* rbasak looks16:08
infinityHah, looks like openhackware has everything it needs in debian/rules already.16:08
cjwatsonand it'd be nice to chase down anything in universe that's failing on all architectures16:08
cjwatsoninfinity: don't steal it :)16:08
infinityBut.  But.16:08
cjwatsonthe point of this was to suggest things that were interesting but not intractable16:09
infinityrbasak: 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:09
xnoxCheezeMonkey: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080701/comments/8616:10
ubottuLaunchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed]16:10
rbasak$ chdist apt-cache raring search hackware16:10
rbasakWhat am I missing?16:10
infinityrbasak: pull-lp-source openhackware16:10
infinityrbasak: You're missing that apt-cache search searches binaries.  Of which there are none.  Cause it's FTBFS.16:10
rbasakOh. OK16:11
infinityrbasak: Actually, since the current Ubuntu delta wants to go away anyway, pull-debian-source openhackware might be more appropriate. :P16:11
rbasakOK, I'll look at forked-daapd, openhackware and gnash. Thanks!16:11
CheezeMonkeyxnox: thankyou, i'll give it a shot16:12
cjwatsonI usually start with both pull-debian-source -d and pull-lp-source -d when investigating this kind of thing16:12
infinitycjwatson: Finally trained your fingers to do that?  Took me ages.16:12
infinitycjwatson: And not sure how I lived without pull* now...16:12
cjwatsonYeah, the benefit function was high enough ...16:13
cjwatsonPretty sure I was evangelising it to you for a while :)16:13
infinityNow, I just need to teach them about apt proxies.16:13
infinityIrks me that pull* doesn't hit (or seed) my local cache.16:13
rbasakSo slof was Arch: all but Debian was making it happen to be a powerpc so that the build would work?16:14
infinityrbasak: Right.  Same with openbios-ppc or whatever it was I fixed.16:14
rbasakOK, got it. I understand the fix then.16:14
cjwatsonrbasak: in Debian, binaries for the first architecture are uploaded by the developer16:14
infinityrbasak: Debian builds arch:all on maintainer machines, not on buildds, so the maintainer just builds where they work. :P16:14
cjwatsoni.e. all uploads are source + >=1 binary16:14
rbasakI see16:14
cjwatsonAnd over the years we've been hammering out "arch all fails to build on buildds" problems16:15
infinityrbasak: Anyhow, we build arch:all on i386, so that's where it falls apart a bit.16:15
cjwatsonIt's an excellent approximation, but it's not 100%16:15
cjwatsonAnd we don't have a way to say "please build arch all on some other architecture" - that's quite hard infrastructure work16:16
infinityAnd, 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
cjwatsonHence, cross-compilers save the day16:16
rbasakWould a new "Build-Arch" control field be a clean answer? I imagine that requires the same difficult infrastructure work though16:16
cjwatsonExactly the same16:16
infinityrbasak: Bikeshedding about the field name is the easy part.16:17
cjwatsonAnd I think we'd determined it was better to put it in Packages-arch-specific, possibly16:17
infinityrbasak: But the implementation details (in both DAK and Soyuz) are something I've been trying to find the time to look at.16:17
cjwatsonOr at least that was what I heard last time I talked to Debian ftpmasters about this16:17
infinitycjwatson: Ew.  Debian's been trying to phase out P-a-s, not make it more relevant.16:17
cjwatsonJust the messenger16:17
infinitycjwatson: Did someone lose the plot there?16:17
cjwatsonThis was from Mark Hymers but it was at Debconf in Bosnia16:17
cjwatsonSo could be out of date16:17
infinityPersonally, I think it's information that belongs in debian/control, but meh.16:18
cjwatsonYou may well be right16:18
infinityPackages should know what they need to be built, without external infrastructure to supplement that.16:18
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
infinityI 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:19
infinityWell, and sourcedeps also filled in the missing blanks from Build-Depends, also a thing of the past.16:20
infinitySo, yeah.  Regressing on that firm "source packages should be self-contained" thing is silly.16:21
rbasakSo openhackware and forked-daapd both fail on power due to something related to __stack_chk_fail16:26
rbasakSO does have solutions for this. But is this expected?16:27
cjwatsonWithout having looked at them, the situations are probably different16:29
cjwatsonI 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 -ffreestanding16:29
cjwatsonforked-daapd is probably llvm/clang-related madness of some kind16:30
cjwatsonit's one of the very few packages in the archive that uses clang to build - indeed it uses features specific to it16:30
rbasakOK, thanks16:31
halfiehi, does the linker/compiler in ubuntu automatically ignores the "-pie" flag when applied to DSOs ?16:40
bschaeferdoko, ping16:42
bschaeferdoko, 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
bschaeferdoko, as Im getting some crashes in libfontconfig and pango and recompiling them seems to fix my problem16:44
dokoI'm not aware of any16:45
bschaeferdoko, alright thanks! (didrocks pointed me to talk to you)16:45
didrocksbschaefer: so it's something else, and I think, you will to dig on what broke it :)16:46
bschaeferdidrocks, yeah, I checked through all the dependencies of libfontconfig and libgcc1 gcc-4.7-base were the only things changed recently16:47
bschaeferdidrocks, but I could have missed something16:47
CheezeMonkeyxnox: no luck :/16:49
=== Zic_ is now known as Zic
rbasakDoes 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:31
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:34
sarnoldMrAnderson_: note that debian unstable is still on 3.81 as well: http://packages.debian.org/search?keywords=make17:35
MrAnderson_sarnold: So, the real question is: "why is Debian still shipping make 3.81" and should go to the Debian maintainers?17:36
cjwatsonIIRC there was some incompatibility that was a problem17:37
sarnoldMrAnderson_: yeah; it's in experimental, so presumably someone is interested in getting 3.82 into newer releases..17:37
cjwatsoncf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61866117:38
ubottuDebian bug 618661 in make "make: Please package new upstream version 3.82 in experimental" [Wishlist,Fixed]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
cjwatsonand a bunch of open problems which you can see at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=make-dfsg17:38
cjwatsonWe 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 up17:39
sarnoldouch. that doesn't seem like a .81 to .82 version number bump :(17:40
xnoxrbasak: I wonder why are you using chdist in the first place =)17:40
rbasakxnox: what do you do instead?17:40
xnoxrbasak: 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
xnoxrbasak: rmadison hello prints all the version across all releases, or just browse http://pad.lv/u/hello17:41
xnoxrbasak: for builds, I use mk-sbuild and thus it's just "sbuild -d raring foo.dsc" to build in raring's sbuild.17:42
rbasakxnox: I use chdist for apt-cache show, search, bin2src and src2bin. rmadison doesn't give me all of that and is painfully slow17:42
cjwatsonchdist is useful for simulating apt-get install/build-dep against an arbitrary release17:42
cjwatsonI guess I find the parameter ordering a bit annoying but have got used to it17:42
xnoxrbasak: ok. My host is raring. Are you on a stable release?17:43
rbasakI'm still on quantal :-/17:43
rbasakJust haven't got round to upgrading yet17:43
xnoxrbasak: 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
rbasakRight. I see now. I really should just upgrade to raring.17:44
rbasakI have periods of time when my full disk backup system is unavailable, like right now.17:45
cjwatsonxnox: 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
rbasakOr I'm about to travel. I really should just sort it out and upgrade17:45
cjwatson(Especially when you want to simulate against raring-proposed or on some arch you don't conveniently have to hand)17:45
rbasakExamining sid is handy with chdist too actually. I just used it as a reference in preparing a bug report to Debian17:46
cjwatsonYou can do it with full chroots of course but it's much slower17:46
rbasakI'm also planning on cronning chdist apt-get --download-only to prime the cache that I haven't quite got round to setting up yet17:47
xnoxcjwatson: 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
cjwatsonxnox: You know now :)17:47
rbasakI've discovered most dev tools by seeing references of them from others over the years17:48
rbasakKnowing about dget saved me time copying and pasting three urls all the time for example17:48
rbasakI 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
rbasakI think the difference is caused by a shortcoming in the docs17:49
cjwatsonrbasak: 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:50
rbasakAgreed. I think some docs dedicated to simple use cases would be useful17:51
cjwatson(I share your general feeling, of course)17:51
=== deryck is now known as deryck[lunch]
=== Reanimator is now known as herbertwest
=== greyback is now known as greyback|eod
=== wedgwood is now known as wedgwood_away
GunnarHjslangasek: Hi Steve, did you see my idea at bug 1155327?18:44
ubottubug 1155327 in skype (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,In progress] https://launchpad.net/bugs/115532718:44
tkamppeterOdyX, hi18:44
tkamppeterOdyX, 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.18:51
ubottubug 1163764 in cups-filters (Ubuntu) "BrowseAllow required in cups-browsed.conf for CUPS browsing" [Undecided,In progress] https://launchpad.net/bugs/116376418:51
=== deryck[lunch] is now known as deryck
=== nhandler_ is now known as nhandler
seb128cjwatson, 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: 116350419:00
seb128bug 116350419:00
ubottubug 1163504 in ubiquity-slideshow-ubuntu (Ubuntu) "Trademarked assets" [High,Confirmed] https://launchpad.net/bugs/116350419:00
seb128it seems to be used by lubuntu only at the moment19:00
seb128I 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:01
xnoxseb128: we are not going to respin quantal CDs, so the quantal bug task is a bit moot for ubiquity-slideshow-ubuntu.19:02
seb128xnox, yeah, feel free to wontfix that one19:02
seb128xnox, it would still be good to fix for raring19:02
seb128xnox, 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 permission19:03
xnoxseb128: I can tweak and commit the change in the slideshow.19:04
seb128xnox, thanks19:04
rbasakinfinity: http://people.canonical.com/~rbasak/upload/openhackware/ please19:04
=== wedgwood_away is now known as wedgwood
infinityrbasak: Cool, I'll poke it after I lunch.19:08
rbasakThanks. Lunch away! I'm EOD now.19:08
xnoxseb128: done. "* Drop references to Skype™ and its logo. (LP: #1163504)" assigned stgraber to actually upload the change.19:09
ubottuLaunchpad bug 1163504 in unity-asset-pool (Ubuntu Raring) "Trademarked assets" [Undecided,New] https://launchpad.net/bugs/116350419:09
infinityrbasak: Diff looks plausibly sane though, thanks.19:09
seb128xnox, \o/, thanks for the quick fix19:09
rbasakinfinity: 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
infinityrbasak: 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
rbasakI followed cjwatson's lead with slof there19:13
infinityYeah, I didn't make openbios-ppc buildable on powerpc either.19:13
infinityI'm now considering revisiting that, so I can push the change to Debian, but carefactor's low.19:14
rbasakI sent the -ffreestanding to Debian, but not the cross compile stuff19:14
infinityrbasak: *nod*19:14
infinityRight, lunch time.19:15
rbasakDinner time for me. I'll actually leave now. Enjoy lunch!19:15
seb128bdmurray, ev, slangasek: do you know why https://errors.ubuntu.com/ just got a spike in 13.04 reports?19:16
infinityseb128: Beta testing?19:17
seb128infinity, that should increase the frequency?19:18
seb128if 1% of users hit a but, having 10 times users should still give you 1%19:18
infinityExcept that every fresh install is a new "user".19:18
infinitySo, 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
seb128do we have any idea what issue those users are hitting?19:19
slangasekseb128: 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 bugs19:19
seb128like what bug is contributing most to the increasE?19:19
infinityYeah, that I don't know.  I'm just throwing out wild guesses for the spike.19:20
seb128so we don't really know if that means that we let a new bug slip through19:20
seb128or if there is an issue we should focus on19:20
slangasekseb128: if there is a new bug that's slipped through, it should show up in the crash rankings19:21
seb128slangasek, nothing "new" in there19:21
evso 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 spiked19:21
evbut following the beta testing theory, https://bugs.launchpad.net/errors/+bug/106982719:21
ubottuLaunchpad bug 1069827 in Errors "Error rate incorrectly spikes with any influx of machines" [High,Confirmed]19:21
seb128bug #1026149 is by far the most ranked19:22
ubottubug 1026149 in update-manager (Ubuntu) "update-manager crashed with aptdaemon.errors.AptDaemonError in _convert_dbus_exception(): org.debian.apt: Could not cancel transaction" [Medium,New] https://launchpad.net/bugs/102614919:22
seb128but it's not "new"19:22
evhttps://bugs.launchpad.net/errors/+bug/1077122 is one attempt at fixing this, and it's waiting on a deployment from webops19:22
ubottuLaunchpad bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed]19:22
evseb128: it's not new, but it's showing more instances than in recent days prior19:22
* ev goes back to his tea19:22
seb128ev, thanks19:22
slangasekthis 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_details19:22
seb128slangasek, do you have anyone who could look at this one?19:23
seb128"this one" being the update-manager one19:23
seb128not indicator-weather19:23
slangasekseb128: hmm, the indicator-weather one looks *much* more frequent than the update-manager one, but doesn't rank when looking just at 13.04, strange19:25
seb128slangasek, the indicator-weather was also much more frequent in december-january19:26
seb128that's weird as well19:26
slangasekev: 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.0419:26
slangasekev: 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 today19:27
seb128slangasek, the "by version" table seems to suggest very low raring reports as well19:28
seb128>= 12.07.30-0ubuntu2 is = 5+1+18=2419:28
seb12812.07.30-0ubuntu5 has 18 reports total19:29
seb128which is the current version for some weeks19:29
seb128the spike is a 0.00 to 0.04 increase on the graph19:29
seb128seems like it's a "we had no report and just got 9", which is an big increase...19:30
seb128but I'm not sure how useful the raring stats are for "common issues", it seems we don't have enough raring users for that19:31
seb128we were just looking at a compiz bug with the unity guys and the most frequent issue got 11 reports, then we fall to 219:31
seb128in a day19:31
seb128compared to 12.10 which scores 6 issues over 10019:32
xnoxpart of the problem the small % of users running raring at the moment. There will be a spike on the release day =/19:34
slangasekseb128: looks like that u-m bug is a repeat of bug #628104; so it's already on our list19:35
ubottubug 628104 in update-manager (Ubuntu) "update-manager crashes: AptDaemonError: org.debian.apt: Could not cancel transaction" [High,Triaged] https://launchpad.net/bugs/62810419:35
seb128slangasek, ok, thanks19:35
slangasekGunnarHj: I'm with jdstrand on this one; we need to get to the bottom of the qtwebkit regression19:45
GunnarHjslangasek: 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:50
GunnarHjslangasek: 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...19:52
=== francisco is now known as Guest66331
smoserslangasek, i added lxc recreate instructions at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/112438421:55
ubottuLaunchpad bug 1124384 in cloud-init (Ubuntu) "reload-configuration can confuse upstart" [High,Confirmed]21:55
slangaseksmoser: thanks21:55
smoserwhich should be very straight forward.21:55
=== salem_ is now known as _salem
=== wedgwood is now known as wedgwood_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!