| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| pitti | Good morning | 05:48 |
|---|---|---|
| * pitti takes the plunge and uploads udev, got 10+ positive results now and no regression report | 06:10 | |
| === doko_ is now known as doko | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| doko | infinity, http://gcc.gnu.org/ml/java-patches/2013-q2/msg00046.html | 07:52 |
| ubottu | gcc.gnu.org bug 2013 in c++ "g++ 2.96: typedefs + namespaces + inheritance == problem" [Normal,Resolved: fixed] | 07:52 |
| doko | looks like stdc-predef.h is there since 2.16, but wasn't installed? | 07:52 |
| === liam_ is now known as Guest39447 | ||
| xnox | ScottK: nope. | 07:59 |
| === mmrazik is now known as mmrazik|afk | ||
| theothertom | hello, is this the right place to ask about rebuilding packages in order to move them to /opt ? | 08:47 |
| StevenK | We will not build packages for the Ubuntu archive that install files under /opt. | 08:49 |
| Laney | I think you want #ubuntu-app-devel or #ubuntu-packaging (not sure which, I'm afraid) | 08:51 |
| theothertom | Laney: OK, thanks. I'll check there | 08:53 |
| Laney | theothertom: Cool, good luck. This channel is for "official" Ubuntu development really, I'm afraid - those other places should be more for third party stuff. :-) | 08:54 |
| theothertom | I fell I'll need the luck, this turned out to be harder than it sounded at the start :) | 08:54 |
| henrix | @pilot in | 09:03 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber | ||
| === mmrazik|afk is now known as mmrazik | ||
| mpt | cjwatson, would turning off source packages by default (as in, indexes downloaded during apt-get update) be something changed in software-properties, or ubuntu-meta? | 09:47 |
| cjwatson | Certainly not ubuntu-meta. | 09:47 |
| cjwatson | apt-setup is the place that controls this during installation. But it would also require changing every piece of documentation that assumes that 'apt-get source' works out of the box. | 09:48 |
| cjwatson | Which is one reason I've always resisted this. | 09:48 |
| mpt | ta | 09:48 |
| xnox | mpt: it would be nice, to auto-enable or offer to auto-enable src-lines when one tries to fetch a source package, and no source entries are specified. | 09:50 |
| mpt | I wouldn't care about it except that downloading unnecessary stuff -> update checks complete less often -> security updates installed later on average | 09:50 |
| mpt | xnox, as I understand it, that's bug 301602 | 09:50 |
| ubottu | bug 301602 in software-properties (Ubuntu) "enabling proposed only adds deb line to apt.source, deb-src missing" [Low,Confirmed] https://launchpad.net/bugs/301602 | 09:50 |
| mpt | Oh, no, that's slightly different | 09:50 |
| mpt | but yes, that would be nifty | 09:50 |
| cjwatson | Unfortunately apt-get source runs as the user and apt configuration is owned by root, so it's not trivial. | 09:51 |
| * ogra_ doesnt get why it would delay anything though | 09:51 | |
| cjwatson | It would only cause update checks to complete less often if the duration of updates exceeded the frequency of updates. | 09:52 |
| ogra_ | apart from making apt-get update minimally slower, the source packages should aways match the binaries | 09:52 |
| cjwatson | Which doesn't sound plausible. | 09:52 |
| xnox | sure, one should be able to be able to read those, copy out / guess-generate -src entries for the user and update-fetch as a user =) | 09:52 |
| cjwatson | And in any case the growth of the archive over time eventually dominates ... | 09:52 |
| mpt | cjwatson, what do you mean by "the duration of updates"? | 09:55 |
| cjwatson | The time it takes to complete 'apt-get update' | 09:55 |
| mpt | whereas by "the frequency of updates" you mean how often updates are issued? | 09:56 |
| mpt | or how often apt-get update is run? | 09:56 |
| apw | pitti, was it today we are expecting udev to explode ? | 09:57 |
| ogra_ | mpt, that was clearly hypothetical (the archive growing faster than an apt-get update takes) | 09:58 |
| mpt | ogra_, I'm not sure what it means yet, I haven't yet got to whether it's hypothetical or actual :-) | 09:59 |
| mpt | How long an apt-get update takes is measured in seconds. How fast the archive grows is measured in, what, kilobytes per second? Not even the same units. | 10:00 |
| ogra_ | mpt, apt-get update getting you package-x.1.2 and while it runs version x-2.3 was uloaded, built and promoted | 10:00 |
| mpt | ah I see | 10:00 |
| ogra_ | *uploaded | 10:00 |
| * apw wonders what just happened there... according to my logs you can all type like mad-people :) | 10:00 | |
| apw | pitti, was it today we are expecting udev to explode ? | 10:00 |
| ogra_ | s/getting you package/getting you info about package/ | 10:01 |
| cjwatson | mpt: I mean how often apt-get update is run | 10:02 |
| cjwatson | mpt: What's the basis of your assertion that update checks complete less often? | 10:02 |
| mpt | cjwatson, in that case, I don't see why frequency of updates-being-issued makes any difference at all. Update checks fail to complete because you turn the computer off, or lose the connection, not because a file was changed while it was being served. | 10:02 |
| cjwatson | Oh, right | 10:02 |
| cjwatson | (I wasn't talking about frequency of updates being issued, as it happens. But anyway.) | 10:02 |
| mpt | (I'm assuming Web servers are smart enough to keep around the old copy of a file long enough to serve the rest of it.) | 10:02 |
| cjwatson | If the file is open, the open descriptor continues to refer to the original version | 10:04 |
| cjwatson | And you entirely misunderstood my comment about how fast the archive grows. | 10:04 |
| mpt | Clearly. | 10:04 |
| cjwatson | My point is that turning off deb-src lines is a change we get to make once ever | 10:04 |
| cjwatson | And the growth of the archive over time will dominate quickly enough anyway | 10:05 |
| cjwatson | So, if there's a problem with unreliable updates, we still have to solve it | 10:05 |
| cjwatson | For instance, dapper source + i386 binary index files: 5878756 bytes. hardy ditto: 9671815 bytes. | 10:06 |
| mpt | I don't know that unreliability is something we can "solve", as long as we're using TCP at least. :-) | 10:06 |
| cjwatson | lucid ditto: 14048852 bytes. | 10:07 |
| cjwatson | And the source accounts for rather less than a third of that. | 10:07 |
| cjwatson | (OK, that's gzip, and we might actually end up fetching bz2 in practice, but much the same analysis applies) | 10:08 |
| mpt | Wait, so we could speed up update checks by a quarter or so, and the argument against it is that they'll slow down later? | 10:09 |
| cjwatson | That's not the argument against it; that's just an argument why it doesn't really help in the long term and we have to solve other problems *anyway*. | 10:10 |
| cjwatson | The argument against it is that it significantly complicates any documentation that involves people helping us. | 10:10 |
| cjwatson | (At least by way of contributing to source code.) | 10:10 |
| cjwatson | Or documentation that tells people how to look at the source we provide. | 10:10 |
| cjwatson | If people want to go hunting for that and figure out good ways to make it not suck, be my guest | 10:11 |
| cjwatson | But everyone so far who's proposed this has just ignored the problem | 10:11 |
| cjwatson | Which I don't think is OK ... | 10:11 |
| mpt | All the "Let's switch to bsdiff" or "make -data dependencies smarter" or "parallelize apt tasks" are similarly things that can be done only once in the face of that growing archive. | 10:12 |
| mpt | But I get your point about the documentation. | 10:12 |
| cjwatson | And any of those would also have to be accompanied by going round and looking at the system as a whole and seeing what would need to be adjusted to match. | 10:12 |
| cjwatson | It does look like the growth has slowed a little bit; I think part of this is archive-level changes, and part is that we've got more aggressive about removing packages | 10:13 |
| cjwatson | By solve other problems, I mean that if updates are failing for whatever reason then that is something we need to (a) be tracking and (b) mitigate, perhaps by way of the system trying again earlier than it would otherwise do, for instance | 10:14 |
| cjwatson | At the moment I believe we basically just pop up an indicator and punt to the user? | 10:15 |
| mpt | Most often update checks are done in the background | 10:15 |
| cjwatson | Right, but there is a notification if they fail, I think | 10:15 |
| cjwatson | And I don't think we schedule additional background runs if an update check fails | 10:16 |
| mpt | If you get a notification merely because you restarted the computer during an update check that you didn't know was happening anyway, that would be a bug | 10:16 |
| cjwatson | Oh. So we make no effort at all. | 10:16 |
| cjwatson | Well, I think there's room for the theory that we could be being more aggressive than that. | 10:17 |
| mpt | I don't know. I know there are many bugs about misusing the applet area | 10:17 |
| cjwatson | (And I don't mean by popping up more notifications.) | 10:17 |
| Daviey | xnox: Regarding you suggestion.. you could make apt-get source and alias for pull-lp-source $DISTRIB_CODENAME .. I can't think that many people really use multiple release support. And if they do, they know how to fix it. | 10:17 |
| cjwatson | I guess what I mean is that it seems unlikely that we wouldn't be able to complete an update check at some point during the day, unless the computer wasn't on for long enough to apply the updates anyway. | 10:29 |
| === mmrazik is now known as mmrazik|lunch | ||
| xnox | @pilot in | 10:38 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber, xnox | ||
| Laney | pilotfest | 10:39 |
| seb128 | some fall asleep in the seat? ;-) | 10:40 |
| mitya57 | xnox: hi, can you please look at https://code.launchpad.net/~mitya57/kubuntu-packaging/qt-lp1180067/+merge/164629 ? | 10:46 |
| mitya57 | (last time I fixed ui themes, but completely forgot about icon themes) | 10:47 |
| xnox | mitya57: I see. The patch is interesting. I thout that when we are build with GTK style, we are linked against libgtk-x11 anyway, and thus can use that api directly instead of doing well esentially dlopen?! | 10:49 |
| xnox | anyway do you have a url where it's applied upstream? | 10:49 |
| mitya57 | xnox: I just used the existing stuff from QGtkStyle... | 10:51 |
| xnox | ack. | 10:51 |
| mitya57 | upstream change is https://codereview.qt-project.org/#change,56458 | 10:51 |
| mitya57 | not applied yet, but (as I wrote) I got a pre-approval on IRC | 10:51 |
| xnox | I wonder why they did it this way, instead of using pre-processor. | 10:51 |
| xnox | I was after Qt5 location, but ok. | 10:52 |
| mitya57 | xnox: also, libQtGui.so.4 isn't linked against gtk here | 10:55 |
| xnox | right, so they dlopen everything then. ok. sounds/looks scary to me. | 10:58 |
| mitya57 | yes, that will be weird if qt had a hard dependency on gtk | 10:59 |
| ev | Daviey: can you let my post to ubuntu-server@.u.c through? | 11:07 |
| cjwatson | FYI, if people are wondering (or indeed noticed) why auto-syncing from Debian stopped, or why you can't syncpackage things uploaded there very recently (12 hours or so I think), it's because there was a Debian upload with a syntactically-invalid Maintainer field that caused the LP import to explode. Being fixed on the Debian side. | 11:09 |
| mitya57 | cjwatson: which upload? (just curious) | 11:10 |
| cjwatson | gdb | 11:10 |
| Laney | that seems like an unfortunate failure mode | 11:10 |
| cjwatson | It's not ideal. It's fairly noticeable though :) | 11:10 |
| cjwatson | (I made that same comment on the ops channel) | 11:10 |
| cjwatson | Hah, apparently auto-syncing anything alphabetically less than gdb works, though ... | 11:13 |
| cjwatson | Updating: aafigure alpine calibre commons-daemon flickcurl | 11:13 |
| geser | seb128: you mean like in http://articles.timesofindia.indiatimes.com/2013-05-03/india/39008133_1_flight-attendants-cockpit-airbus-321 ? | 11:23 |
| seb128 | heh | 11:24 |
| === mmrazik|lunch is now known as mmrazik | ||
| === MacSlow is now known as MacSlow|lunch | ||
| cjwatson | SpamapS: does the Ubuntu change in drupal6 to add a debconf note need to be ported over to drupal7? I ask because drupal6 is slated for removal | 12:19 |
| === MacSlow|lunch is now known as MacSlow | ||
| jamespage | is there a nice way to override kernel.core_pattern during a package build? I have a library that wants to generate a core file for testing.... | 12:49 |
| pitti | jamespage: wouldn't it be easier to just set ulimit -c, and use `pwd`/core ? | 12:53 |
| === _salem is now known as salem_ | ||
| diwic | zequence, hi, I saw you submitted merge proposals, have you also tested the result so you know it actually fixes the problem? | 12:54 |
| jamespage | pitti, the test wrapper sets ulimit -c 100000 | 12:54 |
| jamespage | pitti, but I don't get `pwd`/core | 12:55 |
| penguin42 | pitti: That does assume that core_pattern is set to the default when you start | 12:55 |
| jamespage | pitti, in my local schroot the core_pattern is picked up from the host - "|/usr/share/apport/apport %p %s %c" | 12:56 |
| pitti | sure, but why would the buildds chagne that/ | 12:56 |
| pitti | jamespage: right, but apport mimics the original "core" creation, and I don't think that the buildds have it installed | 12:56 |
| jamespage | pitti, hmm - so its probably OK on a buildd - makes testing it locally awkward | 12:57 |
| pitti | jamespage: oh, I thought you were talking about "during package build" on a buildd | 12:57 |
| pitti | jamespage: but again, if you don't get a core file with ulimit -c with apport, that's a bug | 12:57 |
| jamespage | pitti, well I don't get a core file | 12:57 |
| pitti | $ ulimit -c 100000; sh -c 'kill -SEGV $$' | 12:58 |
| pitti | Speicherzugriffsfehler (Speicherabzug geschrieben) | 12:58 |
| pitti | $ file ./core | 12:58 |
| pitti | ./core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sh -c kill -SEGV $$' | 12:58 |
| jamespage | pitti, and from within a schroot? | 12:58 |
| pitti | $ ulimit -c 10000 | 12:59 |
| pitti | -bash: ulimit: core file size: cannot modify limit: Operation not permitted | 12:59 |
| jamespage | hmm | 12:59 |
| jamespage | lemme take another look - something wonky is going on | 13:00 |
| pitti | I'm not sure why I can't do ulimit in a chroot | 13:00 |
| === greyback is now known as greyback|food | ||
| jamespage | pitti, I think its hard limited to 10000 | 13:06 |
| cjwatson | Depends on your chroot, I guess. 100000 WFM. | 13:08 |
| jamespage | pitti, cjwatson: I only get a core in the schroot filesystem if I "sudo sysctl kernel.core_pattern=core" on the host first | 13:10 |
| mardy | kenvandine: hi! I updated https://code.launchpad.net/~mardy/ubuntu-system-settings/proto/+merge/164195 :-) | 13:11 |
| pitti | asac: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 13:13 |
| kenvandine | mardy, great, thanks | 13:14 |
| pitti | asac: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ | 13:14 |
| === greyback|food is now known as greyback | ||
| mlankhorst | can someone approve all the lts-raring packages for precise-proposed in NEW? | 13:26 |
| zequence | diwic: Yes. The bug report is also prepared for SRU | 13:26 |
| pitti | asac: mac80211_hwsim kernel module | 13:26 |
| pitti | asac: and for ethernet, linux' veth | 13:26 |
| zequence | diwic: I'm a bit unsure of what to do next, as far as the SRU goes, but I guess you guys will roll the package,or something. Seems a little different with pulseaudio | 13:28 |
| diwic | zequence, thanks. Once it has been let through to -proposed you will have to do the testing one more time | 13:28 |
| diwic | zequence, but I think you know that already. As for SRU next part is on me to merge and upload. I want to get a few other things through at the same time, so will not upload today. | 13:28 |
| zequence | diwic: So, until the -proposed testing, is there anything more I need to do? | 13:29 |
| diwic | zequence, except hit me in the head if I forget about it. | 13:30 |
| jcastro | slangasek: I need your help when you're around | 13:30 |
| zequence | diwic: I'll remind you by the end of the week then :) | 13:31 |
| kenvandine | mardy, commented | 13:33 |
| pitti | asac: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html | 13:36 |
| mardy | kenvandine: your remark about the rpath is only about src/src.pro, right? | 13:41 |
| mardy | kenvandine: because I think that in the other cases (for tests) it's needed | 13:41 |
| geser | Could someone please do a give-back of ptouch-driver on armhf in saucy-proposed. It got hit by a chroot failure (on heka). Thanks | 13:42 |
| kenvandine | for all of them | 13:42 |
| kenvandine | mardy, it's not needed | 13:42 |
| SpamapS | cjwatson: re drupal6->7 ... I don't think it would be the worst thing if we dropped that delta. | 13:42 |
| mardy | kenvandine: mmm... not even for the tests? But won't they link to the installed library then? | 13:42 |
| kenvandine | i don't think so | 13:43 |
| kenvandine | mardy, nope, tests work fine | 13:44 |
| cjwatson | SpamapS: OK - I can just go ahead and remove drupal6 if that's fine with you, then, since it's been removed from Debian | 13:48 |
| cjwatson | geser: done | 13:49 |
| NikTh | Here I'm again :P | 13:49 |
| NikTh | New problem occurred | 13:50 |
| Laney | @pilot in | 13:50 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber, xnox, Laney | ||
| * Laney prods henrix stgraber xnox to pilot out if applicable | 13:51 | |
| stgraber | @pilot out | 13:51 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, xnox, Laney | ||
| === wedgwood_away is now known as wedgwood | ||
| henrix | @pilot out | 13:52 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, Laney | ||
| NikTh | infinity: Hi.. remember from yesterday where you helped me to solve the problem on how to upload correctly a custom-kernel in a PPA of mine ? :P Here I'm again .. | 13:53 |
| NikTh | I would appreciate little more help on building failure messages. (or anyone else of course who knows and he/she is able to help) | 13:55 |
| mardy | kenvandine: OK, the rpath I had before was wrong. Still, we need that option (set to /usr/lib/system-settings/) otherwise ld won't find it when starting the app | 13:55 |
| NikTh | Go straight to the last lines where the failure message appear | 13:55 |
| NikTh | https://launchpadlibrarian.net/140388814/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth1_FAILEDTOBUILD.txt.gz | 13:55 |
| kenvandine | mardy, ok | 13:55 |
| mardy | kenvandine: I pushed it, and it seems to be working for me; please check | 13:56 |
| mardy | kenvandine: it would work without it, if the lib was installed in /usr/lib | 13:56 |
| mardy | kenvandine: maybe we should leave it there? | 13:57 |
| kenvandine | tests don't work now | 13:57 |
| kenvandine | ./tst_plugins: error while loading shared libraries: libSystemSettings.so.1: cannot open shared object file: No such file or directory | 13:57 |
| kenvandine | mardy, so in this case you need the old rpath back for tests | 13:57 |
| apw | NikTh, that is an ABI handling problem on your side when making your own custom version number | 13:57 |
| mardy | kenvandine: right, for the tests that's needed | 13:57 |
| SpamapS | cjwatson: indeed, remove away :) | 13:58 |
| kenvandine | mardy, so making it a public lib makes adding dev packages less weird | 13:58 |
| kenvandine | but, it isn't really useful for other apps | 13:59 |
| mardy | kenvandine: that applies to many library, OTOH :-) | 13:59 |
| kenvandine | mardy, your call, i don't mind either way | 13:59 |
| kenvandine | indeed | 13:59 |
| mardy | kenvandine: I'd vote for /usr/lib | 13:59 |
| kenvandine | ok | 13:59 |
| kenvandine | it is versioned | 13:59 |
| kenvandine | so ok :) | 13:59 |
| NikTh | apw: Thanks. Do you know the procedure to get over this problem ? I read somewhere that I have to disable the modules dependencies or something like that, but how ? | 14:00 |
| kenvandine | mardy, but plugins should still go in PLUGIN_MODULE_DIR | 14:00 |
| apw | NikTh, it looks like you have disabled the abi-check but not the modules check | 14:00 |
| apw | NikTh, did you add like abi_check=false or something somewhere ? | 14:00 |
| NikTh | apw: no. I did nothing except to change the debian/changelog (first line only) | 14:01 |
| apw | hmmm. | 14:01 |
| NikTh | apw: maybe this will help you to give me a solution (I did not understood what the say.. newbie here. Well I understood but I don't know how to disable modules-check) | 14:03 |
| NikTh | apw: https://lists.ubuntu.com/archives/kernel-team/2009-October/007423.html | 14:04 |
| === oSoMoN_ is now known as oSoMoN | ||
| mardy | kenvandine: indeed. Check what I pushed | 14:05 |
| mardy | kenvandine: seems to work fine here | 14:05 |
| geser | cjwatson: could you also do a give-back of libgphoto on armhf in saucy-proposed too please. Looks like heka has several chroot failures lately. | 14:05 |
| mardy | kenvandine: I think I delete all the stale stuff, and after a make install it works | 14:05 |
| apw | NikTh, i think you added a whole new version stanza at the top of the changelog which means you need to mangle the abi/module data or you need to disable it. to disable them you would add skipabi=true and skipmodule=true to debian/rules | 14:06 |
| kenvandine | ewww... make install is evil :) | 14:06 |
| cjwatson | SpamapS: done, thanks | 14:07 |
| NikTh | apw: the change at debian/changelog was from 3.8.0-21.32ubuntu1 to 3.8.0-21.32ubuntu1~nikth1 . Nothing else | 14:07 |
| cjwatson | geser: done. the first attempt segfaulted, so let's see ... | 14:08 |
| kenvandine | mardy, ok, i'm happy with this | 14:08 |
| NikTh | apw: but I will try what you suggested and see. | 14:08 |
| apw | NikTh, the ubuntu1 is not in any of our packages, that was added by someone, or perhaps you did dch -i | 14:08 |
| kenvandine | give me a few minutes and i'll propose a branch with a few packaging changes | 14:08 |
| kenvandine | then we'll get it all merged into trunk | 14:08 |
| mardy | kenvandine: excellent! | 14:08 |
| NikTh | Yes I did dch -i , but the first line was already 3.8.0-21.32ubuntu1 | 14:09 |
| apw | dch -i adds the ubuntu1 version before you see the editor, so you did add it, you just don't know you did :) | 14:09 |
| NikTh | apw: hahahaha probably.. | 14:09 |
| apw | NikTh, it is probabally worth bringing specific kernel issues to #ubuntu-kernel channel where you are more likely to get a kernel expert to notice | 14:10 |
| === deryck is now known as deryck[afk] | ||
| NikTh | apw: If I remove this ubuntu1 will everything build correct ? | 14:10 |
| apw | NikTh, nope, it is the act of adding a new version to the changelog which messes up the abi handling, it is using that to determine the previous version and thus where to compare the abi to | 14:11 |
| NikTh | apw: no matters, I will try both. (disable modules check and rename the version) | 14:13 |
| === kentb-out is now known as kentb | ||
| NikTh | apw: I think I found MY mistake. I have screwed up ABI because I wanted to build 3.8.0-21.32 for raring , but the second line in debian/changelog indicated that this version belongs to raring-proposed | 14:19 |
| cjwatson | I doubt that is your problem. | 14:19 |
| cjwatson | raring-proposed is basically an incoming queue for raring (pre-release) or raring-updates (post-release). | 14:20 |
| NikTh | cjwatson: :-) | 14:21 |
| apw | NikTh, your pro | 14:22 |
| apw | NikTh, your problem absolutly is that the first version is -21.32u | 14:22 |
| NikTh | apw: LoL | 14:22 |
| apw | NikTh, your problem absolutly is that the first version is -21.32ubuntu1 etc and the second is -21.32 when the abi thinks its is -19.31 | 14:22 |
| apw | NikTh, you either need to pull in the right abi information or more sensibly disable the checks | 14:23 |
| apw | really, i build a lot of kernels | 14:23 |
| tvoss | slangasek, you around? | 14:23 |
| kenvandine | mardy, https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/packaging/+merge/164904 | 14:24 |
| NikTh | apw: This is the thing now. How to pull the right abi info ? Now I have changed the version from 3.8.0-21.32ubuntu1~nikth1 to 3.8.0-19~nikth1 and built this version against raring | 14:25 |
| NikTh | apw , cjwatson : But cjwatson doubts that is the problem (raring against raring-proposed where the .21.32ubuntu1 belongs) :P | 14:26 |
| apw | NikTh, you wuld need to get the abis for -21.32, and frankly what you are doing is makeing a non-abi compatible version of -21 abi so it make literally no sense to check the ABI | 14:26 |
| apw | NikTh, raring and raring-proposed are the same from an upload point of view, they are rewritten to the same thing, and the ABI checker h | 14:27 |
| apw | has no interest in the series or pocket | 14:27 |
| NikTh | apw : Ok, understood. | 14:27 |
| kenvandine | mardy, once you add a .pc file i can test building a plugin out of tree | 14:29 |
| seb128_ | kenvandine, mardy: oh, nice | 14:34 |
| kenvandine | :) | 14:34 |
| === seb128_ is now known as seb128 | ||
| slangasek | tvoss: hi there | 14:41 |
| slangasek | jcastro: what's up? | 14:41 |
| jcastro | I am stuck between a rock and a hard place with MAAS: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283 | 14:42 |
| ubottu | Launchpad bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed] | 14:42 |
| jcastro | tldr; the maas we're shipping in 12.04 is not working well enough for users | 14:42 |
| slangasek | jcastro: right, and for that reason an exceptional SRU has been permitted here... but from what I'm reading of the bug log, the SRU will regress things for users on install? Why is that not just something that someone is fixing in the maintainer script? | 14:46 |
| jcastro | roaksoax: ^^^ | 14:47 |
| roaksoax | slangasek: it will not regress anything. The doubts that ScottK had were clarified and he was ok with the SRu. What I'm waiting on now is python-celery | 14:49 |
| roaksoax | jcastro: the SRU is stuck because of dependencies (python-celery SRU) | 14:49 |
| slangasek | ok, then I guess I'm not sure where the rock and hard place are | 14:49 |
| slangasek | roaksoax: if the doubts were clarified, it's probably good to get that reflected in the bug status | 14:50 |
| cjwatson | If Scott's OK with the SRU, it'd be nice if that were clear from the bug; the last comment is a question from him ... | 14:50 |
| roaksoax | slangasek: so i'm just waiting for someone to process python-celery SRU and everything else should fall into place once that gets accepted | 14:50 |
| slangasek | because what cjwatson said, and also the bug is still verification-failed | 14:50 |
| rbasak | Might it be an idea to keep the whiteboard area updated with current blockers and status? | 14:50 |
| roaksoax | cjwatson: yeah we discussed that over the IRC channel and never updated the bug report | 14:50 |
| slangasek | ScottK: ^^ are you happy now with bug #1109283 proceeding? If so, would you mind adding a comment to that affect and clearing the v-failed tag? | 14:51 |
| ubottu | bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed] https://launchpad.net/bugs/1109283 | 14:51 |
| jcastro | slangasek: sorry was on a call, my rock/hardplace is that users are having a hard time getting maas to work | 14:52 |
| cjwatson | That's just the rock part, isn't it? :) | 14:52 |
| roaksoax | slangasek: so before maas can land we also need this: bug 1177855 | 14:52 |
| ubottu | bug 1177855 in celery (Ubuntu Precise) "[SRU] Drop Build-Depends on python-sphinxcontrib.issuetracker" [Undecided,New] https://launchpad.net/bugs/1177855 | 14:52 |
| roaksoax | jcastro: are all the users using precise? | 14:53 |
| jcastro | cjwatson: my hard place was being confused as to what exactly is keeping the SRU stuck, which we appear to be resolving now. | 14:53 |
| slangasek | ok :) | 14:53 |
| mitya57 | xnox: I have no clue on what those FTBFS errors mean :( | 14:54 |
| jcastro | roaksoax: That's a guess on my part. | 14:54 |
| jcastro | But I'm going to go out on a limb and say that the MAAS in LTS for server users should be way awesomer than "yeah well, go use a PPA and then chase down roaksoax in order for it to work, sorry!" | 14:55 |
| roaksoax | jcastro: well if they use MAAS from precise and juju from PPA, obviously they are going to have troubles becuase juju from PPA is new upstream releases that might have regress stuff | 14:55 |
| xnox | mitya57: btw, retext segfaults in saucy. | 14:55 |
| cjwatson | Ah, good, libgphoto2/armhf finally built | 14:55 |
| jcastro | roaksoax: I'm working with mgz to provide new juju in -backports | 14:55 |
| mitya57 | oh :( | 14:55 |
| * mitya57 is still on raring | 14:55 | |
| roaksoax | jcastro: cool. But keep in mind that using juju from PPA will obviously break things if it is not the cobblerless maas | 14:56 |
| roaksoax | which is really not MAAS' fault | 14:56 |
| roaksoax | so if users were to use juju from precise and maas from precise they should not have any problems | 14:56 |
| jcastro | roaksoax: I figure with MAAS SRU'ed and pyju and goju in backports that would be enough | 14:56 |
| roaksoax | because we are telling them "use what we support on the LTS, but not juju" | 14:56 |
| roaksoax | jcastro: yes the SRU would but not what it currently is in the archives | 14:57 |
| jcastro | ok, so basically, worry about the SRU for now, and then we can revisit the juju thing after? | 14:57 |
| xnox | mitya57: not sure either. cosmic rays? something funky in saucy-proposed? it did build fine on amd64 here locally in sbuild..... | 14:57 |
| mitya57 | looks like archive i386/amd64 builds are also going fine | 14:58 |
| roaksoax | jcastro: I think juju can still hit backports since I expect the SRU would not take that long anymore now that all of the issues/doubts have been resolved/clarified. It is just queue processing that we really need for the dependencies | 14:59 |
| jcastro | ok so is there anything I can do to help? | 14:59 |
| jcastro | or is it just a matter of waiting for celery? | 14:59 |
| roaksoax | jcastro: it is just matter of having someone to process it, since its been sitting in the queue for a few days now | 15:00 |
| jcastro | so it's just a matter of being the squeakiest wheel at this point? | 15:04 |
| mitya57 | xnox: "btw, retext segfaults in saucy." — are you using stock pyqt or one compiled against qt5? | 15:05 |
| xnox | mitya57: possibly =)))) | 15:05 |
| mitya57 | xnox: it can be the problem in QFont constructor I've been mailing about (anyway they are removing qt5 support from pyqt4 now) | 15:06 |
| roaksoax | jcastro: Yeah | 15:07 |
| Laney | Riddell: You might like to look at https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/qtwebkit-source/raring_231/+merge/160068 which could get you out of qtwebkit-source's current sticky situation | 15:10 |
| seb128 | kenvandine, looking to u-s-s, we need to stop adding packages with arch: "i386 amd64 armhf" just because qtdeclarative is not available on ppc, that's going to bite us back when e.g adding a new arch like arm64 | 15:11 |
| barry | slangasek: did you ever open an uber-bug for the EOF and bad marshal data bugs? | 15:11 |
| Riddell | Laney: it has a sticky situation? | 15:11 |
| barry | bdmurray: ^^ | 15:11 |
| Laney | being stuck in proposed is quite sticky | 15:11 |
| slangasek | barry: no, I assumed we would use the existing bug report | 15:11 |
| Laney | due to being FTBFS on 3/4 arches ... | 15:12 |
| roaksoax | slangasek: could you also please process http://launchpadlibrarian.net/138209431/maas_1.3%2Bbzr1461%2Bdfsg-0ubuntu3_source.changes for raring and copy it to saucy? | 15:12 |
| seb128 | cjwatson, Laney, infinity, slangasek: do you have an opinion on how we should handle the arch list for packages using qt5 knowing that qt5 fails to build on powerpc (v8 not supported/qtdeclarative not working there)? | 15:12 |
| barry | slangasek, bdmurray: well, there are a lot of them ;) i'd like to dupe them all the same one for the changelog entries. any preference on which one to make the master bug? | 15:12 |
| cjwatson | seb128: Architecture: any | 15:12 |
| Laney | yes, don't arch restrict - let that be handled further up the chain | 15:12 |
| seb128 | cjwatson, will that not create issues where things ported from qt4 to qt5 and which were available on ppc will depwait and not migrate? | 15:13 |
| bdmurray | barry: what is the number of the one assigned to you? | 15:13 |
| barry | bdmurray: lp: #1093071 | 15:13 |
| ubottu | Launchpad bug 1093071 in lsb (Ubuntu) "can't import lsb_release in python3 anymore" [Undecided,Confirmed] https://launchpad.net/bugs/1093071 | 15:13 |
| kenvandine | seb128, agreed... we have that all over the place now | 15:13 |
| barry | bdmurray: but it's not restricted to python3 | 15:13 |
| seb128 | kenvandine, why didn't we use arch: any? | 15:13 |
| bdmurray | hmm i thought there was another | 15:13 |
| kenvandine | depwait | 15:13 |
| kenvandine | and | 15:13 |
| * barry looks | 15:14 | |
| kenvandine | daily releases won't publish | 15:14 |
| kenvandine | because it expects ppc to build | 15:14 |
| seb128 | right | 15:14 |
| seb128 | it's hard to say if things are depwaiting because they really wait | 15:14 |
| seb128 | or if they are just stucked on something that will never be there | 15:15 |
| seb128 | cjwatson, ^ do you have any suggestion how to deal with that? | 15:15 |
| barry | bdmurray: nope, i think that's it | 15:15 |
| kenvandine | we have a huge list of packages now that specify the list of arches | 15:15 |
| seb128 | :-( | 15:15 |
| seb128 | "fun" | 15:15 |
| kenvandine | for some insane definition of "fun" :-D | 15:16 |
| kenvandine | seb128, so i wonder if when qt replaces v8 with their new thing... maybe it'll build on ppc :) | 15:16 |
| seb128 | right | 15:16 |
| seb128 | that's not going to be done/land this cycle though, right? | 15:16 |
| kenvandine | i don't think so | 15:17 |
| kenvandine | mardy, do you know when that is expected? | 15:17 |
| kenvandine | i thought someone said for 5.2 | 15:17 |
| bdmurray | barry: I'm still looking | 15:18 |
| kenvandine | seb128, the worst part of that is we don't really have a way to get a definitive list of packages we've done this for | 15:18 |
| seb128 | kenvandine, <rdepends qt5> I guess? | 15:19 |
| seb128 | or qt5declarative | 15:19 |
| kenvandine | i guess for saucy we'll be able to do that | 15:19 |
| kenvandine | for raring we have stuff spread all over PPAs | 15:19 |
| kenvandine | :( | 15:19 |
| seb128 | well, it doesn't hurt for raring ppas | 15:20 |
| kenvandine | indeed | 15:20 |
| seb128 | I would like to solve it in saucy though | 15:20 |
| kenvandine | thankfully we'll be landing it all in saucy | 15:20 |
| kenvandine | so rdepends should give us a list | 15:20 |
| seb128 | we can't just keep pilling packages using "arch: i386 amd64 armhf" to the archive | 15:20 |
| kenvandine | seb128, find me another solution :) | 15:21 |
| seb128 | kenvandine, I'm trying, that's why I started the discussion there | 15:21 |
| kenvandine | :-D | 15:21 |
| bdmurray | barry: ah bug 1058884 | 15:21 |
| ubottu | bug 1058884 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with EOFError in /usr/lib/ubuntu-release-upgrader/check-new-release: EOF read where not expected" [Low,Triaged] https://launchpad.net/bugs/1058884 | 15:21 |
| bdmurray | that's the first one we looked at | 15:21 |
| barry | bdmurray: so let's do this. i'll assign that one to myself and duple all the others that seem related to this one. | 15:22 |
| barry | *dupe | 15:22 |
| Laney | seb128: What's the problem with daily release stuff? That it'll block because ppc won't build? | 15:22 |
| bdmurray | barry: okay, sounds good | 15:23 |
| seb128 | Laney, right, we don't know how to make the difference between a valid and a buggy depwait | 15:23 |
| seb128 | "buggy" | 15:23 |
| seb128 | one that will never unblock | 15:23 |
| Laney | care/not care | 15:23 |
| seb128 | like qt5declarative | 15:23 |
| seb128 | Laney, "care/not care"? | 15:23 |
| seb128 | ah | 15:24 |
| Laney | None of them are buggy - you're just choosing what to care about | 15:24 |
| seb128 | well, ideally we would care about depwaits | 15:24 |
| seb128 | that's why we list all archs but powerpc | 15:24 |
| seb128 | so it doesn't depwait wrongly | 15:24 |
| seb128 | "wrongly" | 15:24 |
| seb128 | the intend is really to say "those are not available on ppc", it feels weird/wrong to achieve that by just letting unresolved depwait status on ppc for those sources | 15:25 |
| roaksoax | jcastro: btw.. i have a surprise for you | 15:25 |
| Laney | I think it's good documentation to do that | 15:25 |
| Laney | and it ensures that whenever the problem gets fixed then you get everything else for free-ish (modulo bugs) | 15:26 |
| Laney | so, I don't know what the ideal solution is --- in proposed-migration things are allowed to migrate if they don't regress | 15:26 |
| Laney | so it would see that powerpc doesn't exist already and consider that to not be worse than what it had before and let it through | 15:27 |
| roaksoax | jcastro: http://www.roaksoax.com/2013/05/getting-started-with-maas-and-juju --> that should provide an overview of how MAAS works, I'll continue to write more blog posts with a quick start | 15:27 |
| seb128 | Laney, how do you know that the depwait is fine to "skip"? | 15:27 |
| seb128 | Laney, we might depwait on a new libunity where the depwait shouldn't be skipped | 15:27 |
| Laney | it looks at the binaries produced and sees if it got worse than before | 15:28 |
| cjwatson | kenvandine,seb128: proposed-migration won't care if an architecture doesn't build as long as it wasn't built previously | 15:28 |
| cjwatson | ah, Laney said that | 15:28 |
| cjwatson | this really does basically just work | 15:28 |
| Laney | so I suppose daily release could do something like that | 15:28 |
| seb128 | cjwatson, what if it existed before (case for apps doing qt4 -> qt5) | 15:28 |
| cjwatson | worst case, we remove those binaries | 15:29 |
| seb128 | ? | 15:29 |
| * didrocks proposed that and seb128 came with the exact same right example :) | 15:29 | |
| cjwatson | encoding it in Architecture is wrong either way | 15:29 |
| seb128 | right, we just did it because we didn't find a right solution :/ | 15:29 |
| seb128 | well we did it for a small set as a workaround | 15:29 |
| seb128 | but it's time we tackle that properly | 15:29 |
| kenvandine | small has grown | 15:29 |
| Laney | indeed, deleting the binaries can be thought of as documenting the new situation | 15:29 |
| Laney | sorry, this thing (intentionally) doesn't work any more | 15:30 |
| seb128 | didrocks, do you think you could add the "publish even if ppc is depwaiting if the binary never existed" logic? | 15:30 |
| didrocks | seb128: can add that to my TODO, but let's target that for next week though | 15:30 |
| seb128 | didrocks, thanks, I will open a bug | 15:31 |
| seb128 | kenvandine, ^ | 15:31 |
| didrocks | seb128: excellent, thanks! | 15:31 |
| kenvandine | thanks | 15:31 |
| seb128 | Laney, cjwatson: thanks for the advices | 15:31 |
| didrocks | seb128: hum, there is an issue with bootstrapping though | 15:31 |
| didrocks | let's say you create libunity2-dev | 15:31 |
| didrocks | this never existed on any arch | 15:32 |
| didrocks | so the first arch which published wins? | 15:32 |
| didrocks | publishes* | 15:32 |
| === mmrazik is now known as mmrazik|afk | ||
| kenvandine | didrocks, so maybe you should check for a list of required arches? | 15:32 |
| didrocks | kenvandine: sounds even more hackish :) | 15:33 |
| kenvandine | less hackish than all the packages listing the arches :) | 15:33 |
| seb128 | cjwatson, Laney: how the proposed -> archive migration works for new packages? | 15:33 |
| kenvandine | so you require at least amd64, i386 and armhf | 15:33 |
| seb128 | that seems wrong and being back to hardcode archs | 15:33 |
| didrocks | kenvandine: it would mean we don't care about powerpc, so if we don't care, we should maybe remove it :p | 15:33 |
| cjwatson | seb128: it requires at least one binary; any more that come along are migrated separately | 15:33 |
| seb128 | cjwatson, ok, so they migrate as they build? | 15:34 |
| cjwatson | (phone, btw) | 15:34 |
| didrocks | so not a nice behavior for daily release, as we don't have this "let's migrate one, then another one and so on…" | 15:34 |
| seb128 | I guess you can try to detect new packages and force a manual overwrite for first publishing | 15:35 |
| seb128 | like "if that package isn't in the archive yet, don't publish" | 15:35 |
| kenvandine | oh, well there will be a packaging change | 15:35 |
| kenvandine | adding the new binary | 15:35 |
| kenvandine | so that requires a manual publish anyway | 15:35 |
| xnox | mitya57: i hit retry button on armhf/powerpc, in case it's simply run out of disk space / cosmic rays. if they fail again, will escalate for someone to poke those builds harder. | 15:35 |
| didrocks | kenvandine: right, but we don't want to say "everything is green" when there was a failure | 15:36 |
| kenvandine | yeah | 15:36 |
| didrocks | because for ignored everything but the first arch which published | 15:36 |
| didrocks | seb128: not sure, it means, everytime you need to go to "next" ppa while one archive is frozen and the next one not opened yet, you need to revalidate all the apps manually to ignore powerpc… | 15:37 |
| didrocks | in the present case | 15:37 |
| didrocks | I would rather go with kenvandine's idea of "required archs" | 15:37 |
| seb128 | whatever works for you, as long as we can go back to have "arch: any" in the sources ;-) | 15:37 |
| kenvandine | at least then the list of arches is maintained in one place | 15:38 |
| mitya57 | xnox: thanks | 15:38 |
| didrocks | seb128: I shouldn't have listen to you in the first place it seems though, I would have implemented that :p | 15:38 |
| kenvandine | and if ppc starts working at some point, we can add that to the required list | 15:38 |
| didrocks | kenvandine: yeah | 15:38 |
| didrocks | ok, let's do that | 15:38 |
| seb128 | didrocks, sure, blame it on me :p | 15:38 |
| didrocks | seb128: completely! :-) | 15:39 |
| kenvandine | seb128, it's always your fault :) | 15:39 |
| didrocks | seb128: mind opening a furious bug? | 15:39 |
| seb128 | didrocks, will do, with french swear words included | 15:40 |
| didrocks | seb128: I don't expect less from you :) | 15:40 |
| apw | pitti, ok the script i want to modify is a debian extra, so not upstream | 15:43 |
| pitti | apw: ah, good; BTW, I have another change to make to systemd (most recent udev upload, which I didn't incorporate yet) | 15:44 |
| pitti | apw: how urgent is your change? if it has time until tomorrow, perhaps you can just send me your diff, and I put it into my local packaging git and do that other change tomorrow morning? | 15:45 |
| apw | pitti, not at all urgent | 15:45 |
| apw | pitti, i'll add a debdiff to the bug and point you at it; once i have some testing in | 15:46 |
| pitti | apw: splendid, thanks | 15:46 |
| jamespage | pitti, core pattern looks OK on builds - https://launchpadlibrarian.net/140395622/buildlog_ubuntu-saucy-amd64.libunwind_1.1-1ubuntu1_UPLOADING.txt.gz | 15:53 |
| pitti | jamespage: ah, good; so it's something in schroot which disallows ulimit ? | 15:55 |
| jamespage | pitti, it restricts ulimit; but the core_pattern from the host appears to stop it dumping a core file to the local directory | 15:56 |
| jamespage | at least thats the behaviour I see | 15:56 |
| jamespage | ulimit -c 10000 was OK | 15:56 |
| === deryck[afk] is now known as deryck | ||
| mnaumann | hi, could a patch pilot please review the patch discussed at https://bugzilla.xfce.org/show_bug.cgi?id=9709#c29 and https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1104435 and upload the patch to saucy, or package upstream 4.10.1 (saucy currently has 4.10.0) which fixes this? | 16:00 |
| ubottu | bugzilla.xfce.org bug 9709 in General "periodic crashes of xfce4-session" [Normal,New] | 16:00 |
| ubottu | Launchpad bug 1104435 in xfce4-session (Ubuntu Saucy) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [High,Triaged] | 16:00 |
| mnaumann | (that's according to the chanelog at http://git.xfce.org/xfce/xfce4-session/tag/?id=xfce4-session-4.10.1 ) | 16:01 |
| tvoss | ricmm, ping | 16:05 |
| ricmm | tvoss: pong | 16:06 |
| cjwatson | seb128,didrocks: For daily releases, you could do exactly the same thing proposed-migration does: that is, copy once some minimal set of architectures builds (you might want that to be i386 amd64 armhf, rather than p-m's "any one") and once you have at least as many architectures as before, and you can just re-copy the same version if another architecture arrives later | 16:10 |
| didrocks | cjwatson: yeah, not sure about the recopy, but first step, I'll do as you tell. Thanks! :) | 16:12 |
| infinity | s/at least as many/the same list of/ | 16:12 |
| cjwatson | Er. Why? Having more isn't an error. | 16:12 |
| cjwatson | Oh, sorry. I meant >= in the set sense | 16:12 |
| Laney | a superset of | 16:12 |
| infinity | didrocks: The recopy is important, in case a new arch starts working that didn't before. | 16:12 |
| cjwatson | And translated that wrongly into English :-) | 16:12 |
| cjwatson | Apparently my brain thinks of these things in set notation or something. | 16:13 |
| infinity | cjwatson: Sure, and I translated the math wrong too, should have been "the same list or better". :) | 16:13 |
| infinity | (Or, as Laney said, the same list or a superset) | 16:13 |
| didrocks | infinity: hum, if we make the binary copy and it's available in -proposed, it will certainly rebuild there if it's possible, right? | 16:13 |
| cjwatson | And the problem with saying "superset" is you need to clarify that you mean that to include the trivial superset (identity). | 16:13 |
| cjwatson | Ah, didrocks has a point there | 16:13 |
| infinity | True, yeah. | 16:14 |
| Laney | I was going to say something about strictness but gave up caring :P | 16:14 |
| infinity | The beautiful thing about English is that you don't need precision, you just need a bunch of nodding heads that appear to all understand WTF you meant. :P | 16:15 |
| * infinity still prefers math. | 16:15 | |
| * Laney writes an Agda program to express precisely what we mean here | 16:15 | |
| mnaumann | Laney: may i bug you about reviewing the patch discussed at https://bugzilla.xfce.org/show_bug.cgi?id=9709#c29 and https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1104435 and upload the patch to saucy, or package upstream 4.10.1 (saucy currently has 4.10.0) which fixes this? | 16:16 |
| ubottu | bugzilla.xfce.org bug 9709 in General "periodic crashes of xfce4-session" [Normal,New] | 16:16 |
| ubottu | Launchpad bug 1104435 in xfce4-session (Ubuntu Saucy) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [High,Triaged] | 16:16 |
| Laney | mnaumann: You may, but have you tried bugging the Xubuntu developers (#xubuntu-devel) first? | 16:16 |
| Laney | xfce4-session certainly has other problems that I'm aware of that are fixed by .1 (logind) | 16:17 |
| seb128 | Laney, find the bug I mentioned earlier back, bug #1181565 | 16:18 |
| ubottu | bug 1181565 in casper (Ubuntu) "wrong permissions on $HOME/.local/ on live session" [Undecided,New] https://launchpad.net/bugs/1181565 | 16:18 |
| mnaumann | Laney: have not, will do. | 16:18 |
| xnox | Laney: mnaumann: I just uploaded that into saucy. | 16:18 |
| mnaumann | oh thanks xnox | 16:18 |
| Laney | thanks | 16:19 |
| xnox | mnaumann: for raring though, it needs bug-report description to be adjusted to match https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template | 16:19 |
| xnox | mnaumann: i presume you do want it as raring SRU. | 16:19 |
| Laney | the upstream update should definitely be done quite soon though, assuming you didn't mean that you did that | 16:19 |
| * xnox polishes the xubuntu-fake-dev badge on my profile. | 16:19 | |
| xnox | Laney: correct. All i did was upload into raring. The patch made sense to me anyway =) | 16:20 |
| Laney | saucy | 16:20 |
| xnox | @pilot out | 16:20 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney | ||
| Laney | seb128: interesting. I suppose it could be the same thing if nothing else creates ~/.local | 16:20 |
| seb128 | Laney, I confirm, I just tested with a test user | 16:21 |
| seb128 | $ ls .local/ -l | 16:21 |
| seb128 | total 4 | 16:21 |
| seb128 | drwx------ 3 ubuntu ubuntu 4096 mai 21 18:20 share | 16:21 |
| ubottu | Ubuntu bug 4096 in meld (Ubuntu) "meld: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4096 | 16:21 |
| seb128 | Laney, after running g-s-d | 16:21 |
| seb128 | I guess it's just using the permission of the mkdir | 16:21 |
| seb128 | the mkdir for .local/share/sounds I mean | 16:21 |
| Laney | that should be fixed now | 16:22 |
| Laney | but it is g_whatever_with_parents, yeah | 16:22 |
| Laney | hrm | 16:22 |
| seb128 | Laney, I'm trying https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=7f4af9ab7824c0479e3f4e77742042949b6d32da | 16:23 |
| Laney | someone ... didn't ... add both patches to series | 16:23 |
| * Laney runs | 16:23 | |
| seb128 | lol | 16:23 |
| seb128 | I've been that someone in the past :p | 16:24 |
| seb128 | Laney, no, it seems to be fine | 16:24 |
| seb128 | you updated the patch that was there and added yours | 16:24 |
| Laney | oh no, it wasn't a new patch | 16:24 |
| Laney | yeah, phew | 16:25 |
| seb128 | Laney, I'm testing that commit I just pointed | 16:25 |
| Laney | ok | 16:25 |
| timholum | Hello, I am looking at intigrating my webapp into unity ( Like gmail, google drive and launchpad do ) Is there a tutorial on how to do that? | 16:25 |
| seb128 | Laney, hum, in fact I wonder if that bug is not already fixed | 16:26 |
| seb128 | Laney, the directory is 700 for me, that should be fine, no reason for the outside users to have access to ~/.local | 16:27 |
| mitya57 | seb128, Mirv: Please get an ack from ScottK before re-adding the appmenu patch… | 16:28 |
| Laney | seb128: it gets 0700 for me in a guest session | 16:28 |
| Laney | let me boot an iso | 16:28 |
| seb128 | mitya57, why? | 16:29 |
| seb128 | mitya57, you recommend that we break something in the distro that is working just for the sake of dropping a patch which cause no problem? | 16:29 |
| === mmrazik|afk is now known as mmrazik | ||
| Logan_ | pitti: Are you around? | 16:30 |
| seb128 | Logan_, hey, it might be a bit after his core hours, he starts early, you better leave your question directly so he can read it/reply later | 16:31 |
| mitya57 | seb128: if you add it back, there will be less interest in implementing it the right way | 16:31 |
| seb128 | mitya57, you don't create interest by breaking Ubuntu... | 16:31 |
| Logan_ | seb128: Kk, I'll message him. | 16:31 |
| Laney | @pilot out | 16:32 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| Laney | will do some more tomorrow, got distracted | 16:32 |
| mitya57 | seb128: I'm fine with it if it'll be fixed later this cycle, I just wanted to make sure ScottK knows about your plans | 16:33 |
| Laney | seb128: looks fine for me on today's daily too, probably was the same bug | 16:34 |
| seb128 | Laney, thanks for confirming | 16:34 |
| seb128 | Laney, oh, you forgot to push your release commit to g-s-d I think | 16:35 |
| Laney | sure did, done now | 16:35 |
| seb128 | thanks | 16:39 |
| pitti | Logan_: back | 16:56 |
| pitti | seb128: oui, c'était l'heure du glace :) | 16:56 |
| seb128 | pitti, ;-) | 16:56 |
| Logan_ | pitti: I sent you a message on Google Hangouts (embracing the future!), but Apport did something weird with my crash report here: https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/1181540 | 16:57 |
| ubottu | Error: launchpad bug 1181540 not found | 16:57 |
| Logan_ | It appeared to just remove the needs-amd64-retrace tag. | 16:57 |
| pitti | Logan_: I don't see a message from you | 16:57 |
| Logan_ | Odd. | 16:58 |
| Logan_ | I sent it to your personal Google+, not the Canonical one, if that helps. :P | 16:58 |
| pitti | Logan_: so the apport retracing service just removed the tag? | 16:59 |
| Logan_ | Yes. | 16:59 |
| * pitti checks log files | 16:59 | |
| pitti | indeed, very strange | 17:01 |
| pitti | no output at all | 17:01 |
| pitti | Logan_: I have a list of affected bugs; I'll re-tag them and watch it | 17:02 |
| Logan_ | kk | 17:02 |
| Logan_ | Thanks! | 17:02 |
| seb128 | pitti, stop feeding the bot with icecreams, it starts being lazy | 17:03 |
| seb128 | ;-) | 17:03 |
| pitti | lol | 17:03 |
| pitti | Logan_: would you mind making it public? that would make things a tad easier for me | 17:03 |
| Logan_ | Sure. | 17:03 |
| === bfiller is now known as bfiller_afk | ||
| Logan_ | pitti: lol, it just removed it again... | 17:21 |
| rickspencer3 | hey pgraner, gema, pitti, etc... nice to see so much green on the saucy smoke tests :) | 17:22 |
| rickspencer3 | http://reports.qa.ubuntu.com/ | 17:23 |
| apw | infinity, yo ... do you know if the Kernel-Version: and Package-Type: fields will be recognised correctly in ubuntu | 17:23 |
| infinity | apw: Package-Type is in dpkg-dev going back to 1.15.7, I'm not sure what Kernel-Version is all about. | 17:24 |
| apw | infinity, well kernel-wedge (which i am merging from debian) has just dropped the XB- and XC- prefixes from them | 17:24 |
| apw | i assume this implies they have moved from 'extensions' to real entries, but i am not so sure who consumes them to be sure that we have the said changes | 17:25 |
| infinity | apw: Kernel-Version should be safe, from what I'm seeing in a glance at dpkg code. | 17:26 |
| apw | infinity, ok so according to the bug which removed them dpkg-dev since 2007 has them, so i assume we are good there | 17:26 |
| * apw calls it good | 17:27 | |
| pitti | Logan_: yes, I know; retracing notify-osd is broken ATM, it cannot find the executable path; I'll investigate tomorrow morning | 17:28 |
| Logan_ | kk | 17:28 |
| * pitti waves good night | 17:28 | |
| Logan_ | Good night! | 17:28 |
| seb128 | pitti, night | 17:28 |
| infinity | apw: Do we build kernel sources on saucy that then get uploaded to lucid? | 17:28 |
| infinity | apw: The Package-Type thing could cause some weird issues on dpkg-dev << 1.15.7, and lucid is 1.15.5.6 | 17:28 |
| === mmrazik is now known as mmrazik|afk | ||
| infinity | apw: Other than that corner case, I see no potential issues here. | 17:28 |
| pgraner | rickspencer3, :) | 17:29 |
| apw | infinity, well i think we should be building the relevant sources packages on the same release we are uploading, right | 17:29 |
| infinity | apw: Ideally, yes, but I suspect that might not always be true. ;) | 17:29 |
| infinity | apw: Oh, except you re-run kernel-wedge in your clean target, don't you? So, even if it's "wrong" in the source package, it'll get unwronged before build. | 17:30 |
| apw | infinity, ok so this would only be uploaded as far back as precise, but there is a risk that people would build real lucid wrong | 17:31 |
| apw | infinity, right it is only wrong in what is used at source package build time, in a real build we re-re-build it to make it arch specific | 17:31 |
| apw | infinity, so that sounds like we are good to go | 17:31 |
| infinity | apw: Kay, then it should probably all be fine anyway. | 17:31 |
| apw | infinity, thanks for the sanity check | 17:31 |
| infinity | apw: (Though it's also true that, in theory, the lucid source packages should be generated in a lucid chroot, I just suspect that's not always the case) | 17:32 |
| apw | infinity, i know that to not always be the case :(, though i have just at sprint supprised people by reminding them it was true | 17:32 |
| rbasak | infinity: oops, forgot to poke you about facter. Too late? I'm EOD now :-/ | 17:33 |
| infinity | rbasak: I can give it a review in a bit. If it needs fixing before I sponsor, I'll either JFDI and let you know what I did, or email you for a back-and-forth. | 17:34 |
| rbasak | infinity: thanks! | 17:34 |
| infinity | rbasak: Or stay connected to IRC so I can spew running commentary to you while you sleep. :P | 17:34 |
| rbasak | Sure. I'll see it in my awaylog in the morning. | 17:34 |
| rbasak | (not bedtime yet - but I'm out this evening) | 17:34 |
| infinity | apw: Well, 99% of the time, where you generate your source package doesn't matter. It's just weird cases like this where it comes up. | 17:35 |
| apw | infinity, yeah but as a 'rule' it is a good one | 17:36 |
| infinity | apw: Or the "apt is silly" case, where generating the source package reruns autotools, so you want to keep similar versions to minimize the diff. | 17:36 |
| apw | yeah | 17:37 |
| === bfiller_afk is now known as bfiller | ||
| YokoZar | Has phase 2 of https://wiki.ubuntu.com/MultiarchCross begun yet? Will I be able to start multi-arching build-deps in Saucy? | 19:30 |
| infinity | YokoZar: I'm not sure you're reading that right. | 19:34 |
| infinity | YokoZar: Assuming you mean "can I build-dep on foo:i386 on an amd64 build", that's not what that's talking about, and no, you can't. | 19:34 |
| YokoZar | infinity: Err maybe. I'm more keen on being able to build 32 bit wine on amd64 without needed a chroot | 19:36 |
| infinity | YokoZar: Should I introduce you to sbuild? :) | 19:36 |
| infinity | (Which, yes, uses chroots, but building in your base system is silly anyway) | 19:37 |
| YokoZar | infinity: I'm not sure I can convince upstream devs to build actual packaged wine -- the most common dev workflow is to build wine (for both 32 and 64 bit) simultaneously and then run it within the build tree. | 19:38 |
| dobey | i just wish arch: all packages could be built on any arch, rather than only i386, on the buildds :) | 19:38 |
| dobey | YokoZar: if they're not building packages, what does it matter what Build-Depends can or can't do? | 19:39 |
| infinity | dobey: That's a different problem, and I need to sort out a finished proposal and implementation for that. | 19:39 |
| dobey | infinity: i know. i just figured i'd take the opportunity to moan about an actual issue :) | 19:39 |
| dobey | also. man does it take forever for packages to get built, in my non-work-related PPAs :) | 19:41 |
| YokoZar | dobey: it's more about the coinstallability of -dev packages | 19:41 |
| infinity | YokoZar: Oh, see, I was trying to sort out what you were driving at. | 19:41 |
| infinity | YokoZar: Multiarching -dev packages is entirely supported today, if you so feel the urge. The toolchain will find the headers in the right spots. | 19:41 |
| infinity | YokoZar: But (and this is a big but), if you're moving headers around, beware that rdeps may suffer due to effin' stupid configure checks that look at absolute paths instead of asking the compiler about include locations. | 19:42 |
| infinity | YokoZar: So, a full rdep rebuild test is in order if you multiarch a -dev package that's not a leaf. | 19:42 |
| dobey | oh. hrmm | 19:42 |
| dobey | maybe i should fix some things to add the arch host to --includedir | 19:43 |
| infinity | (See the hideous pain we went through with multiarch python headers) | 19:43 |
| infinity | dobey: Or just ask the compiler, full stop. | 19:43 |
| YokoZar | infinity: Interestingly I suppose I can do the leaf packages first then, unlike with the original multiarch transition where we had to go in the opposite direction. | 19:43 |
| infinity | dobey: Listing every possible header location on Linux (+ multiarch), Solaris, HP-UX, etc, is silly. And /usr/local, and, and... | 19:43 |
| dobey | infinity: listing them ehwere? | 19:44 |
| dobey | where | 19:44 |
| infinity | dobey: As in, configure scripts that test -f {/usr/include,/usr/local/include,etc,etc}myheader.h instead of doing a compile-test with "#include <myheader.h>" and seeing if it's found. | 19:45 |
| infinity | dobey: The former is all too common, but the latter is correct, and requires no changes if headers move, so long as the compiler can still find them. | 19:45 |
| dobey | infinity: oh no. i wouldn't do that. i meant i should change the packages i maintain that install headers, to add --includedir=/usr/include/${DEB_MULTIARCH_HOST}/ to the configure arguments (or do something similarly appropriate for cmake, etc…) | 19:47 |
| dobey | in debian/rules | 19:47 |
| infinity | dobey: Ahh, yes. It gets more fun than that, if you want to minimize bloat. | 19:47 |
| infinity | dobey: If your headers aren't arch-specific, it's *correct* to have them in /usr/include, and the ones that differ should be in /usr/include/<triplet> | 19:48 |
| dobey | infinity: and file conflicts between :i386 and :amd64 are so much fun :) | 19:48 |
| infinity | dobey: Packages that have had to care about this sort of thing since long before multiarch (ie: glibc) already mostly get this right, but most libraries just dump the world in $includedir, so splitting it is an exercise in fun. | 19:48 |
| infinity | dobey: If the files are identical, they don't conflict, that's the point. | 19:48 |
| infinity | dobey: Multiarch is special that way. | 19:49 |
| infinity | dobey: So, it's also true that if you have no arch-specific headers at all, you can just make your -dev package M-A:same and you're done. | 19:50 |
| dobey | ok | 19:50 |
| dobey | then i probably just need to do that | 19:50 |
| infinity | dobey: Err, assuming you're installing other arch-specific stuff (like the .a) to a sane location, of course. | 19:50 |
| dobey | right | 19:51 |
| dobey | i also need to go through and add a bunch of dep8 tests to stuff; but haven't had time to do so yet :( | 19:52 |
| infinity | dobey: Of course, you may have arch-specific headers and not realise it if you're using autotool substitutions for endianness or wordsize macros, etc. | 19:55 |
| infinity | dobey: But simple enough to grab, say, an amd64 and powerpc binary and unpack them and diff /usr/include/* | 19:55 |
| roaksoax | slangasek: it seems that celery is still in the unapproved queue: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= | 20:03 |
| YokoZar | should apt-get build-dep foo:i386 do something under m-a: cross? | 20:05 |
| roaksoax | slangasek: thanks if you just got it accepted :)! | 20:06 |
| slangasek | roaksoax: yeah, that was me | 20:06 |
| slangasek | roaksoax: sorry, don't know why it didn't take the first time | 20:07 |
| roaksoax | slangasek: no worries :). Thanks though :) | 20:07 |
| slangasek | roaksoax: as for maas in raring-proposed: I'll take a look at it, but we are past the window where it's ok to rely on pocket copies of SRUs into the development series; please reupload to saucy separately | 20:08 |
| YokoZar | Oh I see the intended syntax is apt-get --arch=i386 build-dep foo instead of apt-get build-dep foo:i386 | 20:10 |
| roaksoax | slangasek: yeah i wanted it to be a 0-day sru but never got processed unfortunately. Will do | 20:10 |
| roaksoax | thanks | 20:10 |
| roaksoax | slangasek: however, if you prefer it so, I could re-upload to raring with the correct versioning as well. | 20:12 |
| slangasek | roaksoax: I don't mind having a "wrong" version for the SRU and you just incrementing to the next one for saucy | 20:13 |
| roaksoax | slangasek: sure that works for me then! thanks! | 20:13 |
| roaksoax | slangasek: hold on, now that I give a second thought, I want to include another minor fix so I won't have a SRU antoher time | 20:14 |
| roaksoax | slangasek: please reject it and will shortly upload a new version | 20:14 |
| slangasek | ok | 20:14 |
| roaksoax | slangasek: thank you! | 20:14 |
| Noskcaj | kirkland, ping | 21:10 |
| kirkland | Noskcaj: hi | 21:10 |
| Noskcaj | kirkland, yay, he responds. | 21:10 |
| Noskcaj | kirkland, have you got a time for a testdrive hackfest yet? | 21:11 |
| kirkland | Noskcaj: right now? no | 21:11 |
| Noskcaj | kirkland, ok, please let me know when you or andres have time to do one. | 21:12 |
| kirkland | Noskcaj: okay | 21:12 |
| kirkland | Noskcaj: what are you hoping to accomplish in said hackfest? | 21:14 |
| === Kaleo_ is now known as Kaleo | ||
| Noskcaj | kirkland, get someone else admin status, learn a lott more of the code, try and get aas many people as possible helping. the hackfests were very effective with autopilot last series | 21:15 |
| Noskcaj | and to get parallels out, which would make my classroom session a lot easier | 21:16 |
| === salem_ is now known as _salem | ||
| shankstaBytes | if I run make install will that overwrite my package of the same program that is install? | 22:19 |
| cjwatson | That depends on the Makefile. | 22:20 |
| cjwatson | They often default to some other prefix (e.g. /usr/local), but there's nothing I can say here that will apply to all programs. | 22:21 |
| shankstaBytes | cjwatson: i see | 22:21 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!