| shadeslayer | whom can I poke to mass close bugs? | 00:09 |
|---|---|---|
| === zz_mwhudson is now known as mwhudson | ||
| ScottK | shadeslayer: Do it yourself with the LP email interface. | 02:32 |
| miseria | "ajedrez batalla entre negros y blancos, al final del final el blanco no tendra peones y el negro prevalecera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 03:05 |
| === freeflying is now known as freeflying_away | ||
| WHAT_UP | I don't know if this is more applicable here or in #ubuntu-app-devel, but would anyone know of any problems that would occur were I to add a "queue" command to APT so that "apt-get queue install foo" adds the installation of foo to a queue and installs it once all dpkg locks have been released? | 04:47 |
| sarnold | WHAT_UP: #ubuntu-app-devel is more about phone/tablet/etc click packages .. I don't know if this place is best, but better than #ubuntu-app-devel anyway :) | 04:49 |
| WHAT_UP | Oh. Hah. Okay, thanks! | 04:50 |
| sarnold | WHAT_UP: I like that queue idea, I've got such a short attention span I hate waiting the minute or two for large piles of installs / removals before continuing | 04:50 |
| WHAT_UP | Or more than a minute if you make the mistake of installing something like texlive-full over a slow connection :P. | 04:51 |
| sarnold | ha! I was swearing at texlive just last week.. | 04:51 |
| === BruceMa is now known as BruceMa-afk | ||
| infinity | WHAT_UP: Filing a wishlist bug on apt in Debian would probably be the most appropriate place to discuss it. | 05:09 |
| === elky_ is now known as elky | ||
| === BruceMa-afk is now known as BruceMa | ||
| === IdleOne is now known as io | ||
| _nedr | Hello ubuntu developers thanks for the great work... Just a request when... you're doing your nautilus replacement it would be nice to have as many options in about:config like in firefox... this achieves the triple goal of 1. keeping things modular, 2. gives linux power-users freedom, 3. allow you to change something without the community bursting into flames(we can revert most changes ), 4. allow for great addon ecosystem.. Firefox's addon market-pla | 07:14 |
| _nedr | ce (which predates Apple's App Store) is something Ubuntu (as a whole) should really study to try an emulate | 07:14 |
| _nedr | utorrent is another great example that everyone should strive to emulate in my opinion... 1. It is high-performance 2. Super-sane defaults with more advanced features ready to present itself when (and only when) you want it, 3. Users get more functionality via Preferences (without being overwhelmed), 4. Has an about:config to tweak those settings which only 0.1% of (very vocal and important ) users would ever need... | 07:18 |
| dholbach | good morning | 08:00 |
| dholbach | can an archive admin have a look at the list of file names in http://paste.ubuntu.com/6953343/ and see if that resolves the discussion here: https://bugs.launchpad.net/cordova-ubuntu/+bug/1279814/comments/11? - I'd like to be a bit more certain before the next upload :) | 08:55 |
| ubottu | Launchpad bug 1279814 in Cordova Ubuntu "[needs-packaging] Get cordova-ubuntu-3.4 into trusty release" [Critical,Fix committed] | 08:55 |
| tvoss | doko_, good morning :) | 08:57 |
| tvoss | doko_, I encountered an interesting issue when trying to use ThreadSanitizer with gcc in trusty | 08:57 |
| xnox | dholbach: that looks wrong. | 08:58 |
| xnox | dholbach: only arch independant files are allowed under /usr/share (no tripplets) | 08:58 |
| tvoss | doko_, a very simple example fails to link with gcc but works flawlessly with clang, I sent you a stripped down test case by mail | 08:58 |
| dholbach | xnox, have you seen the discussion in the bug comment? these files are meant to be embedded, not to be used on the local machine - the .deb is a container | 08:59 |
| dholbach | or well, a mechanism so make those files available | 08:59 |
| xnox | dholbach: it should be /usr/lib/<tripplet>/ubuntu-html5-platform-3.4/* | 08:59 |
| dholbach | <seb128> infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed" | 08:59 |
| dholbach | <infinity> Ahh, binaries in /usr/share make sense in that context. But they still shouldn't overlap between arches, if they currently do. | 08:59 |
| dholbach | xnox, ^ | 08:59 |
| xnox | dholbach: i see, crazy =) | 09:00 |
| xnox | dholbach: i will not get involved then =) | 09:00 |
| dholbach | xnox, fair enough - thanks for the review anyway :) | 09:01 |
| tvoss | xnox, hey there. Could you give me a hand with some symbol files I'm struggling with? | 09:01 |
| brendand | dpm, i have another translations question :) | 09:02 |
| dpm | go for it :) | 09:02 |
| spineau | doko_: Good morning, I've just checked http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, the universe dependencies of checkbox-gui are still not mentioned in this report. As their mir bugs are Fix committed, could it be possible to move them to main? bug 1277408 and bug 1278822 | 09:03 |
| ubottu | bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [High,Fix committed] https://launchpad.net/bugs/1277408 | 09:03 |
| ubottu | bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [High,Fix committed] https://launchpad.net/bugs/1278822 | 09:03 |
| xnox | tvoss: sure, what's up? | 09:03 |
| tvoss | xnox, the mp in question is https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols | 09:03 |
| tvoss | xnox, the symbols work on amd64, but they fail on 32 bit platforms. I tried tracking down the issue for a few days now, without success | 09:04 |
| brendand | dpm, in checkbox we use intltool-merge for the .desktop file. did you manage to do something similar in phone apps? | 09:05 |
| dpm | brendand, we generally don't use intltool-merge. In Ubuntu translations from the desktop file are not in the .desktop file, but are rather loaded from the .mo files | 09:06 |
| dpm | brendand, the only think you need to worry about is to extract the translations from it and make sure they're in the .pot file, you don't need to merge them afterwards | 09:07 |
| brendand | dpm, oh say maybe checkbox is doing it wrong :) | 09:07 |
| brendand | dpm, is there an example? | 09:07 |
| dpm | brendand, lp:ubuntu-weather-app (see the README.translations file) if you are using cmake. If you're not using cmake, have a look at the same branch about 3 or 4 revisions ago on how to do the same with qmake (README.translations should also give you the info for qmake there) | 09:09 |
| brendand | dpm, yeah i saw the code but i'm a bit unsure what the end result is. what does the .desktop file look like? | 09:10 |
| dpm | brendand, it should look like a regular desktop file with no translations, and it needs to have the X-Ubuntu-Gettext-Domain key specified and pointing to the translations domain | 09:12 |
| brendand | dpm, why does it have no description? | 09:12 |
| brendand | dpm, as in the Description: field | 09:12 |
| dpm | brendand, descriptions are not shown on the phone. That metadata is stored in the software store | 09:13 |
| brendand | dpm, oh i see | 09:13 |
| dpm | the descriptions should be translatable in the store, but I still haven't spend time to figure out how to upload translations to the store, I need to talk to beuno about that | 09:14 |
| dpm | *spent | 09:14 |
| brendand | dpm, do desktop apps also use the same method of translating the desktop file? | 09:21 |
| brendand | looks like it | 09:21 |
| dpm | brendand, yes, in Ubuntu we always specify the X-Ubuntu-Gettext-Domain and don't have inline translations in the .desktop file. They're loaded at runtime from .mo files, as the rest of the translations in the source code itself | 09:22 |
| === freeflying_away is now known as freeflying | ||
| xnox | tvoss: it looks ok (sans the http://paste.ubuntu.com/6953591/ which is not committed?) | 09:52 |
| tvoss | xnox, well, Jenkins complains about missing symbols for 32 bit platforms | 09:53 |
| xnox | tvoss: do you have link? | 09:53 |
| tvoss | xnox, armhf: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/98/console | 09:54 |
| xnox | tvoss: yeah, it looks like includes are borked a bit. (experimented with a few options). On the other hand per-arch rules files work correctly, so i've instead used symlinks. | 10:14 |
| xnox | tvoss: however, it appears (during i386 build) that 32bit symbols are incomplete/different. | 10:15 |
| tvoss | xnox, I checked all of the symbols for armhf and the symbols reported as missing are definitely in the file. Even copying them into the toplevel symbols file does not work for me | 10:17 |
| xnox | i've proposed this https://code.launchpad.net/~xnox/dbus-cpp/symbols/+merge/206880 and will see what jenkins build says about it at https://code.launchpad.net/~xnox/dbus-cpp/symbols/+merge/206882 | 10:20 |
| brendand | dpm, apologies. i'm having a hard time understanding how the translation of the desktop file works in ubuntu-weather-app | 10:31 |
| brendand | dpm, from what i can see, the 'make pot' target creates a .js file in .build/, and that has a string extracted for translation | 10:32 |
| dpm | brendand, exactly | 10:32 |
| brendand | dpm, and that does end up in the template, but i don't see how that's then related to the .desktop file itself | 10:32 |
| brendand | dpm, #: ../.build/ubuntu-weather-app.desktop.js:1 | 10:33 |
| brendand | msgid "Weather" | 10:33 |
| brendand | msgstr "" | 10:33 |
| dpm | brendand, it's similar to what intltool does (not a .js file, but an intermediate .h header). intltool is just a frontend to xgettext: what it does is to convert the .desktop file (which xgettext does not understand) into a format xgettext understands and can parse to extract strings for. You can ignore that intermediate file. | 10:34 |
| dpm | so in the case of intltool that intermediate file is a .h file and in our case it's a .js file. With that script in the .pro file we're mimicking what intltool makes, but with qmake. | 10:35 |
| dpm | the goal is to extract the translatable string from the .desktop file and put it in the .pot template | 10:36 |
| brendand | dpm, but the string in the pot file is marked with the name of the .js file - doesn't that matter? | 10:36 |
| dpm | brendand, it does not matter. This is just an aid for translators to know the source file where the translation comes from, it's not used for any build rules or anything. It might be slightly confusing for translators, but most of them will know from experience that it comes from the .desktop file, if they ever need to trace it back | 10:38 |
| brendand | dpm, how does it know that particular translation refers to that string though? | 10:40 |
| dpm | brendand, gettext does lookup based on the original string. So when it sees "Weather" thrown at it, no matter where it comes from, it returns e.g. "El temps" | 10:41 |
| brendand | dpm, is it possible the same string can be translated differently? | 10:42 |
| dpm | brendand, yes, you can specify a context, but I don't think we support that in our SDK yet | 10:43 |
| brendand | dpm, i guess the domain has something to do with it too | 10:47 |
| === trijntje_ is now known as trijntje | ||
| dpm | brendand, yes, you could do that with two different domains, but I'd advise against it unless you really need it, just to keep things simple and have one domain per app | 10:54 |
| brendand | dpm, I notice there were some comments to translators in the weather app pot file | 11:01 |
| brendand | dpm, are those added manually? | 11:01 |
| dpm | brendand, yes. Generally you put them as a code comment above the line of code you want to provide more context for. These are picked up by xgettext when creating the .pot file and put in there. For core apps we added an argument to the xgettext call that means comments will only be picked up if they are prefixed by the word TRANSLATORS: | 11:03 |
| brendand | dpm, ah right i see | 11:04 |
| brendand | dpm, that makes sense. so it goes in the code, not directly in the pot file | 11:05 |
| dpm | exactly | 11:05 |
| tvoss | xnox, seems like Jenkins is a bit unhappy: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-amd64-ci/101/console | 11:18 |
| xnox | tvoss: yeah, it doesn't seem to like symlinks with 1.0 source format =( | 11:19 |
| infinity | xnox: That's because diff/patch can't represent symlinks... | 11:22 |
| infinity | xnox: You can only have symlinks in your Debian delta if they'll land in a tarball (ie: a 3.0 source format, or native) | 11:23 |
| tvoss | xnox, so what do I need to do now? | 11:23 |
| xnox | infinity: yeah, and dpkg broke force generating packages of a given format - e.g. i can't force 3.0 (quilt) without a tarball and a - version, or 3.0 (native) with a - version. | 11:23 |
| infinity | tvoss: Either symlink those files at build time (and clean them appropriately), or use a source format that can represent symlinks in debian/ | 11:24 |
| infinity | xnox: I reduced the is_native checks to a warning ages ago. | 11:24 |
| tvoss | infinity, I'm a bit lost here, sorry. | 11:24 |
| infinity | xnox: Not that that's the right answer here anyway. One should actually pick a sane format. :P | 11:24 |
| infinity | xnox: If 1.0 non-native is fine for this package, surely 3.0 (quilt) would be too. | 11:25 |
| infinity | xnox: And if they don't want broken out patches, 3.0 (quilt) with --single-debian-patch. | 11:26 |
| xnox | infinity: flipped it to 3.0 (native) for now, to get jenkins build going. Not sure what the rest of ci/releasy/machineries expect. | 11:27 |
| infinity | 3.0 (quilt) with --single-debian-patch ends up being pretty much the same as 1.0 non-native, but with the added bonus of debian/ being a tarball, not a diff. | 11:27 |
| beuno | dpm, they are translatable in the web UI | 11:27 |
| infinity | xnox: native is wrong, it has an orig... | 11:28 |
| infinity | xnox: Oh, also, we could just fix the buggy symbols usage and let them keep it format 1.0 | 11:30 |
| tvoss | infinity, I wonder what buggy means, could you help me understand that? | 11:30 |
| xnox | infinity: true. it's native during merge-proposals, and then ci-train generate the tarball and makes it non-native.... | 11:30 |
| infinity | tvoss: So, you probably should drop the symlinks and instead 'echo #include "libdbus-cpp1.1.symbols.32bit"' > libdbus-cpp1.1.symbols.i386 | 11:30 |
| xnox | infinity: at least the top level version number is native in lp:dbus-cpp .... | 11:31 |
| tvoss | infinity, I didn't add the symlinks | 11:31 |
| tvoss | infinity, xnox introduced that for testing purposes | 11:31 |
| infinity | tvoss: Using includes instead of symlinks also allows you to add arch-specific symbols, should you ever need to. | 11:31 |
| infinity | xnox: Oh, it's your fault. So, see above. | 11:31 |
| doko_ | stgraber, cgmanager needs a bug subscriber | 11:31 |
| xnox | infinity: yeah, that was me. we had (arch=!amd64 !arm64)#include "...symbols.32bit" and that did not do the right thing. | 11:31 |
| infinity | xnox: Hrm? It should DTRT. Maybe there was a typo. :P | 11:32 |
| xnox | infinity: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols and https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/99/console | 11:33 |
| xnox | infinity: http://bazaar.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/view/head:/debian/libdbus-cpp1.1.symbols | 11:34 |
| xnox | infinity: (missing ppc64el, but still) | 11:34 |
| dpm | beuno, yes, I just have to spend some time to figure out how it works. When you've got a minute, could you comment on bug 1237992 ? Desktop file translations is the last big bit remaining to get a localized UI, and I think at least for the default apps, they should be loaded from the translations already available from the .mo files, but I'd like to hear your thoughts | 11:34 |
| ubottu | bug 1237992 in unity-scope-click (Ubuntu) "Need to load translations from .desktop files for click apps" [Medium,Triaged] https://launchpad.net/bugs/1237992 | 11:34 |
| infinity | xnox: Erm, the reason that didn't work is cause that build was on armhf, and the symbols file didn't reference it. | 11:40 |
| infinity | Oh, wait. !foo. Nevermind. | 11:40 |
| infinity | dpkg-gensymbols and I might want to have a chat. | 11:41 |
| xnox | infinity: it appeared to have not done the second #include what's so ever... | 11:42 |
| infinity | Oh. I think I know why that is. And my suggested fix would work. But there's another option. | 11:50 |
| infinity | So, if you read the manpage, it's not that those *files* get included on the arches you specify. | 11:50 |
| infinity | It's that the files all get included, and their SYMBOLS get tagged with the preceding tag. | 11:50 |
| infinity | So, you essentially tagged everything twice. | 11:51 |
| infinity | Because most of the symbols are in both files. | 11:51 |
| infinity | The more common approach is a symbols.common with all the intersecting symbols, and .32-bit and .64-bit would only contain the ones that actually change. | 11:51 |
| tvoss | infinity, but that wouldn't explain why all of the symbols from the .32bit file are reported missing | 11:52 |
| infinity | tvoss: Because the second include takes precedence, and it all goes a bit wonky. | 11:53 |
| tvoss | infinity, I tried adding the "raw" symbols to the top-level .symbols file, too. And that did not work either | 11:54 |
| infinity | You start out with (!amd64)foo@ver, and then overwrite it with (amd64)foo@ver, which then means there's no record of that symbol needing to exist on armhf (or, indeed, on anything but amd64). | 11:54 |
| infinity | tvoss: Includes override anything previously declared. If a symbol overlaps, the last declaration wins. | 11:55 |
| tvoss | infinity, hmmm, trying to understand if that's a bug then or in accordance with the man page (as I understood it differently) | 11:55 |
| infinity | tvoss: That's how the manpage reads, it's just not how people read it. | 11:55 |
| infinity | If that makes sense. | 11:55 |
| infinity | As a result, all symbols included from file-to-include will be considered to be tagged | 11:55 |
| infinity | with tag ... tagN by default. | 11:55 |
| infinity | The symbols files are read line by line, and include directives are processed as soon as | 11:56 |
| infinity | they are encountered. This means that the content of the included file can override any | 11:56 |
| infinity | content that appeared before the include directive | 11:56 |
| tvoss | infinity, ack | 11:56 |
| infinity | tvoss: So, simple solution is foo.symbols.amd64 == #include "foo.symbols.64-bit", more "correct" solution is foo.symbols is three lines, an include of common symbols, and then two conditional includes of non-overlapping 64/32-bit symbols. | 11:57 |
| tvoss | infinity, okay, I will go for the short term solution first to see if jenkins is happy with that | 11:58 |
| infinity | tvoss: Oh well, at least I learned something today. I also read that manpage wrong until just now. | 12:01 |
| infinity | tvoss: I think we both read what we wanted it to say, and entirely missed all the words telling us we were wrong. :) | 12:01 |
| tvoss | infinity, it's admittedly interesting behavior if the per symbol tags are different, though | 12:01 |
| infinity | (Would probably be nice to have an arch-qualified include directive in addition to the 'add these tags to the include' directive) | 12:02 |
| rbasak | I think I've inadvertently broken all packages that depend on virtual package phpapi-20121212, provided by php5-common, on i386. How can I find all packages in the archive that depend on this? I've tried "apt-cache rdepends" and "reverse-depends" but these don't see anything. Is this because it's a virtual package that I'm looking for? | 12:18 |
| infinity | rbasak: Yeah, reverse-depends doesn't do virtuals. How did you break it? | 12:19 |
| infinity | rbasak: Or do you just mean that the phpapi bumped and you need to do a transition, which is entirely normal? | 12:19 |
| rbasak | infinity: yeah, effectively. I fixed LFS support, which caused the generated provided package to change to phpapi-20121212+lfs. | 12:20 |
| rbasak | I can see that I need to do a no change rebuild of php5-json to fix the php5 dep8 tests, which should be straightforward. | 12:20 |
| infinity | rbasak: Are you sure you fixed it? | 12:20 |
| rbasak | I'm wondering what else I need to rebuild it. | 12:20 |
| rbasak | infinity: /me checks | 12:21 |
| infinity | rbasak: I fixed it literally a decade ago and backed it all out because some of PHP's deps didn't support it properly. | 12:21 |
| infinity | rbasak: Searching the changelog for "LFS" is an englightening history lesson. | 12:23 |
| infinity | enlightening too. | 12:23 |
| * rbasak was unaware of this | 12:24 | |
| rbasak | It seemed to me that Debian intended to build LFS support, but due to a minor oversight it wasn't happening in debian/rules | 12:24 |
| rbasak | Indeed, yes. It seems that LFS was happening in Quantal. | 12:25 |
| rbasak | bug 1280044 and the corresponding Debian bug | 12:25 |
| ubottu | bug 1280044 in php5 (Ubuntu) "dpkg-buildflags wipes out LFS support in package build" [High,Triaged] https://launchpad.net/bugs/1280044 | 12:25 |
| rbasak | The reporter thought it was a regression, and the build logs suggest to me that it was. | 12:26 |
| infinity | rbasak: Ahh, indeed. | 12:27 |
| infinity | rbasak: Kay, carry on with your transition then. :P | 12:27 |
| infinity | Seems the LFS history is, indeed, history. | 12:27 |
| rbasak | I tested on amd64 only (well that was stupid, for an LFS fix), and the dep8 tests passed fine :-/ | 12:28 |
| rbasak | infinity: so, back to the original question. How can I detect everything that needs rebuilding? | 12:29 |
| infinity | rbasak: grep-dctrl is likely the easiest. | 12:29 |
| rbasak | infinity: ah, of course. Thanks! | 12:30 |
| infinity | rbasak: Except... You didn't bump the Provides? | 12:30 |
| infinity | Version: 5.5.8+dfsg-2ubuntu1 | 12:31 |
| infinity | Provides: php5-mhash, phpapi-20121212 | 12:31 |
| rbasak | infinity: it didn't occur to me that it would be a problem, or that there would even be a transition here. So, no. But the packaging seems to have done it for me, which is nice. | 12:31 |
| infinity | Version: 5.5.9+dfsg-1ubuntu1 | 12:31 |
| infinity | Provides: php5-mhash, phpapi-20121212 | 12:31 |
| rbasak | infinity: it's now phpapi-20121212+lfs | 12:31 |
| infinity | Oh, maybe only on 32-bit arches? | 12:31 |
| rbasak | infinity: are you looking at i386? | 12:31 |
| rbasak | Right | 12:31 |
| infinity | Gross. | 12:31 |
| rbasak | And this is why I didn't realise there was anything amiss. I tested only am64 :-/ | 12:32 |
| infinity | rbasak: http://paste.ubuntu.com/6954185/ | 12:34 |
| infinity | rbasak: Or perhaps more helpful: http://paste.ubuntu.com/6954186/ | 12:34 |
| rbasak | infinity: thanks! I'd just started downloading Packages files. Didn't think to use /var/lib/apt/lists. Can you tell I don't do this often? | 12:35 |
| rbasak | infinity: so, just to check, this all seems sane to you? I should need a no-change rebuild against each of these, right? | 12:36 |
| infinity | rbasak: Yeahp, a no-change of all the sources (minus php5, obviously) should do the trick. | 12:36 |
| rbasak | infinity: thanks! I appreciate your help. | 12:37 |
| * rbasak gets to it | 12:37 | |
| infinity | rbasak: Double-check that the +lfs thing actually happened on all 32-bit arches before you do. | 12:37 |
| rbasak | OK | 12:37 |
| rbasak | https://launchpad.net/ubuntu/trusty/armhf/php5-common/5.5.9+dfsg-1ubuntu1 and https://launchpad.net/ubuntu/trusty/powerpc/php5-common/5.5.9+dfsg-1ubuntu1 both list Provides: phpapi-20121212+lfs so I think that means yes. | 12:40 |
| tvoss | xnox, infinity still no luck with: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 | 12:47 |
| === dholbach_ is now known as dholbach | ||
| tvoss | xnox, infinity that is, with arch-specific symbol files that include .32bit and .64bit, respectively | 12:58 |
| infinity | tvoss: shouldn't need the arch qualifiers in there anymore. | 13:04 |
| infinity | Also, the lack of trailing newlines are a bit hard to read... | 13:04 |
| === MacSlow is now known as MacSlow|lunch | ||
| * infinity fixes those bits up and sees how it fares locally. | 13:04 | |
| infinity | tvoss: So, this diff on top of your branch works smashingly for me: http://paste.ubuntu.com/6954321/ | 13:14 |
| tvoss | infinity, pushed here, let's see what jenkins says :) | 13:26 |
| tvoss | https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 | 13:26 |
| doko_ | stgraber, could you merge the changes from ifenslave-2.6 into ifenslave? | 13:26 |
| rbasak | What happens to packages that FTBFS in universe that don't end up getting fixed? Are they removed, or do we ship the previously built binaries anyway? | 13:47 |
| rbasak | ffmpeg-php failed the rebuild test. My php change will make it uninstallable on i386, but I can see that a no change rebuild will fail on it. | 13:48 |
| rbasak | The package is already gone from Debian testing. It seems like a longer term issue that can't easily be fixed: https://bugs.launchpad.net/ubuntu/+source/ffmpeg-php/+bug/1277603 | 13:49 |
| ubottu | Launchpad bug 1277603 in ffmpeg-php (Ubuntu) "FTBFS against libav 9" [High,New] | 13:49 |
| === doko_ is now known as doko | ||
| tvoss | infinity, so do you still have a .symbols file around then, or just the arch-specific symbol files? | 13:59 |
| tvoss | infinity, https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 isn't happy | 13:59 |
| infinity | tvoss: I had the symbols file there, but it's removable cruft. | 13:59 |
| tvoss | infinity, yeah, I kept it around, too | 14:00 |
| infinity | Okay, how the heck is yours different from the testbuild I *just* did on i386? | 14:00 |
| tvoss | infinity, I have no idea, except for it is running somewhere in jenkins | 14:01 |
| infinity | tvoss: Your branch just built fine on i386 here. Grr. | 14:06 |
| tvoss | infinity, wtf? | 14:08 |
| doko | Sweetsha1k, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please use openjdk-7 in nlpsolver (not 6) | 14:12 |
| === MacSlow|lunch is now known as MacSlow | ||
| doko | bdmurray, cjwatson: please can you subscribe the foundations team to bug reports for libconfig-auto-perl and dpkg-cross? | 14:28 |
| doko | or slangasek ^^^ | 14:30 |
| doko | cyphermox_, network-manager recommends wader, which is not in main | 14:33 |
| cjwatson | doko: done (cc bdmurray, slangasek) | 14:34 |
| brendand | dpm, time to bother you again... | 14:40 |
| dpm | brendand, then do bother me with a question, rather than with a ping, and I'll be happy to answer :) | 14:44 |
| brendand | dpm, do we always have to update .pot files manually, or is there a way to get launchpad to do it for us? | 14:46 |
| brendand | dpm, i would guess LP only updates the .po files (from what I've seen) | 14:46 |
| dpm | brendand, in summary, yes, you do have to update the .pot files manually. LP in principle supports updating .pot files for autotools-based projects, but that's a feature that has not seen much usage and I'm not sure about its status tbh | 14:47 |
| shadeslayer | pitti: poke | 14:49 |
| rbasak | OK this is awkward. php5-common built by src:php5 depends on php5-json, built by src:php-json, which build-depends on php5-cli, which depends on php5-common. | 14:59 |
| cjwatson | Yes, that cycle requires manual bootstrapping as I remember | 14:59 |
| === JanC_ is now known as JanC | ||
| rbasak | cjwatson: any advice on unsticking this? Should I upload a php5 that does not depend on php5-json, or something? | 15:00 |
| cjwatson | No, don't do in the archive | 15:00 |
| cjwatson | *do it in ... | 15:00 |
| cjwatson | Is this dep-waiting right now, or are you still staging this? | 15:01 |
| rbasak | php5 is stuck in -proposed, and I just uploaded (via sponsor) a no change rebuild of php5-json. Only now do I realise the issue (sorry) | 15:02 |
| rbasak | So the php-json FTBFS | 15:02 |
| shadeslayer | tseliot: pitti regarding proprietary drivers, should I only show a notification if the proprietary drivers are available and recommended, or should I show it regardless of whether or not the proprietary drivers are recommended | 15:02 |
| cjwatson | Let me get some lunch and then I'll unstick it. My recollection is that I just need to temporarily rip out the php5-common -> php5-json dependency in a bootstrap archive. | 15:02 |
| cjwatson | (I've done this once before, although it was a while back.) | 15:03 |
| rbasak | cjwatson: OK, thanks. I appreciate it. Is this something that I should be able to do in future, or does it require extra stuff I can't do? | 15:03 |
| tseliot | shadeslayer: you'll get a recommended driver if more drivers are available for the same devices (such as nvidia-331, nvidia-304) | 15:04 |
| shadeslayer | tseliot: right, but shouldn't there be no notification if the driver that is active is also the recommended one | 15:05 |
| tseliot | shadeslayer: I guess not. I don't think we use notifications in any case though | 15:06 |
| shadeslayer | tseliot: no, this is for Kubuntu :) | 15:06 |
| shadeslayer | http://im9.eu/picture/qe2485 | 15:06 |
| tseliot | shadeslayer: if the driver in use is already the recommended driver, then I guess you can avoid showing a notification | 15:07 |
| shadeslayer | *nod* | 15:08 |
| shadeslayer | apachelogger: ^^ | 15:08 |
| bdmurray | cjwatson: thanks | 15:12 |
| cjwatson | rbasak: It's only doable by archive admins | 15:17 |
| rbasak | OK, thanks. | 15:17 |
| stgraber | doko: I'm subscribed to the cgmanager bugs now. I expect the bug triagers of both foundations and server to subscribe too but I can't do that myself as I'm not an admin for those teams. | 15:28 |
| stgraber | doko: for ifenslave2.6 => ifenslave, I plan on going through all network packages soon but probably not this week (or if so, after FeatureFreeze) | 15:29 |
| === Sweetsha1k is now known as Sweetshark | ||
| === tkamppeter_ is now known as tkamppeter | ||
| dobey | hrmm. who is dealing with firefox these days? ins 27 going into trusty soon? | 15:50 |
| seb128 | dobey, chrisccoulson is doing work on it but it's not his primary focus | 15:51 |
| seb128 | dobey, the trusty migration is blocked by ppc issues, infinity said he's wanting to help get them resolved | 15:51 |
| seb128 | he said he should be able to have a look before beta | 15:51 |
| dobey | ah | 15:51 |
| dobey | ok | 15:51 |
| seb128 | dobey, you can get it from trusty-proposed | 15:52 |
| dobey | ok | 15:53 |
| chrisccoulson | "not my primary focus" is an understatement ;) | 15:58 |
| seb128 | chrisccoulson, hey ;-) | 16:02 |
| roadmr | dholbach: hello! got time for yet another checkbox-related question? | 16:05 |
| chrisccoulson | hi seb128 :) | 16:08 |
| dholbach | roadmr, not right now - in a call - can you just ask in here and ping me in 30m if you didn't get a reply? | 16:10 |
| roadmr | dholbach: will do, I can wait, not in a hurry, here goes | 16:10 |
| roadmr | dholbach: ubuntu-desktop Depends: checkbox-qt. I will make checkbox-qt a transitional package, with Depends: checkbox-gui | checkbox-ng (as checkbox-gui doesn't build on powerpc and arm64, we have checkbox-ng as a fallback). This should cause checkbox to "fall off" the CD (no longer needed), and all of checkbox-gui (or checkbox-ng)'s dependencies to be included instead. Does this sound OK and is acceptable? | 16:11 |
| xnox | roadmr: surely just the seed need changing. I've asked a few times in the past if checkbox is wanted on the cd or not. | 16:17 |
| roadmr | xnox: oh so the seed needs changing? even if checkbox-qt is there already? | 16:17 |
| xnox | roadmr: i believe it provides "System Testing" app that one can run manually. Do you still want it? | 16:17 |
| xnox | roadmr: yeah, seed change is needed as well. (eventually it will be blocking from removing transitional package post-trusty) and it's best for seeds not to depend on transitional packages =) | 16:18 |
| roadmr | xnox: yes, we'd like for it to be there. As seen here, we're replacing the old checkbox-qt with a new checkbox-gui app with an entirely new engine | 16:18 |
| xnox | as we don't want cruft empty packages on the CDs ;-) | 16:18 |
| xnox | roadmr: cool, so the new name is checkbox-gui? | 16:19 |
| roadmr | xnox: sounds reasonable :) so would it be best then to ask for the checkbox-qt dependency in ubuntu-desktop to be replaced by "checkbox-gui | checkbox-ng" ? | 16:19 |
| roadmr | xnox: yes, the only caveat is that checkbox-gui doesn't build on powerpc, ppc64el and arm64 (qtdeclarative5 dependencies missing), so the checkbox-ng fallback (it's a text-mode ui to the same engine) is needed so that I don't render ubuntu-desktop uninstallable on those archs :/ | 16:20 |
| xnox | roadmr: ubuntu-desktop -> is generated from the seed, so once i change it, and ubuntu-desktop meta is refreshed it will have new deps. | 16:20 |
| xnox | roadmr: at the moment there is: checkbox-qt in desktop seed, checkbox-cli in server, checkbox-gtk in supported. | 16:20 |
| xnox | roadmr: we also don't have ubuntu-desktop images on powerppc ppc64el and arm64, so that's ok. | 16:21 |
| roadmr | xnox: ok, so the fallback wouldn't be necessary? | 16:21 |
| xnox | roadmr: and the latter two don't have any hardware with graphics cards yet and/or ship with a display ;-) | 16:21 |
| xnox | roadmr: yeah, fallback is not needed. | 16:21 |
| xnox | roadmr: checkbox-ng to replace checkbox-cli on the server images? | 16:22 |
| Laney | I think it'll just skip them on arches it's not available anyway | 16:22 |
| roadmr | xnox: checkbox-ng on server images, yes. Just give me a second to confirm that works as intended | 16:24 |
| cjwatson | rbasak: php-json/i386 rebootstrapped, doing armhf and powerpc now | 16:27 |
| roadmr | xnox: ok, so for desktop seed we'd like checkbox-gui to replace checkbox-qt. The package exists already, and I'll make checkbox-qt a transitional package for upgraders anyway | 16:33 |
| xnox | roadmr: sounds good. | 16:33 |
| roadmr | xnox: for servers, I need to whip up a metapackage that pulls the cli and a job provider (cli is useless without it). Or would you prefer adding the two packages to the server seed? | 16:34 |
| xnox | roadmr: well they are simply shipped in the pool at the moment. so one either does task-select and/or apt-get install checkbox-cli to install them. | 16:35 |
| xnox | roadmr: so seeding two on the server image means that $ apt-get install provider-tests checkbox-ng works without network access and just the cd. | 16:36 |
| xnox | roadmr: what's that other package that needs seeding? | 16:36 |
| roadmr | xnox: checkbox-ng and plainbox-provider-checkbox would be needed in server | 16:37 |
| roadmr | xnox: a problem is that people could install checkbox-ng which is useless without the provider, and not realize they also need the provider | 16:37 |
| infinity | roadmr: If it's useless without another package, why doesn't it depend on it? | 16:38 |
| roadmr | xnox: ^^ the metapackage would help here, it's just a helper for the user to get the right packages | 16:38 |
| xnox | infinity: or the otherway around, why not depend on the provider, which depends on the "frontend virtual provides" and on the server iso that will resolve to the only one available - the cli one. | 16:39 |
| roadmr | xnox: that's a good idea :) | 16:40 |
| roadmr | infinity: that's a good point. checkbox-ng is useless without a provider but a user could conceivably get checkbox-ng and then create their own provider | 16:41 |
| infinity | roadmr: A user could concievably install coreutils and their own libc too, but we don't let them do that. | 16:41 |
| infinity | roadmr: Package dependencies exist for a reason. | 16:42 |
| roadmr | infinity: we had that problem with old checkbox: the engine and the test library (what is now the provider) were completely glued, you couldn't use the core without that bunch of (possibly irrelevant) tests | 16:42 |
| infinity | If it's literally useless without another package, it depends on that package, period. | 16:42 |
| infinity | If that package is one of a class of packages, then it should "Provides: foo-package-class-lolz", and you should depend on that. | 16:43 |
| infinity | So other packages can also provide it. | 16:43 |
| infinity | But letting users install a package that is DOA isn't doing anyone favours. | 16:43 |
| roadmr | infinity: you're right, let me think how best to organize this for server | 16:44 |
| infinity | roadmr: Make it depend on "foo-provider-server-friendly-cli | virtual-package-for-foo-providers", and then explicitly seed the fancy gui one on desktop. | 16:46 |
| infinity | roadmr: So desktop installs get the setup you want them too, but people manually installing it get the slim CLI version by default. | 16:46 |
| infinity | s/too/to/ | 16:46 |
| roadmr | infinity: nice solution, thanks! | 16:47 |
| bdmurray | stgraber: Could you have a look at bug 1279106 sometime? | 17:00 |
| ubottu | bug 1279106 in casper (Ubuntu) "Customized LiveUSB setup cannot handle persistence" [Undecided,New] https://launchpad.net/bugs/1279106 | 17:00 |
| stgraber | bdmurray: sure, though that won't be very soon | 17:02 |
| bdmurray | stgraber: I mention it because it seems to have a patch | 17:04 |
| stgraber | bdmurray: yep, I saw that. Unfortunately that bit of the code is annoyingly fragile so I usually need a good test setup and a couple of days to go through the casper bugs. | 17:05 |
| stgraber | (as in, it's about the 10th time we get patches for that bug and it always pops up somewhere else ;)) | 17:06 |
| bdmurray | stgraber: okay, thanks for looking | 17:06 |
| u-foka | Can anyone help me debug gnome screensaver? Are there debug symbols for it somewhere? | 17:27 |
| seb128 | u-foka, there are debugs symbols for most binaries in Ubuntu, see https://wiki.ubuntu.com/DebuggingProgramCrash | 17:30 |
| u-foka | seb128, thanks, i didn't know that these were moved to a separate repo :) | 17:32 |
| pitti | shadeslayer: it should only show a notification if there are drivers which you can install | 17:33 |
| === pbn_ is now known as pbn | ||
| shadeslayer | pitti: even if these drivers are not the "Recommended" ones? | 17:33 |
| pitti | shadeslayer: well, in that case you'd usually have more than one available, and one should be the recommended one? | 17:35 |
| shadeslayer | pitti: sure, but for eg. what if the recommended driver is radeon and I can also install fglrzx | 17:37 |
| shadeslayer | *fglrx | 17:37 |
| shadeslayer | should the notification be shown then? ( I already have radeon installed ) | 17:37 |
| pitti | do we actually do that? | 17:37 |
| shadeslayer | yeah :D | 17:37 |
| pitti | my gut feeling is "no" then | 17:37 |
| rbasak | cjwatson: thanks, I can see i386 and armhf are built now. Are you doing powerpc? I might as well wait before rebuilding the reverse deps, I suppose. | 17:38 |
| shadeslayer | pitti: http://im9.eu/picture/g16271 | 17:38 |
| seb128 | bdmurray, ev: hey, do you know if the trusty e.u.c retracers are having issue? several of the recent issues/bugs have no retracing, e.g on the daily view the reports 4-5-7-9 | 17:53 |
| bdmurray | seb128: I'll have a look | 17:55 |
| seb128 | bdmurray, thanks | 17:56 |
| bdmurray | seb128: daily view for all packages? | 17:56 |
| === dpm is now known as dpm-afk | ||
| seb128 | bdmurray, yes, but restricted to trusty | 17:56 |
| seb128 | sorry, I forgot to mention | 17:56 |
| seb128 | bdmurray, e.g https://errors.ubuntu.com/problem/39bbce347f9a5260a0fe549c5b650e5f2ea53b6c | 17:57 |
| seb128 | or https://errors.ubuntu.com/problem/51867c7babfc41c749a4ed34ba54148f534a28c1 | 17:57 |
| === bschaefer_ is now known as bschaefer | ||
| seb128 | https://errors.ubuntu.com/problem/844b51aadb0b772e8277eec836767fbd00c5f46e | 17:57 |
| pitti | smoser: did you see my question yesterday wrt. the broken cloud-init images? should I file a bug about that? | 18:32 |
| smoser | pitti, i'm sorry . i didn't see your question, but utlemming raised that. | 18:33 |
| smoser | i fixed trunk just now | 18:33 |
| smoser | i'll upload fix shortly. | 18:33 |
| pitti | smoser: in short, all cloud images > feb 14 don't boot | 18:33 |
| pitti | smoser: splendid, thanks | 18:33 |
| smoser | well, they boto | 18:33 |
| smoser | boot fine | 18:33 |
| smoser | they just dont read your datasource | 18:33 |
| pitti | right, they seme to ignore the seed image | 18:33 |
| pitti | and just time out on trying to talk to 169.* | 18:34 |
| utlemming | smoser: fwiw, I should probably have a QA story on using the seed image | 18:34 |
| pitti | utlemming: well, we kind of do indirectly : http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-setup-testbed/ | 18:36 |
| pitti | utlemming: it failed since Feb 14 | 18:36 |
| smoser | pitti, your url isn't any good. | 18:36 |
| utlemming | pitti: and we didn't see the failure till now.... | 18:36 |
| pitti | smoser: yeah, it requires VPN; unfortunately that job isn't published to the public jenkins, jibel is just fixing that | 18:37 |
| smoser | well, the images are used enough places that the local datasource gets tested via cloud-image seed reasonably well for regression :) | 18:37 |
| smoser | pitti, utlemming just uploaded cloud-init_0.7.5~bzr952-0ubuntu1_source.changes | 19:12 |
| pitti | smoser: splendid, thanks; so tomorrow's cloud images should work again | 19:13 |
| smoser | yeah. sorry about that. | 19:14 |
| smoser | we could do a dep-8 test for this. | 19:15 |
| smoser | and fail build. | 19:15 |
| smoser | er... wait. | 19:15 |
| smoser | could we? | 19:15 |
| smoser | can dep-8 test have access to download a cloud-image ? | 19:15 |
| roadmr | smoser: hm did that thing with the seed image get reported other than here? (my own report): https://bugs.launchpad.net/cloud-init/+bug/1281305 | 19:15 |
| ubottu | Launchpad bug 1281305 in cloud-init "NoCloud source broken in Trusty cloud images" [Undecided,New] | 19:16 |
| smoser | otherwise we'd have to build a image. | 19:16 |
| roadmr | just so I know if my bug is a dupe :) | 19:16 |
| smoser | roadmr, no. and i didn't see your bug. so i didn't comment in the changelog with it. | 19:16 |
| smoser | but the upload surely should fix it. | 19:16 |
| smoser | roadmr, fwiw, your use of genisoimage can be done with 'cloud-localds' | 19:17 |
| roadmr | smoser: cool! well as long as it works, we should all be happy :) | 19:17 |
| smoser | which is expliciltly for this purpose | 19:17 |
| roadmr | smoser: oh cool! | 19:17 |
| roadmr | smoser: then maybe the README for that NoCloud source could use updating to mention this | 19:22 |
| smoser | it shoudl be., | 19:22 |
| roadmr | smoser: anyway, thanks for fixing this, my virtualization tests will look nicer (i.e. pass) now :D | 19:23 |
| smoser | roadmr, if you see cloud images fail for something like this, please feel free/obligated to ping utlemming or I here | 19:23 |
| smoser | and if we don't respond, email is fine too for me. | 19:24 |
| roadmr | smoser: will do, we run daily tests on them (at least boot/ensure the NoCloud source is read) so I'll definitely do that | 19:24 |
| xnox | stgraber: Yeah! latvia is through ;-) let's see how it goes against your other country affiliation game now ;-) | 19:28 |
| stgraber | xnox: I have a felling I'm missing some context here :) | 19:30 |
| xnox | stgraber: olympics - sochi - hockey | 19:31 |
| roadmr | xnox: latvia stands no chance :( | 19:31 |
| xnox | stgraber: latvia beat switzerland to go through to quater-finals. Next up against Canada. | 19:31 |
| xnox | roadmr: eh, a few years back we beat russia 3-2, that was amazing ;-) | 19:32 |
| roadmr | xnox: \o/ ok now I'm a bit more worried | 19:32 |
| stgraber | xnox: ah, I must admit having only barely looked at some of the results on Google, been rather busy lately so not much time to follow the olympics ;) though it looks like Switzerland has a rather bad hockey team this year, those scores aren't particularly impressive (compared to past olympics anyway)... | 19:33 |
| ochosi | xnox: watching olympics when you should be stressed out of your mind because of FF approaching with light-speed? :} | 19:34 |
| roadmr | xnox: since checkbox-gui was added directly to the seed I no longer need checkbox-qt to be a transitional package; in fact it should just go away. If I just delete the debian/control section for it, I'll get "out of date" in proposed-migration, right? will this need admin attention? | 19:38 |
| xnox | roadmr: you need transitional package. | 19:39 |
| xnox | roadmr: otherwise upgrades will not upgrade from checkbox-qt to checkbox-gui, but instead would just be removed or left around at -qt version. | 19:40 |
| xnox | roadmr: however checkbox-qt transitional binary might be published in universe and will not be present on the images. | 19:40 |
| roadmr | xnox: ok, I see, so they can't just go away | 19:41 |
| roadmr | xnox: thanks, let's fix that then | 19:42 |
| roadmr | xnox: haha sorry for the dumb questions. Do dependencies of the package I'm transitioning need the same treatment? I'll make checkbox-qt transitional, it depends on checkbox which should also go away, do I also need checkbox transitional binary? | 19:53 |
| xnox | roadmr: transitional binary package should be empty, old-name (e.g. Package: checkbox-qt), depends on the new one (e.g. Depends: checkbox-gui) and description stating that it's transitional package. | 19:55 |
| xnox | roadmr: see / search other examples in the archive. | 19:56 |
| xnox | roadmr: apt-cache show dummy, brings up a few. | 19:56 |
| roadmr | xnox: yay! yes, I have an example here, thanks! | 19:57 |
| === mwhudson is now known as zz_mwhudson | ||
| === dpm-afk is now known as dpm | ||
| sarnold | slangasek: hi! we (apparmor upstream team, security team) need some help with library versioning for libapparmor, do you have some free time to help? | 20:54 |
| sarnold | slangasek: we have changed some of our interfaces (https://lists.ubuntu.com/archives/apparmor/2013-June/003878.html) -- but the interface in question was more an "internal" interface than public interface, and before the change was broken. | 20:55 |
| sarnold | slangasek: here's our library versioning scheme for our 2.8.3 upstream release: http://paste.ubuntu.com/6956459/ and here's our versioning for our 2.8.95 "snapshot" (we want a bit more features in 2.9 still, and the .95 approach was chosen to help keep packaging happy with both rpm and dpkg downstreams) | 20:57 |
| sarnold | slangasek: our 2.8.95 library versioning: http://paste.ubuntu.com/6956454/ | 20:57 |
| sarnold | slangasek: we also added new interfaces to our library in the meantime | 20:57 |
| sarnold | slangasek: so, I prepared some new packages for trusty proposed, using the following debian/control file: http://paste.ubuntu.com/6956473/ but upgrading a trusty vm with these packages showed some problems: http://paste.ubuntu.com/6952650/ | 20:58 |
| === zz_mwhudson is now known as mwhudson | ||
| jdstrand | sarnold: so, you might have missed it, but I think sbeattie, tyhicks and I thought we'd solve the man page issue by simply moving those to libapparmor-dev | 21:00 |
| sarnold | slangasek: what do you think of the library versioning we've selected for the 2.8.95 snapshot? since the apparmor source package wouldn't build the libapparmor1 package any more, I think we'd need to add some Breaks: and Conflicts: to the libapparmor2 packaging, and rebuild dependent packages (lxc, libvirt, dbus, libusermetrics) | 21:01 |
| jdstrand | sarnold: we'll need to do the same for apparmor-easyprof and python3-apparmor | 21:01 |
| sarnold | jdstrand: yeah, that makes sense, but I figured it'd be best to show the current state of things | 21:02 |
| jdstrand | sarnold: so I don't think slangasek needs to comment on those bits | 21:02 |
| jdstrand | sure | 21:02 |
| jdstrand | thanks | 21:02 |
| jdstrand | especially since we're not sure about libapparmor2 vs libapparmor1 | 21:03 |
| jdstrand | anyhoo, I'll let you handle it :) | 21:03 |
| sarnold | jdstrand: yes, even if we decide to go back to libapparmor1, it might still be worth moving the manpage | 21:03 |
| pitti | cjwatson, infinity: there doesn't seem to be any test suite for britney at all ATM, is that right? | 21:59 |
| pitti | I'm writing an initial one, so that we can recreate bugs like "package promoted although there were failing tests", etc. | 21:59 |
| pitti | which hit us hard more than once already | 22:00 |
| cjwatson | rbasak: sorry, yeah, I am doing powerpc but I was interrupted by my dad showing up for dinner | 22:06 |
| cjwatson | pitti: there's a test suite in Debian, actually, but I've never quite got round to fixing it up to work properly with Ubuntu *guilty face* | 22:06 |
| pitti | cjwatson: it wouldn't have the autopkgtest bits anyway, right? | 22:07 |
| cjwatson | pitti: http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git;a=summary | 22:07 |
| cjwatson | pitti: no, that's right, but I expect it'd be a useful framework for that | 22:07 |
| pitti | so far I just wrote enough code to produce a set of test data files with a convenient API, and got it to run there | 22:07 |
| cjwatson | we should definitely have an Ubuntu branch of that | 22:07 |
| pitti | cjwatson: nice, thanks for pointing that out | 22:08 |
| pitti | ah, that uses static data/ dirs | 22:09 |
| slangasek | sarnold: so libapparmor> so if there's an ABI break, it certainly makes sense to bump the soname as you've done here; you wouldn't need both Breaks: and Conflicts: however, though in this case since the manpages are shipped in the runtime library package you either need to fix that by moving them elsewhere (which I recommend), or having Breaks/Replaces on libapparmor1 | 22:12 |
| === mwhudson is now known as zz_mwhudson | ||
| sarnold | slangasek: hi slangasek :) yes, moving the manpage seems like the polite thing to do; what's the next step? just the Breaks: line? | 22:14 |
| slangasek | sarnold: if the manpages are moved, there is no step 2 | 22:15 |
| slangasek | (aside from making sure the runtime lib package is appropriately named to match the soname) | 22:15 |
| sarnold | slangasek: that seems suspiciously easy :) | 22:16 |
| sarnold | slangasek: do we still want / need the no-change rebuilds of the rdepends to update them to libapparmor2? | 22:17 |
| doko | bdmurray, the php5-* issues were apparently tranistional. did build after given back | 22:27 |
| jdstrand | sarnold: I can answer that. based on slangasek's advice (having libapparmor2, we need to rebuild the other packages to they don't keep the now NBS-libapparmor1 in the archive | 22:35 |
| jdstrand | ) | 22:36 |
| jdstrand | meh, punctuation is not correct, but you get the idea | 22:36 |
| cjwatson | rbasak: ok, php-json/powerpc rebootstrapped now as well, should publish soon | 22:37 |
| === zz_mwhudson is now known as mwhudson | ||
| jjohansen | jdstrand: that is just broken, I still maintain things that don't depend on new functionality should not need to be rebuilt against the new library :P | 22:39 |
| cjwatson | we aren't going to keep old libraries that no longer have source in the archive | 22:39 |
| jjohansen | emphasis on the should, it appears that that isn't reality | 22:39 |
| jjohansen | cjwatson: sure | 22:39 |
| jdstrand | jjohansen: they probably would work fine, but what I mentioned is an archive thing | 22:39 |
| jdstrand | they were built with libapparmor1, so their depends has that, so if we didn't rebuild, libapparmor1 would stay in the archive | 22:40 |
| jjohansen | jdstrand: again, I will claim this is wrong and should be fixed in debian packaging | 22:41 |
| jjohansen | :P | 22:41 |
| seb128 | jdstrand, it would stay in the archive but your rebuilds/new version would not get out proposed | 22:41 |
| seb128 | jdstrand, nowadays britney ensures transitions are completes before migrating things | 22:41 |
| seb128 | out of proposed | 22:42 |
| jdstrand | oh, I didn't know it was that smart. cool | 22:42 |
| jdstrand | nice | 22:42 |
| jjohansen | slangasek: so a library versioning question. Basically following libtool guideline http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info | 22:57 |
| jjohansen | the difference between just adding new interfaces is how AGE is set | 22:57 |
| jjohansen | - new interfaces, revision = 0, current++, age++ | 22:57 |
| jjohansen | - break ABI revision = 0, current++, age=0 | 22:57 |
| jjohansen | is this correct? Because as I understand it this would result in a new library version for packaging | 22:57 |
| doko | tkamppeter, did you track any blockers to convert system-config-printer to python3? | 23:07 |
| pitti | I hope you don't mean the UI -- wasn't there a plan to only use the backend from that? | 23:08 |
| slangasek | jjohansen: I think that's correct; though if I were you I would try a test build and see what it spits out, I've always thought the libtool library versioning scheme was annoyingly baroque | 23:37 |
| jjohansen | slangasek: yeah just looking at the rules, we kept asking is this really correct? | 23:38 |
| doko | xnox, trying to compare | 23:59 |
| doko | http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4.html | 23:59 |
| doko | https://release.debian.org/transitions/html/python3.4.html | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
