=== kees_ is now known as kees
=== neunon_ is now known as neunon
[03:47] <Ionic> what's the difference between this channel and #ubuntu-app-devel?
[04:24] <Snow-Man> this one is better
[04:24] <Snow-Man> (I have no idea)
[04:28] <RAOF> Ionic: From /topic - “Devel of Ubuntu (not support or app devel)”.
[04:36] <Ionic> RAOF: yes, but what is "app development" specifically?
[04:36] <RAOF> Development of apps that run on Ubuntu?
[04:36] <Ionic> if I have problems with the ubuntu build system for building a package, where do I ask?
[04:36] <RAOF> Particularly: Ubuntu Touch apps.
[04:37] <RAOF> #ubuntu-app-devel
[04:37] <RAOF> Unless you're developing a component of Ubuntu, this is not (the best) channel for you :)
[04:37] <Ionic> (more like dh_* stuff, but the problem seems to be ubuntu-specific)
[04:38] <Ionic> ok, thanks
[04:38] <RAOF> Hm, dh_ stuff is more this channel's forte.
[04:38] <RAOF> What's seems to be your problem?
[04:39] <Ionic> well, I have a rather complex source package with multiple subpackages
[04:39] <Ionic> some libraries, some binaries, some data stuff
[04:39] <Ionic> one of those binaries naturally depends on libraries build off that source package
[04:40] <RAOF> As is so often the case, yes...
[04:40] <Ionic> dependencies are added via dh_makeshlibs/dh_shlibdeps... which works okay-ish for Debian, but seems to be problematic on Ubuntu for some reason
[04:40] <Ionic> the dependencies are "okay", but incomplete
[04:40] <RAOF> That's odd; we don't change that infrastructure to any great extent.
[04:40] <Ionic> not really incomplete more like... minimal
[04:41] <Ionic> a dependency on other_pkg is added that depends on lib_pkg{1,2,3}
[04:41] <Ionic> our Debian package also depends on lib_pkg{1,2,3} directly
[04:42] <RAOF> Ah.
[04:42] <Ionic> the issue is weird, I'm currently using override_dh_* to run dh_makeshlibs -- -dV and dh_shlibdeps -- -v
[04:42] <Ionic> (for getting more useful information)
[04:42] <RAOF> Does base_pkg link directly with lib_pkg{1,2,3}, or does it only link with other_pkg?
[04:42] <Ionic> I can show you what I mean once the pbuilder run is through
[04:42] <Ionic> it links directly with lib_pkg{1,2,3}, that's the weird thing
[04:43] <Ionic> it looks like Ubuntu optimizes this stuff, while Debian is fine leaving it unoptimized
[04:43] <RAOF> Does it use any symbols from lib_pkg{1,2,3}?
[04:43] <RAOF> (Directly)
[04:44] <RAOF> Because we do indeed by default not add transitive dependencies of that nature.
[04:44] <RAOF> (Although neither will Debian at some point)
[04:44] <Ionic> of that I'm not sure
[04:44] <Ionic> meh
[04:44] <Ionic> -dV was a mistake, now my build failed
[04:45] <Ionic> dpkg-gensymbols probably wants -d -V for some reason
[04:46] <Ionic> RAOF: just for reference, can I force Ubuntu to add transitive dependencies?
[04:46] <Ionic> although, to be honest, I do not understand why the specific user ran into problems anyway
[04:47] <Ionic> as transitive dependencies should still be fulfilled by minimized dependencies
[04:47] <RAOF> Ionic: dpkg-shlibdeps *should* be adding a dependency for everything in your DT_NEEDED sections.
[04:47] <RAOF> (As dumped by objdump -x /path/to/your/thingy | grep NEEDED)
[04:47] <Ionic> thanks, that will be handy
[04:48] <Ionic> aha!
[04:48] <Ionic> the three libraries are not showing up in DT_NEEDED
[04:49] <Ionic> that's rather new though... older versions of the software have them in DT_NEEDED, so we probably broke something(?)
[04:50] <RAOF> This likely means that the program doesn't use symbols from those libraries directly, and our default flags pass --as-needed throug to the linker.
[04:50] <RAOF> Or possibly you broke something :)
[04:50] <Ionic> ah
=== zsombi_ is now known as zsombi
[04:51] <Ionic> well, I can "bisect" at least
[04:51] <RAOF> --as-needed shouldn't change program behaviour, though, because you'll still load the libraries, just indirectly.
[04:51] <Ionic> so that's very helpful, thank you
[04:51] <Ionic> when was -Wl,-as-needed introduced?
[04:51] <RAOF> Quite a while ago.
[04:52] <RAOF> 2010 :)
[04:52] <Ionic> weird... my gentoo system is also listing the libraries in DT_NEEDED
[04:52] <Ionic> and AFAIK it also uses -Wl,-as-needed by default
[04:54] <RAOF> Also, -as-needed looks like it was a Wheezy Debian goal :)
[04:55] <Ionic> so, probably not the cause of this
[04:55] <RAOF> That's looking likely, yse.
[04:57] <Ionic> does launchpad PPA have an automatic version history, or is that up to the group/person?
[04:59] <RAOF> Up to the group/person.
[04:59] <RAOF> It'll keep old binaries around for a small time, but it's pretty aggressively reaped.
[05:01] <Ionic> http://pastie.org/private/qhuvueripuwkld2daiyna definitely linking against libNX_{damage,tst,composite} ... and not even using -Wl,-as-needed
[05:09] <Ionic> hmhmhm.
[05:09] <Ionic> our release builds are still fine, only nightlies are affected
[05:09] <Ionic> according to https://launchpad.net/~x2go/+archive/ubuntu/stable/+files/nxagent_3.5.0.31-0%7E605%7Eubuntu14.04.1_amd64.deb anyway
[05:10] <Ionic> unpacking and examining leads to "NEEDED               libNX_Xdamage.so.1" etc., which is fine
[05:10] <Ionic> ok, now... what did I break?
[05:11] <RAOF> :)
[05:16] <Ionic> the only changes are related to the client part, and adding pointer guards to the server code...
[05:23] <Ionic> weird, I cannot reproduce that
[05:24] <Ionic> building myself via pbuilder-dist trusty leads to the same missing libraries in DT_NEEDED
[05:25] <Ionic> off the 3.5.0.31 release branch ofc
[05:35] <Ionic> just to make sure I didn't mess up by using the upstream git repo, I've checked out the bzr branch (bzr branch lp:~x2go/x2go/nx-libs_build-main), ran dpkg-buildpackage -S and am now running pbuilder-dist trusty ../nx-libs_3.5.0.31-0x2go1.dsc again
[05:35] <Ionic> it's missing the "ubuntu..." tag, but I believe this to be a non-issue
[05:38] <Ionic> 'lo and behold... same issue
[05:38] <Ionic> at this point I can only assume it's caused by something ubuntu-internal
[05:43] <RAOF> Ionic: Hm. Feel free to pastebin the pbuilder log or something.
[05:43] <Ionic> uh, that's huge
[05:44] <RAOF> True :)
[05:44] <RAOF> That's why it's in a pastebin!
[05:44]  * RAOF is going to make dinner now, but will be back later.
[05:45] <StevenK> RAOF: Dinner at quarter to 4?
[05:46] <RAOF> *Making* dinner. It then gets to simmer gently until we want to eat it!
[05:49] <Ionic> well, that crashed my terminal.
[05:50] <Ionic> www.ionic.de/x2go/ubuntu-pbuilder-paste.gz
[06:21] <Ionic> I'll need to go to bed, but I'll read the backlog
[06:21] <Ionic> oh, one more thing maybe
[06:22] <Ionic> https://launchpad.net/~x2go/+archive/ubuntu/stable/+build/7083881/+files/buildlog_ubuntu-trusty-amd64.nx-libs_2%3A3.5.0.31-0%7E605%7Eubuntu14.04.1_BUILDING.txt.gz < this is the build log for the "same" build on launchpad about a month ago (2015-03-17)
[06:24] <Ionic> and the package created through that is fine, seriously. https://launchpad.net/~x2go/+archive/ubuntu/stable/+files/nxagent_3.5.0.31-0%7E605%7Eubuntu14.04.1_amd64.deb < that's the file created by that build
[06:24] <Ionic> feel free to unpack it and check with objdump
[06:44] <ricotz> flexiondotorg, https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1443773
[06:44] <ubottu> Launchpad bug 1443773 in plank (Ubuntu) "FFe: Sync plank 0.9.0-1 (universe) from Debian experimental (main)" [Undecided,New]
[07:13] <RAOF> pitti: Good morning! Would you like to upload a new colord to experimental?
[07:15] <seb128> RAOF, hyey, he's in Texas this week, maybe not up yet
[07:15] <RAOF> seb128: Oho!
[07:15] <RAOF> Well, that invitation is open to all DDs :)
[07:20] <seb128> RAOF, sorry, I don't have a debian install to build binaries and Debian doesn't accept source uploads, maybe Laney can help when he gets online in 40min or so
[07:20] <RAOF> seb128: Oh, no urgency.
[07:29] <tjaalton> RAOF: I can do that :)
=== enrico_ is now known as enrico
[08:01] <darkxst> cjwatson, hi, is user-setup in ubuntu forked from debian? we have a bug with Automatic Login option, but that code does not exist in debian. see bug 1412791
[08:01] <ubottu> bug 1412791 in user-setup (Ubuntu) "automatic login configured in ubiquity cannot be disabled by gnome-control-center" [Undecided,New] https://launchpad.net/bugs/1412791
[08:03] <darkxst> cjwatson, and relevant code: http://bazaar.launchpad.net/~darkxst/user-setup/noTimedLogin/revision/284
[09:21] <Odd_Bloke> How can I map between Ubuntu versions and codenames in Python?  I'm struggling to get Google to produce anything useful.
[09:26] <jamespage> Odd_Bloke, python-distro-info
[09:28] <Odd_Bloke> jamespage: Ah, thanks. Is there documentation for it anywhere?
[09:30] <jamespage> Odd_Bloke, "pydoc distro_info"
[09:30] <jamespage> ;-)
[09:31] <jamespage> Odd_Bloke, UbuntuDistroInfo is probably the class you're interested in
=== Malsasa_ is now known as Malsasa
[09:37] <Odd_Bloke> jamespage: Great, thanks!
[09:53] <Anupkumar> can any one help me with this bug? https://bugs.freedesktop.org/show_bug.cgi?id=89711
[09:53] <ubottu> Freedesktop bug 89711 in general "udisksctl loop-setup does not mount some ISOs" [Normal,New]
=== marcusto_ is now known as marcustomlinson
[10:47] <Riddell> pitti: can you say why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html should a bunch of regressions on kde bits but when I look at the public links it's all green ?
[10:49] <Laney> Riddell: Looks like it hasn't synced from the machine which runs them to jenkins.qa.ubuntu.com
[10:52] <Laney> Riddell: I pinged the people who should be able to see
[10:52] <Laney> (#ubuntu-ci-eng)
[10:53] <Riddell> thanks Laney
[10:53] <LocutusOfBorg1> hi folks :)
[10:54] <LocutusOfBorg1> ginggs, sometimes people give thanks to developers
[10:54] <LocutusOfBorg1> and this is for you :)
[10:54] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1443152/comments/4
[10:54] <ubottu> Launchpad bug 1443152 in virtualbox (Ubuntu) "BUG: unable to handle kernel paging request at 00007fe416858408" [Undecided,Invalid]
[11:03] <ginggs> LocutusOfBorg1: it was all your handiwork :)
[11:04] <LocutusOfBorg1> there is no work without a sponsor ;)
=== marcusto_ is now known as marcustomlinson_
=== MacSlow is now known as MacSlow|lunch
=== DalekSec_ is now known as DalekSec
=== _salem is now known as salem_
[12:17] <cjwatson> darkxst: Automatic login is an Ubuntu addition to user-setup, yes.  It should be reasonably clear from the changelog.
[12:18] <cjwatson> darkxst: You should branch from and propose merges into lp:~ubuntu-core-dev/user-setup/ubuntu, not lp:user-setup.
[12:18] <cjwatson> darkxst: Then the MP might be comprehensible :-)
[12:19] <cjwatson> I suspect you just need to resubmit that MP with the correct target branch.
[12:38] <smoser> pitti, wolfe is back
[12:38] <smoser> sorry, i was on holiday yesterday
=== marcusto_ is now known as marcustomlinson_
=== MacSlow|lunch is now known as MacSlow
[13:24] <strikov> Hey guys. Is it possible that /run/systemd/system/ folder disappears from time to time? We're trying to fix juju bug where it can't detect systemd *from time to time* by checking if this path exists.
[13:24] <strikov> I suspect that the issue is somewhere else but want to make sure that we don't do anything very wrong.
[13:26] <rbasak> strikov: you know that /run disappears on boot, right?
[13:27] <strikov> rbasak: yeah, i observe this issue by running juju bootstrap multiple times
[13:28] <strikov> rbasak: so i don't think that reboot is our problem
[13:28] <pitti> Good morning!
[13:28] <pitti> smoser: cheers
[13:28] <pitti> Riddell: I think the public jenkins is ridiculously behind
[13:28] <pitti> RAOF: ah, can do; just from git?
[13:31] <pitti> Riddell: I retried a bunch of failed tests this morning
[13:31] <pitti> there's still a couple of them left, I'll keep retrying
[13:32] <pitti> RAOF: want to push a release tag?
[13:33] <pitti> RAOF: ah, collab-main, I'll do it I guess
[13:35] <strikov> morning pitti; i just integrated your 'switch to upstart' adt code into juju-1.22.1 (1.23 won't be ready before release); it works nicely but I wonder if it's possible to run this code once during testbed setup; Right now I do this switch at the very beginning of every test and it looks messy;
[13:37] <cjwatson> bdrung: Would you mind if I uploaded an sbuild merge?  There's a bug fix in Debian that affects building d-i
[13:37] <bdrung_work> cjwatson, not at all!
[13:38] <cjwatson> bdrung_work: Thanks.  We're very close to being able to run modern sbuild in Launchpad and it'd be nice to be using a package from Ubuntu for the purpose :-)
[13:38] <pitti> strikov: (sprint meeting going on, let's discuss later)
[13:39] <strikov> pitti: sure, thanks
[13:40] <bdrung_work> cjwatson, why are Debian and Ubuntu have problems to use the packages from the repositories on their build machines?
[13:53] <cjwatson> bdrung_work: Debian has a load of changes to buildd, nothing significant to sbuild
[13:55] <cjwatson> bdrung_work: In Ubuntu's case the main blocker has been patches for ddebs, but we're almost over that hump now
[14:16] <rbasak> pitti: fyi, bug 1431581 looks like it is due to systemd switch, based on https://launchpad.net/ubuntu/+source/nis/3.17-32ubuntu2 from slangasek
[14:16] <ubottu> bug 1431581 in nis (Ubuntu) "NIS does not install on 15.04" [Undecided,Confirmed] https://launchpad.net/bugs/1431581
[14:17] <pitti> rbasak: queueing, thakns
[14:23] <pitti> RAOF: uploaded and release tag pushed
=== caribou_ is now known as caribou
[14:25] <pitti> Laney: can I ask you to review/accept my apport upload? important security update
[14:27] <pitti> infinity1: or you &^
[14:29] <infinity1> pitti: Looking.
[14:29] <pitti> Laney, infinity1: ah, stgraber is looking already
[14:30]  * Laney nods
=== jhenke_ is now known as jhenke
[14:31] <infinity1> pitti: You should normalize your TZ when generating ChangeLog.
=== infinity1 is now known as infinity
[14:32] <stgraber> apparently there's no bzr flag for it (we just checked)
[14:32] <pitti> yeah, sorry about that massive changelog diff
[14:32] <pitti> perhaps I can call bzr log with $TZ or so
[14:32] <infinity> stgraber: No, but there's an environ... Yeah.
=== danjared_ is now known as danjared
[14:35] <pitti> infinity, stgraber: fixed in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2945, so from now one this shouldn't happen any more
[14:36] <pitti> except for the next upload which will put the changelog timestamps back
[14:43] <infinity> pitti: Ta.  That drives me nuts.
[14:52] <pitti> infinity: is a final full langpack upload okay for next Monday? We often/usually do that on Monday (final translation deadline), but just checking
[14:53] <pitti> we'll get a cron'ed export on Monday; if we need/want it earlier, I'll ask the LP guys to kick off a manual run
[15:39] <pitti> wgrant: can we do a manual full vivid langpack export on Thursday, so that we can upload the final packs on Fri?
[15:39] <pitti> wgrant: I think the cron would only give them to us on Monday, which is too late
[15:39] <pitti> seb128: FYI, we just got a langpack update for vivid, so cron is working again
[15:40] <seb128> pitti, \o/
[16:03] <mdeslaur> kees, infinity, stgraber, slangasek: meeting?
[16:03] <pitti> kees: TB meeting?
=== Malsasa_ is now known as Malsasa
[16:56] <arges> hallyn_: bug 1444057 fyi
[16:56] <ubottu> bug 1444057 in qemu (Ubuntu) "gdb in a guest VM fails to continue" [High,In progress] https://launchpad.net/bugs/1444057
=== dholbach__ is now known as dholbach
[18:15] <smoser> arges, does that really only fail inside a vm ?
[18:22] <cyphermox> kirkland: could you please check if /usr/lib/pulse-6.0/modules contains module-bluez5-discover.so?
[18:27] <arges> smoser: it fails outside a vm, i'm trying to debug a vm
[18:28] <smoser> ok. that makes more sense.
[18:28] <smoser> "in a guest vm" was confusing in the subject of the bug.
[18:29] <arges> smoser: i'll fix that=
[18:29] <arges> gdb remote target of a guest VM fails to continue Edit
[18:30] <smoser> :)
=== Malsasa_ is now known as Malsasa
[18:59] <hartmans> Hi.  I made a backport request (LP: #1439215) and unfortunately the person resolving that didn't act on the debdiff I attached.  The package builds but is useless without the package.
[18:59] <ubottu> Launchpad bug 1439215 in utopic-backports "Please backport moonshot-ui 0.7.1-1 (universe) from vivid" [Undecided,Fix released] https://launchpad.net/bugs/1439215
[19:00] <hartmans> I could use help with the right procedure to request a new upload with the diff applied.
[19:00] <hartmans> Should I use the existing bug or a new bug and if a new bug, on the package or on the backports project?
[19:26] <cjwatson> pitti: https://code.launchpad.net/~cjwatson/ddeb-retriever/lp-fetch/+merge/256192
[19:27] <cjwatson> debfx: ^- Could you look at hartmans's request above, since you processed that backport?
[19:28] <cjwatson> hartmans: if it were me I would reopen the bug on the grounds that it wasn't completely acted upon
[19:29] <hartmans> If I do that should I attach a new debdiff to update version and subscribe ubuntu-sponsors?
[19:29] <hartmans> Also, do sponsor requests need a debdiff or is a branch link acceptable?
[19:29] <cjwatson> hartmans: Shouldn't be necessary; any sponsor should be able to cope with trivial reformatting
[19:29] <cjwatson> hartmans: And ditto I'd expect a sponsor to be able to cope with grabbing a patch from any roughly reasonable source
[19:30] <cjwatson> (I'm not saying that definitely nobody will be jobsworth about it, but ...)
[19:33] <debfx> hartmans: sorry, must have missed that. I'll upload a new version.
[19:35] <cjwatson> pitti: We should manually create .lp-threshold for the first run set to something reasonable, say today's date, so that we don't have to scan back through everything
[19:36] <pitti> cjwatson: agreed
[19:36] <pitti> cjwatson: I didn't look through it with a fine comb again, but this looks very similar to the changes I've reviewed some two weeks ago?
[19:36] <cjwatson> pitti: Yes, it's just bug-fixes since then
[19:36] <cjwatson> pitti: And the order_by_date=True stuff which was a result of LP reviews
[19:36] <pitti> cjwatson: so if you feel good about it, please feel free to merge
[19:37] <pitti> or rather, push, for cleaner history
[19:38] <cjwatson> pitti: will do, thanks!
[19:38] <pitti> thanks to you!
[19:40] <hartmans> debfx: thanks much.
[19:40] <cjwatson> pitti: Done; please yell if cronspam explodes
[19:41] <cjwatson> pitti: Otherwise I believe we can now flip the switch right after vivid
[19:42] <pitti> cjwatson: did you already roll it out? (cron doesn't bzr pull)
[19:42] <cjwatson> pitti: Yes
[19:42] <pitti> ah, good
[19:42] <cjwatson> And I did date -d 2015-04-14 +%s >/srv/ddebs.ubuntu.com/www/.lp-threshold
[19:42] <pitti> cjwatson: so we should spot-check some ddebs which are being uploaded today
[19:42] <cjwatson> Right, it should be a no-op at the moment but worth confirming
=== roaksoax_ is now known as roaksoax
[20:25] <Ionic> so... any help with the DT_NEEDED situation would be greatly appreciated
=== lifeless1 is now known as lifeless
=== salem_ is now known as _salem
[21:43] <Ionic> for debian, there's this stuff called... snapshots?
[21:44] <Ionic> unstable is typically snapshotted and the state of a specific day archived
[21:44] <Ionic> I don't know if the same holds for testing and stable, though
[21:44] <Ionic> and if that is applicable to Ubuntu in any way
[21:45] <Ionic> if I could build a base image via pbuilder-dist ... create from a specific "snapshot repo", that might be helping in debugging my issue
[21:45] <Ionic> (yes, I'm kinda desperate)
[21:47] <infinity> Ionic: Not at all discounting that snapshotting would be useful, I'm not sure how it would help much here.
[21:47] <infinity> Ionic: If your build system is producing underlinked binaries, that's generally your build system's fault.
[21:50] <Ionic> infinity: I would like it to be, but I don't see any way how that may be the case
[21:51] <Ionic> infinity: checking out the bzr branch that was used for building the packages a month ago, using dpkg-buildpackage -S and pbuilder-dist trusty foo.dsc is precisely recreating the missing lib dependency situation, while the packages built on launchpad a month ago don't have that bug
[21:52] <Ionic> from the same branch and everything
[21:52] <Ionic> the nightlies show this weird behavior, and also they are built from master, there were no changes that would explain this behavior
[21:54] <Ionic> I've been thinking about triggering a rebuild of the latest release on launchpad, but that would mean removing the "good" packages and potentially replacing them with the "bad" ones if the bug is indeed reproducable
[21:57] <cjwatson> Ionic: You can always create a separate PPA for that kind of test.
[21:57] <Ionic> under my account, maybe?
[21:58] <Ionic> I have only been working with launchpad the past two days, so I'm still very unknowing of how to upload a package correctly, copy a build recipe and stuff
[22:02] <pitti> sforshee: bug 1444166
[22:02] <ubottu> bug 1444166 in systemd (Ubuntu) "closing lid does not suspend during the first couple of minutes" [Undecided,New] https://launchpad.net/bugs/1444166
[22:03] <cjwatson> Ionic: It can have the same owner as the PPA you're presumably already using.
[22:03] <cjwatson> Ionic: https://help.launchpad.net/Packaging/PPA
[22:04] <Ionic> cjwatson: the owner is a group currently (which I'm a member of, naturally)
[22:05] <Ionic> I'd just need to copy the stuff over into my own PPA to not disrupt the group
[22:07] <cjwatson> Ionic: Teams can have multiple PPAs too, but as you like.
[22:08] <cjwatson> Ionic: It'd be a copy either way.
[22:08] <Ionic> point is that I don't want to have a test build publicly visible on the team... pages, whatever
[22:09] <Ionic> I'll look into that, thank you
[22:09] <Ionic> is ubuntu<version> automatically added by launchpad without me having to do anything?
[22:10] <cjwatson> No.
[22:10] <cjwatson> The version is up to you.
[22:11] <Ionic> hum
[22:11] <cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[22:11] <Ionic> we do not add an ubuntu tag in our source explicitly
[22:11] <cjwatson> "ubuntu" has a special meaning in the primary Ubuntu archive.  It isn't required for PPAs, and is indeed potentially confusing/undesirable in some cases.
[22:12] <cjwatson> (that special meaning is precisely "this package has an Ubuntu delta and should not be overridden by an automatic sync of a newer version from Debian")
[22:13] <Ionic> ok
[22:13] <Ionic> for our packages, ubuntu<ubuntu-version> is being added, presumably to make the packages in the PPA unique
[22:13] <Ionic> for each dist
[22:14] <Ionic> I thought that to be standard behavior when building for multiple dists
[22:18] <Ionic> 36
[22:18] <Ionic> ... wrong command, sorry
[22:19] <Unit193> Pingo!
[22:19] <Unit193> ..Bingo!
[22:29] <cjwatson> Ionic: That's reasonable, but Launchpad doesn't add it for you.  If it's not in your VCS, then some tool you're using is adding it.
[22:33] <Ionic> cjwatson: probably. I will have to investigate.
[23:02] <infinity> cjwatson: Hrm?  It's added for recipe builds, is it not?
[23:03] <infinity> '--append-version',
[23:03] <infinity>             '~ubuntu%s.1' % distroseries_version], env=env)
[23:03] <infinity> cjwatson: I imagine that's what he was refering to.
[23:03] <Ionic> I was told that "launchpad adds this", but no further explanation (because I didn't care)
[23:04] <Ionic> yep, exactly :)
[23:04] <Ionic> that's what I'm seeing
[23:04] <infinity> Ionic: Yeah, that happens for recipes, but not for direct uploads.
[23:04] <infinity> Ionic: Direct uploads get whatever version you used in debian/changelog.
[23:05] <Ionic> well, the recipe is triggered by bzr updates which syncs with our git repository, or something like this
[23:08] <Ionic> (so, for reproducibly, I will also use recipes)
[23:10] <RAOF> pitti: Thanks muchly!
[23:15] <cjwatson> infinity,Ionic: Oh, right, yeah, recipes do it.
[23:15] <cjwatson> I always forget about those. :-)
=== essembe is now known as sbeattie
[23:39] <pitti> RAOF: yw!
[23:46] <RAOF> pitti: Next colord job: work out why all the tests don't pass in an autopkgtest environment :)