[00:17] slangasek, so tonight i ask for review of the bug 1432829 fix (that i incorrectly asked about last night) [00:17] bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed] https://launchpad.net/bugs/1432829 [00:17] attached to bug . [00:18] xnox, your thoguhts woudl be appreciated there too === anthonyf is now known as Guest55250 === salem_ is now known as _salem === kickinz1|afk is now known as kickinz1 [08:18] good morning [08:25] ginggs, hi, can I release your "conflicts" virtualbox patch under MIT license? === kickinz1 is now known as kickinz1|afk === timchen1` is now known as timchen119 === kickinz1|afk is now known as kickinz1 === dholbach_ is now known as dholbach [09:00] LocutusOfBorg: hi, it's not much of a patch, it was merely a suggestion. :) I haven't checked that those are the only conflicts required. [10:15] mlankhorst, Did you create a new xorg-server build? Just testing the isos again and added the x-staging PPA. But I have ~ppa2. Thought a ~ppa3 was in the works? [10:15] flexiondotorg, he just uploaded the fix to vivid [10:16] seb128, Thanks. mlankhorst Excellent :D [10:17] seb128, mlankhorst I'll wait for that to propagate and test later. [10:20] hallyn: I'm thinking something like this: http://paste.ubuntu.com/10626570/ [10:21] Does everything that needs /lib/init/apparmor-profile-load correctly depend on init-system-helpers already? [10:21] (I've not tested these patches) [10:21] jodh, tyhicks: ^^ [10:23] The [ -x /sbin/apparmor_parser ] is now redundant, but I've left it there so the move is simpler to follow (rather than change the file while it's being moved) [10:23] hmm, how do I get a .source.changes file with sbuild? I've tried all weird combinations of -s --debuilt-opt=... [10:23] zyga: I use -S and just get one. [10:23] I want to backport a package from vivid to trusty and I want to upload .source.chanegs to a ppa [10:23] rbasak: sbuild -S ? [10:23] Yep [10:24] rbasak: er, no [10:24] rbasak: no such option [10:24] rbasak: *sbuild* [10:24] Oh, I'm sorry. [10:24] rbasak: not dpkg-buildpackage [10:24] I just sbuild on the .dsc with no special parameters, after -S to buildpackage. [10:24] rbasak: I'm on vivid and I suspect that the source package should be built with the trusty chroot [10:24] Oh [10:24] Hold on. [10:24] (maybe I'm wrong) [10:24] I get the source changes with dpkg-buildpackage -S [10:25] No need to run sbuild at all. [10:25] but that still runs debian/clean, right? [10:25] It's a source-only upload after all. [10:25] on the host [10:25] It does, yes. Which is annoying because I don't usually have build deps installed. [10:25] and that may need build-deps [10:25] So I use -nc [10:25] rbasak: you are right but I want to understand how to do it correctly [10:25] (and make sure the tree is clean, and check with debdiff afterwards to be sure) [10:25] * zyga tries [10:26] I'd love to know if there's a better way. [10:26] (I don't want to see -nc deprecated for this reason) [10:26] I never have build deps installed on the machines I develop on. I do all builds inside schroot at a minimum. [10:26] hmm, I didn't see .orig.tar.gz uploaded, I should have added -sa, right? [10:26] Yes, if needed. [10:26] when is it needed? [10:26] If the archive or PPA already has it, no need. [10:26] the tarball is in vivid [10:27] ah, ok [10:27] * zyga waits to see [10:27] I'm not sure about vivid -> trusty ppa backport. [10:27] Though I think you still won't need it. [10:27] Who's talking about deprecating -nc? It's a perfectly reasonable and useful option, especially in scripted contexts. [10:27] There's a warning about it when I run it sometimes. [10:27] Eh, it's warned forever [10:27] A deprecation warning. [10:28] Oh, it's not about -nc directly. [10:28] Do you mean "building a source package without cleaning up as you asked; it might contain undesired files"? [10:28] dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting [10:28] dpkg-buildpackage: warning: (Use -d flag to override.) [10:28] dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future [10:29] Oh right, that's entirely different [10:29] Yeah sorry, I recalled it wrong. [10:29] Anyway, if you've just edited a package, not done anything special in its tree, and aren't relying on any clever autogeneration stuff, then "debuild -d -S -nc" is perfectly reasonable [10:30] Thanks. I had just never used -d. [10:31] Any thoughts on making scripts supplied in debian/ executable in the tarball vs. marking it executable via debian/rules? [10:32] upstart's apparmor-profile-load did the latter. [10:32] I think I prefer the former. [10:32] rbasak: it worked, package built fine [10:32] * zyga puts piglit trusty + vivid packages into a test ppa [10:32] zyga: \o/ sorry for my confusion [10:33] rbasak: thanks for the help! [10:33] It "just happens" so I never really thought about the details! [10:35] flexiondotorg: FYI, xorg fixed some kvm issues making autopkgtests failing FYI, so I guess you should be good with the version in the archive (still only in -proposed now) [10:56] rbasak: Executable bits in debian/ are dependant on source package format. For v3 packages or native packages, because it's a tarball member, you can rely on it just working, for v1 non-native, you need to do it in rules, since debian/* is a diff, not a tarball, and you can't express file metadata in diffs. [10:56] Aha. That makes sense. Thanks! [10:56] rbasak: People who flip-flop between source formats a bit tend to just always do it in rules to prevent being bitten. [10:57] upstart is 1.0 non-native, so it would make sense why it was being done there. [10:58] hmm, how can I teach my sbuild the key needed to access a ppa (I'm using --extra-repository)? ideally I'd like to do that on a per-build basis as I don't want to have many chroots [10:59] there's the --chroot-setup-commands option [10:59] but I'm not sure what apt-key magic to use to add a ppa-specific key [11:00] apt-key add /path/to/key.pub [11:00] rbasak: oh that's just too easy, thanks [11:00] There might be a better way with these new-fangled sbuild options though. [11:00] I always use add-apt-repository but it has way too many dependencies to use here, I think [11:01] rbasak: yeah, I looked but nothing popped up [11:01] the --extra-repository option is awesome enough though [11:01] zyga: Either use apt-key, or just configure the PPA with something like add-apt-repository on another system/chroot, let it do the hard work, and then copy the /etc/apt/trusted.gpg.d/ppa-name.gpg in. [11:02] It does seem like extra-repository could use an extra-repository-keyring option to go with it, though. [11:02] yeah, I totally agree [11:02] so looking at this key (reached from the ppa, page) I just copy that somewhere and use apt-key add [11:02] http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x3DF628E6E62E6AAB [11:04] * zyga tries [11:04] * zyga needs a bind mount for the key perhaps [11:04] or a better command to get the key [11:04] inside the chroot [11:05] heh [11:05] ironically this image is the best way I found so far https://launchpad.net/+help-soyuz/images/add-apt-repo2.png [11:05] and there's no text version [11:05] and that's ... warty? [11:05] wow time flies [11:07] warty? Did gwibber exist then? [11:08] the theme looks from that age though [11:08] sbuild -d trusty --extra-repository='deb http://ppa.launchpad.net/zkrynicki/piglit/ubuntu trusty main' --chroot-setup-command='gpg --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv EECD2FED2EB41383F931DEF63DF628E6E62E6AAB' [11:08] that's the magic that works without anything extra added [11:08] * zyga wants someone to make a new sbuild from scratch, that's EASY and has great defaults [11:09] that's not just for debian core developers but also for people like me that have different workflows [11:10] It would be nice to just have a --ppa option [11:11] yep [11:11] * zyga builds piglit :-) [11:14] zyga: I don't think a new sbuild is needed, but a simple wrapper for people with more limited usecases wouldn't be too hard. [11:14] zyga: One just needs to define what those limited usecases *are*. [11:15] zyga: I still think what we need for occasional Ubuntu/Debian devs (people doing one-off test builds, whatever) is a simple "build-it-like-a-buildd-would package.dsc" [11:15] zyga: Which would be a wrapper around grabbing a chroot tarball and calling sbuild in a buildd-compatible sort of way. [11:17] infinity: I think that was tried a number of times. I think the problem with wrappers is that they don't fix design problems have ways around things like ~/.sbuilrc breaking whatever the wrapper may want to do. There are ways around that but I think wrappers are never as good as a great solution. [11:17] infinity: the amount of tinkering from defaults to get a working trusty sbuild is an example [11:18] infinity: add sbuild profile [11:18] infinity: add eatmydata [11:18] infinity: do the bind mount to avoid downloads [11:18] Lots of that isn't required... [11:18] infinity: (and it's still not going to work offline really) [11:18] infinity: well, it's an opinion [11:18] infinity: (do more more more things for a feeder achive) [11:18] infinity: I think they are because without them packaging is a pain to do [11:18] Sure, there are lots of options. But lots of options are orthogonal to wanting a thing that's easy to use. [11:18] infinity: all of that should be default [11:19] infinity: then lintian, piuparts (which never worked for me no matter what I tried, adt) [11:19] infinity: I agree it depends on what you want to do [11:19] infinity: but the case that sbuild has lousy defaults for 2015 is a good one, I think === dholbach_ is now known as dholbach [11:20] infinity: it's like motif was cool and there were themes to make it look nice [11:20] infinity: but no amount of themeing will make it like modern OS [11:20] infinity: I tried to do a wrapper for myself a number of times but it always failed on something (and I learned a new thing at the same time) [11:21] infinity: there's just a lot of complexity there [11:21] infinity: but also old designs and stuff people cannot reuse now (shell, perl) for writing a better tool [11:22] zyga: I question the assertion that people can't use shell and perl. :P [11:22] infinity: for new quality tools? [11:22] Yes. [11:22] meh [11:22] I disagree [11:23] perl is an ecosystem going under and shell is just useless for programming [11:23] Disagree all you want, but language doesn't determine the quality of the output, the programmer does. [11:23] unless it's running options with --sbuild [11:23] infinity: sure [11:23] infinity: but ecosystems matter [11:23] And each tool in its place. shell isn't for highly complex tasks, but it works for smaller things. [11:23] infinity: doing a new tool in perl today indicates that someone is out of touch with reality [11:23] infinity: I agree on shell [11:23] infinity: but sbuild is big [11:23] infinity: and the task is not suitable for a shell program [11:24] infinity: especially if you want the program to be better and smarter than what we have now [11:24] infinity: e.g. non-executable configuration perhaps [11:24] I also disagree that the perl ecosystem is "dying", it's alive and well. But to people always chasing the new hotness, I can understand how "a module it good enough that it doesn't need to be changed every two weeks" looks like "stagnation". [11:24] infinity: it may be lively but it is a niche and one that is shrinking compared to the overal ecosystem using arguably better tools [11:25] infinity: perl is a horrid language [11:25] Anyhow, the important bits of sbuild and schroot have been C++ for ages. [11:25] infinity: like the bits around dpkg and apt? [11:25] zyga: "horrid" is a matter of opinion, not fact. Surely, you see that? I think python is "horrid", but that doesn't stop (many) others from seeing the beauty in it. [11:25] infinity: yeah, that's good, those tools are complex but I wouldn't go on replacing them :) [11:26] infinity: no, horrid is a matter of opinion but perl is just bad as a language, it's got a big bag of mistakes that people know not to do, that's not an opinion, that's a fact === dholbach_ is now known as dholbach [11:26] infinity: I'd love to see an argument for beauty there but I have yet to find one [11:27] infinity: then implementation quality matters too [11:27] infinity: but let's not make it a perl topic [11:27] I was surprised by one thing, reading dpkg changelog [11:27] You say that after filling my screen with a language war. [11:27] that some patches for osx were added [11:27] cjwatson: sorry, that was not my intention, I wanted to focus on highlighting opinions vs facts that are relatively undisputed [11:28] I wonder what's the motivation for dpkg on osx [11:28] fink. [11:29] hmm, osx is a curious mixture of environments [11:30] OSX devs come in two flavours: People who desperately wish it was more like a Linux distro, and... All the people who are wrong. [11:30] (No bias here) [11:30] infinity: heh :) [11:33] infinity: poke to do bug 1417328 for me please [11:33] bug 1417328 in percona-xtradb-cluster-galera-2.x (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328 [11:34] I don't forsee any issues, but I'd like to see the whole thing cleared up and 5.6 landed in case things appear that I need to fix up. [11:34] rbasak: I'll look in a bit. In somewhat of a glibc groove here, and don't want to get any more distracted than I already am. [11:34] I should probably close this window. :P [11:34] OK thanks [11:48] if i don't specify -B to adt-run then it tries to build the binaries, which is what i want, but it complains: [11:48] dpkg-buildpackage: error: fakeroot not found, either install the fakeroot [11:48] package, specify a command with the -r option, or run this as root [11:49] i have this installed though, is this maybe because it's trying to do the build on the testbed (ubuntu touch device in this case) === Malsasa_ is now known as Malsasa [11:58] Yeah you'll want fakeroot on your testbed [11:59] Or some other way to get root on your testbed [11:59] I would build the package locally, and then test on the testbed without build dependencies or fakeroot there. [11:59] (ie. separate the build environment from the test environment, rather than having them combined) [12:00] You can use -B to separate them, by building packages first eg. with sbuild [12:01] Riddell: howdy, do you know if anyone's looking at kde-baseapps autopkgtest failure? === MacSlow is now known as MacSlow|lunch [12:09] Laney: yeah I'm on it now, I'll just patch it out I guess [12:11] up to you - it's weird that the check thinks it has internet access but the test goes on to fail [12:11] but thanks [12:12] mm === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [13:58] rbasak: looks perfect - xcept the breaks/replaces should be against upstart-bin, not upstart, iiuc. [13:58] hallyn: oh, good point - thanks. [13:58] hallyn: do you know that jobs will correctly pull in init-system-helpers? [13:59] what do you mean? [13:59] Currently things that expect /lib/init/apparmor-update-profile to exist just call it, but presumably they depend on upstart-bin, so it's definitely present. [14:00] Now these things need to depend (maybe indirectly) on init-system-helpers instead, in order to not break. [14:00] So do we know this is the case? [14:02] rdepends list is pretty long, but seems random [14:02] cgmanager and lxc both depend on it [14:03] cloud-init [14:03] * rbasak wonders what else uses it [14:03] Is there any easy way to grep the entire archive? [14:04] i'm looking at apt-cache rdepends init-system-helpers | sort | less [14:05] msut be something common in there i'm just not seeing it :) [14:06] Perhaps you're expected to depend on it explicitly. [14:07] In which case what matters are the recursive reverse depends on upstart-bin, which shipped /lib/init/apparmor-update-profile previously [14:08] Perhaps the init scripts that depended on it existing (eg. didn't test -x) just assumed it would be there, and it was on all Ubuntu because of upstart-bin. [14:14] man .. i'm sure it's obvoius, but i'm not finding it === doko_ is now known as doko [15:00] hallyn: All those init-system-helpers deps (or most) are coming from dh_systemd. [15:02] rbasak: The "pleasant" automated way to fix this would be to make dh_installinit grep init scripts for apparmor-profile-load and add init-system-helpers to misc:Depends, but you'd still need to identify the right packages to rebuild to make that work. === Malsasa_ is now known as Malsasa [15:57] xnox, in systemd, what all runs 'ifup NIC' ? is it more than the ifup@ service ? [16:00] didrocks, mlankhorst seb128 Just tested the new xorg-server. Looks good. Thanks for your help! [16:00] flexiondotorg, yw! [16:01] seb128, Looks like another bug got fixed too. [16:01] which one? [16:02] https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/ [16:02] Launchpad bug 1368784 in virtualbox (Ubuntu) "Utopic Virtualbox guest gets only up to resolution of 640x480" [High,Confirmed] [16:02] great [16:02] seb128, Just confirming. [16:02] seb128, Nuts. [16:02] Sadly not. [16:03] The pp2 version that yanked redBIOS did fix the bug above however 😕 [16:03] *ppa2 version from x-staging [16:07] smoser: not so sure, i believe there is networking job that parses /etc/network/interfaces and then does magic [16:07] should be udev triggered as well.... on nic bring ups.... [16:07] dunno, talk to debian people. [16:07] * xnox uses systemd-networkd / network manager === seb128_ is now known as seb128 [17:35] seb128: is there a bug reference for your unity-settings-upload to trusty -proposed? [17:35] bdmurray, did I forget to include that in the changelog? [17:35] seb128: yes [17:35] bdmurray, sorry, let me fix that and reupload [17:35] bdmurray, thanks for spotting it [17:35] seb128: no problem [17:39] bdmurray, k, rejected the old one, new one in the queue [19:45] robert_ancell: your upload of lightdm in the precise-proposed queue should supercede the existing upload correct? [19:45] bdmurray, yes [19:46] bdmurray, I probably should have marked the patch as fixing bug 1431654 [19:46] bug 1431654 in lightdm (Ubuntu) "lightdm (1.2.3-0ubuntu2.6) 100%/high cpu usage" [Critical,Fix committed] https://launchpad.net/bugs/1431654 [19:46] that would make things clearer and allow it to be verified [19:47] bdmurray, do you want me to re-upload? [19:48] robert_ancell: I think that'd be best, yes please [19:48] ok [19:54] bdmurray, new version should be there now [20:00] robert_ancell: okay, accepted [20:00] bdmurray, thanks [20:47] Hi, is there a channel dedicated to network-manager specifically? [20:49] Heh, was about to say their wiki claims #nm. [21:04] Unit193: indeed, it's #nm [21:05] Heh, it's a secret (+s) channel. And dang, was supposed to file a bug for you... === davidcalle_ is now known as davidcalle