[00:00] this specific one was because i forgot -sa i think [00:21] rbasak: we may want to setup a usd tree for php7.0 ... i think with the split packages, esp., it will be easiest to merge with git going forward. I've got the current code in a tree now locally that i've been using to dev on and for purposes of requesting new merges [00:55] can anyone point me to what a git url should look like for an ubuntu package on lp? [00:56] if it were bzr I'd push to lp:~evarlast/ubuntu/wily/b2/trunk what is the lp git equivalent? [01:00] jrwren: i'd recommend setting up a lpmep alias as [01:01] [url "git+ssh://user@git.launchpad.net/~user/ubuntu/+source/"] [01:01] insteadof = lpmep: [01:01] at which point you can use [01:01] lpmep:packagename [01:01] and it will dtrt [01:01] (aiui) [01:03] jrwren, so that's just shorthand for lp:~user/ubuntu/+source/pkgname [01:04] the reason to do the ubuntu/+source is that it links it to the gneeral packaging git trees in lp [01:04] https://help.launchpad.net/Code/Git [01:04] is useful for config/setup and questions [01:04] rharper: thanks :) [01:06] nacc: sure [01:07] hrm, our disable systemd in udeb patch for multipath-tools also disables in the non-udeb package in the update; this screws up the service starting since it never emits the sd_notify [01:08] at least I know why it doesn't start with the upstream systemd file; I think debian suffers from this as well ; indeed [01:08] the disable for udeb patch is from debian [01:08] time to fix and file a debian bug [01:09] heh, no-one notices for several reasons: 1) most folks don't really use multipath 2) there's a socket activation version of multipathd ; so even if multipathd isn't always running, if you just run multipath -ll; it'll spawn and work without the daemon going; 3) we also have an init script which just doesn't do the whole sd_notify and runs without -d (don't daemonize) [01:09] what a pita === beuno_ is now known as beuno [01:12] w 21 [01:12] excuse me. [01:41] nacc: thanks! that is exactly what I wanted === juliank is now known as Guest39948 === juliank_ is now known as juliank === Guest38484 is now known as mfisch === mfisch is now known as Guest13749 === juliank is now known as Guest44413 === juliank_ is now known as juliank [03:18] caribou: The Breaks/Replaces should be << the version where you introduce the transitional package (so, xenial's) [03:19] caribou: Assuming I'm reading your question correctly. Would be easier to see your current bits and review. [05:58] goo dmorning === dax is now known as daxcat [07:26] lp is slow catching up with debian, packages not syncable after 9h [07:34] good morning [07:52] flexiondotorg: ok thanks, will do it. === marcusto_ is now known as marcustomlinson [09:21] Laney: hey! What are the requirements to become a DMB member? [09:22] sil2100: be in ~ubuntu-dev, nominate yourself [09:22] show up at the meetings and do the thing :) [09:24] Laney: aren't I too much of a hmmm... freshman for that? [09:24] The DMB had always veterans in it :) [09:26] sil2100: I wasn't a core-dev when I first joined :-o [09:26] Oh [09:26] I got interviewed by the DMB that I was a member of [09:26] that was funny [09:27] hoho, ok, might be a nice experience then, let me nominate myself [09:27] 15:00 UTC and 19:00 UTC [09:27] well I guess that can be changed if the members decide [09:27] but that's what they are atm [09:30] what's up with lp? still can't sync packages from debian [09:31] the internal mirror doesn't get updates [09:33] seb128: hey... Bonjour! Who can review the theme css changes nowadays? [09:34] * Trevinho thought to be on desktop channel :-P [09:51] pitti, morning, can we do anything about these nvidia regressions https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html ? [09:59] is there a good reason why ~/.local/bin and ~/.local/share/man are not recognized as valid-locations-in-which-useful-things-are-kept in Ubuntu? pip install --user defaults to these locations [09:59] the pip developers tell me these locations just work in Fedora [10:00] install an application using pip install --user, and it puts the entry_points scripts in ~/.local/bin, which is not on the default Ubuntu path. It puts the man pages, .desktop files etc. under ~/local/man etc., which means the man page is not recognized by man, and so forth [10:00] sorry, that should be ~/.local/share/man [10:01] only when the user creates a ~/bin directly and symlinks to the executable in ~/.local/bin does the .desktop file show up in the Dash. Until that point the application cannot even be launched without the end user knowing the complete path [10:01] ngaio, at least for ~/.local/bin, it'd be easy for a malicious app to, say, put 'sudo' on your PATH and sniff your password [10:01] so how do the Fedora folks get around that problem? [10:01] they likely don't [10:01] because they have ~/.local/bin on the path [10:01] yup [10:02] and in ubuntu there is ~/bin.... so what's to stop that being used for a malicious sudo ? [10:03] it's not on your PATH by default, I don't think [10:03] it is by default [10:03] hmm not on mine [10:03] if you create a bin folder in the home directory [10:03] it will be there on next login [10:03] interesting, /me tries [10:03] automatically [10:05] Saviq, it is a debian default [10:05] <_hc> if something has access to write files to ~/bin, it probably also can do a keylogger [10:05] we inherit it ... [10:05] <_hc> which would leave less of a trace than a malicious ~/bin/sudo [10:07] right [10:09] sudo pip install foo.tar.gz is definitely not good, but not being able to launch a program is not good either :-) So what is the best way to handle this? [10:10] just add the two paths to your env ? [10:11] ogra_, that would imply a special shell script just for Ubuntu, as it cannot go in the setup.py, right? [10:12] i meant in your ~/.bashrc or ~/.profile [10:12] I'm asking because I'm an application developer and I want users to be able to install my application on Ubuntu, and while a PPA would be best not all the dependencies are in Debian and I doubt they will be for some time [10:13] * ogra_ could now say that snappy would help here ... but wont :P ... if you use a PPA, you can as well have your deps in there [10:14] yes a PPA would be best but to be honest it's so difficult trying to figure out the packaging of python packages that aren't mine and use things like SWIG that I'm not familiar with [10:19] so in any case, it seems like ~/.local/bin will not be made a default path for 16.04, is that correct? [10:23] Saviq: I suppose they should just get overridden; I did that now [10:23] pitti, thank you [10:24] ngaio, unlikely [10:28] ogra_, ok thanks... I'll let the pip folks know, as some people in the #pypa channel are curious about it too [11:11] xnox, hi, any idea/opinion about a nodejs sync/merge? [11:18] cjwatson: I'm just looking at http://bazaar.launchpad.net/~ubuntu-core-dev/partman-efi/ubuntu/annotate/head:/check.d/efi - you found the minimum partition size for FAT32 to be 65536 + 1048 sectors. This smells funny, as FAT32 (which your ESP uses by default) actually apparently has a minimum size of 65527 *sectors*. On 512b disks that makes your number close to the lower bound, but native 4k disks require an ESP of at least 256 MiB, it even [11:18] may be better to use (65536 + 1048) sectors. [11:19] dasjoe: cyphermox is dealing with this kind of thing nowadays [11:20] cjwatson: right, I'll just leave this message here for them to see :) [11:51] cyphermox, there is also some small change to os-proper (bug 1374759) which maybe you could sanity check and maybe sponsor... [11:51] bug 1374759 in os-prober (Ubuntu) ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old" [Medium,Confirmed] https://launchpad.net/bugs/1374759 [11:52] * smb wonders why he almost always fails to spell prober properly [12:02] hehe [12:02] good morning! [12:04] dasjoe: ok, I'll just look to find some way to figure out whether we're on 4k disks or not, or to make sure we can really reliably count in sectors regardless of disk sector size [12:10] cyphermox, good morning too :) [12:12] lamont, errm, I know I am a pita... any news on the bind9 exports frontier? [12:15] smb: You'll proberly work it out one day. [12:19] rbasak: o/ Did you see my comment on https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691? [12:19] Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,Fix committed] [12:22] Odd_Bloke: yes I did. Sorry, I haven't managed to circle back to squid3 yet. === _salem is now known as salem_ [12:23] rbasak: No worries; just checking in. :) [12:28] smb: this weekend, somehow, I'll get it upcoded, upload sunday or sometime monday evening [12:39] smb: this os-prober change kind of works a little bit by chance ;) [12:44] cyphermox, You mean mine or upstreams? I found mine more reasonable for checking before actually mounting stuff. :) [12:45] yours [12:45] cyphermox, oh why? [12:45] where is upstreams? [12:45] cyphermox, included in os-prober 1.68 [12:46] hum, we already have 1.68? [12:47] cyphermox, the addition of having a helper to check for extended partition. Right but they do the check in a function that states it needs partitions mounted [12:47] yeah [12:47] you need both things [12:47] cyphermox, which is the reason its still broken in Xenial [12:47] cyphermox, yep, I was proposing my change on top of the current xenial version [12:48] you should check for an "extended" partition, but that only works because the BIOS GRUB partition has no filesystem data according to blkid, and extended partitions are extended partitions [12:49] cyphermox, the extended partition we talk about is the small thing that gets created for the container. I think its always only about 2 sectors [12:50] well, it's not extended, it's a protective MBR which just happens to look much the same ;) [12:50] wait, we're not talking about the same thing [12:50] this would potentially fix the two bugs, anyway [12:51] cyphermox, could be yeah. What I mean is that say you create an extended msdos partition as sda2 (with the actual partitions being inside being sda5...onwards) [12:52] yep [12:52] So currently this sda2 which contains noting but potentially an mbr is still tried to be mounted and it should not [12:54] So what I believe blkid returns for that sda2 will never be more than a PTTYPE thing (at least not a filesystem). and apparently before would have returned an error for it [12:55] LocutusOfBorg, we are past featurefreeze.... i have not looked into it. [12:55] lamont, sorry I ignored you a bit... would be awesome. consider me being on watch for it :) [13:19] Mirv, Thank you for the sponsoring earlier :-) [13:24] xnox, it is an LTS release, this is why I'm worrying about a sync/merge [13:24] see ubuntu-devel or ubuntu-devel-discuss mail list, where somebody asked for it [13:28] it is a universe package.... [13:30] flexiondotorg: you're welcome :) the queue was so long, and I'm familiar with your packages by now [13:30] Mirv, :-) [13:31] LocutusOfBorg: btw when syncing from Debian in order to close filed sync request bugs, the bug filers do appreciate the credit they get if you use the -s parameter for syncpackage (I once forgot it and got a note that the bug filer would have liked it) [13:32] and -b to close the bug [13:32] Mirv, I use -s usually, but the only one that is asking me to sponsor stuff is mapreri :) [13:33] xnox, I prefer to not sync/merge, I don't want to trigger some sort of transition or similar, I don't know if nodejs-depending packages will still build/work [13:33] do you think it is safe? [13:33] how can I test it? [13:33] LocutusOfBorg: ok :) I just noticed the yamllint which I tried to sponsor at the same time, but I thanked the bug filer adrien in the bug report. [13:33] we have autopkgtestsuite for node, I wish I could do something similar locally [13:33] Mirv, bad timing [13:34] I usually sync/merge packages I have uploaded/sponsored in Debian [13:34] https://tracker.debian.org/pkg/yamllint [13:34] so, sorry but I didn't notice the bug [13:34] I would have done the -s switch then :) [13:35] LocutusOfBorg: oh right! well Adrien got anyway the package he liked :) [13:36] sure [13:36] I'll thanks him too for the bug report [13:46] cyphermox: hi! The general recommendation I've seen is to use 260 MB partitions even on 512b disks, just to be safe and to ensure a flawless migration to 4k disks in the future [13:47] what does the spec say? [13:49] cyphermox: which spec? FAT32 defines a minimal partition size of 65527 sectors, iirc [13:50] yes [13:55] smb: no worries [13:58] lamont, Well "worrying" is what I do a bit. :) [13:58] heh [13:58] ditto [13:59] dasjoe: ok, but I don't think we should change the check in partman-efi [13:59] if people know what they're doing and partitioning manually, it should be possible to create a 32Mb partition, and that might well be sufficient for their purpose [14:00] (or you know, a whatever-equivalent size for 4K disks) [14:00] chrisccoulson, would you sync/merge firefox from debian now? :) [14:01] LocutusOfBorg, no [14:01] dasjoe: where we deal with the recommended sizes from Microsoft and all of that would be in partman-auto instead; where the automatic partitioning happens [14:01] cyphermox: probably not, I was looking for where the automatic stuff happens [14:01] chrisccoulson, I thought it was good to reduce the delta [14:01] cyphermox: right, that's why I couldn't find it in partman-efi [14:01] yeah [14:02] cyphermox: still, formatting a FAT32 with less than 65527 sectors may be invalid so it would be better to use FAT16 in this case [14:02] well, it won't be less than 65527? [14:03] cyphermox: oh right, missed what you said about detecting sector size [14:03] to me it comes up to 66583.998... with the value set in partman-efi right now [14:04] (which is fine for 512b disks, but not for 4K disks, but I don't know yet what the best way to detect 4K would be here) [14:04] http://bazaar.launchpad.net/~ubuntu-core-dev/partman-efi/ubuntu/view/head:/commit.d/format_efi#L65 ← This uses "blockdev --getss". 4k disks with 512b emulation may lie here, but that is of no concern to us [14:05] ah, right [14:17] cyphermox, thank you for sponsoring [14:18] smb: my pleasure [14:19] tjaalton: hey, any idea why x11-xserver-utils hasn't migrated out of proposed yet? [14:21] dobey: let me check [14:22] huh, no idea [14:22] dasjoe: try this for partman-efi: https://code.launchpad.net/~mathieu-tl/partman-efi/too-small-4k [14:23] ah, looking really quickly our minimum for the efi partition would be 538 M anyway [14:23] dobey: poked #ubuntu-release [14:24] dasjoe: ^ [14:24] cyphermox: 538M? [14:24] trying: x11-xserver-utils [14:24] skipped: x11-xserver-utils (0 <- 40) [14:24] got: 213+0: a-54:a-23:a-29:i-28:p-27:p-28:s-24 [14:24] * amd64: arandr [14:24] dobey, tjaalton ^ [14:24] apparently it makes arandr uninstallable [14:24] muktupavels, Do you have a few mins to help on a compiz merge conflict? [14:24] * Add Breaks on arandr << 0.1.9 (see #815731). [14:25] pitti: yeah, it's supposed to? :) [14:25] flexiondotorg, ? [14:25] dasjoe: on amd64: 538 538 1075 fat32 <--- the first is the minimum, second is a priority value, and third is the maximum [14:25] muktupavels, See this comment https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882/comments/737610 [14:25] dobey: well, then arandr apparently needs and update [14:25] pitti: ah, meh [14:25] muktupavels, There are conflicts between our merge proposal for Compiz. [14:26] hmm [14:26] priority should make it go somewhere between the minimum and maximum, possibly somewhere near the minimum AFAICT [14:26] muktupavels, How to proceed? Should I take your branch and re-integrate my changes? [14:26] flexiondotorg, i know [14:26] cyphermox: I see, thanks. Sorry for the noise, then [14:26] Or can you merge my stuff into your branch? [14:27] tjaalton: oh i see debian has 0.1.9-1 for arandr, and xenial has 0.1.8-1 [14:27] tjaalton: i guess you need to sync it too? [14:27] yeah [14:27] missed that [14:27] dasjoe: np; it was worth checking. I just tweaked the minimum /boot size recently too. [14:28] dobey: synced [14:28] hopefully it will migrate now :) [14:28] flexiondotorg, I dont know what is right way to do this... I would probably start with my branch, then merge your branch, fix conflicts and create new merge proposal with my branch set as prerequisite [14:28] cyphermox: can you see why 538M was chosen? I'll talk to rlaager and edit the root-on-ZFS guide [14:29] flexiondotorg, bzr reports 5 conflicts.. [14:31] cyphermox: a quick googling for the numbers you pasted results in http://bazaar.launchpad.net/~ubuntu-installer/partman-auto/master/files/head:/recipes-amd64-efi/ - which does not reflect https://lists.debian.org/debian-boot/2015/05/msg00030.html :) [14:31] flexiondotorg, looks like it should not be hard to fix... [14:32] dasjoe: that's not much of an issue, mostly just cosmetic [14:32] cyphermox: found the source, https://bugs.launchpad.net/curtin/+bug/1306164 [14:32] Launchpad bug 1306164 in curtin (Ubuntu) "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix released] [14:32] yes, that's the right bug [14:33] dasjoe: so, free vs. fat I was hoping it had been fixed already, so I'll look again, but it was about some cases where partman-efi wouldn't notice the EFI partition at all in that case, not that the sizes were wrong [14:35] can anybody please explain me why gdcm is not migrating? poppler? [14:38] muktupavels, OK, I'll take your branch and merge my stuff in to it and resubmit. [14:38] muktupavels, I'll ping you with merge proposal when I'm done. [14:38] flexiondotorg, I am alredy fixing conflicts [14:40] trying: gdcm [14:40] skipped: gdcm (10 <- 30) got: 213+0: a-54:a-23:a-29:i-28:p-27:p-28:s-24 * amd64: libgdcm-tools [14:40] muktupavels, Brilliant. [14:40] muktupavels, Thanks for your help. [14:41] Oh, it might not be that. [14:41] muktupavels, I need to go to a meeting, but I'll be back a little later. can we catch up then. [14:41] flexiondotorg, I will push new branch in few seconds... [14:42] rbasak, exactly [14:42] I'm not sure what is wrong with that [14:42] it is obviously installable [14:58] LocutusOfBorg, is it perhaps telling you that other things depending on that get broken via that library, as it next trys to migrate it with other packages which fail for a different reason === Guest13749 is now known as mfisch === mfisch is now known as Guest88074 [14:59] (for kde sounding things) [15:00] LocutusOfBorg: it's installable in xenial-proposed. It might not be installable in the release pocket after gdcm has migrated. === Guest88074 is now known as mfisch [15:04] rbasak, though that is an internal package from gdcm [15:04] rbasak, exactly, internal package [15:04] Perhaps it depends on something else in the proposed pocket though. [15:04] So it needs to migrate at the same time as something else. [15:04] rbasak, it is tied up with some other bits [15:05] reverse-depends -r xenial libgdcm-tools [15:05] Trying easy from autohinter: boomaga/0.7.1-1build3 cups-filters/1.8.2-2ubuntu3 gambas3/3.8.4-2ubuntu2 gdal/1.11.3+dfsg-3build1 gdcm/2.6.3-3ubuntu1 inkscape/0.91-7ubuntu2 ipe-tools/20150406-3build4 libreoffice/1:5.1.1~rc2-0ubuntu1 pdf2djvu/0.9.3-1build2 pdf2htmlex/0.14.6+ds-2build1 poppler/0.41.0-0ubuntu1 popplerkit.framework/0.0.20051227svn-7.1build10 texlive-bin/2015.20150524.37493-7build5 [15:05] No reverse dependencies found [15:05] xpdf/3.04-1build1 [15:05] LocutusOfBorg, what about its forward ones [15:05] I'm just saying that it isn't "obviously installable". That's all. Because our version of installable isn't exactly the same as what would be in the release pocket after migration. [15:06] Perhaps it needs a hint, or perhaps there's no combination that works. I don't know. [15:06] apw, I also tried with -b , isn't it enough? [15:06] rbasak, maybe some sort of deeper log of the script might help [15:06] britney seems to thnk those others are tied up with it, that they are co-dependant [15:07] so karbon might be the solution? [15:27] stgraber: with lxd, is there any way to get ephemeral containers using a tmpfs overlay like good old lxc-start-ephemeral? [15:27] stgraber: I just found out why my lxd tests are so much slower than the lxc ones, and it's due to that -- I added eatmydata now, but writing all those ephemeral containers to disk is still quite a waste [15:30] cloning is super-fast thanks to btrfs, but then the fsync axe hits [15:31] pitti: unfortunately we don't support overlay filesystems as container storage due to the way they work (makes snapshot, restore, copy, move a nightmare) and because of their odd behavior (problems with inotify and extended attributes) [15:32] stgraber: ok, fair enough; at least I'm not missing some s3kr1t option; thanks! [15:32] so, eatmydata it is! [15:33] pitti: if you were on zfs you could probably set "sync=disabled and atime=no" which is a eatmydata equivalent but at the backing fs level (can be set recursively for part of the zfs tree, say lxd/containers) [15:33] stgraber: well, I certainly do want sync for my actual file system [15:34] but I want testbeds (their overlays/deltas) to be entirely in RAM [15:34] with QEMU I put the qcow overlay onto tmpfs, but we don't have that storage abstraction there [15:35] stgraber: but yeah, I feel your pain wrt. inotify and its quirks [15:36] stgraber: I just found another overlayfs regression in the xenial kernel today [15:36] stgraber: I mean quirks of overlayfs [15:38] what we'd like ideally is for a way to tell zfs/btrfs to store the cow bits of a given subvolume on a specific block device, then have that block device be a ramfs [15:38] but neither of them supports anything like that [15:38] stgraber: right [15:39] stgraber: I just naïvely tried to mount a tmpfs onto /var/lib/lxd/containers, that didn't work so well [15:40] (yay messing around in lxd's guts, rightly got my hand slapped :) ) [15:42] pitti: Have you noticed that component-mismatches is 2 days stale? [15:43] infinity: err, no, I didn't; but then again *I* am 2 days stale too, so maybe that just compensated [15:44] pitti: Heh. [15:44] same for -proposed [15:46] * ogra_ has the feeling he sees the FF crash dialog more often than the main window in 15.10 since the last update FF crashes at least once per hour for me recently :( [15:46] -rw-r--r-- 1 ubuntu-archive ubuntu_archive 5089560 Mar 9 18:28 mirror/ubuntu-germinate/germinate.output [15:46] infinity: ^ germinate didn't update for 2 days, and c-m only runs if that changes [15:47] pitti: Curious. [15:47] * pitti runs it by hand [15:48] hm, I expected to be greeted with some error message, but it's working silently [15:48] adconrad@pepo:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ ls -l germinate.output [15:49] -rw-r--r-- 1 lp_publish lp_publish 5823778 Mar 11 15:23 germinate.output [15:49] It's updating on pepo. Looks like it's no longer mirroring... [15:49] wut [15:50] rsync's still open [15:50] oh, is update-germinate not what creates/updates mirror/ubuntu-germinate/germinate.output ? [15:50] pitti: No. [15:50] pitti: It's mirrored from ftpmaster. [15:50] By archive-reports. [15:50] Which might be dying before it gets there? But that also seems unlikely, as the world would be halted. [15:51] depends how late [15:52] I'd suggest commenting out archive-reports from crontab, waiting for everything to quiesce, and then running it under sh -x [15:54] pitti, hi, regarding https://lists.ubuntu.com/archives/ubuntu-desktop/2016-March/004790.html the reason why xfce4-volumed is still using gst 0.10 is because the GStreamer devs never ported the mixer interface to gst 1.0 [15:55] so it's not so much that the projects are dead, but rather impossible to keep maintained. Still happy for xfce4-volumed to be shot out of the repos though. I don't have time to work around the mixer interface's absence and provide a working package. [15:55] sidi: I suppose the other mixer apps speak pulse directly now? [15:55] pitti, yes, albeit we have a separate daemon in Xfce for pulse (xfce4-volumed-pulse) [16:00] stgraber: how do you get upstream translations for LXD, btw? (noticed some odd-looking mix of German and English) [16:00] sidi: thanks for the heads-up [16:03] pitti, thanks for taking care (re: xfce4-volumed) :) [16:03] knome: well, I didn't do anything about it :) [16:04] if you're removing it, should we take care that it's out of our seed, or would you take care of that too [16:07] knome: I won't remove any seeded package (or any package with reverse deps), that'd be a bit blunt :) [16:07] pitti, i think that'd do good ;> [16:07] ok, we'll coordinate getting it out of the seeds then [16:08] stgraber: FYI, I'm filing/investigating bug 1556175 which makes reboots of lxd containers reeeeeeally slow (in case you get other reports about that) [16:08] bug 1556175 in ifupdown (Ubuntu) "networking.service hangs on shutdown in LXD" [Undecided,New] https://launchpad.net/bugs/1556175 [16:14] oh, that'd also explain why the ppc64el instances reboot so effingly slow, this doesn't seem limited to lxd indeed === daxcat is now known as rwd [16:32] pitti: Seems our discussion on DVD authoring is taking a bit of time. It's mostly a matter of finding a replacement. Hope we will have come to some kind of a conclusion by monday [16:49] lamont: as doko is out, would you happen to know why we switched isc-dhcp from libbind-export-dev to libbind-dev and now link with the non-export libs? [16:50] lamont: oh, the new bind9 doesn't actually have the -export stuff any more; either way, this apparently changed the behaviour of handling SIGTERM (which is now broken in dhclient) [16:50] lamont: does that ring a bell by any chance? [16:50] pitti: I'll be restoring -export this weekend [16:50] it's supposed to be killable, but dhcp isn't tehre yet [16:51] lamont: ah, so this is more or less known? [16:51] * pitti just spent 1.5 hours drilling down bug 1556175 [16:51] bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged] https://launchpad.net/bugs/1556175 [16:52] pitti: dhcp leases do not renew [16:52] not sure which bug number [16:52] we could quick-fix it to send SIGKILL instead of TERM, but not sure if that could cause other problems [16:53] it needs things taht are in the lib to not be in the lib, so back to two builds and two sets of libs [16:54] lamont: ok, thanks; so I'll check that next week when it's split again [16:55] the path was the dhcp maintainer in debian going "yeah, with 9.10, we can merge these and drop the export libs" followed by the bug erport and the "oh, actually, the version of dhcp that will work is not due out until may/june... oops" [16:55] and what with everything, my life is hectic with deadlines that put fixing bind below the cutline for too many days running [16:56] if someone (doko ??) wanted to prep a diff to put things back, the bind9 git tree on anonscm.debian has the 9.9.5 diff (which just needs sonames changeed) relatively isolated [16:57] otherwise, it's on my list for my sunday afternoon [16:59] cheers === salem_ is now known as _salem === _salem is now known as salem_ [17:48] rbasak: Based on the upstream feedback in #1549388, I think it'd be smart to update postfix in trusty to the latest 2.11 version (mentioning this with my Debian hat on, I don't plan to do it). [17:48] lamont: ^^^ [17:53] rbasak: ScottK that does sound like a good excuse for a backport [17:53] backport/sru === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [18:09] slangasek: just realized something with the php7.0/php-universe-source7.0 packages, the autopkgtests are only applicable to the former. They pass with the latter, becasue they just run the former's tests basically. So I think I should just update the rules file to only do the test generation for the former, and delete the tests/control file in the latter? [18:09] nacc: none of the tests test these universe extension packages? [18:09] slangasek: no === _salem is now known as salem_ [18:09] slangasek: no tests do, actually, in general [18:10] slangasek: the tests that would can only be run during build-time anda re disabled in rules [18:10] RUN_TESTS := no, currently [18:10] as I think it would slow the build down quite a bit :) [18:10] I can find out from Debian to be sure [18:10] nacc: then yeah, that sounds right to me. I'm in progress on the review of the package you posted already, so a debdiff against the current php-universe package may be easiest for me to incorporate, but whatever you send I'll pick up [18:10] slangasek: thanks! it's a very small change === salem_ is now known as _salem [18:12] slangasek: what i'm not sure about and would appreciate your input on, is if it is better to make php7.0 in ubuntu have all the split stuff and then just have php7.0-universe-source have the WITH_UNIVERSE toggle and the renames? THat seemed cleanest to me, but does mean there are some not-strictly-needed for php7.0 chagnes in php7.0. I'm happy to do it either way, though. === pepee- is now known as pepee [18:12] currently, that is, i've done what i just described, and php7.0 has the split in the latest version and php7.0-universe-source is just a small delta to that [18:13] nacc: having extra binary packages listed in debian/control that are not built in debian/rules is permissible, if that answers your question === _salem is now known as salem_ [18:15] so e.g. you should be able to drop the prepared: target in debian/rules [18:16] slangasek: sorry, i asked it too roundabout :) would you rather see the main/universe split happen in src:php7.0 or in src:php7.0-universe-source? Right now, the split happens in src:php7.0 and then src:php7.0-universe-source is just choosing (effectively) to build src:php7.0's universe bits. Alternatively, src:php7.0 could be kept roughly in sync with debian (just with the WITH_UNIVERSE==no cases) and [18:16] ScottK: thanks [18:16] then src:php-universe-source7.0 could have the remainder of the split (all the WITH_UNIVERSE == yes cases) [18:20] nacc: I would prefer the two source packages to be as close to one another as possible, minimal delta so that they can be easily diffed against one another later for maintenance [18:20] does *that* answer the question? :) [18:21] slangasek: :) yeah; I personally think what I have is the cleanest for ust ot maintain. MOst of the delta is in php7.0 and then the diff between php7.0 and php-universe-source7.0 is very small. The only issue is the chagne to not run the tests in php-universe-source7.0 woudl be in src:php7.0, which means I need to provide a ubuntu3 debdiff (which is easy) and then a new php-universe-source7.0.dsc and [18:21] debian.tar.xz [18:25] nacc: ok, sounds good - I'm heading afk for a bit but will check for diffs when I get back. btw, if you didn't see it I sent a follow-up comment to the bug with some (untested) thoughts on simplifying some of the debian/rules bits [18:25] slangasek: actually, i can provide debdiffs for both [18:25] slangasek: yep, jsut saw it, thanks! [18:45] slangasek: so one issue with the suggestion above to not alter debian/control (an dI realize this might be a bug in the version i sent already in the bug) is that the .dsc file refers to binary packages that are not created by that src package? [18:50] slangasek: the "fix" to that might be to have the shipped debian/control files reflect the right values (so i'd put that back in, dropped it in ubuntu2) [18:53] tjaalton: it might be worth adding a DistUpgradeQuirk to the ubuntu-release-upgrader re fglrx. e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeQuirks.py#L161 [18:55] bdmurray: indeed [19:01] tjaalton: is that something somebody on your team can take care of? [19:03] bdmurray: probably tseliot [19:12] tjaalton: I reported bug 1556248 about it. [19:12] bug 1556248 in ubuntu-release-upgrader (Ubuntu) "dist upgrade quirk need for fglrx and 16.04" [Undecided,New] https://launchpad.net/bugs/1556248 [19:20] tjaalton: hey. might you know how i can make the xrandr monitor config be saved across X restarts? when i --setmonitor, it gets lost on logout/reboot [19:23] dobey: if the monitor config thing doesn't support it, then I guess some script to run on session start is your bet [19:23] bdmurray: thanks [19:25] tjaalton: so, the way i got a single screen was i had to run the xrandr --setmonitor, then i had to open the control center display properties and hit "Apply"; --setmonitor didn't propagate a visual reconfiguration for some reason [19:28] huh [19:33] so aside from that, and maybe a couple of minor annoyances, i seem to have reasonably working 60Hz 4k now :) [19:41] cool === rwd is now known as ro [19:55] steam install is busted though :-/ === JanC_ is now known as JanC [20:44] Good day. Could someone please direct me to the best channel to discuss changes in unity-gtk-module ? [20:45] * ScottK waves to persia [20:45] (no idea about the answer to your question though) [20:45] Heh, no worries. This might be the channel. [20:46] I wanted to add an entry to the blacklist, to fix bug #1242937 harder: I have a merge proposal, but I've been away long enough not to be confident with what to do with it. [20:46] bug 1242937 in Unity GTK+ module "unity-gtk-module does not respect "ubuntu-local" property (used by e.g. Freeciv) as appmenu-gtk did" [Medium,Fix committed] https://launchpad.net/bugs/1242937 === salem_ is now known as _salem === ro is now known as ezri [21:11] slangasek: debdiffs just posted [21:41] slangasek: so the only remaining (outstanding) issue is there is a doc dependency i don't think i can resolve ... the src:php7.0 installdocs target links everything to php7.0-common, e.g. ./usr/share/doc/php7.0-xml -> php7.0-common ... since that binary target is not from this source package, policy doesn't allow linking for src:php-universe-source7.0 [21:42] coreycb, for python-neutron-lib... I don't see the package in Debian? [21:42] coreycb, and it needs a team bug subscriber... [21:42] mterry: it's in the NEW queue [21:42] i think [21:43] (per rmadison) [21:43] nacc, ah the NEW queue in Debian. Very new package then :) [21:43] mterry: yep :) [21:43] nacc, well it's bug history in Debian is spotless then! :) [21:43] mterry: heh, always nice! [21:46] slangasek: these binary targets depend on php7.0-common, though ... so not sure if this might be a gray area in the policy. I could also override it differently for the universe build, since there is the dependency [21:46] nacc: the binary packages built from php-universe-source shouldn't symlink their docs directories to php7.0-common [21:48] slangasek: ok, they don't (i put in a comment as to why) [21:54] slangasek: fyi, debian has pulled in the twig-testcase fix in 7.0.4-6 [21:58] niedbalski: Your upload fixing bug 1515278 doesn't include a bug reference to it. [21:58] bug 1515278 in oslo.messaging (Ubuntu Wily) "[SRU] rabbit queues should expire when unused" [Medium,In progress] https://launchpad.net/bugs/1515278 [22:02] Where are the ISO boot screen translations on Launchpad? [22:03] The are some untranslated strings for Ubuntu MATE. I'd like to point translators in the right direction. [22:07] mterry, it's in debian new [22:08] mterry, I imagine that doesn't count though [22:09] mterry, I just added a team bug subscriber [22:10] coreycb, left comment approving. Didn't change status, since it's also an FFe bug [22:24] attente: It seems that we're shipping the wrong default in freeciv: thanks for checking. I'll fix that in Debian, and do a sync, unless you see a reason to process it twice. [22:25] persia: sure, let me know when that's done and i'll approve your merge proposal [22:30] pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/wily/2016-03-11/22:22:46.log shows sadness in a particular autopkgtest artifact, which is crashing proposed-migration and I suspect also explains the lack of component-mismatches runs (since that's later in archive-reports). Could you please have a look? [22:35] mterry, thanks [23:09] slangasek: looking at merging libsdl1.2, as we're out of sync with debian. You did a merge in November, I've got the debdiff done and ready to go, do you have any advice on testing? I think it'll also need a FFe, as it's a new upstream version [23:18] nacc: my advice is to not merge it, I reviewed the diff already and it's a nonsense "new upstream version" that drops a file, purportedly for freeness reasons, then re-adds the same file in a Debian patch [23:20] slangasek: ok :) i wondered about that, it didn't really look like a change [23:20]