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