=== timrc is now known as timrc-afk
=== _salem is now known as salem_
[03:10] <pitti> Good morning
[03:11] <pitti> slangasek: wrt. ddeb-retriever rollout> I noticed yesterday that a lot of ddebs can't be mapped to package indexes because they were built for the train PPAs or will be in binNEW
[03:11] <pitti> slangasek: so ddeb-retriever needs to grow a "queue" mechanism to try and process them until they do get published; so still can't roll out yet :/
=== salem_ is now known as _salem
[04:20] <pitti> xnox: I don't fully understand bug 1326327, but this should go to Debian as well, right? it sounds related to debian bug 749400?
[04:20] <ubottu> bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327
[04:20] <ubottu> Debian bug 749400 in debhelper "dh_installinit: disable init scripts on removal of package" [Normal,Open] http://bugs.debian.org/749400
[04:20] <pitti> xnox: perhaps you can forward it, with some more explanation?
=== ohnivy_kon is now known as lisca
[06:54] <spacetime> Hey, I'm trying to add a new seed but when I update, I get http://paste.ubuntu.com/7834499/  . Could someone help me figure out what I'm doing wrong?
[07:12] <cjwatson> spacetime: Looks like you didn't add it to STRUCTURE properly
[07:23] <spacetime> cjwatson: where's STRUCTURE?
[07:24] <spacetime> cancel that. found it.
[08:33] <Riddell> StevenK: wish hobbsee a happy birthday
[08:38] <xnox> pitti: i thought that it's a bit reverse, in Ubuntu we had delta on top of Debian to do the opposite.
[08:38] <xnox> pitti: and I'm not yet sure if everything is correct, cause e.g. I've seen really strange generated postinst in qemu.
[08:38]  * xnox reads the pointed out bugs again.
[08:42] <Laney> is anyone else getting BADSIG on ddebs.u.c?
[08:44] <Laney> hrm, yeah, looks like Release.gpg is out of date
[08:44] <Laney> http://ddebs.ubuntu.com/dists/utopic/
[08:45] <pitti> Laney: yeah, sorry; current ddeb-retriever has run for almost a day already, seems I touched a lot of .debs or so and apt-ftparchive takes aaages
[08:47] <Laney> pitti: and dists/ is updated in a racy way?
[08:47] <pitti> Laney: yes, currently not atomic
[08:47] <Laney> mmm, I see
[08:48] <pitti> another deficiency of the temporary hack from 8 years ago *sigh*
[08:48] <pitti> Laney: unless apt-ftparchive already does that by itself, but seems not?
[08:48]  * pitti puts that at the end of the long queue of TODOs for current rewrite
[08:49] <Laney> I'd think that it would, but I've not used it myself to say for sure
[08:52] <Laney> Maybe you have to do this yourself actually, looking at its manpage
[09:52] <jodh> pitti: fyi http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD shows "404 - Cannot find file"
[09:53] <jodh> pitti: (as linked to from http://dep.debian.net/deps/dep8/)
[09:53] <pitti> jodh: I know, it was renamed to .rst
[09:53] <pitti> jodh: hm, I updated that in svn ages ago; seems that doesn't automatically get rolled out
[09:53] <pitti> jodh: thanks, I'll find out who to contact about this
[09:54] <jodh> pitti: ta. Is there any capability in the dep8 framework to look for core files left behind by tests, or is it up to each test to implement those checks?
[09:54] <pitti> http://lists.alioth.debian.org/pipermail/dep-commits/2014-July/000316.html FTR
[09:55] <pitti> jodh: the latter; I don't want to search the entire file system for core file, that would be quite inefficient
[09:55] <pitti> the test knows where to look for them (and most tests don't use core dumps)
[09:55] <pitti> you can put them into $ADT_ARTIFACTS if you want to export them
[09:55] <pitti> (but please compress them first :) )
[09:56] <pitti> jodh: we could collect apport crash reports though, if that's sufficient
[09:56] <jodh> pitti: ack. I've found a couple of commands recently that core dump but there is no dep8 test. so I was kinda hoping I could create a NOP dep8 test and get the rest for free. However, copy+paste it is... :)
[09:58] <jodh> pitti: might be a nice extension to have a way for a dep8 test to request that core files be checked for in say '/', any directory specified by a *.install file and any directory in or below the ADT test run directory though.
[09:59] <jodh> pitti: I agree that we don't want to trawl the entire FS though :)
[10:00] <pitti> poked
[10:00] <pitti> and we don't want to routinely pick up all core files, I think; they are quite huge, and we basically store them forever
[10:01] <jodh> pitti: I'm not suggesting we pick them up necessarily, just that iff a test specifies an interest in core files, that test would be failed if any were found.
[10:01] <pitti> I think it makes more sense to (1) either collect and post-process apport reports (without core)
[10:01] <pitti> or (2) locally run the test with -s
[10:01] <pitti> to get a shell, and debug in the testbed
[10:02] <jodh> pitti: cheaper to find the problems earlier imho
[10:02] <pitti> jodh: but woudl that actually buy you much? you still need to reproduce the same test environment
[10:02] <pitti> so you could just as well re-run the test
[10:03] <jodh> pitti: yes, but if we atleast flag it at the dep8 stage, we could avoid releasing versions of programs that dump core everywhere :)
[10:04] <pitti> right
[10:04] <pitti> jodh: you mean your test succeeds, but something still crashes?
[10:06] <jodh> pitti: I'm not talking about any of my tests. There are a couple of bugs I've hit recently in packages with no dep8 tests. The commands in these packages core dump when run.
[10:07] <pitti> ah, so a smoke test like running the program with some sensible/easy options succeeds would help there?
[10:10] <jodh> pitti: yeah.
=== pitti is now known as somedude
=== somedude is now known as pitti
[11:12] <pitti> Laney: hm, I just had a quick attempt at atomically updating dists/, but that's utterly hard :/
[11:13] <pitti> meh, I already have half a soyuz implementation in ddeb-retriever; I really don't want to pile more hacks upon it
[11:13] <pitti> Laney: it does update Packages.gz atomically, but not the whole dists/
[11:14] <Laney> pitti: Dare I ask if ddebs in launchpad is coming soon anyway? ...
[11:14] <cjwatson> Laney: Blocked on prodstack 4
[11:14] <cjwatson> The Launchpad side is done
[11:15] <Laney> Yeah so I understand
[11:15] <pitti> is that ddebs in librarian, or actual archive generation, too?
[11:15] <cjwatson> But we need the new librarian or it'll run out of space
[11:15] <cjwatson> pitti: librarian
[11:15] <cjwatson> Er, wait
[11:15] <pitti> that's already a huge progress in terms of stopping to lose ddebs
[11:15] <cjwatson> Just the librarian bit is blocked on prodstack.  As far as I know the ddebs implementation in Launchpad covers archive generation too.
[11:15] <pitti> my main difficulty is to re-model binNEW, component changes, copying from PPA, and all the other funny stuff that can happen to the main indexes
[11:16] <wgrant> We don't do archive generation for the primary archive today.
[11:16] <pitti> oh, way cool!
[11:16] <wgrant> The primary archive's ddebs, that is.
[11:16] <wgrant> It's difficult to implement.
[11:16] <cjwatson> Ah, I'm misinterpreting r16629 then, sorry
[11:17] <wgrant> That's only for PPAs atm.
[11:17] <cjwatson> I assumed that since that touched lp.archivepublisher.model.ftparchive that it affected primary too
[11:17] <Laney> pitti: In the meantime I'd go ask #debian-ftp for help if you're motivated
[11:17] <pitti> Laney: still fighting with my code to properly queue ddebs to cope with PPA/binary NEW, and other fun exceptions
=== juliank0 is now known as juliank
[11:53] <Bluefoxicy> Any thoughts on making /tmp and /run/user btrfs subvolumes, mounted as noexec,nodev,nosuid ?
[11:54] <Bluefoxicy> (yes, I realize nobody has told the system perl/python/bash interpreters to check for noexec and refuse to load scripts)
[11:55] <xnox> Bluefoxicy: /run/user may not be btrfs.
[11:55] <xnox> that would be violation of XDR Directory Spec.
[11:57] <xnox> and it's already noexec.
[11:57] <xnox> by default we don't do anything for /tmp. there were plans to make /tmp on tmpfs by default, and thus hence noexec would be possible but that hasn't been implemented.
[11:59] <xnox> Bluefoxicy: for reference see /lib/init/fstab
[11:59] <Bluefoxicy> xnox:  wait, what?
[12:00] <Bluefoxicy> oh
[12:00] <Bluefoxicy> it's a tmpfs
[12:00] <Bluefoxicy> xnox:  I didn't notice that, somehow, in the pile of mount output
[12:01] <xnox> Bluefoxicy: locally i have /tmp on tmpfs with noexec, nodev, nosuid.... but we can't  / don't have that by default.
[12:01] <Bluefoxicy> nod
[12:01] <Bluefoxicy> I've been mounting @home that way
=== MacSlow is now known as MacSlow|lunch
[12:02] <mdeslaur> you'd probably want to mount /var/tmp noexec also, else, there's no point
[12:03] <mdeslaur> (well, I personally think there's no point for /tmp either, but meh)
=== _salem is now known as salem_
[12:23] <Bluefoxicy> heh
[12:37] <pitti> xnox: thanks for fixing lava-dispatcher! can you please send this fix to Debian?
[12:37] <xnox> pitti: yeah, i will.
[12:37] <pitti> xnox: danke
[12:38] <xnox> that should help with parted transition.
=== MacSlow|lunch is now known as MacSlow
[12:59] <pitti> slangasek: pressed the big red ddeb button; *phew*
[13:13] <seb128> barry, hey, why did you change my patch pilot schedule for tomorrow?
[13:14] <barry> seb128: um, what?
[13:14] <seb128> barry, just got an email
[13:15] <barry> seb128: how weird!  i haven't touched the pp calendar.
[13:15] <seb128> barry, from google calendar, say you changed my patch pilot invitation for wed jul 23
[13:15] <seb128> saying
[13:15] <seb128> barry, that's the patch pilot schedule I think
[13:15] <barry> seb128: that's mysterious ;)
[13:16] <seb128> yet happened, fwded you the email in case you don't believe me
[13:16] <seb128> barry, didrocks mentioned recently you edit his as well
[13:16] <seb128> barry, I wonder if your workflow is doing thing you don't expect or something?
[13:16] <barry> seb128: oh, i believe you got the email
[13:17] <barry> seb128: like, every time i upload a package, someone's patch pilot gets changed? :)
[13:17] <seb128> lol
[13:18] <seb128> you didn't open google calendar?
[13:18] <seb128> k, dunno what that happened then
[13:18] <seb128> but I would like to know what changed
[13:18] <seb128> like was I scheduled for tomorrow, or did you just move the invitation to another day?
[13:18] <barry> seb128: i see the email.  i have no clue why that's coming from me!
[13:18] <barry> seb128: i only opened my canonical calendar when you pinged me, but that would violate causality
[13:19] <seb128> k, dunno what happened then :/
[13:19] <seb128> strange
[13:19] <barry> me neither!  i guess dholbach isn't around.  i think he owns that calendar
[13:20] <barry> seb128: i'll forward that to him and cc you
[13:23] <seb128> barry, thanks
[13:26] <xnox> infinity: pkg-util-linux ftbfs on i386
[13:29] <cjwatson> xnox: lava-dispatcher> oh, thanks, I was going to look at that once I was back off 3G tethering
[13:34] <xnox> cjwatson: isp bonding in progress?
[13:34] <xnox> =)
[13:34] <cjwatson> xnox: No, disk trouble on my router
[13:34] <cjwatson> It never rains but it pours
[13:34] <cjwatson> The actual ADSL line is fine :)
=== lisca is now known as diskzokej
[13:37] <ogra_> cjwatson, SES Astra offers pretty cheap 20MBit sattelite lines in germany recently ... i wonder if they have something similar for the UK
[13:38] <xnox> shadeslayer: cjwatson: ubiquity upload has a strange dep change. "s/python3-dbus/python2-dbus" on ubiquity-frontend-kde. What's up with that, shadeslayer ?
[13:38] <xnox> should I fix it?
[13:45] <juliank> ogra_: cjwatson: See http://uk.ses-broadband.com/10390967/uk
[13:45] <cjwatson> xnox: I completely missed that.  Looks like a typo.  Please fix
[13:45] <cjwatson> ogra_,juliank: No thanks, just switched ISP and not in a rush to have any more hassle
[13:46] <ogra_> juliank, heh, in germany they actually founded a sub-company https://www.orbitcom.de/shop/astra-connect-xxl.html
[13:46] <xnox> juliank: satelite is crap uplink, no?!
[13:46] <juliank> xnox: 2 mbit/s uplink.
[13:46] <juliank> But you can get much faster offerings
[13:46] <cjwatson> And my trouble today has nothing to do with my ADSL anyway
[13:46]  * xnox likes to upload tarballs & binaries into debian.....
[13:46] <juliank> symmetrical elsewhere
[13:47] <mlankhorst> xnox: with debug symbols :-D
[13:47] <ogra_> xnox, well, i would keep the DSL i have and use the sat as a cheap download line :) the latency is surely awful
[13:48] <ogra_> but 20MBit vs 2MBit DSL that i can get here without replacing the whole wiring of the house ;)
[13:49] <xnox> juliank: ogra_: i have 120 MBit / 20 MBit at the moment with Virgin media cable.
[13:49] <ogra_> lucky you
[13:49] <juliank> I have 10/10 at university town home and 16/1 at parent home
[13:49]  * ogra_ pays a fortune for a 2MBit SDSL line ... the fastest i can get in this house 
[13:52] <cjwatson> xnox: Looks like fixing ubiquity should be the last piece of the parted transition, indeed
[13:58] <xnox> uploaded.
=== kentb-out is now known as kentb
[14:01] <cjwatson> thanks!
[14:02] <juliank> ogra_: Get Sat internet then. 20 down / 6 up at http://www.skydsl.eu/de-DE/Satelliten-Internet/tariff/skydsl2p/sky2pt8
[14:03] <juliank> Using Eutelsat, not Astra.
[14:03] <ogra_> that means i need a second dish i guess
[14:03] <ogra_> i already have a TV dish pointing to astra
[14:04] <juliank> ogra_: You should be able to use a single dish. If less upstream is OK, get an SES Astra one.
[14:04] <shadeslayer> xnox: not my doing
[14:04] <juliank> You can usually reach both Eutelsat and Astra with a single dish
[14:04] <ogra_> well, we'll see :)
[14:05] <juliank> ogra_: SkyDSL is a bit expensive, but is a real flatrate, the Astra Connect stuff had traffic limits.
[14:05] <ogra_> juliank, not the XXL offer
[14:05] <ogra_> thats flat for 69€
[14:05] <juliank> Ah cool
[14:05] <xnox> shadeslayer: is this not your commit? http://bazaar.launchpad.net/~rohangarg/ubiquity/plasma5/revision/6199
[14:06] <ogra_> and i doubt i actually want to do uploads via sat :)
[14:06] <juliank> ogra_: Why?
[14:06] <ogra_> dunno ... latency ?
[14:06] <juliank> Sky DSL only costs 60€ after 12 months have passed, BTW.
[14:06] <ogra_> do you have any first hand experience with it ?
[14:07] <juliank> ogra_: But that does not matter for package uploads :)
[14:07] <ogra_> indeed
[14:07]  * juliank only had a 1-way downstream sat connection (upstream via 56k modem). No idea about the bi-directional stuff.
[14:09] <juliank> ogra_: Latency is about 700ms according to SkyDSL
[14:14] <shadeslayer> xnox: oh uh
[14:14] <shadeslayer> how did that happen 0.o
[14:14] <arges> cjwatson: hey today's my sru day, are there any freezes I should be aware of before reviewing the upload queue?
[14:17] <cjwatson> arges: coordinate with infinity
[14:18] <arges> cjwatson: ok
[14:18] <cjwatson> arges: you probably at least want to be pretty careful about trusty
[14:19] <arges> I figured as much; infinity anything that would be constructive for me to review in the trusty upload queue or pending SRUs?
[14:30] <stokachu> stgraber, ive run into a weird issue with lxc -- sudo lxc-create -t ubuntu -n maas -- --packages maas,maas-dns,maas-dhcp fails where as running apt-get install after lxc creation allows maas to install
[14:31] <flexiondotorg> cjwatson, Can I ask you a quick question about live-build?
[14:31] <stokachu> stgraber, http://paste.ubuntu.com/7832005/
[14:31] <cjwatson> flexiondotorg: just ask, don't ask to ask :)
[14:31] <stokachu> stgraber, you seen anything like that before?
[14:32] <flexiondotorg> I'm working on Ubuntu MATE Remix. I'm using the following script to make to iso images.
[14:32] <flexiondotorg> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-iso/view/head:/build-ubuntu-iso
[14:32] <flexiondotorg> The resulting .iso is missing to pool and dist directories that I see in the official flavours.
[14:32] <flexiondotorg> Is there a way to enable/mimic that behaviour?
[14:33] <ogra_> not easily
[14:33] <ogra_> Laney, wasnt that your script initially ? ^^^
[14:33] <ogra_> (iirc popey based on it)
[14:33] <Laney> umm
[14:33] <flexiondotorg> It is adapted from a script by Laney
[14:34] <Laney> I can't really provide support for that
[14:34] <cjwatson> flexiondotorg: live-build has some features a bit like that (dpkg -L live-build | xargs grep -s pool), but we only use live-build to build the actual squashfs, we don't use it for the whole thing
[14:34] <flexiondotorg> cjwatson, Yeah so I've seen.
[14:34] <cjwatson> we use lp:ubuntu-cdimage plus the various other bits listed in configs/devel there to put the top-level ISO stuff together
[14:34] <flexiondotorg> I've read  lp:ubuntu-cdimage
[14:35] <ogra_> why not simply start working on making it a real flavour
[14:35] <cjwatson> I guess you might be able to do something with config/package-lists/ in live-build, but I have no idea really
[14:35] <flexiondotorg> I'm just trying to mimic the official iso image as much as posisble while we are not an official remix.
[14:35] <ogra_> thats most likely easier than trying to get cdimage/debian-cd to work with the script
[14:35] <flexiondotorg> OK, that is a useful pointer.
[14:35] <cjwatson> Right, ubuntu-mate seems like the kind of thing that might be on a relatively short path to being official if you asked
[14:35] <ogra_> yeah
[14:36] <flexiondotorg> cjwatson, We do want official status.
[14:36] <flexiondotorg> I just wanted to get all the initial work completed up front to ease the merge.
[14:36] <flexiondotorg> I'm about there.
[14:36] <ogra_> flexiondotorg, but proper builds :)
[14:36] <cjwatson> I wouldn't worry about this part of it for that purpose
[14:36] <cjwatson> Certainly not if it's going to involve a ton of duplicated work
[14:37] <ogra_> flexiondotorg, we have ubuntu-desktop-next ... thats probably years from being something official ... and still we build daily images for it
[14:37] <cjwatson> I mean, it absolutely is possible to set up cdimage locally, all the code is public, but it involves things like a full mirror
[14:37] <flexiondotorg> ogra_, I really want to benefit from the official builds. I've had to get EFI and SecureBoot without access to either hardware.
[14:37] <cjwatson> It's a pain
[14:38] <cjwatson> So while I'm happy to help if that's what you actually need, I'd prefer to only go through that for things that can't be official RSN
[14:38] <flexiondotorg> cjwatson, I did review your code. But decided it wasn't worth the effort in re-implementing it utside the official infrastructure.
[14:39] <flexiondotorg> cjwatson, Not sure I follow. But what I'd like to do is merge my livecd-rootfs changes (minimal) , seeds and meta-packages so that Ubuntu MATE could be built officially.
[14:39] <flexiondotorg> Is that something that is possible without going through all the "official flavour" process?
[14:41] <cjwatson> Sure
[14:41] <flexiondotorg> That would be great.
[14:41] <ogra_> we have a process for that ?
[14:41] <cjwatson> unhelpful
[14:41] <ogra_> just curious
[14:41] <cjwatson> it may not be written down clearly but there is certainly a process (as in series of steps)
[14:42] <ogra_> i thought having a seed and building from the archive would be enough
[14:42] <flexiondotorg> cjwatson, Is that something you can share so I can start the process?
[14:42] <cjwatson> it would normally involve talking to the tech board
[14:42] <cjwatson> feel free to CC me (cjwatson@u.c)
[14:42] <flexiondotorg> cjwatson, Can I do that or do I need a "sponsor"?
[14:42] <cjwatson> And https://wiki.ubuntu.com/RecognizedFlavors
[14:43] <cjwatson> flexiondotorg: whoever's the project lead ought to do it; you're going to want people who can actually upload stuff directly as soon as possible
[14:43] <flexiondotorg> cjwatson, Thanks. I am the project lead.
[14:43] <slangasek> pitti: ah, so the ddeb-retriever update is deployed now? \o/  Sorry for not making any progress on this on Friday for you, ran out of time :(
[14:44] <pitti> slangasek: yes, it is (I kept a backup of the old files too, just to be sure)
=== Sweetsha1k is now known as Sweetshark
[15:33] <apachelogger> mvo_: we've just been wondering... is there a reason apt-xapian-index doesn't register a APT::Update::Post-Invoke-Success hook to update the database?
[15:34] <mvo_> apachelogger: the only reason that its expensive to run and would make each apt-get update very slow (and even rebuilding in the background is a bit anoying as it tends to consume quite a bit of io/cpu)
[15:36] <apachelogger> mvo_: aren't incremental updates relatively fast? the thing is... currently all kde software using libqapt needs to explicitly update the database which is highly annoying and causes unintended side effects when someone forgets to do that, so we've been wondering about how to remove the requirement globally
[15:37] <mvo_> apachelogger: they are sort of fast, we had problems in the past with corruption though, this is iirc why the --update part got disabled
[15:37] <mvo_> apachelogger: might be worthwhile to see if that is still a sissue
[15:39] <apachelogger> mvo_: thanks, I'll put down a todo to look into this in detail
[15:39] <mvo_> thanks
[15:45] <bdmurray> pitti: I've seen a few cases where an apport retraced crash does not have a Stacktrace in it. Would we need the CoreDump to definitively sort out what happened?
[15:56] <pitti> bdmurray: yes, I think it would certainly be helpful for debugging the underlying gdb problem
[15:57] <bdmurray> pitti: okay, so this is insufficient? https://pastebin.canonical.com/113960/
[15:57] <pitti> infinity, kees, slangasek, mdeslaur: TB meeting in 3 mins reminder
[15:57] <mdeslaur> pitti: ack
[15:58] <slangasek> pitti: yes; I have conflicting meetings, I'm afraid I have to send my regrets
[15:58] <pitti> bdmurray: fun, that has a StacktraceTop, so it shoudl have had a Stacktrace, too
[15:58] <pitti> slangasek: noted
[15:58] <kees> pitti: thanks!
[15:59] <pitti> bdmurray: could also be funny characters/breaks/etc. which confuse the parsing of the stack trace (but I wouldn't know without seeing the original raw gdb output :/)
[16:00] <bdmurray> pitti: okay, I'll work on saving the CoreDumps then
[16:00] <pitti> bdmurray: is this a "sun ray glitch" thing, or did you see this more often?
[16:05] <bdmurray> pitti: looking at the statsd counters for this there is a very low volume, so I think I'll file a bug for some day later
[16:08] <pitti> bdmurray, jibel: btw, I haven't yet had time to look into/respond to the retracing armhf thread, will do ASAP
[16:08]  * pitti has been stuck with other high-prio things, sorry
[16:09] <bdmurray> pitti: a fair number of things are retracing - https://errors.ubuntu.com/?release=Ubuntu%2014.10&period=day&pkg_arch=armhf
[16:10] <infinity> pitti: Gah.  Not even remotely paying attention to things like meeting reminders.
[16:10] <pitti> infinity: it's just over; you still have a carried "review/reply to juju MRE proposal"
[16:11] <infinity> pitti: Right, I didn't do that, so carried it is.  Sorry about the no-show.
[16:11] <pitti> infinity: no worries
[16:11]  * pitti waves good night
[16:13] <pitti> bdmurray: hm, I can't click on any of these errors, I always get the "computer over" fail page; so these are all ok?
[16:14] <pitti> bdmurray: ah, some work
[16:14] <pitti> bdmurray: but e. g. https://errors.ubuntu.com/oops/94734414-1180-11e4-8bdd-fa163e78b027 failed to retrace
[16:14] <pitti> bdmurray: none of these show "stacktrace", for privacy reasons I suppose?
[16:15] <pitti> ah no, e. g. https://errors.ubuntu.com/problem/eb8fe775c22d5210f56ad7ac038ac1b1895f4465 is just fine
[16:15] <pitti> bdmurray: so that part was (hopefully) due to the broken gdb-multiarch, and should be fixed now
[16:15] <pitti> anyway, tomorrow; it's been too long today
[16:15]  * pitti waves
=== timrc-afk is now known as timrc
=== roadmr is now known as roadmr_afk
=== hallyn_ is now known as hallyn
=== roaksoax_ is now known as roaksoax
=== wedgwood is now known as Guest45740
=== timrc is now known as timrc-afk
=== roadmr_afk is now known as roadmr
[20:20] <Pici> Is /36
=== timrc-afk is now known as timrc
=== salem_ is now known as _salem
[22:38] <achiang> hallyn: hey, i'm experimenting with something in lxc and i'd like to do something i know is dangerous... how do i grant permission to /proc?
[22:38] <achiang> Cannot chdir into /proc/ directory: Permission denied
=== timrc is now known as timrc-afk
[22:40] <elopio> hello
[22:40] <elopio> is there a core dev around to review the packaging changes in this branch?
[22:40] <elopio> https://code.launchpad.net/~canonical-platform-qa/url-dispatcher/fake_dispatcher/+merge/227778
[22:41] <hallyn> achiang: ?  you should be able to cd into /proc....
[22:42] <achiang> hallyn: hm, maybe my problem is something else... i'm attempting to run our own webbrowser-app in a container
[22:42] <hallyn> achiang: edit /etc/apparmor.d/abstractions/lxc/container-base
[22:42] <achiang> hallyn: and we essentially have a thin layer over the blink runtime.
[22:42] <achiang> hallyn: i notice from here that we start chrome with --disable-setuid-sandbox - https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
[22:43] <achiang> so maybe our webbrowser-app (oxide) has the same issue
[22:43] <hallyn> yeah, i'm running it like that
[22:43] <cjwatson> elopio: looks fine to me as long as the resulting url-dispatcher-testability binary package only contains python3 modules
[22:43] <cjwatson> elopio: actually don't you want ${python3:Depends} in url-dispatcher-testability too?
[22:43] <achiang> hallyn: "running it like that" -- what is "it" ?
[22:43] <hallyn> chrome instide a container following stgraber's instructions :)
[22:44] <hallyn> the rason to disable seccomp is bc by default we now have the container already inside seccomp
[22:44] <achiang> hallyn: ah. well maybe oxide doesn't respect that cmdline arg yet
[22:45] <cjwatson> elopio: I would generally include ${python3:Depends} in the dependencies of packages shipping python3 modules even if it doesn't expand to anything at that point
[22:45] <elopio> cjwatson: right, the packaging guid of python3 mentions that.
[22:45] <hallyn> achiang: anyway yes, if you just set lxc.aa_profile = unconfined you should have full access to /proc
[22:45] <elopio> cjwatson: can I add it in a following branch? This is not my branch, and I wouldn't like to delay it more.
[22:45] <hallyn> if htat works, then from there you can write a policy that works for you
[22:45] <achiang> hallyn: where do i set that? in the file you pointed me at above?
[22:45] <hallyn> (lemme know if you need help wit htat)
[22:45] <hallyn> no, in the contaienr configuration file
[22:45] <hallyn> .local/share/lxc/u1/config or /var/lib/lxc/u1/config
[22:45] <cjwatson> elopio: I'd rather it went in this branch, seeing that this is likely to have to wait for silo 8 to get sorted out anyway
[22:46] <achiang> hallyn: ok, i have that...
[22:46] <cjwatson> elopio: as a matter of form I don't think it's good to pressure people into giving acks
[22:46] <achiang> hallyn: well, i have lots of things in there.
[22:46] <elopio> cjwatson: ok, I'll tell brendan to update it.
[22:47] <cjwatson> the point of getting core-dev acks on things is to fix the packaging before it lands so fixes aren't forgotten :)
[22:47] <cjwatson> thanks
[22:47] <elopio> cjwatson: sorry, I didn't understand that last message.
[22:47] <elopio> oh, yes, you are right.
[22:47] <hallyn> achiang: not sure what you mean.  lots of things in that file?
[22:47] <achiang> hallyn: this is my config for the container - http://pastebin.ubuntu.com/7838928/
[22:47] <cjwatson> elopio: if you can verify that it makes no difference to the generated dependencies either way, then I'd be OK with fixing it in a follow-up
[22:47] <hallyn> achiang: looks good
[22:48] <hallyn> fire it up
[22:48] <achiang> hallyn: and this is my default.conf - http://pastebin.ubuntu.com/7838930/
[22:48] <elopio> cjwatson: no, I think you are right. Better to get it as good as possible on this branch. I thought this would auto-land, but it goes through a silo, so we wouldn't be delaying anything.
[22:48] <hallyn> achiang: you're saying it was already like that?
[22:49] <elopio> actually, I can push to this branch.
[22:49] <achiang> hallyn: i just made those edits, stopped the container, and restarted it... now getting - http://pastebin.ubuntu.com/7838936/
[22:49] <elopio> would it be bad manners to modify somebody else's branch?
[22:50] <cjwatson> if you can commit to it I don't see why it's bad
[22:50] <cjwatson> presumably it's team-owned for a reason
[22:50] <cjwatson> elopio: yeah, silo not yet assigned and we only have one free right now, would prefer to reserve that for emergencies in any event ...
[22:51] <cjwatson> (silly system, but)
[22:51] <hallyn> achiang: strace the app
[22:56] <elopio> cjwatson: ok, pushed.
[22:58] <achiang> hallyn: huh. kinda interesting - http://pastebin.ubuntu.com/7838964/
[22:59] <cjwatson> elopio: thanks, looks good to me
[23:00] <elopio> thanks to you.
[23:00] <elopio> this is nice :D the testability packages are making me happy.
[23:00] <hallyn> achiang: hm, I suppose try "sudo strace -f -ff -u ubuntu -o oxide webbrowser-app"
[23:02] <achiang> hallyn: neat - http://pastebin.ubuntu.com/7838978/
[23:02] <hallyn> haha
[23:03] <hallyn> achiang: ok, well can you "cd /proc" ?
[23:03] <slangasek> hallyn: hmm, so why is cgmanager no longer in the Debian NEW queue, nor in Debian unstable?
[23:03] <achiang> hallyn: yes
[23:03] <hallyn> slangasek: well, dba raised a stink;
[23:04] <achiang> hallyn: http://pastebin.ubuntu.com/7838982/
[23:04] <hallyn> slangasek: there's a trail both in the ITP and in private emails including the debian ftp admins
[23:04] <hallyn> slangasek: short story is dba is supposed to push a new version based on my 0.28 upstream.  he said he'd do that last friday.
[23:05] <hallyn> uh, i think it was last friday.  anyway, this morning he said he'd upload today
[23:05] <slangasek> hallyn: um.  so on what grounds was your package rejected from the NEW queue?  Or dba's package, for that matter?
[23:05] <hallyn> i can fwd you some amusing emails if you like.  i also asked him in private (after he pmd me) if there was any advantage to his packaging;  no answer to that.
[23:06] <hallyn> on the grounds that there was conflict.  I was seen as usurping his submission.
[23:06] <hallyn> so ftpadmin (paultag) dropped both
[23:06] <hallyn> said for us to work out out
[23:06] <hallyn> my only complaint in all this is,
[23:06] <hallyn> at teh same time they take months to accept NEW packages, while they complained that we pushed cgmanager to ubuntu without waiting for debian
[23:06] <slangasek> ok
[23:06] <hallyn> (paultag did)
[23:07] <infinity> Working things out with dba is often entertaining.  Good luck.
[23:07] <hallyn> i like teh guy, but that stance was annoying
[23:07] <slangasek> I think I'll be taking that up with paultag, because I don't consider that grounds for a reject ;)
[23:07] <hallyn> as i told dba in private, i dont' give a rats ass who maintains the package, but if he doesn't have time, why the hell push this way?
[23:08] <hallyn> (that is, i don't care about me being the maintainer;  but i do care taht someone i can work with maintains it)
[23:08] <hallyn> anyway.  achiang - i'm perplexed.
[23:08] <hallyn> oh.
=== timrc-afk is now known as timrc
[23:09] <hallyn> achiang: you showed me a grep.  can you pastebin the full strace output?
[23:09] <achiang> hallyn: oh erm... there are lots of files.
[23:09] <hallyn> achiang: drop -ff and rerun?
[23:09] <hallyn> should then all go to one file
[23:09] <achiang> hallyn: i'll pastebin the one with the chdir
[23:09] <hallyn> (re-run with new filename else it'll append :)
[23:09] <hallyn> well i need to follow all the creds changes
[23:10] <hallyn> slangasek: I assuem you're saying there is not yet a new cgmanager in NEW?
[23:10] <hallyn> that makes me sad
[23:10] <achiang> hallyn: ok
[23:10] <slangasek> hallyn: there is not
[23:12] <achiang> hallyn: giant pastebin - http://pastebin.ubuntu.com/7839005/
[23:15] <hallyn> achiang: ah, thanks.  looking
[23:18] <hallyn> two instances of 7979  prctl(PR_SET_NO_NEW_PRIVS, 0x1, 0, 0, 0) = 0
[23:20] <hallyn> and 7979  prctl(PR_SET_SECCOMP, 0x2, 0x7fffbe55f810, 0xffffffffffffffff, 0) = 0
[23:21] <hallyn> achiang: can you grep -i seccomp /proc/self/status int he container?
[23:21] <hallyn> both tasks 7979 and 7989 tried to set NNP, then set seccomp filters, then exited with 7979  +++ exited with 100 +++
[23:23] <achiang> $ grep -i seccomp /proc/self/status
[23:23] <achiang> Seccomp:	0
[23:26] <hallyn> hm
[23:26] <hallyn> and i assume this works outside of a container?
[23:27] <achiang> hallyn: well... kinda. i at least get a window that pops up on my desktop (although it is blank)
[23:27] <achiang> hallyn: that would be running outside the container on a trusty host
[23:27] <achiang> just running the trusty version of webbrowser-app from the cmdline
[23:29] <hallyn> achiang: so if you strace it on the host, what happens after the PR_SET_SECCOMP ?
[23:29] <achiang> is anyone running utopic natively? perhaps they could just try to launch webbrowser-app from the cmdline and see if that works
[23:32] <achiang> hallyn: http://pastebin.ubuntu.com/7839069/
[23:34] <achiang> hallyn: i'd say don't worry about spending more time on me today. i'll send a mail to chrisccoulson asking for some help... it could be as easy as supporting the same --disable-setuid-sandbox for oxide
[23:35] <achiang> hallyn: thanks a ton already
[23:39] <hallyn> achiang: my utopic laptop is the one that died recently;  so i'm not until my new one arrives.  lenovo keeps pushing the ship date back day by day :)
[23:39] <achiang> nice