[00:09] <shadeslayer> whom can I poke to mass close bugs?
[02:32] <ScottK> shadeslayer: Do it yourself with the LP email interface.
[03:05] <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*
[04:47] <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:49] <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:50] <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:51] <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..
[05:09] <infinity> WHAT_UP: Filing a wishlist bug on apt in Debian would probably be the most appropriate place to discuss it.
[07:14] <_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:18] <_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...
[08:00] <dholbach> good morning
[08:55] <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:57] <tvoss> doko_, good morning :)
[08:57] <tvoss> doko_, I encountered an interesting issue when trying to use ThreadSanitizer with gcc in trusty
[08:58] <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:59] <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/*
 infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed"
 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, ^
[09:00] <xnox> dholbach: i see, crazy =)
[09:00] <xnox> dholbach: i will not get involved then =)
[09:01] <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:02] <brendand> dpm, i have another translations question :)
[09:02] <dpm> go for it :)
[09:03] <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] <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:04] <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:05] <brendand> dpm, in checkbox we use intltool-merge for the .desktop file. did you manage to do something similar in phone apps?
[09:06] <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:07] <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:09] <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:10] <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:12] <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:13] <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:14] <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:21] <brendand> dpm, do desktop apps also use the same method of translating the desktop file?
[09:21] <brendand> looks like it
[09:22] <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:52] <xnox> tvoss: it looks ok (sans the http://paste.ubuntu.com/6953591/ which is not committed?)
[09:53] <tvoss> xnox, well, Jenkins complains about missing symbols for 32 bit platforms
[09:53] <xnox> tvoss: do you have link?
[09:54] <tvoss> xnox, armhf: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/98/console
[10:14] <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:15] <xnox> tvoss: however, it appears (during i386 build) that 32bit symbols are incomplete/different.
[10:17] <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:20] <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:31] <brendand> dpm, apologies. i'm having a hard time understanding how the translation of the desktop file works in ubuntu-weather-app
[10:32] <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:33] <brendand> dpm, #: ../.build/ubuntu-weather-app.desktop.js:1
[10:33] <brendand> msgid "Weather"
[10:33] <brendand> msgstr ""
[10:34] <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:35] <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:36] <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:38] <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:40] <brendand> dpm, how does it know that particular translation refers to that string though?
[10:41] <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:42] <brendand> dpm, is it possible the same string can be translated differently?
[10:43] <dpm> brendand, yes, you can specify a context, but I don't think we support that in our SDK yet
[10:47] <brendand> dpm, i guess the domain has something to do with it too
[10:54] <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
[11:01] <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:03] <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:04] <brendand> dpm, ah right i see
[11:05] <brendand> dpm, that makes sense. so it goes in the code, not directly in the pot file
[11:05] <dpm> exactly
[11:18] <tvoss> xnox, seems like Jenkins is a bit unhappy: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-amd64-ci/101/console
[11:19] <xnox> tvoss: yeah, it doesn't seem to like symlinks with 1.0 source format =(
[11:22] <infinity> xnox: That's because diff/patch can't represent symlinks...
[11:23] <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:24] <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:25] <infinity> xnox: If 1.0 non-native is fine for this package, surely 3.0 (quilt) would be too.
[11:26] <infinity> xnox: And if they don't want broken out patches, 3.0 (quilt) with --single-debian-patch.
[11:27] <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:28] <infinity> xnox: native is wrong, it has an orig...
[11:30] <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:31] <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:32] <infinity> xnox: Hrm?  It should DTRT.  Maybe there was a typo. :P
[11:33] <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:34] <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:40] <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:41] <infinity> dpkg-gensymbols and I might want to have a chat.
[11:42] <xnox> infinity: it appeared to have not done the second #include what's so ever...
[11:50] <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:51] <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:52] <tvoss> infinity, but that wouldn't explain why all of the symbols from the .32bit file are reported missing
[11:53] <infinity> tvoss: Because the second include takes precedence, and it all goes a bit wonky.
[11:54] <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:55] <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:56] <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:57] <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:58] <tvoss> infinity, okay, I will go for the short term solution first to see if jenkins is happy with that
[12:01] <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:02] <infinity> (Would probably be nice to have an arch-qualified include directive in addition to the 'add these tags to the include' directive)
[12:18] <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:19] <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:20] <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:21] <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:23] <infinity> rbasak: Searching the changelog for "LFS" is an englightening history lesson.
[12:23] <infinity> enlightening too.
[12:24]  * 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:25] <rbasak> Indeed, yes. It seems that LFS was happening in Quantal.
[12:25] <rbasak> bug 1280044 and the corresponding Debian bug
[12:26] <rbasak> The reporter thought it was a regression, and the build logs suggest to me that it was.
[12:27] <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:28] <rbasak> I tested on amd64 only (well that was stupid, for an LFS fix), and the dep8 tests passed fine :-/
[12:29] <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:30] <rbasak> infinity: ah, of course. Thanks!
[12:30] <infinity> rbasak: Except... You didn't bump the Provides?
[12:31] <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:32] <rbasak> And this is why I didn't realise there was anything amiss. I tested only am64 :-/
[12:34] <infinity> rbasak: http://paste.ubuntu.com/6954185/
[12:34] <infinity> rbasak: Or perhaps more helpful: http://paste.ubuntu.com/6954186/
[12:35] <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:36] <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:37] <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:40] <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:47] <tvoss> xnox, infinity still no luck with: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359
[12:58] <tvoss> xnox, infinity that is, with arch-specific symbol files that include .32bit and .64bit, respectively
[13:04] <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]  * infinity fixes those bits up and sees how it fares locally.
[13:14] <infinity> tvoss: So, this diff on top of your branch works smashingly for me: http://paste.ubuntu.com/6954321/
[13:26] <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:47] <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:48] <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:49] <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:59] <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.
[14:00] <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:01] <tvoss> infinity, I have no idea, except for it is running somewhere in jenkins
[14:06] <infinity> tvoss: Your branch just built fine on i386 here.  Grr.
[14:08] <tvoss> infinity, wtf?
[14:12] <doko> Sweetsha1k, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please use openjdk-7 in nlpsolver (not 6)
[14:28] <doko> bdmurray, cjwatson: please can you subscribe the foundations team to bug reports for libconfig-auto-perl and dpkg-cross?
[14:30] <doko> or slangasek ^^^
[14:33] <doko> cyphermox_, network-manager recommends wader, which is not in main
[14:34] <cjwatson> doko: done (cc bdmurray, slangasek)
[14:40] <brendand> dpm, time to bother you again...
[14:44] <dpm> brendand, then do bother me with a question, rather than with a ping, and I'll be happy to answer :)
[14:46] <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:47] <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:49] <shadeslayer> pitti: poke
[14:59] <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
[15:00] <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:01] <cjwatson> Is this dep-waiting right now, or are you still staging this?
[15:02] <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:03] <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:04] <tseliot> shadeslayer: you'll get a recommended driver if more drivers are available for the same devices (such as nvidia-331, nvidia-304)
[15:05] <shadeslayer> tseliot: right, but shouldn't there be no notification if the driver that is active is also the recommended one
[15:06] <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:07] <tseliot> shadeslayer: if the driver in use is already the recommended driver, then I guess you can avoid showing a notification
[15:08] <shadeslayer> *nod*
[15:08] <shadeslayer> apachelogger: ^^
[15:12] <bdmurray> cjwatson: thanks
[15:17] <cjwatson> rbasak: It's only doable by archive admins
[15:17] <rbasak> OK, thanks.
[15:28] <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:29] <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:50] <dobey> hrmm. who is dealing with firefox these days? ins 27 going into trusty soon?
[15:51] <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:52] <seb128> dobey, you can get it from trusty-proposed
[15:53] <dobey> ok
[15:58] <chrisccoulson> "not my primary focus" is an understatement ;)
[16:02] <seb128> chrisccoulson, hey ;-)
[16:05] <roadmr> dholbach: hello! got time for yet another checkbox-related question?
[16:08] <chrisccoulson> hi seb128 :)
[16:10] <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:11] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:24] <roadmr> xnox: checkbox-ng on server images, yes. Just give me a second to confirm that works as intended
[16:27] <cjwatson> rbasak: php-json/i386 rebootstrapped, doing armhf and powerpc now
[16:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <roadmr> xnox: that's a good idea :)
[16:41] <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:42] <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:43] <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:44] <roadmr> infinity: you're right, let me think how best to organize this for server
[16:46] <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:47] <roadmr> infinity: nice solution, thanks!
[17:00] <bdmurray> stgraber: Could you have a look at bug 1279106 sometime?
[17:02] <stgraber> bdmurray: sure, though that won't be very soon
[17:04] <bdmurray> stgraber: I mention it because it seems to have a patch
[17:05] <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:06] <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:27] <u-foka> Can anyone help me debug gnome screensaver? Are there debug symbols for it somewhere?
[17:30] <seb128> u-foka, there are debugs symbols for most binaries in Ubuntu, see https://wiki.ubuntu.com/DebuggingProgramCrash
[17:32] <u-foka> seb128, thanks, i didn't know that these were moved to a separate repo :)
[17:33] <pitti> shadeslayer: it should only show a notification if there are drivers which you can install
[17:33] <shadeslayer> pitti: even if these drivers are not the "Recommended" ones?
[17:35] <pitti> shadeslayer: well, in that case you'd usually have more than one available, and one should be the recommended one?
[17:37] <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:38] <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:53] <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:55] <bdmurray> seb128: I'll have a look
[17:56] <seb128> bdmurray, thanks
[17:56] <bdmurray> seb128: daily view for all packages?
[17:56] <seb128> bdmurray, yes, but restricted to trusty
[17:56] <seb128> sorry, I forgot to mention
[17:57] <seb128> bdmurray, e.g https://errors.ubuntu.com/problem/39bbce347f9a5260a0fe549c5b650e5f2ea53b6c
[17:57] <seb128> or https://errors.ubuntu.com/problem/51867c7babfc41c749a4ed34ba54148f534a28c1
[17:57] <seb128> https://errors.ubuntu.com/problem/844b51aadb0b772e8277eec836767fbd00c5f46e
[18:32] <pitti> smoser: did you see my question yesterday wrt. the broken cloud-init images? should I file a bug about that?
[18:33] <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:34] <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:36] <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:37] <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 :)
[19:12] <smoser> pitti, utlemming just uploaded cloud-init_0.7.5~bzr952-0ubuntu1_source.changes
[19:13] <pitti> smoser: splendid, thanks; so tomorrow's cloud images should work again
[19:14] <smoser> yeah. sorry about that.
[19:15] <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: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:17] <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:22] <roadmr> smoser: then maybe the README for that NoCloud source could use updating to mention this
[19:22] <smoser> it shoudl be.,
[19:23] <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:24] <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:28] <xnox> stgraber: Yeah! latvia is through ;-) let's see how it goes against your other country affiliation game now ;-)
[19:30] <stgraber> xnox: I have a felling I'm missing some context here :)
[19:31] <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:32] <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:33] <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:34] <ochosi> xnox: watching olympics when you should be stressed out of your mind because of FF approaching with light-speed? :}
[19:38] <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:39] <xnox> roadmr: you need transitional package.
[19:40] <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:41] <roadmr> xnox: ok, I see, so they can't just go away
[19:42] <roadmr> xnox: thanks, let's fix that then
[19:53] <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:55] <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:56] <xnox> roadmr: see / search other examples in the archive.
[19:56] <xnox> roadmr: apt-cache show dummy, brings up a few.
[19:57] <roadmr> xnox: yay! yes, I have an example here, thanks!
[20:54] <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:55] <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:57] <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:58] <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/
[21:00] <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:01] <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:02] <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:03] <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:59] <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.
[22:00] <pitti> which hit us hard more than once already
[22:06] <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:07] <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:08] <pitti> cjwatson: nice, thanks for pointing that out
[22:09] <pitti> ah, that uses static data/ dirs
[22:12] <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:14] <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:15] <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:16] <sarnold> slangasek: that seems suspiciously easy :)
[22:17] <sarnold> slangasek: do we still want / need the no-change rebuilds of the rdepends to update them to libapparmor2?
[22:27] <doko> bdmurray, the php5-* issues were apparently tranistional. did build after given back
[22:35] <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:36] <jdstrand> )
[22:36] <jdstrand> meh, punctuation is not correct, but you get the idea
[22:37] <cjwatson> rbasak: ok, php-json/powerpc rebootstrapped now as well, should publish soon
[22:39] <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:40] <jdstrand> they were built with libapparmor1, so their depends has that, so if we didn't rebuild, libapparmor1 would stay in the archive
[22:41] <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:42] <seb128> out of proposed
[22:42] <jdstrand> oh, I didn't know it was that smart. cool
[22:42] <jdstrand> nice
[22:57] <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
[23:07] <doko> tkamppeter, did you track any blockers to convert system-config-printer to python3?
[23:08] <pitti> I hope you don't mean the UI -- wasn't there a plan to only use the backend from that?
[23:37] <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:38] <jjohansen> slangasek: yeah just looking at the rules, we kept asking is this really correct?
[23:59] <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


[19:25] <aschepler> Hi. Bug #1926856 against evolution-ews has been a big pain for me, and it has an upstream fix, but it looks like it hasn't been prioritized or anything since I entered it in May. Can I give it a little nudge forward, or is some other process better for it?


[02:02] <veebox> i pasted a big file to my desktop, but theres not a progress bar to be found
[16:27] <chemnic> Hi. I noticed the option for encrypting home is not present in latest installer. Is this a bug, or intentional?
[16:30] <TJ-> chemnic: I've not seen mention of it but ecryptfs isn't being actively maintained any more and ext4 and other file-system are gaining support for native encryption so I suspect it's been dropped
[16:33] <chemnic> I suspect encrypting the whole system with LVM is encouraged then?
[16:34] <TJ-> well we've had FDE and per-user for a while, they're 2 different use cases
[16:34] <TJ-> FDE protects in a power-off state, per-user protects whilst logged out
[17:09] <enyc> Silly (actually not so)  question:  Did anybody consider  btrfs or otherwise  as default ubuntu fs, instead of ext4?  =).
[17:10] <Onigiri> enyc: Does btrfs still shred data in raid5 & 6 modes?
[17:12] <enyc> Onigiri: i don't know =)
[17:13] <enyc> Onigiri: there is a whole-mess brough-up with ubuntu-devs about ext4 setitngs and e2fsprogs compatibility, but thas another matter.
[17:33] <TJ-> enyc: one of the scenrios I thought about later re ext4 is when using iscsi, if the iscsi host is 16.04, exports a blkdev to an 18.04 host, which formats it ext4, then later the iscsi host needs to fsck that F/S ... or the opposite, 18.04 iscsi host, formats and exports an ext4 formatted F/S, to a 16.04 host
[17:41] <AlexPortable> Is there a list of changes from 16.04 ?
[17:43] <tomreyn> AlexPortable: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes - not complete, yet, of course.
[17:44] <Azure_Chaos> How stable is the new beta compared to debian testing im trying to switch if its decent.
[17:49] <AlexPortable> I've used gnome-session-fallback in the past on 16.04, how would this work out on 18.04 ?
[17:50] <forester> I have read that synaptic will work again in 18.04. Is it so?
[17:50] <forester> Hi
[17:51] <ecormier> forester: it works...
[17:51] <forester> Thank you
[17:51] <ecormier> forester: no, I mean it works on 17.10
[17:52] <forester> I have tryed beta 17.10 and it was not.
[17:52] <ecormier> you have to login using xorg, not wayland
[17:52] <forester> Will Synaptic be working in UbuntuMate due to snappy?
[17:52] <ecormier> or there is an xhost command you can run to make it work
[17:53] <forester> ok
[17:53] <Odd_Bloke> The default desktop session in 18.04 will be X, not Wayland.
[17:53] <Odd_Bloke> (But under 17.10 you could still opt in to an X session.)
[17:53] <forester> When log in.
[17:54] <ecormier> https://askubuntu.com/questions/963842/synaptic-not-launching-on-ubuntu-17-10
[17:54] <tomreyn> and then there is the "xhost +SI:localuser:root" workaround, whihc i assume would also work for synaptic.
[17:54] <forester> Thank you
[17:54] <ecormier> tomreyn: yep
[17:55] <AlexPortable> I've set `XSession=gnome-fallback` in lightdmconfig, now moving to GDM, how do I set this?
[18:07] <AlexPortable> How can i get a taskbar on ubuntu 18.04 ?
[18:41] <enyc> TJ-: can you add that to relevant bug?
[18:42] <enyc> TJ-: i'm going to do a multi-boot test to check the grub2 issues following cjwatson's feedback in ubuntu-devel
[18:43] <enyc> TJ-: ALSO -- ther ewoulg be peolpe ithotut JUST ubuntu.  My understanding is that upstream  e2fsprogs has  ONLY JUST (within days!!)  enabled 64bit,metadata_csum  'for everybody' by default.  tytso wearing "debian hat" had turned it on for  (usulally more technically skilled)  debian users, in order to get more testing...  it wonut' have been on many places for a while etc.
[18:44] <TJ-> enyc: Yeah, I read Ted's comments. I'll see if I can get some time tomorrow to set up a iscsi test harness
[18:45] <estan> hi folks. i might be going insane. i'm helping test out a package from bionic-proposed. i noticed that some files listed in the installed file list (dpkg -L libblosc-dev) wasn't present after installation.
[18:45] <enyc> TJ-: i think it improtant you make some points clearly yourself,  explain etc.
[18:45] <estan> so i started investigating: https://paste.ubuntu.com/p/FMDjsJmypY/
[18:45] <TJ-> estan: where's the source for this package?
[18:45] <enyc> TJ-: i have files to setup a VM:  I'm going to   14.04-server (with minimal updates,), install 16.04-server also similarly, then 18.04-nightly     i.e. no HWE kernels out of the box
[18:46] <estan> TJ-: it's synced unmodified from debian unstable, so it's here: https://salsa.debian.org/debian/c-blosc/tree/debian/master
[18:46] <enyc> TJ-: then going to go update 14.04 and watch it rewrite bootloader ;p
[18:46] <TJ-> estan: give me a moment then
[18:46] <enyc> TJ-: see how much  grub-probe and os-prober  etc etc gets on or chokes-to-death
[18:47] <enyc> TJ-: INTERESTINGLY  it may be detecting/multi-booting those other os  with grub's own FS-reading code in userspace, not relying on 14.04 to have kernel support to mount the 18.04 FS
[18:47] <estan> TJ-: i had a little look at it, there's a libblosc-dev.examples, and the dh_installexamples helper is getting invoked during the package build (build log is here: https://launchpadlibrarian.net/360523710/buildlog_ubuntu-bionic-amd64.c-blosc_1.14.0+ds1-1_BUILDING.txt.gz)
[18:47] <enyc> TJ-: do you agree with my initial multi-booting test-case ?
[18:47] <enyc> [efi multi booting is somewhat different, but thats another matter]
[18:48] <estan> TJ-: dpkg -L libblosc-dev lists those example files, they just haven't been copied to where they're supposed to be during package installation, for some reason.
[18:48] <estan> (i'm trying this out in an ubuntu:18.04 docker container, if that matters, i hope the docker container doesn't have some strange dpkg that strips out stuff :p)
[18:49] <TJ-> ha! "fatal: could not create work tree dir 'master': No space left on device" ... I love lvextend :)
[18:57] <estan> i think i'm going to go ahead and blame these missing examples files on cosmic rays.
[18:59] <TJ-> estan: you're doing this in docker? is it redirecting /usr/share/doc/ to /dev/null ?
[19:03] <estan> TJ-: ah no, i started suspecting that and tried touching a file there. worked fine :/
[19:04] <estan> TJ-: https://paste.ubuntu.com/p/5MMRm2SkGT/
[19:06] <TJ-> estan: use "dpkg --debug=100 ..."
[19:12] <estan> TJ-: https://paste.ubuntu.com/p/FKgnVJS87f/ , hmm, so "D000100: tarobject nonexistent".
[19:14] <estan> but it's strange, because if i open up the .deb (https://launchpad.net/ubuntu/bionic/+upload/17731721/+files/libblosc-dev_1.14.0+ds1-1_amd64.deb), and have a look at data.tar.xz, the examples are there just fine.
[19:28] <estan> here's an excerpt from an strace of the dpkg process when (i think) it's trying to install one of the example files: https://paste.ubuntu.com/p/DhmpCR4njf/
[19:34] <TJ-> estan: did you build the package yourself or fetch it from the debian server?
[19:34] <estan> TJ-: i fetched it.
[19:34] <estan> from bionic-proposed using `apt-get download libblosc-dev`.
[19:36] <TJ-> estan: I can't reproduce your issue from the package itself, but I don't use docker. Does /any/ package manage to install anything under /usr/share/doc/ in that container?
[19:36] <estan> i'm really starting to suspect something funny with docker/overlayfs.. here's one bug that seems at least vaguely similar to this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836211 (note how it was re-opened).
[19:36] <TJ-> estan: have you checkd dmesg for any file-system error reports?
[19:38] <estan> hm, actually. i had a look at the strace package (which i installed actively myself inside the container), and it's docs are broken as well.
[19:39] <estan> e.g. https://paste.ubuntu.com/p/Tj23RQRs7K/
[19:39] <estan> so something with docker/overlayfs breaks it.
[19:40] <estan> the dmesg isn't showing anything unusual.
[19:41] <TJ-> Like I said earlier, maybe the internal dpkg is redirecting to /dev/null to save space since docs aren't expected to be useful in a container
[19:42] <estan> aha, i thought you meant redirection at another level (like the fs), not a patched dpkg.
[19:43] <estan> but now i think you may be right. i'll look at how the official ubuntu docker image is created.
[19:50] <estan> aha, bingo: https://paste.ubuntu.com/p/9m9HbW3cQp/
[19:50] <estan> thanks TJ-.
[19:52] <estan> very sneaky. and i still haven't found out where that file is written. oh well.
[19:58] <TJ-> estan: haha, I looked at the dpkg.conf but didn't think they'd slip a run-parts file in there
[19:59] <TJ-> estan: based on your pastebin the file isn't extracted from the tar at all
[19:59] <AlexPortable> How do I choose session to use on GDM?
[20:00] <estan> TJ-: yea. i didn't even know had such sneaky functionality built-in, and without even printing a big fat "hey i'm skipping this" during package installation.
[20:01] <TJ-> estan: :)
[20:01] <estan> (also underestimated the hoops the extent to which the docker image creating folks try to slim down people's images out of the box)
[20:01] <estan> s/the hoops//
[20:02] <TJ-> yes, it's a good obsession after all the bloat there is in other realms
[20:02] <TJ-> looking at you, Electron!
[20:02] <estan> *shudder*
[20:12]  * enyc grumbelsa nd mutters atd tries to get bionic boot image to work in virtualbox ;p
[20:13]  * TJ- pets Qemu :)
[20:16] <enyc> worknig with more ram ;p
[20:16] <enyc> i didn't find a "server" image
[20:22] <TJ-> enyc: you mean an ubuntu-server /installed/ image?
[20:23] <enyc> no
[20:23] <enyc> just dvd-image
[20:23] <enyc> iso-file
[20:23] <enyc> 'for "server"
[20:23] <TJ-> http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[20:23] <enyc> oh ;p
[20:23] <enyc> never mind, ive got bionic-desktop installing on end of disk after the other 2 servers
[20:23] <enyc> 'which is good enough
[20:23] <enyc> fine to test this multi-boot-problem
[20:24] <enyc> i'll see if 14.04 chokes and breaks grub in updating itself
[20:24] <TJ-> the cloud-image server has preinstalled bootables which are great for overlaying on a bootable disk layout https://cloud-images.ubuntu.com/bionic/current/
[20:44] <archetech-U> Client: HexChat 2.12.4 • OS: Ubuntu "bionic" 18.04 • CPU: Intel(R) Pentium(R) CPU G4400 @ 3.30GHz (992MHz) • Memory: Physical: 7.6 GiB Total (6.6 GiB Free) Swap: 1000.0 MiB Total (1000.0 MiB Free) • Storage: 13.1 GB / 168.3 GB (155.2 GB Free) • VGA: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] @ Intel Corporation Skylake Host Bridge/DRAM Registers • Uptime: 5m 28s
[20:44] <archetech-U> oops
[20:57] <enyc> TJ-: i see
[20:57] <enyc> TJ-: neveretnhess now updating my 14.04 (going to put in a new kernel...)
[23:21] <AlexPortable> How do I achieve this on ubuntu? https://www.omgubuntu.co.uk/wp-content/uploads/2017/11/firefox-57-on-ubuntu.jpg


[06:19] <mup> Issue operator#832 opened: App vs. unit inconsistency in `set_workload_version` <Created by sed-i> <https://github.com/canonical/operator/issues/832>
[13:28] <mup> Issue operator#832 closed: App vs. unit inconsistency in `set_workload_version` <Created by sed-i> <Closed by pengale> <https://github.com/canonical/operator/issues/832>


[06:55] <nhaines> pleia2: in the ubuntu-community-team list: lots of people saying that everyone's suggestions are wrong and discussion is waisting time and they have totally different viewpoints and everyone should just stop talking and act.
[06:56] <nhaines> Not in the ubuntu-community-team list: anyone offering any reasoning on why they disagree, hints as to what they think the problems are, or what they think anyone should be doing.
[06:56] <nhaines> At least among the people who are saying "stop talking."
[07:11] <pleia2> nhaines: heh, yeah, trying to collate the ideas and so we can have a clear, coherent list and people can sign up for what they wish
[07:11] <pleia2> where the volunteers flow is what we'll work on
[07:12] <nhaines> As it should be anyway.  But I wish people would quit saying we're obviously thinking about thinigs wrong and that we should just stop talking and start doing.
[07:12] <pleia2> indeed
[07:13] <pleia2> I brain filter them out, we'll have a list of projects that can build action items soon enough :)
[07:15] <pleia2> chillax pills for sleepies kicking in, time to wander to bed
[07:16] <nhaines> Yeah, was just annoying having to read the emails just in case.  :)
[07:16] <pleia2> agreed :)
[07:16] <nhaines> Yup, back to my book.    Good night!
[07:16] <pleia2> happy writing
[07:17] <nhaines> Thanks!  It's tedious but I'm really happy with the language support section even if I did basically have to learnJapanese.


[00:07] <effie_jayx> hey all
[00:27] <keenken> hey anyone home?
[00:28] <azeem_> Cameron just moved into his new home
[00:29] <hyperair> i thought cameron was a pace
[00:29] <hyperair> place*
[00:30] <keenken> if i wanted to start helping patch, read bugs, etc, where do I go.
[00:38] <kklimonda> keenken: well, if you want to triage on bugs then #ubuntu-bugs is a nice place to start, if you'd rather fix them I guess this channel is a good place.
[00:38] <keenken> triage means?
[00:41] <kklimonda> housekeeping - checking if bugs are reported in a right place, if they have enough informations and if so if they have the right status. sending them upstream (or asking reporters to do it) etc.
[00:44] <kklimonda> slangasek: can we drop delta for quodlibet-plugins now that debian package recommends either brasero or k3b and lastfmsubmitd has been moved to Suggests?
[00:45] <keenken> if i wanted to fix bugs, what would I need to know?
[00:49] <kklimonda> well, first it's good to know a bit about programming - it's good to understand a patch you are applying (or even writing)
[00:51] <kklimonda> then you should know about packaging, bug triaging and how to work with debian and upstream projects
[00:53] <keenken> kklimonda, where could I get a definitive guide or something of that nature(that incoporates all of that)?
[00:53] <keenken> kklimonda, i know a bit of c++
[00:54] <keenken> the rest after that, kklimonda, i'm not sure about.
[00:55] <kklimonda> keenken: see https://wiki.ubuntu.com/ContributeToUbuntu#Contributing%20to%20the%20Universe%20Repository%20%28MOTU%29
[04:57] <lfaraone> lifeless: in bug 556968, you said that the bug was fixed in 0.5.0 upstream, yet you set the upstream but task to "confirmed". It is in fact fixed, no?
[05:00] <lfaraone> lifeless: re cherrypicking, it appears that the relevant fix is in http://bazaar.launchpad.net/~bzr/bzr-git/trunk/revision/743 if I'm reading the changlog properly.
[05:17] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/556968/comments/3
[06:48] <bilalakhtar> Hi MOTUs! Call for sponsorship. Packages are liboauth (http://revu.ubuntuwire.com/p/liboauth ) , python-tweepy (http://revu.ubuntuwire.com/p/python-tweepy ) and gconjugo ( http://revu.ubuntuwire.com/p/gconjugo )
[06:49] <bilalakhtar> Ann of the above packages are lintian-free and test built in maverick chroot with no problem
[06:50] <nigelbabu> bilalakhtar: have you thought about getting that to debian?
[06:51] <bilalakhtar> nigelbabu: nope, I put packages into debian after ubuntu
[06:51] <bilalakhtar> I go *the* *long* way
[06:51] <nigelbabu> bilalakhtar: well, if you put it into debian, its comes into ubuntu automatically
[06:51] <bilalakhtar> so that I get credit for both
[06:51] <bilalakhtar> nigelbabu: I know that
[06:52] <nigelbabu> bilalakhtar: actually you get credit for both anyway
[06:52] <nigelbabu> when packages are synced, its still your name that comes on it
[06:52] <bilalakhtar> nigelbabu: but I can't become a motu just by sync requests, can I?
[06:53] <nigelbabu> well, being a motu is not about maintaing a single package
[06:53] <nigelbabu> or 2 or 3 packages
[06:53] <nigelbabu> its about fixing whats broken in universe
[06:54] <nigelbabu> if you want to maintain stuff, its best done in debian and letting it flow downstream (just my take)
[06:54] <nigelbabu> if you want to be motu, you should be working on merges, fixing bugs, fixing rc bugs, etc
[06:54] <bilalakhtar> nigelbabu: thanks for your advice, but I prefer to ring both the bells at the same time and get packages everywhere!
[06:54] <bilalakhtar> I am fixing needs-packaging bugs right now.
[06:54] <nigelbabu> I still dont get it
[06:55] <nigelbabu> if you get your pckage into debian, they end up being everywhere
[06:55] <bilalakhtar> nigelbabu: I know that. Ok, now my question is a different one. Which kind of bugs should we fix? shouldn't the upstream devels fix the,?
[06:56] <bilalakhtar> nigelbabu: you mean we should update packages as soon as bug fixes are released?
[06:57] <nigelbabu> bilalakhtar: depends on the upstream cycle.  if the upstream is going to make a new release soon, you're better off getting the new release in
[06:57] <maco> working upstream is pretty strongly encouraged
[06:57] <nigelbabu> and after that you can backport individual bug fixes
[06:57] <maco> submitting a debdiff to both only really makes sense if it needs to be fixed urgently
[06:57] <bilalakhtar> so thats it. and what are merges? (the last question)
[06:58] <maco> merges are when there's a new version in debian and there are patches in ubuntu and you need to reconcile the differences
[06:58] <bilalakhtar> maco: ok
[06:59] <bilalakhtar> maco: so are you a motu? can you review my packages?
[06:59] <maco> so if theres a -1ubuntu3 and debian puts out a -2, youd merge whatever changes were made from -1 to -1ubuntu3 with the -1 to -2 changes to make -2ubuntu1
[06:59] <bilalakhtar> atleast one of them
[06:59] <bilalakhtar> maco: yeah, got it
[06:59] <maco> yes im a motu but no i cant do any reviews until at least sunday
[07:00] <bilalakhtar> maco: Fine. another question. Can a person become a motu by just merges, bug fixing, package updating and new packaging ?
[07:00] <maco> yes
[07:01] <bilalakhtar> ok, then, so long. bye,guys!
[07:01] <maco> bug fixing and package updating was the bulk of my stuff
[07:01] <maco> only did one new package and one merge before applyin
[07:01] <maco> bah
[07:01] <maco> wouldve also liked to point out that there are enough danged packages already, no need to go adding /more/ to the pile in universe
[07:08] <imbrandon> mornin all
[07:10] <nigelbabu> maco: I wanted to add that part
[07:11] <nigelbabu> maco: the 'fix-the-broken-stuff-before-you-add-more' thing
[07:11] <maco> righto
[07:12] <nigelbabu> well, thanks for joining in
[07:12] <maco> when i said to persia when i first started thinking about motu that i needed to do a few more from-scratch packages on revu, he was like "no! we dont need more work!"
[07:12] <nigelbabu> maco: yeah, he still says that
[07:12] <maco> yep
[07:12] <nigelbabu> and there's still more broken stuff
[07:12] <maco> thats why ive only ever submitted one package to revu :P
[07:12] <nigelbabu> I've never used it
[07:12] <nigelbabu> I've used mentors.debian.org though
[07:13] <maco> and now im co-maintaining it in debian! so thatll get fixed before hitting ubuntu from now on :)
[07:13] <nigelbabu> wow, zach was right.  the trend is for ubuntu devs to become DM/DD
[07:14] <nigelbabu> I need to start my work on gwibber in debian... being procrastinating
[07:17] <Laney> yes! do it!
[07:18] <Laney> there are lots of people offering help but none actually doing it afaics
[07:18] <AnAnt> Hello, is the UDS over yet ?
[07:18] <Laney> last day today
[07:20] <AnAnt> ok
[07:20] <nigelbabu> Laney: yep.  I'm just lazy to partition and install debian
[07:20] <nigelbabu> once I get to it, things will move fast
[07:20] <Laney> you can get very far with a debian chroot
[07:20] <Laney> and the whole way with a vm
[07:20] <nigelbabu> debian chroot isn't that hepful whn you want a dbus thingie I think
[07:21] <nigelbabu> the last time I tried, I didn't have much time to test + gwibber wasn't really rocking then
[07:21] <nigelbabu> so, in a week or so, I'll get back to it
[07:21] <bilalakhtar> nigelbabu: Back. Your nick seems indian. Are you one?
[07:22] <maco> bilalakhtar: i was going to point out when you disappeared that there's plenty of stuff in the archive already that needs fixing. adding *more* packages (and thus more work) isnt really necessary to become a motu
[07:22] <nigelbabu> bilalakhtar: that's a surprise, most of the time folks say my nick seems enlighs.  Yes, I'm indian
[07:22] <maco> nigelbabu: it's the "babu" that sounds indian
[07:23] <maco> i only ever put one package through revu, and that was one that was previously in debian and ubuntu but was removed and i was taking over shepherding it
[07:23] <nigelbabu> maco: oh yeah, I forgot I'm using this nick.  usually, I use the nigelb one.  I'll change after uds
[07:23] <bilalakhtar> maco: You definitely know Indian words. Well, so you mean I should work on merges?
[07:24] <maco> bilalakhtar: at this point in the release cycle, *definitely* merges need doing
[07:24] <bilalakhtar> maco: After merging, should I attach a debdiff?
[07:24] <bilalakhtar> I mean, to the bug? or should I upload the complete package to something like revu?
[07:24] <maco> bilalakhtar: attach the .diff.gz if its a new upstream version (ie the .orig changed)
[07:25] <maco> no, merges dont go to revu
[07:25] <maco> youll know thats the case if 2.3-2ubuntu3 goes to 2.4-1ubuntu1
[07:25] <maco> if the software version number (before the -) stays the same though, then sure, debdiff works
[07:26] <bilalakhtar> maco: What is the difference betweek a debdiff and a diff.gz ?
[07:26] <maco> but! don't forget to use -vFOO where FOO is the last ubuntu version in the debian/changelog, that way it diffs against far enough back
[07:26] <Laney> maco: only the uploader has to do that
[07:26] <Laney> it's for the .changes file
[07:27] <bilalakhtar> Got it. https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[07:27] <maco> Laney: oh i thought the dsc would need too...
[07:27] <maco> ok
[07:27] <maco> debdiff is a patch of a package and you apply it after youve unpacked the orig.gz and diff.gz
[07:27] <Laney> and you never need to attach the diff.gz for a merge
[07:27] <maco> Laney: um ok i'll bow to you then
[07:27] <nigelbabu> maco: haha
[07:27] <Laney> just diff between the debian and ubuntu versions
[07:27] <maco> ive only ever had to have a sponsor on a merge once, and it was 6 months ago
[07:28] <Laney> :)
[07:28] <Laney> we ask for a .diff.gz when uploading new upstraem versions (ie 0ubuntu1)
[07:28] <Laney> of course there is always UDD these days…
[07:29] <maco> yeah UDD is how i did the last merge for which i lacked upload rights
[07:29] <nigelbabu> yeah, most of dev session went like this
[07:29] <maco> then bzr push lp:~kubuntu-members/amarok
[07:29] <nigelbabu> "we need to update docs" " we need to review patches" and "we need to use UDD more"
[07:29] <bilalakhtar> maco: Check whether I am right :- orig.tar.gz is the upstream tarball, .diff.gz is the debian/ directory diff (this one should be the debian one) and debdiff is the patches to be applied to make the package ubuntu-centric
[07:29] <nigelbabu> Almost all deve related sessions went into that mode at some point
[07:29] <maco> bilalakhtar: debdiff is the changes to be applied in *this specific revision*
[07:30] <maco> bilalakhtar: diff.gz contains all previous revisions as well
[07:30] <bilalakhtar> maco: S=ok
[07:30] <maco> (all kubuntu members can merge to the branches, then the ~kubuntu-dev folks check them and push to the buildds on occasion)
[07:31] <bilalakhtar> maco: In merges, diff.gz  and debdiff will be modified. orig won't be, diff will contain the debdiff changes also. am I right?
[07:31] <maco> depends
[07:32] <maco> if debian got a brand spankin' new version of the software, then ubuntu will need a new .orig.gz
[07:32] <bilalakhtar> maco: Can a merge have changes in the upstream part (outside debian folder) also? yeah, you answered it
[07:33] <Laney> it can, but you should use any patch system that is in place already
[07:33] <bilalakhtar> Laney: you mean quilt? yeah, I know how to use that. I have used it many times
[07:33] <bilalakhtar> QUESTION: Where can I find merges on which I should work?
[07:34] <bilalakhtar> I mean merge requests
[07:34] <maco> heh at uds barcelona i was asked a bunch of times "so when you going to apply to motu?" and my answer was "when i figure out quilt"
[07:34] <Laney> merges.ubuntu.com
[07:34] <maco> http://people.ubuntuwire.com/~lucas/merges.html
[07:35] <maco> bilalakhtar: by the way, see that touched-it-last column on the right of the page i linked? send an email to whomever is listed there letting them know you're doing that merge so they dont start trying to do it after youve already got it covered
[07:36] <bilalakhtar> maco: These are the lp ids of the people?
[07:36] <Laney> you can do any of mine without asking ;)
[07:36] <maco> bilalakhtar: yep
[07:37] <maco> ooh one of my TIL's is the package i'm co-maintaining in debian, and it can just be sync'd
[07:37] <maco> Laney: do i just file a sync request then?
[07:37] <Laney> I think I already did the haskell ones
[07:37] <Laney> maybe not -testpack
[07:37] <bilalakhtar> maco: I didn't understand what does "patch" mean in the third column in this page
[07:38] <bilalakhtar> Laney: What is merges.ubuntu.com for?
[07:38] <bilalakhtar> maco: I find all the patches there. nothing to work for.
[07:38] <Laney> same as that other page, showing outstanding merges
[07:39] <bilalakhtar> What is an "outstanding" merge?
[07:39] <maco> bilalakhtar: not-done-yet
[07:39] <bilalakhtar> maco: But what are the patches for, if the merge isn't done?
[07:39] <maco> bilalakhtar: and patch seems to be showing what's different between the two packages...ie, what you need to resolve
[07:39] <maco> its just a diff of the two
[07:40] <maco> by the way, i think the UDD way of merging works *really* well
[07:40] <maco> hmm
[07:40] <Laney> it looks like the ubuntu delta
[07:40] <maco> james_w: hey how do i get on the list of people who are willing to be spammed about merge requests?
[07:41] <bilalakhtar> maco: Yeah, same question. What does "last uploader" mean? the person who last uploaded the package in ubuntu?
[07:42] <maco> yes
[07:43] <bilalakhtar> maco: See if I am correct: The red merges on this page are packages who have a major version number change (part before -0ubuntu1 ) and white ones have a change after - .
[07:44] <maco> uhh dunno. i havent looked that closely. this is a fairly new page for this
[07:45] <bilalakhtar> maco: Last question: What does UDD mean?
[07:45] <maco> Ubuntu Distributed Development
[07:46] <maco> the new bzr way of making it easy to not-clash when 2 people work on the same package
[07:46] <maco> you can also just push stuff to launchpad and submit a merge request and someone will come along and do the uploady bits
[07:46] <maco> and bzr handles 3-way merges (upstream, debian, ubuntu) like you need for this /really/ well
[07:48] <bilalakhtar> maco: Do people use bazaar for pkg code hosting also? are all the packages having a branch in lp ?
[07:48] <maco> all but about 500 do
[07:49] <bilalakhtar> which are those 500?
[07:49] <maco> i dont have the list memorized ;-)
[07:49] <maco> i know some kde ones are on that list because they're so huge the import times out
[07:49] <bilalakhtar> maco: You could say "new packages", "universe old ones " etx
[07:49] <bilalakhtar> etc
[07:50] <maco> and yes the push is to use bzr for working on packages, but convincing 150 people to stop doing things they way they always have and learn something new is *hard*
[07:50] <maco> theyre fairly random
[07:50] <maco> its not *intentional* that 500 arent done
[07:50] <maco> its just that importing them has thus-far failed
[08:14] <carstenh> bilalakhtar: the ubuntu changes in topgit are also in debian, so this can be dropped.
[08:30] <imbrandon> maco: heh lots more than 150 i would say
[08:35] <slangasek> kklimonda: I question whether an ORed recommends is correct, but there's no need to carry a delta for that
[08:37] <shadeslayer> are new versions of packages allowed in SRU?
[08:37] <imbrandon> in rare cases minor revisions are
[08:38] <shadeslayer> like kraft recently released a new version 0.4 from their last stable release 0.2,i packaged it in my PPA
[08:38] <imbrandon> sounds like a good -backport canidate not sru, 0.2 to 0.4 likely will be a big jump in code
[08:38] <imbrandon> but you/i would have to look to verify that
[08:39] <shadeslayer> imbrandon: ok,also debian has picked up my package as a base to package their version,so ill wait for it to go into debian,sync to maverick and then do a backport
[08:40] <shadeslayer> debian bug 580718
[08:41] <imbrandon> shadeslayer: sounds like a good plan
[08:41] <shadeslayer> :)
[08:41] <shadeslayer> but this really depends on debian.. how long they take to upload it to their archives :P
[09:03] <carstenh> bilalakhtar: the ubuntu changes in topgit are also in debian, so this can be dropped.
[09:07] <bilalakhtar> carstenh: yeah? what?
[09:08] <bilalakhtar> carstenh: When did I talk about that?
[10:13] <jetienne> q. how can i recompile a given package ?
[11:08] <Laney> apt-get source foo; apt-get build-dep foo; cd foo-version; debuild
[12:03] <james_w> maco: join the ubuntu-reviews mailing list
[13:21] <Henk__> Hi guys; I have some questions with launchpad, bazaar and a project with subprojects (core, and large test files)
[13:21] <Henk__> Anybody here able to help me out?
[13:25] <shadeslayer> Henk__: try #launchpad
[13:26] <lfaraone> Currently, we have an application that foo that wraps the application bar, and takes a single argument, a path. We want to pass all excess arguments from foo to bar. Would the appropreate way be "foo PATHTOFILE -- ADDITIONAL_PARAMETERS"?
[13:27] <Henk__> the idea is to focus further development for ubuntu
[13:27] <Henk__> and setup the directories for this
[13:35] <carstenh> lfaraone: i really like this syntax for the necessary separation of arguments for the wrapper and the actual program, but if there is exactly one argument and this will not change there is no need for this explicit separation and it could be done easier: foo path bar_argument_1 bar_argument_2 ...
[13:37] <carstenh> Henk__: you should be more specific if you want anybody to answer. if it is to complex to subsume in a few lines a mailing list might be a better way to communicate and it would also reach more people
[13:37] <lfaraone> carstenh: on further review, it looks like there could be two arguments.
[13:37] <lfaraone> carstenh: and the first argument may be optional.
[13:38] <carstenh> lfaraone: an optional argument sounds like -- might be a sane choice :)
[13:39] <Henk__> carstenh: I am already stuck for a couple of days; reading more docs/wikis/pdfs on the subject brings me not any further; I think I am missing some vital point
[13:40] <carstenh> lfaraone: on the other side, dpkg chooses a different approach and it works quite well, but for this it is required that all options can be unambiguous assigned to one command
[13:43] <lfaraone> Anybody have time to do some straightforward SRU verification on bug 578841?
[13:44] <carstenh> Henk__: nobody can help you if you don't ask your question ...
[13:48] <Henk__> I am still puzzling about the directory structures... it is the combination of a group project in launchpad+bazaar (the basis for future inclusion in ubuntu) and a core package and optional large data/test packages to test/checkout the numerics
[13:49] <Henk__> how to set up the local tree? where to init bzr and how about packaging?
[13:50] <Henk__> you do not want to create an .orig.tgz of a 50 MB test data set
[13:52] <Henk__> the way I normally work is to extract a code into a user directory and extract everything there; however following standard guidelines the 3 codes should go to /usr/bin, the doc to /usr/share/somting, where should the test files go?
[13:54] <Henk__> so one should think of the following packages/lauchpad entries => code_x.y.z-all.deb, test_x.y-any.deb, doctex_x.y-any.deb
[13:59] <Henk__> the tests produce files which are included in a (large checkout) pdf with proof of error free code
[14:00] <Henk__> not evrybody will want to do that; but the doc shoul be included in the deb
[14:12] <Henk__> or is there any package which has a similar setup; then I would be able to apt-get the sources...
[14:12] <Henk__> preferable ubuntu native
[14:13] <azeem> Henk__: why is code Arch: all and test Arch: any?
[14:14] <Henk__> code wil be compiled; the tests contain ascii data sets; should work on any arch (incl windows)
[14:14] <azeem> then you got it backwards
[14:15] <Henk__> sorry; please read backwards then azeem :)
[14:15] <azeem> *shrug*
[14:15] <Henk__> pardon me?
[14:16] <Henk__> (just a sec; something urgently to do)
[14:25] <Henk__> (back again)
[14:26] <carstenh> Henk__: -doc packages are commonly named packagename-doc, separation of verification tool and the actualy program seems to be fine
[14:27] <carstenh> Henk__: native packages are debian/ubuntu-specific programs that are not useful on another system, unless you are a debian developer for at least 10 years, those can package their software however they like ;)
[14:27] <Henk__> how do you accomplish that they go into the same packagename directory where tests are under "testdir" and the doc under "docdir"?
[14:28] <azeem> what do you mean with "packagename directory"
[14:28] <Henk__> well I meant by I am developing under ubuntu; so there is no upstream origin
[14:28] <azeem> that has nothing to do with packaging
[14:29] <Henk__> some tarball which comes from a distant source
[14:30] <Henk__> the 3 subpackages will have to be packaged otherwise apt-get will not work
[14:30] <carstenh> there are enough examples of non-native packages where the maintainer is also upstream
[14:30] <Henk__> I am not upstream, I have some ubuntu machines myself
[14:31] <carstenh> Henk__: /usr/share/debhelper/examples (or similar) has an example how to create multiple binary packages from one source package
[14:31] <Henk__> I will peek into it; sec
[14:32] <carstenh> Henk__: and if you are not sure which directories should your files go to you should first try to find the answer by reading the FHS (filesystem hierarchy standard)
[14:33] <Henk__> no I meant my own develpoing file structure needed for launchpad/bazaar
[14:34] <Henk__> the 3 codes can go into /usr/bin
[14:35] <Henk__> the pdfs can go into /usr/share/doc/packagename
[14:35] <carstenh> Henk__: you can change the layout later if you want and you don't need to publish your repository in early stages
[14:35] <azeem> Henk__: what does launchpad/bzr have to do with /usr/bin?
[14:36] <carstenh> so I wouldn't try to find the perfect directory layout before you even start the project
[14:36] <Henk__> I want to start using launchpad/bzr
[14:36] <Henk__> the code is up and running for a couple of years now
[14:36] <Henk__> published with tarballs
[14:37] <Henk__> now is the time to finally start with bazaar
[14:37] <Henk__> and thus with launchpad as well
[14:37] <carstenh> | Bug #337209 in bzr-builddeb: “import-dsc doesn't work against ...
[14:37] <carstenh> looks like bzr can import debian source packages
[14:37] <Henk__> when that is all in place then part of std universe is an optiom
[14:39] <carstenh> any reason why packaging it without bzr and then import it using this tool and let the tool developed by experienced bzr users decide which layout to choose?
[14:39] <Henk__> it is not yet debian or any distro format; only tarball with an apache license (which by the way is not suportted by dh_make)
[14:40] <Henk__> I am the developer, and I want start to use bazaar
[14:40] <carstenh> dh_make just creates templates not ready to use packages
[14:40] <Henk__> I know
[14:41] <Henk__> but how to package the test files?
[14:41] <carstenh> how can anything not beeing supported by a bunch of file templates and a tools that copies these around?
[14:41] <Henk__> you do not want to copy them; the package will double to 100 MB for the test files only
[14:42] <carstenh> are these files created during package building or are the distributed by upstream? if so, are they distributed in a different tarball?
[14:42] <Henk__> they will be split
[14:42] <Henk__> the test files are not distributed now
[14:43] <carstenh> and they will be distributed how?
[14:43] <Breaking_Pitt> guys I can't continue and i don't know what to do...can someone provide me some help in tus problem? http://pastie.org/960216
[14:43] <Henk__> but are available on request
[14:43] <carstenh> Henk__: so not in the upstream tarball ... create a different source package
[14:44] <Henk__> they will be now; my ADSL line doesnt like webcrawlers to crawl such big tarballs
[14:45] <Henk__> yes carstenh I concluded that; the way to go for the test files; but how about the optional (large) docs? they can go into .usr/share/doc or local
[14:47] <carstenh> Henk__: i wouldn't split doc and binary into two source packages but into two binary packages
[14:48] <carstenh> Breaking_Pitt: looks like a bug in debhelper or the upstream makefile unless you told it in your rules file tthat it should use the target distclean
[14:49] <carstenh> Breaking_Pitt: let someone check your rules files or try to overwrite the clean target
[14:50] <Breaking_Pitt> my rules file it's a default rules file
[14:50] <Breaking_Pitt> can i pastie it?
[14:50] <carstenh> not in a channel, there are paste sites ...
[14:50] <carstenh> google after override_dh_clean should point you into the right direction
[14:51] <Breaking_Pitt> here is my rules http://pastie.org/960282
[14:51] <Breaking_Pitt> and here is my makefile
[14:52] <Breaking_Pitt> http://pastie.org/960285
[14:54] <carstenh> i don't know why dh runs the distclean target, both look ok.  try asking google what override_dh_clean is and does. i have to go now
[14:54] <carstenh> i hope you can fix your problem :)
[14:55] <Breaking_Pitt> can by setup.py the problem carstenh ?
[14:59] <carstenh> Breaking_Pitt: | If there is a setup.py or Build.PL, it is run to clean the package.
[14:59] <Breaking_Pitt> I have a setup.py
[14:59] <carstenh> Breaking_Pitt: this says the manpage, so yes, it could :)
[14:59] <Henk__> (away for 15 min)
[15:00] <carstenh> Breaking_Pitt: man dh_auto_clean suggests the same solution i told you
[15:01] <Breaking_Pitt> let me see
[15:03] <Breaking_Pitt> I have to use this? override_dh_auto_clean: $(MAKE) packageclean
[15:19] <Breaking_Pitt> carstenh, maybe this can be caused by my debhelper version?
[15:19] <Breaking_Pitt> i have tested the same in the ubuntu vm an dit works correctly
[15:23] <kklimonda> can we update all gnome projects to the newer micro release version (instead of backporting fixes) or is it only for packages in main?
[15:28] <kklimonda> jdong: ^ :)
[15:29] <ari-tczew> kklimonda: do you mean about lucid right?
[15:30] <kklimonda> ari-tczew: lucid and karmic
[15:31] <jdong> kklimonda: depends on how hairy the debdiffs look :)
[15:33] <Henk__> (back again)
[15:34] <Henk__> (still stuck)
[15:35] <Henk__> thnaks for the help; bye
[15:36] <kklimonda> jdong: the one for lucid looks harmless.. the karmic one is bigger (as there were two micro releases) and it touches parts of interface
[15:38] <jdong> lucid one sounds okay then, but the Karmic one might need a closer look
[15:38]  * kklimonda thinks that we should give it a go anyway as the upstream author asked to do that
[15:39] <jdong> if upstream asks to do it, we can certainly evaluate it a bit more closely
[15:39] <kklimonda> he's apparently getting bug reports from ubuntu users :)
[15:39] <kklimonda> mhm, I have diffs ready so I'll upload them to the bug report and give you a link
[15:40] <jdong> ok
[15:40] <jdong> I'll be in and out today, but when you link them I'll certainly give em a look
[15:47] <kklimonda> jdong: lucid patch uploaded at bug 580522
[15:47] <kklimonda> hmm, maybe I should just attach branch?
[17:20] <carstenh> Breaking_Pitt: the debhelper version is not the problem
[17:20] <Breaking_Pitt> what cause that in ubuntu works and in debian no?
[17:21] <carstenh> Breaking_Pitt: oh, then it is the debhelper version, though the same could happen with the debhelper from debian and another build system
[17:22] <Breaking_Pitt> I think that it's the main reason
[17:22] <Breaking_Pitt> i have tested with unstable in debian
[17:22] <Breaking_Pitt> and it create the package in a correct way
[17:24] <carstenh> this part ofdebhelper is not considered to be working with all upstream build systems, at least according to the man page, but in your case a versioned dependency on debhelper instead of overwriting the clean target is another way to make your package build
[17:24] <Breaking_Pitt> ;) thanks for all
[17:24] <Breaking_Pitt> but still have a lot of doubts
[17:24] <Breaking_Pitt> :(
[17:25] <carstenh> Breaking_Pitt: could also be some python issue, i don't know how setup.py works. which debhelper version do you use under ubuntu?
[17:26] <Breaking_Pitt> 7.4.15
[17:27] <carstenh> Breaking_Pitt: changelog does not look like the different debhelper version could cause this
[17:27] <Breaking_Pitt> i don't know
[17:28] <carstenh> writing a clean target in debian/rules could avoid a lot of headache ;)
[17:28] <carstenh> or you could install the newer debhelper on ubuntu and try ...
[17:30] <Breaking_Pitt> in ubuntu works correctly... in debian no
[17:32] <carstenh> so it fails with the newer debhelpre version. i would really just copy and adapt a clean target from /usr/share/doc/debhelper/examples/
[17:46] <Breaking_Pitt> ok let me see
[20:05] <kklimonda> jdong: do you, as a member of sru team, prefer working with branches linked to sru-able bugs or rather with patches attached to bugs?
[20:06] <jdong> kklimonda: I don't have a preference either way :)
[20:07] <kklimonda> jdong: and what is the "right" place to push branches to LP for packages to? lp:~<login>/<distro>/<serie>/<package>/<pocket> looks good?
[20:07] <jdong> kklimonda: that I don't know :)
[20:08] <kklimonda> jdong: I've also pushed branch for karmic part of bug 580522 lp:~kklimonda/hamster-applet/karmic-proposed
[21:38] <kklimonda> btw, who can verify sru in universe and who can do it in main?