[00:35] <slangasek> bdmurray: the mini.iso is built from debian-installer source, so probably there; though it's possible the correct fix is "stop building the mini.iso"...
[00:36] <cjwatson> The bug sounds like a gnupg problem ...
[00:36] <cjwatson> I mean the netboot mini.isos are genuinely useful and used, and there's no particular reason they shouldn't be able to load additional components
[00:37] <cjwatson> And this is probably affecting all use of d-i netboot
[00:38] <cjwatson> Compare https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753985
[00:39] <cjwatson> Though why is sha512 needed?  Our Release/Packages/Sources files don't use it
[00:41] <cjwatson> oh, Release.gpg
[00:41] <cjwatson> publish-distro.d/10-sign-releases:                      printf '%s\n' "-u 437D05B5 -u C0B21F32 --digest-algo SHA512"
[00:41] <cjwatson> so the attached patch in comment #8 is correct and should be applied
[00:42] <cjwatson> slangasek: ^-
[00:42] <cjwatson> probably doesn't affect CDs because we re-sign Release for those, IIRC
[00:42] <slangasek> cjwatson: oh, alrighty then
[00:42] <cjwatson> (due to reconstructing Packages)
[00:43] <slangasek> bdmurray: so turns out gnupg is the right place to fix it :-)
[00:43] <cjwatson> d-i will need to be rebuilt afterwards, but that happens reasonably often anyway because hi kernel
[00:45] <bdmurray> slangasek, cjwatson: alright, thanks
[01:25] <micah> so these pages about how to get software into the software center used to exist, but now they dont and the only thing on developer.ubuntu.com are things related to mobile, where is the non-mobile stuff gone? http://developer.ubuntu.com/publish/apps/other-forms-of-submitting-apps/my-apps-packages/ http://developer.ubuntu.com/2012/02/how-to-prepare-a-compiled-application-for-ubuntu-software-center/ ?
[01:26] <micah> hm, maybe this isn't the right place for app development questions
[01:30] <micah> it looks like it was moved, and there were no redirects made for it
[05:09] <anishparanjpe> I want to find all the modules that ubuntu installed apart from those in the kernel source. Is there a list of those modules?
[06:55] <pitti> Good morning
[07:13] <pitti> stgraber: I filed bug 1410666 for tracking this
[07:49] <dholbach> good morning
[07:50] <seb128> hey dholbach
[07:53] <dholbach> hey seb128
[08:44] <LocutusOfBorg1> hi developerz!
[09:49] <flexiondotorg> Trevinho, I've had some success with adding MATE support to lp:compiz 😃
[09:49] <flexiondotorg> Trevinho, I need to tweak the plugin configuration so it is sane for MATE, but it is working.
[09:50] <flexiondotorg> Trevinho, When I am done should I submit the merge proposal against lp:compiz or is there another repo I should use?
[10:08] <flexiondotorg> cjwatson, In order to make iso images of Ubuntu MATE using my own scripts I had to create meta packages from my seeds.
[10:08] <flexiondotorg> cjwatson, I assume that I do not need to make my meta packages available for official builds because tasksel tasks are made from the seeds, correct?
[10:21] <cjwatson> flexiondotorg: It's usual to put metapackages in the archive too
[10:22] <flexiondotorg> cjwatson, So if I have meta packages for ubuntu-mate-* those should all go in to the official archive too?
[10:26] <cjwatson> flexiondotorg: Yes, I would say so
[10:29] <cjwatson> slangasek: ^- could flexiondotorg have another contact to work with to help merge all the Ubuntu MATE stuff?  I can't promise to be desperately responsive
[11:16] <flexiondotorg> cjwatson, for package uploads dholbach has been helping me, but again I know he is somewhat busy too.
[11:16] <dholbach> flexiondotorg, do you need help with anything?
[11:16] <cjwatson> flexiondotorg: It would be helpful I think if you had somebody who's a specialist in image builds.
[11:16] <cjwatson> dholbach doesn't have access to all the right pieces ...
[11:17] <dholbach> ah ok
[11:17] <flexiondotorg> dholbach, I am going to start preparing my requests for packaing. I'll subscribe ubuntu-sponsors.
[11:17] <cjwatson> But in any event it needs to not be me, because I'm mostly doing Launchpad now.
[11:17] <flexiondotorg> cjwatson, dholbach I basically have two areas I'm takling. The build system and getting some packages into the archive.
[11:17] <flexiondotorg> I think dholbach can help with the later?
[11:17] <cjwatson> The odd bit of help is fine, but not as a default contact.
[11:18] <cjwatson> Yes, I expect so.
[11:19] <flexiondotorg> cjwatson, I have submitted merge proposal to livecd-rootfs and ubuntu-cd that adds Ubuntu MATE support. They are pending.
[11:19] <flexiondotorg> cjwatson, I'm happy to do the leg work and submit the merge proposals.
[11:19] <lesshaste> does anyone maintain the bzip2 source code? The official web page has no changes since 2010
[11:19] <flexiondotorg> cjwatson, Is there anything else I should be modifying for the build Ubuntu MATE images?
[11:20] <cjwatson> flexiondotorg: Right, which is why I'm asking for my previous manager to give you a contact to get that stuff properly reviewed and merged.
[11:20] <cjwatson> And to answer that last question.
[11:20] <flexiondotorg> cjwatson, Understood. Thanks. I'll try and progress with slangasek.
[11:30] <Trevinho> flexiondotorg: lp:compiz is fine
[11:48] <flexiondotorg> Trevinho, Thanks.
[12:35] <pitti> cjwatson, xnox: I'm looking into providing systemd units for ubiquity; do you have a clever technique how to test a locally built ubiquity deb on a live system?
[12:35] <pitti> like, interrupt the boot early, scp/dpkg -i it or so? or does it require rebuilding the image (expensive)?
[12:36] <cjwatson> pitti: break=casper-bottom
[12:37] <cjwatson> then you can fiddle in /root; don't recall whether you have networking (it should be possible but maybe not by default), if it's just text files you can just edit them in manually
[12:37] <pitti> cjwatson: ah, thanks; I figure I can call dhclient -1 eth0 or so
[12:38] <cjwatson> Yeah, well you probably don't have dhclient but ipconfig from klibc-utils should be there
[12:39] <cjwatson> Or you can use stuff from /root with judicious use of LD_LIBRARY_PATH or chroot, which you'll need to do for scp anyway
[12:40] <pitti> cjwatson: that seems to work: chroot /root, mount -t proc proc /proc, dhclient -1 eth0
[12:41] <pitti> cheers
[12:41] <cjwatson> np
[12:41] <xnox> pitti: whilst above is good, I do following -> boot to desktop, fiddle with files, switch to tty1 -> service lightdm stop, killall -9 X, service lightdm start
[12:41] <xnox> pitti: note that ubiquity jobs is start on starting lightdm.
[12:41] <pitti> xnox: ah, that sounds good too
[12:41] <xnox> pitti: in systemd world, I hope you can boot to live desktop.
[12:41] <pitti> xnox: right, I'll do the  same
[12:41] <cjwatson> I can understand wanting to not get into that when bringing up systemd jobs though
[12:41] <pitti> xnox: yes, that works fine
[12:41] <cjwatson> I mean you'll definitely want to test behaviour from clean boot too
[12:41] <pitti> xnox: just the "directly to installer" mode obviously doesn't work, that's the one I want to create
[12:42] <xnox> pitti: from there start ubiquity job and it should do things. Imho, ubiquity should be highjacking default dm, cause that's what it is.
[12:42] <xnox> pitti: in general ubiquity job should pre-empt normal one, given the conditions on the kernel command line.
[12:42] <pitti> xnox: yeah, either it registers itself as "the" dm (display-manager.service) or it does like in the upstart world and starts itself before display-manager.service
[12:43] <pitti> I factorized the startup logic into scripts/start-ubiquity-dm and share that from the .upstart and the .service
[12:43] <xnox> pitti: probably before is best, cause "on exit, normal dm should start and autologin"
[12:43] <cjwatson> ConditionKernelCommandLine should make things much nicer
[12:43] <pitti> anyway, I'll put up an MP for critisizing once I'm done
[12:43] <xnox> is the current expected behaviour
[12:43] <pitti> xnox: right
[12:44] <xnox> pitti: https://wiki.ubuntu.com/DesktopCDOptions you might find it useful. "automatic-ubiquity only-ubiquity maybe-ubiquity debug-ubiquity" should run ubiquyity
[12:44] <xnox> pitti: there are also kernel options for oem-config as well.
[12:44] <xnox> (that needs porting as well)
[12:45] <pitti> xnox: yes, I'm aware of the oem-config bits, but one at a time :)
[12:50] <shadeslayer> Could someone advise me of a way to throw away changes to a file system after it's unmounted?
[12:50] <pitti> shadeslayer: overlayfs/aufs?
[12:50] <shadeslayer> pitti: I was using that, but that keeps the the changes in the upper dir
[12:51] <shadeslayer> use case : I need to expose files on a host to a schroot, and any changes inside the schroot should be thrown away
[12:51] <shadeslayer> +after the schroot is closed
[12:51] <pitti> shadeslayer: with a tmpfs as the upper dir and lazily unmounting upper dir afterwards might work?
[12:51] <pitti> shadeslayer: sounds like you are reimplementing schroot :)
[12:52] <shadeslayer> heh
[12:52] <shadeslayer> I'm using this at the moment : /var/lib/jenkins/workspace/ /var/lib/jenkins/workspace/ overlayfs rw,lowerdir=/var/lib/jenkins/workspace/,upperdir=/tmp/jenkins 0 0
[12:52] <pitti> shadeslayer: so, I don't know exactly how schroot does that, but it's by and large that -- r/o lowerdir, tmpfs (or dir) upperdir, and unmounts everything if you close the schroot
[12:53] <cjwatson> schroot uses some unionfs (aufs, overlayfs, unionfs depending on config) with a throwaway overlay
[12:54] <cjwatson> if schroot isn't throwing away the changes then you just need to adjust its config
[12:54] <cjwatson> I would just tell the fstab in the relevant schroot profile to bind-mount the relevant directory, and then schroot's own overlay handling should take care of the rest
[12:55] <cjwatson> hm, actually that's not quite right is it
[12:56] <cjwatson> I think your problem is that /etc/schroot/setup.d/10mount comes after 05union
[12:56] <cjwatson> which is normally right, but you need to get in beforehand
[12:57] <cjwatson> so unless there's some way to do it with the standard setup.d scripts that I missed, I'd add another setup.d script before 05union that does the bind-mount you need
[12:58] <cjwatson> maybe 04mount_early with a fstab-early config file in the profile
[12:59] <cjwatson> but read through the existing setup.d scripts first to see what you can do already
[13:01] <pitti> meh, scp doesn't work in casper -- netcat FTW
[13:27] <shadeslayer> cjwatson: hm, I'll have a look
[13:40] <willpearson> Hi, we are having a problem with USN-2469-1 on Ubuntu 12.04 LTS causing a problem with graphite.
[13:41] <willpearson> The change to serving the static content isn't working for us.
[14:52] <stgraber> pitti: cool, thanks, I'll upload the fix today
[14:52] <pitti> stgraber: ah, you know what's wrong?
[14:53] <pitti> seems the systemd unit also needs some love (see first comment on the bug)
[14:54] <stgraber> pitti: yeah, needs to be changed to "starting lxc or cgmanager-ready"
[14:54] <pitti> stgraber: oh, lxc depends on cgmanager? i. e. dependency loop?
[14:55] <stgraber> well, started cgmanager is bad to begin with because in a container you'll get cgproxy, not cgmanager, so you need the cgmanager-ready event. Now when you have a "starting" and depend on something else, the "starting" in this case lxc will be held until the other event is emitted (in this case started cgmanager)
[14:56] <stgraber> as upstart doesn't keep and replay the event history, that basically means hanging until cgmanager restarts and started cgmanager is emitted again
[14:56] <shadeslayer> stgraber: btw I wanted to setup a unpriv lxc container, tried following the steps here https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-unpriv but I get a error that ~/ doesn't have the 'x' bit set
[14:56] <shadeslayer> stgraber: are there more proper instructions than that?
[14:56] <stgraber> shadeslayer: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
[14:56] <stgraber> that does mention the chmod +x (or setfacl)
[14:59] <shadeslayer> stgraber: lxc_container: confile.c: network_netdev: 482 network is not created for 'lxc.network.link' = 'lxcbr0' option
[14:59] <shadeslayer> lxc_container: parse.c: lxc_file_for_each_line: 57 Failed to parse config: lxc.network.link = lxcbr0
[14:59] <pitti> stgraber: ah, makes sense; I think I ran into this a few years ago, nice gotcha when thinking about states instead of events
[15:00] <stgraber> shadeslayer: what do you have in ~/.config/lxc/default.conf ?
[15:00] <shadeslayer> http://paste.ubuntu.com/9748358/
[15:00] <stgraber> shadeslayer: that first line looks a bit mangled
[15:01] <shadeslayer> aha indeed
[15:02] <shadeslayer> stgraber: lxc-start: conf.c: mk_devtmpfs: 1181 Permission denied - Unable to create /dev/.lxc for autodev
[15:03] <pitti> stgraber: mangled? it's perfect Klingon! :-)
[15:03] <shadeslayer> xD
[15:03] <stgraber> shadeslayer: hmm, what's in that container?
[15:03] <shadeslayer> stgraber: I just downloaded the sid container
[15:04] <shadeslayer> though trying to run it on a non-systemd utopic machine
[15:04] <stgraber> shadeslayer: ah, that'd be why, yeah, sadly that won't work until proper systemd support lands
[15:04] <shadeslayer> aha
[15:04] <stgraber> we have the patches though so hopefully that'll all land in vivid in the next couple of weeks
[15:04] <shadeslayer> I assumed the containers on the website worked
[15:04] <pitti> shadeslayer: install sysvinit-core into it (chroot into its rootfs)?
[15:05] <stgraber> yeah, that'd be a fair assumption and that's usually quite true, expect that I never got around to blacklisting sid and jessie after they switched to systemd
[15:05] <shadeslayer> now I get lxc-start: lsm/apparmor.c: mount_feature_enabled: 61 Permission denied - Error mounting securityfs
[15:05] <shadeslayer> after installing sysvinit-core
[15:07] <stgraber> shadeslayer: can you try a trusty container just to make sure that lxc itself is happy?
[15:07] <shadeslayer> checking
[15:10] <shadeslayer> stgraber: yeah, so it's a debian specific issue
[15:12] <stgraber> wheezy starts fine, but probably a bit too old for you :)
[15:12] <shadeslayer> yeah :P
[15:13] <stgraber> I've added jessie and sid to the blacklist for now so they should vanish from the list pretty soon
[15:13] <stgraber> and will come back once unpriv systemd support lands
[15:13] <shadeslayer> ack
[15:13] <shadeslayer> thanks :)
[15:14] <stgraber> pitti: so I'm really unsure what's going on with that systemd unit... Does systemd expect the command to background itself or to stay in the foreground?
[15:14] <stgraber> pitti: I assume the former so that's why I'm not passing the -f flag as I am with upstart, besides that, it's the exact same thing running in either case...
[15:14] <pitti> stgraber: usually it should stay in the foreground (Type=normal)
[15:15] <stgraber> ah, so that's probably the problem
[15:15] <pitti> stgraber: Type=forking is for daemons which fork; some can't be run in the foreground
[15:15] <pitti> stgraber: it's usually better to let them run in the foreground, to capture their stdout/err, and the extra fork is just unnecessary
[15:15] <stgraber> pitti: ok, if you're still on systemd with lxcfs installed, can you edit ExecStart and add a -f in there, see if that does the trick?
[15:16] <stgraber> pitti: yeah, agreed and I always do that with upstart, just wasn't sure that systemd had the same default behavior
[15:16] <pitti> stgraber: I'm not, but easy enough to bring one up, hang on
[15:19] <pitti> stgraber: still the same
[15:20] <stgraber> pitti: and no extra error messages this time?
[15:20] <pitti> still the same "Failed to start FUSE filesystem for LXC."
[15:20] <pitti> $ sudo /usr/bin/lxcfs -f -s -o allow_other /var/lib/lxcfs/
[15:20] <pitti> Failed opening dbus connection: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /sys/fs/cgroup/cgmanager/sock: No such file or directory
[15:20] <pitti> WARNING: failed to escape to root cgroup
[15:21] <stgraber> no cgmanager running?
[15:21] <pitti> stgraber: bug 1400394
[15:21] <pitti> stgraber: yep, systemctl start cgmanager, then start lxcfs -> runs
[15:22] <stgraber> pitti: ok, so After=cgmanager.service should become Requires=cgmanager.service then?
[15:22] <pitti> stgraber: drop the local-fs.target, not needed
[15:22] <stgraber> pitti: ok
[15:22] <pitti> stgraber: and then Requires=cgmanager.target\nAfter=cgmanager.target
[15:23] <stgraber> ah, why .target and not .service? (sorry, still new to this)
[15:23] <pitti> stgraber: Type=simple is also the default
[15:23] <pitti> stgraber: err sorry, .service of course
[15:23] <pitti> stgraber: the local-fs.target was still in my head apparently
[15:23] <stgraber> :)
[15:23] <pitti> stgraber: OOI, why KillMode=? isn't the default (control-group) ok?
[15:25] <pitti> stgraber: I tested this, and confirmed it to work (also after reboot): http://paste.ubuntu.com/9748762/
[15:25] <pitti> stgraber: before/after is ordering, requires/wants is dependencies, they are both independent (sometimes you only need one or the other)
[15:26] <stgraber> pitti: so the expected problem with cgroup killing is that lxcfs escapes its cgroup :)
[15:26] <pitti> stgraber: oha :)
[15:27] <pitti> stgraber: systemctl stop lxcfs works (no lxcfs process any more), but indeed it did escape its cgroup
[15:27] <stgraber> does systemd have some kind of fallback then?
[15:28] <pitti> stgraber: apparently so; I'm not yet familiar with that level of detail
[15:28] <stgraber> anyway, I think it's better to stick with =process for now :)
[15:28] <pitti> I learned more than I ever wanted to know about how it sets up cgroups (when I wrote the lxc user support patch), but haven't yet looked at the teardown
[15:28] <pitti> stgraber: yep, sounds fine
[15:29] <pitti> stgraber: so my diff is: add -f, drop the default Type= and the unnecessary local-fs.target, add Requires=cgmanager.service
[15:30] <stgraber> pitti: sounds like what I've got here
[15:30] <stgraber> pitti: https://github.com/lxc/lxcfs-pkg-ubuntu/commit/67f3a4d7ecc183cb1e798cc0ffc48bdae010d39b
[15:32] <pitti> stgraber: LGTM, thanks!@
[15:32]  * pitti eyes at the @, where did that come from
[15:32] <stgraber> ok, uploaded. Hopefully adt will be happy this time.
[15:34] <stgraber> pitti: so the latest cgmanager upload is supposed to enable the unit by default, is that not the case in practice?
[15:35] <pitti> stgraber: it actually is; maybe I still had 0.34, lemme check
[15:36] <pitti> no, it's 0.35
[15:36] <pitti>    Loaded: loaded (/lib/systemd/system/cgmanager.service; disabled; vendor preset: enabled)
[15:37] <pitti> stgraber: oh, I know!
[15:37] <pitti> stgraber: 0.35 doesn't enable itself during upgrades (hallyn knew about that)
[15:37] <pitti> stgraber: I figure we need to wait for a cloud image with 0.35 proper; I figure my image just got dist-upgraded from 0.34 to 0.35
[15:37] <pitti> well, it helped us spot that bug
[15:40] <stgraber> pitti: ah, I guess that makes sense
[15:57] <mitya57> ScottK, hi, what's your opinion on https://bugs.launchpad.net/ubuntu/+source/qtenginio-opensource-src/+bug/1409433/comments/3
[16:01] <pitti> stgraber: "Jenkins Fixed - vivid-adt-lxcfs 4" -- c'est de la musique dans mes oreilles :)
[16:02] <stgraber> yay!
[16:12] <mitya57> cjwatson, hi, do you think it will be possible to drop perlqt dependency from debconf? That will allow us to demote a bunch of packages (see mterry's comment on bug 1409433).
[16:20] <cjwatson> mitya57: Probably pretty hard, the B-D is needed to generate the .ui file
[16:21] <mitya57> cjwatson, can we just use the pre-generated one?
[16:21] <cjwatson> mitya57: No idea
[16:21] <mitya57> cjwatson, well, if I write the patch (which will be Ubuntu delta), will you have any objections?
[16:21] <cjwatson> mitya57: I would expect it to be hard to load the .ui at run-time (one of mterry's suggestions), because debconf has to work when unconfigured
[16:21] <mterry> cjwatson, as I mention in the bug, the file is just 155 lines.  We could patch it in or maybe even change the code to load the .ui file instead of using a .pm one
[16:22] <mterry> cjwatson, ok
[16:22] <cjwatson> I don't hugely object if you patch in the pregenerated file as long as you maintain that patch henceforth
[16:22] <mterry> cjwatson, but still.   Patching 155 lines to avoid many large packages in main seems worth it.  Do you know roughly how often that .ui file changes?
[16:22] <cjwatson> No idea
[16:22] <cjwatson> Check git history
[16:23] <cjwatson> Build-time changes are safe enough as long as you're actually going to maintain them.  Run-time changes are risky
[16:24] <mitya57> cjwatson, last change in 2010 (by you)
[16:24] <mitya57> http://anonscm.debian.org/cgit/debconf/debconf.git/log/Debconf/FrontEnd/Kde/WizardUi.ui
[16:25] <mterry> And before that, 2009, then 2003
[16:25] <mterry> mitya57, Seems like a reasonable amount to maintain.  If it changes in future and you're busy, just send me a poke.  I'll gladly take the risk to demote all those packages
[16:26] <mterry> mitya57, the 2009 and 2010 changes were just removing and adding the frontend back.  The file itself hasn't changed since 2003 it seems
[16:26] <mterry> Although I guess it was ported to qt4, which probably did have changes
[16:26] <mterry> But still.  Point is, not a frenzy of updates
[16:27] <mitya57> I think it will need to be ported to Qt 5 before Stretch
[16:27] <mitya57> But that will be easy to merge
[16:28] <shadeslayer> does anyone know if there's a way to make a package upgradable but not uninstallable? ( I'm not sure if such a state exists )
[16:29] <mitya57> mterry: I will then wait for ScottK's reply (maybe he knows other reasons why qscintilla/pyqt5 need to stay in main), and after that upload a patched debconf
[16:29] <shadeslayer> I'd prefer not to mark it as essential
[16:29] <cjwatson> make the prerm fail
[16:30] <cjwatson> hope you (a) have a good reason (b) don't put it in the primary archive, though
[16:31] <shadeslayer> heh
[16:31] <shadeslayer> sounds extremely icky
[16:46] <PaulW2U> ssh -p 60000 paul@vps.pcw.me.uk
[17:16] <shadeslayer> chrisccoulson: firefox question for you, if I want to rename the firefox package to say .. magic .. I imagine alot of stuff would break if I  change MOZ_PKG_BASENAME / MOZ_PKG_NAME
[17:23] <shadeslayer> chrisccoulson: so, what would be the right way to go about this?
[17:23] <davmor2> cjwatson: to make a perm fail surely you just wash your hair before the magic 48hours is up ;)
[17:24] <Odd_Bloke> Surely a prerm is a haircut?
[18:03] <kkirsche> Hey guys does anyone know where I can find the Sign On API for Ubuntu One so I can implement a sign on option using Ubuntu One?
[18:20] <kkirsche> found it http://canonical-identity-provider.readthedocs.org/en/latest/resources/token.html#token-oauth
[19:24] <dobey> kkirsche: sign on to what?
[19:24] <kkirsche> dobey: I want to extend omniauth to allow Ubuntu One as a method of authentication for web apps
[19:25] <dobey> oh, ok. thought maybe you wanted to use it in a client app on ubuntu :)
[19:27] <kkirsche> :) nope, sorry. Thanks though
[21:33] <dobey> anyone smarter regarding the archive/proposed stuff than me, that can tell me what this bit of log actually means? http://pastebin.ubuntu.com/9752159/ slangasek maybe?
[23:50] <Riddell> anyone able to tell me why the transitions I'm doing for kate4/kate and konsole4/konsole aren't going into the archive? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[23:51] <Riddell> both apps have moved to qt5 but we want to keep the plugins from the qt4 version around for apps which use them