[00:17] <smoser> slangasek, so tonight i ask for review of the bug 1432829 fix (that i incorrectly asked about last night)
[00:17] <smoser> attached to bug .
[00:18] <smoser> xnox, your thoguhts woudl be appreciated there too
[08:18] <dholbach> good morning
[08:25] <LocutusOfBorg1> ginggs, hi, can I release your "conflicts" virtualbox patch under MIT license?
[09:00] <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.
[10:15] <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:16] <flexiondotorg> seb128, Thanks. mlankhorst Excellent :D
[10:17] <flexiondotorg> seb128, mlankhorst I'll wait for that to propagate and test later.
[10:20] <rbasak> hallyn: I'm thinking something like this: http://paste.ubuntu.com/10626570/
[10:21] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <rbasak> Thanks. I had just never used -d.
[10:31] <rbasak> Any thoughts on making scripts supplied in debian/ executable in the tarball vs. marking it executable via debian/rules?
[10:32] <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:33] <zyga> rbasak: thanks for the help!
[10:33] <rbasak> It "just happens" so I never really thought about the details!
[10:35] <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:56] <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:57] <rbasak> upstart is 1.0 non-native, so it would make sense why it was being done there.
[10:58] <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:59] <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
[11:00] <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:01] <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:02] <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:04]  * 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:05] <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:07] <rbasak> warty? Did gwibber exist then?
[11:08] <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:09] <zyga> that's not just for debian core developers but also for people like me that have different workflows
[11:10] <rbasak> It would be nice to just have a --ppa option
[11:11] <zyga> yep
[11:11]  * zyga builds piglit :-)
[11:14] <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:15] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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] <zyga> infinity: I'd love to see an argument for beauty there but I have yet to find one
[11:27] <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:28] <zyga> I wonder what's the motivation for dpkg on osx
[11:28] <infinity> fink.
[11:29] <zyga> hmm, osx is a curious mixture of environments
[11:30] <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:33] <rbasak> infinity: poke to do bug 1417328 for me please
[11:34] <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:48] <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:49] <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:58] <rbasak> Yeah you'll want fakeroot on your testbed
[11:59] <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)
[12:00] <rbasak> You can use -B to separate them, by building packages first eg. with sbuild
[12:01] <Laney> Riddell: howdy, do you know if anyone's looking at kde-baseapps autopkgtest failure?
[12:09] <Riddell> Laney: yeah I'm on it now, I'll just patch it out I guess
[12:11] <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:12] <Riddell> mm
[13:58] <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:59] <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.
[14:00] <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:02] <hallyn> rdepends list is pretty long, but seems random
[14:02] <hallyn> cgmanager and lxc both depend on it
[14:03] <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:04] <hallyn> i'm looking at apt-cache rdepends init-system-helpers | sort | less
[14:05] <hallyn> msut be something common in there i'm just not seeing it :)
[14:06] <rbasak> Perhaps you're expected to depend on it explicitly.
[14:07] <rbasak> In which case what matters are the recursive reverse depends on upstart-bin, which shipped /lib/init/apparmor-update-profile previously
[14:08] <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:14] <hallyn> man ..  i'm sure it's obvoius, but i'm not finding it
[15:00] <infinity> hallyn: All those init-system-helpers deps (or most) are coming from dh_systemd.
[15:02] <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:57] <smoser> xnox, in systemd, what all runs 'ifup NIC' ? is it more than the ifup@ service ?
[16:00] <flexiondotorg> didrocks, mlankhorst seb128 Just tested the new xorg-server. Looks good. Thanks for your help!
[16:00] <seb128> flexiondotorg, yw!
[16:01] <flexiondotorg> seb128, Looks like another bug got fixed too.
[16:01] <seb128> which one?
[16:02] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/
[16:02] <seb128> great
[16:02] <flexiondotorg> seb128, Just confirming.
[16:02] <flexiondotorg> seb128, Nuts.
[16:02] <flexiondotorg> Sadly not.
[16:03] <flexiondotorg> The pp2 version that yanked redBIOS did fix the bug above however 😕
[16:03] <flexiondotorg> *ppa2 version from x-staging
[16:07] <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
[17:35] <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:39] <seb128> bdmurray, k, rejected the old one, new one in the queue
[19:45] <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:46] <robert_ancell> bdmurray, I probably should have marked the patch as fixing bug 1431654
[19:46] <bdmurray> that would make things clearer and allow it to be verified
[19:47] <robert_ancell> bdmurray, do you want me to re-upload?
[19:48] <bdmurray> robert_ancell: I think that'd be best, yes please
[19:48] <robert_ancell> ok
[19:54] <robert_ancell> bdmurray, new version should be there now
[20:00] <bdmurray> robert_ancell: okay, accepted
[20:00] <robert_ancell> bdmurray, thanks
[20:47] <Peaker> Hi, is there a channel dedicated to network-manager specifically?
[20:49] <Unit193> Heh, was about to say their wiki claims #nm.
[21:04] <cyphermox> Unit193: indeed, it's #nm
[21:05] <Unit193> Heh, it's a secret (+s) channel.  And dang, was supposed to file a bug for you...