=== ValicekB_ is now known as ValicekB [00:16] does anyone know why my package here says newer version available? I tried dpkg --compare-versions and it says my version is greater? https://launchpad.net/~shuhao/+archive/ubuntu/ppa [00:18] Pwnna: a version with an epoch such as 1:0... is going to be higher than any version number without an epoch [00:19] Pwnna: did you include the 1: in your --compare-versions test? [00:24] sarnold: no. am i missing a 1:? [00:24] i thought that was optional.. okay i'll change it [00:24] thanks for the tip! [00:25] Pwnna: those epochs allow for changing versions when upstreams change from e.g. 20151014 to 1.1. they're annoying but more or less necessary.. and once used, nearly impossible to ever remove. [00:26] sarnold: yeah i understand them. i just thought that epochs by default are 1 if unspecified. [00:26] my mistake [00:26] Pwnna: Default epoch is 0 [00:26] ahh [00:27] is my naming proper for the rest of the version string? [00:27] i'm not quite sure about the 0.4.8-1+1SNAP... [00:27] Pwnna: I assume the snapshot is from upstream? [00:28] yes [00:28] a snapshot of master [00:28] Pwnna: If so, I'd say your + is in the wrong place. [00:28] so i want to convey the date of the package and the sha [00:28] infinity: where would it be? [00:28] ie: Should be 0.4.8+20151014-0shuhao1 or something pleasant like that. [00:29] where would I put the sha? [00:29] Pwnna: Tail end of the upstream version (the '-' splits upstream and distro) if you care deeply, I prefer to just mention it in the changelog. [00:30] Since hashes can't sort, they make crappy versions. :P [00:30] yeah [00:30] i was told to tag a date and then a sha [00:30] so it would be 0.4.8+20151014-sha-0shuhao1 or something like that? [00:30] *shrug* ... Personal preference. I don't think it adds much useful info to have it in the version, as long as it's also in the changelog, but it also doesn't hurt. [00:31] Pwnna: 0.4.8+20151014+sha would be your upstream version (as encoded in the orig.tar.gz filename) and -0shuhao1 for the Debian revision. [00:31] hm [00:32] another question [00:32] Pwnna: If you intend to do more than one release per day, make the timestamp longer, as you did in your current upload, I just didn't feel like typing more digits. :P [00:32] yeah [00:32] i'm okay [00:32] i think i can do monthly [00:32] Pwnna: But, IMO, long timestamp in version, and sha in debian/changelog entry is just as informative and less gross. YMMV, etc. [00:33] fair enough [00:33] infinity: how would my orig.tar.gz work? like what's the directory structure inside the tarball? [00:33] Pwnna: Should look the same (modulo code update, of course) as the orig.tar.gz in the archive for 0.4.8 [00:34] Pwnna: Which is usually just an exported checkout of upstream at a tag, or similar, but sometimes involves some prep scripts. Not my project, so don't know. :P [00:34] infinity: so like i see the ubuntu package just have xournal-0.4.8 as the directory name inside the orig.tar.gz [00:35] That's usually what upstream build scripts of the "make dist" type produce. [00:35] i don't think there's a make dis [00:35] The exact top-level name doesn't matter, though. [00:35] oh it doesn?t [00:35] Pwnna: Oh. The first directory makes zero difference. YOu can call it "giraffes-are-awesome" if you want. [00:35] i thought it had to match the version [00:35] aaaah [00:35] Pwnna: dpkg ignores the first part. [00:35] No, dpkg-source sorts it out. [00:35] okay cool cool [00:36] also 01 at the end, what's the 0 supposed to be? [00:36] i read the docs but i think i missed that part.. [00:37] Pwnna: -0ubuntuX implies "Ubuntu revision X with an upstream that's ahead of Debian" [00:37] Pwnna: So -0userX implies "User revision X with an upstream ahead of Ubuntu", at least in an Ubuntu/PPA context. [00:37] but what's the prefix 0? [00:38] Pwnna: The prefix 0 in the Ubuntu context is so that if Debian releases 0.5-1, it sorts higher than our 0.5-0ubuntu1 [00:38] ah i see [00:38] Pwnna: In your use case, it's less meanigful to do it that way, but it maps logically and looks consistent. ;) [00:39] Pwnna: The other logical mapping is -0ubuntu1~user1, but that sort of implies that your stuff is maybe, some day headed to the archive proper. [00:41] ah i see [00:42] Pwnna: ie: if I were prepping a new glibc version in my PPA, I would call it "2.22-0ubuntu1~adconrad1" (or just ~ppa1, because I'm a lazy typist), but that implies that 2.22-0ubuntu1 is archive-bound once the PPA versions don't suck. [00:43] Pwnna: If I was doing glibc snapshots in a PPA, I'd do 2.23~20150114-0adconrad1, cause we'll ship a glibc snapshot in the distro over my dead body. ;) [00:43] fair enough [00:43] i want to actually get this package upstreamed [00:44] because a bug is present from vivid and up [00:44] but upstream hasn't do a release because the maintainer is "busy" [00:44] idk where to look for this [00:45] doko: "will cause the behavior of programs to be inconsistent"> I don't see why that's controversial; you're explicitly saying that on some systems the software will do certificate verification and on other systems it won't, and it depends on a setting outside the program that's part of the system's python3.4 installation [00:47] Pwnna: If you want to actually SRU fixes into the distro, finding the right commits and cherrypicking as patches would be more palatable than saying "update to this commit", generally. [00:47] slangasek, no, in all cases it's the same behaviour unless a sysadmin chooses to change the default. that's not different than any other change to a config file [00:47] yeah but all the new commits since the previous verson has been fixes or another. [00:47] there might have been 1 feature [00:47] either way, i might push upstream again [01:00] how long does uploading build take? [01:03] Pwnna: That version still has the "-1" in the middle. ;) [01:03] after the version number? [01:03] Pwnna: As for how long publishing to disk takes after a build, it varies, but give it a hald hour or so (or wait for the icon to change). [01:03] my new version number is 1:0.4.8-1+20151014+f5c777d4e-0shuhao1 [01:03] Pwnna: The old upstream version was 0.4.8, the Debian revision was -1 [01:04] Pwnna: Your upstream should be 0.4.8+20151014+f5c777d4e [01:04] but i thought i have to have that in order for it to be > than the ubuntu version? === _salem is now known as salem_ [01:04] Pwnna: Upstream and Debian revision are compared separately, so 0.4.8+20151014+f5c777d4e >> 0.4.8 [01:05] oh [01:05] i see. [01:05] i suppose i should just get it right and rebuild it again [01:05] but i have to delete this package first, no? === salem_ is now known as _salem [01:05] doko: yes, that's exactly the difference in behavior I'm talking about. [01:06] Pwnna: Nah, the new one would be a higher version, so it'll supersede it. [01:06] Pwnna: Well, might be. Things get confusing when there are two dashes in a version number... [01:06] i just did a comparison and it returned 1 [01:06] yeah i'll delete it and reupload [01:07] wait so what's debian version? [01:07] it's after the dash, right? [01:07] Pwnna: The debian revision is everything after the last dash. [01:07] Pwnna: Which is confusing for humans and poorly-written software alike when there's more than one. ;) [01:08] what's the significance of the debian revision again? if they put in patches? [01:08] and then ubuntu1 for the ubuntu revision [01:08] or user1 for the users' revision [01:09] The debian revision (-1, -0ubuntu1, -0user1, -3derivative7, whatever) denotes changes made on top of upstream. [01:09] So, generally, in a 3.0(quilt) style package, at least, everything in debian/* [01:09] A bare -N is what we inherit from Debian, then -NfooX is the X revision on top of debian's N revisions. [01:11] i see [01:12] also, for the release in the change log, debian has "unstable", ubuntu has things like "wily". how do you automate building for them? [01:12] i'm aware for ppa copy packages [01:12] but [01:12] seems tedious? [01:12] and i want to build from like a common base. [01:12] For uploads directly to the archive, we put the series in the changelog. [01:12] For syncs from Debian, we cheat and force the target. [01:12] Just as copy-package would do. [01:13] If your goal is a common base, and you know there won't be ABI issues between releases, upload to the oldest release you intend to support and then just copy with binaries to all the newer ones. [01:13] Test on the newest release, and if it works, you probably didn't mess up. :P [01:14] sorry i mean a common base as in. since i commit things like changelog and debian/ into a repository [01:14] how do i build so that i don't need to manually edit the change log between building for different releases? [01:15] If you want to build for each release with each release's toolchain, you need 1 upload per release (with a unique version for each), there's no way around that. [01:15] So if you're already twiddling the version, changing the target isn't extra effort. [01:17] no i mean if i want to have 1 source base and want to generate a package for multiple ubuntu targets, can i do it without fiddling the change log to change wily to vivid and so forth? [01:17] or does it even matter? [01:17] or does it only matter in the context of the ppa? [01:18] Pwnna: Well, like I said, you need to have a unique version for each of those, so the changelog needs changing regardless. [01:18] do you need an unique version for each ubuntu release? [01:18] even if it is the same upstream version with no changes to the source code? [01:18] Pwnna: Well, we roll packages forward, so no, but also yes. :P [01:19] Pwnna: A package uploaded to trusty that hasn't changed since still has the same version in wily. [01:19] Pwnna: But it also wasn't rebuilt. [01:19] Pwnna: If you're *building* for each series, they need a unique version, since you have unique builds that can't clash. [01:19] ah [01:19] i see [01:20] my problem stems from the fact that in the ppa there's vivid/wily series [01:20] and if i'm on wily i can't import vivid unless i copy them, right? [01:20] Pwnna: Right, so your solution is one of two things. Either upload to vivid and copy (with binaries) to wily, so it's published in both. If that works, because no ABI transitions have broken you, that's the simplest. [01:20] Pwnna: Alternately, you need unique versions and two uploads. [01:21] right. i see [01:21] i keep getting Launchpad encountered an error during the following operation: copying a package. xournal 1:0.4.8+20151014+f5c777d4e-0shuhao1 in vivid (source has no binaries to be copied) [01:22] is this because my thing is still saying Pending publication? [01:22] Yep. [01:22] when you expand it [01:22] Patience. :) [01:22] mkay :) [01:22] thanks a lot infinity [01:22] it was very helpful! [01:22] i think i can go on packaging more things.. [01:22] except idk how to package things without autoconf yet.. [01:27] infinity: after you copy packages (just a binary copy?), how long does it take for it to show up? [01:28] Pwnna: That same half-hour-or-less that it takes for your builds to publish. It's the same process. [01:28] even with the copy binary? [01:28] it doesn't say a build is running [01:29] https://launchpad.net/~shuhao/+archive/ubuntu/fixed/+packages [01:29] Pwnna: Yeah, it still needs to build the Packages.gz indexes for wily, etc. [01:29] ah i see. so there's no status update on launchpad for this, then? [01:29] Pwnna: Well, it does show the source as "Status: Pending". [01:30] Pwnna: When that flips to "Published", you should be more or less good to go. [01:30] yeah [01:30] okay. cool. i thought it might have more info with pending or something [01:30] thanks a lot :) === _salem is now known as salem_ === salem_ is now known as _salem === NCommander is now known as Guest52207 [02:45] rbasak: regarding netcf, no i'd rather we get the newer netcf package into debian unstable. i'd asked xnox to sponsor https://mentors.debian.net/package/netcf . let me ping him [02:45] xnox: ping :) === NComman`` is now known as NCommander === NCommander is now known as Guest86757 === Guest86757 is now known as NCommander [05:18] any hope to see libpng 1.6 in the next LTS repo? [05:19] I have 2 packages which needs this version [05:20] it's like people's moving to 1.6 [05:59] Good morning === nudtrobert1 is now known as nudtrobert [07:57] laney: hi there! any chance you could sponsor https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1506166 ? i noticed you were the last uploader if i'm not mistaken [07:57] Launchpad bug 1506166 in vte3 (Ubuntu) "Bracketed paste should be per-terminal [PATCH]" [Undecided,New] [07:57] zaytsev: \o [07:58] unit193: o_O [08:00] unit193: oh, having tilted my head in a normal position, i suddenly realized you were just about to say "hi" :) hi to you sir, then === TheMuso` is now known as TheMuso [08:32] infinity: when do you want the final wily langpacks (fresh build)? [09:05] dobey, which was the package you were touching yesterday (the go issues)? [09:06] pitti, he "doesn't intend to start building "RC" images until Friday night or Saturday morning" [09:07] hi zaytsev [09:07] doko: ack, thanks [09:07] sure I can help [09:07] can you re-format the bug description to add the sections in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure please? [09:07] wgrant: I forgot to request a full export on https://translations.launchpad.net/ubuntu/wily/+language-packs early enough, just did it an hour or so ago [09:08] wgrant: if the job is already running, could you cancel it and re-run a full export? [09:08] wgrant: if it didn't start yet, then it should just all work by itself I figure [09:11] pitti: Checking [09:12] pitti: Not scheduled to start for another hour and aib.t [09:13] wgrant: ah good, then it should be fine; what's "aib.t"? [09:13] pitti: "a bit" with hilarious typos. [09:13] wgrant: :) thanks! [09:28] pitti: did i say thanks for the golang-race-detector-runtime reviews yet? [09:28] pitti: if not, thank you! [09:28] oh reminds me i should make golang-go Recommends: it [09:32] laney: will do in the evening and ping you again, don't have launchpad access from work. thanks! [09:39] mwhudson: you're welcome! [09:39] hm [09:39] can Recommends be arch-dependent? === nudtrobert1 is now known as nudtrobert [09:42] mwhudson: yes, similar to Depends: [09:49] pitti: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1506393 if you have a moment or two [09:49] Launchpad bug 1506393 in golang (Ubuntu) "golang package should recommend golang-race-detector runtime" [Undecided,New] [09:59] mwhudson: done, bug updated [10:00] pitti: one day i will get a version number right :-) [10:00] pitti: thanks [10:00] mwhudson: dch -i :) [10:00] heh i did that for some other package and the uploader changed the 2 into 1.1... [10:00] mwhudson: we only use 0.1 increments for stable updates [10:00] ah ok [10:05] looks like hexchat is broken in wily. [10:05] [M#z9 trying to overwrite '/usr/share/man/man1/hexchat.1.gz', which is also in package hexchat-common 2.10.2-1ubuntu1 [10:06] * popey files bug 1506399 [10:06] bug 1506399 in hexchat (Ubuntu) "Can't update hexchat on wily" [Undecided,New] https://launchpad.net/bugs/1506399 [10:11] popey, oh, likely my fault :-/ [10:11] * seb128 fixes [10:15] #blameseb128 [10:16] itz gtk boog [10:17] so at least know we know there is an hexchat user, popey [10:17] he doesnt really use it, he only installs it to find bugs and nag you ;) [10:17] guess si [10:17] so [10:17] he probably have every deb in the archive installed [10:27] so true [10:27] (I have it because Ubuntu MATE has it) [10:28] pitti, should the freeradius autopkg test be given back? [10:28] Removing adt-satdep:amd64 because I can't find python-unit:amd64 [10:29] doko: won't help; python-unit was removed a few days ago, so freeradius' test needs to be changed to not depend on python-unit any more [10:29] doko: I'll have a look, thanks for pointing out [10:29] ohh [10:30] Riddell, sitter: somebody looking at the cantor autopkg test failure? [10:30] doko: it's hinted as force-badtest [10:30] ahh, good [10:30] doko: ah, I bump the version [10:30] (in the ints) [10:30] hints too [10:31] cyphermox: just confirming nm 1.0.4-0ubuntu5 in wily now works with pppoe (bug 1446689) thanks! [10:31] bug 1446689 in network-manager (Debian) "network-manager configured to use /usr/sbin/pppoe but does not recommend pppoe" [Unknown,New] https://launchpad.net/bugs/1446689 [10:34] tyhicks, sarnold: i've added some info on how nvidia-modprobe works to bug 1421209 [10:34] bug 1421209 in nvidia-modprobe (Ubuntu) "[MIR] nvidia-modprobe" [Undecided,New] https://launchpad.net/bugs/1421209 [10:35] doko: fixed the tests; doing a local package build as it hasn't built in wily yet [10:38] doko: uploaded (main, needs RT ack) [10:39] cjwatson: looks like a merge for libapache2-mod-perl2 will fix the FTBFS. It's not completely clear to me that there aren't any new features, but the fixes make it seem reasonable to me to pull all of it in. Any opinion? [10:40] Or I could just cherry-pick the FTBFS fix which is trivial. [10:40] doko, Riddell: taking a look at cantor [10:41] thanks ginggs [10:48] rbasak: Feel free to steal my merge if you like; I have no opinions other than that :-) [10:50] OK, thanks [12:09] Riddell: I think something regressed in kf5.15 that makes cantor tests fail === _salem is now known as salem_ [12:30] doko: pay-service and ubuntu-push are the ones i'm concerned with at the moment [12:32] dobey, did you try the build on wily first? [12:35] doko: i don't have access to any ppc or arm64 hardware to test on. ubuntu-push at least compiles on arm64 on wily though, but the tests are failing on that arch there. i think the push guys are working on getting those tests fixed though [12:36] dobey, same for ppc64el [12:37] right [13:15] dpkg-deb: building package 'ubuntu-push-dev-server' in '../ubuntu-push-dev-server_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'. [13:15] dpkg-deb: building package 'ubuntu-push-client' in '../ubuntu-push-client_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'. [13:15] dpkg-deb: building package 'ubuntu-push-autopilot' in '../ubuntu-push-autopilot_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'. [13:15] dobey, ^^^ [13:17] doko: ok? [13:19] doko: should the failed builds on https://launchpad.net/ubuntu/+source/ubuntu-push/0.68+15.10.20150814.1-0ubuntu1 be retried perhaps? [13:20] oh there's a new golang upload in wily? [13:21] dobey, updated https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1431486 [13:21] Launchpad bug 1431486 in ubuntu-push (Ubuntu) "ubuntu-push fails to build with gccgo" [Undecided,Confirmed] [13:21] what's happened to /lib/udev/write_net_rules in wily? [13:21] dobey, so I think with this schema you can fix all the other build failures on powerpc as well [13:21] in vivid it was part of udev, while in wily i can't find where it resides [13:22] mwhudson, ^^^ [13:25] ick [13:28] dobey, given back, still ftbfs [13:29] Riddell, doko: failing cantor tests should pass with this -> Uploading cantor_15.08.2-0ubuntu2_source.changes: done. [13:29] sitter, ta [13:29] ppisati: not needed any more as the old 75-persistent-net-generator.rules is gone [13:29] doko: hmm [13:30] pitti: someone pointed me to your old thread 'enable stateless persistant network interface names' [13:30] pitti: let me read it [13:33] is there a FFe for parole? [13:37] pitti: ok cool, so i should just give up any hope of having my old eth0 back [13:37] pitti: and get used to... [13:38] pitti: enxb827eb2da1ca [13:38] pitti: is that correct? [13:39] ppisati: that's the current default name for USB devices, yes; admittedly ugly, but at least stable :/ [13:39] ppisati: you can change the policy of course [13:39] or we might decide that we don't want to support stable names for USB and use the kernel names for those [13:39] pitti: with a systemd.link rule, right? [13:40] ppisati: yes, that or an udev rule (or a link file) which assigns a name to a particular one; see /usr/share/doc/udev/README.Debian [13:40] ... gz [13:41] pitti: uhm, the name is ugly but i can live with that if i can find a way to assign an ip to it via dhcp [13:41] pitti: i mean, i guess /etc/network/interfaces is dead too at this point [13:42] ppisati: that's an independent decision; but I hear snappy/server team etc. are looking at networkd [13:42] ppisati: for that the interface names don't really matter that much as you can select interfaces by properties (not just by name) [13:43] pitti: don't you need to specify the name of the nic in the [Match] section? [13:43] pitti: letme explain my problem [13:44] pitti: i'm preparing a custom image for an arm board (vanilla ubuntu) [13:44] ppisati: no, you can match on any property [13:45] pitti: and i don't know the MAC nor the name of the interface until the first boot [13:45] ppisati: e. g. on MAC address, original name, current name, location (path), driver, type, etc. [13:45] (sorry, not original name, just name) [13:46] ppisati: how was that done in the old world? hardcoding eth0 and hoping that there's no biosdevname or device drivers which use a different name? [13:46] and hoping that there would just be one eth? [13:46] the equivalent of that would be to use [Match]\nName=en* [13:47] or create an /etc/network/interfaces with the first /sys/class/net/en* that you find [13:47] which is pretty much exactly what happened with hardcoding "eth0" -- whichever ethernet happened to be detected first got it [13:52] pitti: you don't usually have more than one nic on these boards [13:54] pitti: anyhow, i'll see what i can do [14:05] ppisati: you attached an usb ethernet, then you already have two, no? [14:06] pitti: no, that's the integrated nic [14:06] pitti: arm's nic are usually on the usb bus [14:06] ah [14:06] pitti: beaglebone, rasppi, cubox, etcetc [14:06] 99% of them [14:06] ppisati, in snappy we use the kernel cmdline option to turn that off [14:06] arm64 is different beast thopugh [14:07] ogra_: what's that cmdline option? [14:07] ppisati, net.ifnames=0 [14:09] Hi pitti jibel : is it possible to get a retest of juju-core in vivid-proposed? I reran adt tests against proposed and I see it passed (after an lxc fix?) http://autopkgtest.ubuntu.com/packages/j/juju-core/vivid/amd64/ [14:09] sinzui: sure [14:10] ogra_: works like a charm, thanks [14:10] :D [14:10] ogra_: i'll use it until the systemd networkd situaion is sorted out [14:10] xeah [14:11] *yeah [14:11] thats our plan as well [14:11] ogra_: +1 [14:11] pitti: thank you as well :) [14:13] ppisati: right, you can also disable it entirely (again, see README.Debian); either on kernel command line or via touching a file in the fs, whatever is easier [14:15] pitti, btw, did your last systemd upload change anythin wrt network bringp for /e/n/i interfaces ? https://bugs.launchpad.net/snappy/+bug/1503329 .... seems systemd and udev are among the changed packages between the image that works and the one that fails [14:15] Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed] [14:16] ogra_: no, just a crash fix for "shutdown" [14:17] pitti, thats, that rules out systemd [14:17] ogra_: oh, from ubuntu4 to ubuntu5? that's by far not the latest (from today, that was ubuntu9) [14:17] oh, ok [14:17] https://launchpad.net/ubuntu/+source/systemd/225-1ubuntu5 [14:17] ogra_: yes, that reverted calling if-*.d/ from networkd [14:17] (as I wrote on u-devel@) [14:18] well, still curious why it then works on second boot [14:18] there must be something else [14:18] i assume that code would affect every boot [14:19] ogra_: the if-*.d/ calling, yes; and it certainly isn't related to DHCP [14:19] ogra_: are the images using networkd? [14:20] hmm, not sure we use networkd at all ... if they do, most likely unintended [14:21] ogra_: it doesn't even run by default, you have to explicitly enable and configure it [14:21] ah, then it couldnt have slipped in [14:21] afaik we still just use ifupdown [14:23] ogra_: the interface names also look like what you expect, right? that rules out the "udev.postinst: Actually call upgrade_fixes(), so that the "disable [14:23] persistent names on upgrades" quirk actually runs." [14:23] fix [14:23] and it'll hardly be the micmute keymap fix [14:23] pitti, its just eth0 everywhere [14:30] pitti: what's the file i need to touch to disable the renaming? /me has read /usr/share/doc/udev/README.Debian.gz but didn't see its name [14:31] ppisati: sudo touch /etc/udev/rules.d/80-net-setup-link.rules [15:05] does anyone here have experiences with git buildpackage? [15:07] !anyone | Pwnna [15:07] "A high percentage of the first questions asked in this channel start with "Does anyone/anybody..." Why not ask your next question (the real one) and find out?" [15:08] i don't quite understand the branching process if i'm also upstream [15:08] uh. znc lagging hard. [15:09] Usually upstream just stays in its own branch [15:09] When you want to update packaging, merge from that upstream branch into the packaging branch [15:09] Often the upstream branch is named "upstream" and the packaging branch "master" but that's not required [15:10] rbasak: but if i'm developing a program that i want to package [15:10] and i develop in master [15:10] Pwnna: even then it's easier to maintain a separate packaging branch [15:10] right so i develop on master and then i put the debian/ directory in a debian branch [15:11] Yeah that would work. [15:11] You'll need to configure git-buildpackage to tell it which branch is which [15:11] can i commit the .git/gbp.conf somewhere? does it make sense to do so? [15:11] debian recommends putting things inside a debian/ branch. does that make any sense if my program is expected to work on debian/wheezy, debian/jessie, ubuntu/trusty, ubuntu/vivid, ubuntu/wily and so forth? [15:14] bp also supports debian/gbp.conf (which you'd commit to the repo) [15:14] *gbp [15:14] if you want to commit some config, put it in there [15:14] ah cool [15:15] i want to have a reproducible build setup rather than having it all on this one machine. [15:15] so should I just have a debian branch, and then everytime i want to release, i merge from master/tag? [15:15] I think that would be fine [15:16] If you want, call that branch debian/sid [15:16] And then you have space for stable maintenance if needed [15:16] hm. that might be a good idea [15:16] in change log, do i just call it sid, then? [15:16] You can always rename things later [15:16] yeah i want to get the process right. [15:16] Yeah debian/changelog has no bearing on branch names [15:17] rbasak: but it does for ppa upload, right? [15:18] It matters what you put in debian/changelog for uploads [15:18] (and because you don't want to be wrong) [15:18] But it has nothing to do with what branches you use in git [15:20] yeah i know that, i'm switching topic to what i have to be in debian/changelog [15:20] sorry, should have clarified [15:20] so for the release field, what's the "proper" release if i want to release the same package for a bunch of debian/ubuntu versions? [15:22] It's different [15:22] So you'll want various branches for that. [15:23] Easiest way is to script it. for r in sid wily vivid trusty precise; do dch -r -D $r ''" etc. [15:23] I have an example, hold on [15:24] https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/functions is what I did for docker. [15:28] barry: hey! Can I look into the pylint FTBFS? :) [15:28] sil2100: yes please :) [15:28] barry: sorry to steal away from you all the python package fun, but I noticed that the others usually have someone assigned ;) [15:29] sil2100: just the contrary, really appreciate it. i've been stuck on a "fun" one [15:30] Yeah, the configglue one is similar, but I'm waiting for the upstream developer to maybe fix it upstream first === ryao_ is now known as ryao [15:40] :\ [15:45] apw, please could you test a linux build using the binutils from the ubuntu-toolchain-r/test PPA until release? I'd like to find out if these are good enough for opening the x-series [15:46] doko, in hte W pocket i assume [15:46] doko, and yes [15:46] yes [15:46] apw, still building [15:57] morphis, hey, how close are you to landing silo 43? [15:57] morphis, also, I've got mako/wily and flo/vivid that don't want to turn bluetooth on, anything I can do to debug? bluetoothctl on wily just hangs, only thing I can do is Ctrl+C out of it [16:55] xnox: Do you remember any context around this apturl change? "Drop libgtk2-perl Recommends to Suggests" [16:56] bdmurray: i believe this was together with the effort to drop gtk2 out of main images. [16:56] which is a lost cause, cuase qt5 to date depends on gtk2 [16:56] and also inline with dropping non gobject interspection bindings out of main. [16:56] xnox: I think it is causing an issue with debconf and software-center. bug 1389582 [16:56] bug 1389582 in software-center (Ubuntu) "software-center misses a dependency on libgtk2-perl" [Undecided,Confirmed] https://launchpad.net/bugs/1389582 [16:57] bdmurray: i did not see it comming like that. [16:58]