[06:41] <pitti> Good morning
[06:42] <pitti> bdmurray: darn, it got its core dump removed already; but I'll look for a few apport-failed-retrace armhf bugs
[06:45] <pitti> infinity: I don't think that putting upstream changelogs into any .deb is making good use of storage space and download bandwidth; but for -doc packages I'm okay with letting them back in
[06:53] <infinity> pitti: Well, in the case of glibc-doc, the upstream changelogs are intentionally included as part of documenting the package.
[06:53] <infinity> pitti: I don't feel particularly strongly about it, mind you.
[06:54] <infinity> pitti: (I only noticed because of a lintian warning in Debian about the upstream changelog having a non-conforming name, and then noticed we don't ship it at all in Ubuntu) :P
[07:48] <dholbach> good morning
[07:58] <ion> that
[11:28] <ogra> wow, seems Laney had a busy weekend
[11:28] <Laney> heh
[11:28] <Laney> scripts are powerful things :P
[11:32] <ogra> W:Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources  406  Not Acceptable
[11:32] <ogra> *sigh*
[11:32] <ogra> why the heck do i randomly see 406 errors since last week
[11:39] <ogra> oh
[11:40] <ogra> http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources actually tells me there is no uncompressed file named "Sources", there are .gz and .bz2 variants though ... do we have an apt bug ?
[11:40] <cjwatson> Always been that way
[11:40] <ogra> hmm, why does apt try to download the uncompressed file then
[11:41] <cjwatson> I think the URL in the error is just misleading
[11:41] <cjwatson> strace or tcpdump or whatever if you want to see what it's actually doing
[11:41] <ogra> well, the url actually gives me an apache error page
[11:41] <ogra> "Not Acceptable"
[11:41] <cjwatson> Sure, but I doubt that's the URL it actually got the root-cause error from
[11:41] <ogra> pointing out that there are gz and bz2 files of this file available
[11:41] <cjwatson> Like I say, get a proper trace rather than relying on that error message
[11:42] <cjwatson> Because it was probably a knock-on error from something else
[11:42] <cjwatson> (Yes, it might have got some other error, tried to fall back to the uncompressed variant, and then got 406 - but that just means the 406 is hiding some real error behind it)
[11:44] <ogra> ok, server side i can at least grab the gz and bz2 files manually so yeah, your theory sounds right
[11:44]  * ogra wonders why his 12.04 desktop feels so much more buggy than raring in so many areas
[11:47] <ogra> (screen locking doesnt work properly, update-manager is undiscoverable once it auto-started and sits in your launcher (you can click it doesnt come up) ... and now since mid last week this apt issue))
[11:48] <ogra> oh, and we should consider ripping the weather indicator out of precise if nobody fixes it
[11:53] <Laney> it's had several SRUs
[11:55] <sladen> ogra: then people would just go back to using windows
[11:55] <ogra> Laney, none that fixed anything (at least for me)
[11:57] <ogra> it reliably crashes after about a day
[11:57] <ogra> stat("/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_raring_main_source_Sources", {st_mode=S_IFREG|0644, st_size=4104933, ...}) = 0
[11:57] <ogra> write(1, "\r                               "..., 214) = 214
[11:57] <ogra> write(16, "600 URI Acquire\nURI: http://de.a"..., 546) = 546
[11:57] <ogra> hmpf
[11:57] <ogra> is there any way to see the full URL here in strace ?
[11:58] <ion> -s10000
[12:00] <ogra> hmm, intresting, with that it hangs with "Waiting for headers" at some point at the end
[12:01] <ogra> ah, there we go ... it hung for nearly 2min
[12:05]  * cjwatson scratches his head
[12:05] <cjwatson> jdstrand: Do you know how chromium-browser got from raring-proposed to raring?  The proposed-migration logs don't mention it anywhere, and it seems to have been done slightly incorrectly (i.e. left in -proposed)
[12:05] <cjwatson> And +publishinghistory doesn't say who copied it, which is weird
[12:09] <Laney> Does it usually? I thought that it only shows the user for deletes
[12:09] <Laney> From: in -changes is the copier AFAIK
[12:11] <cjwatson> Laney: I fixed +publishinghistory to show the copying user back in August
[12:11] <cjwatson> But yes, raring-changes shows it copied manually by jdstrand
[12:11] <cjwatson> jdstrand: Please don't ever do this
[12:12] <cjwatson> If you find you need to, (a) you're probably hiding a problem somewhere else, (b) there are other ways to do it (britney hints)
[12:12] <cjwatson> (I suspect perhaps my +publishinghistory fix only shows the copier when the publication record was copied from another distribution)
[12:13] <Laney> The one I was looking at was an SRU, so that would match
[12:13] <cjwatson> jdstrand: Did you check update_excuses before doing the copy?
[12:14] <cjwatson> Unfortunately we don't log that so I can't retroactively check what might now be uninstallable as a result of the copy
[12:14] <zequence> Hi, I'd like a bit of help regarding a SRU. bug 956438. I've got a branch of jackd2 whcih fixes a bug in quantal and precise, which I would like to get uploaded to proposed. I've followed all the procedures from what I can see.
[12:16] <zequence> I've got testing packages (still building) at ppa:zequence/sru
[12:17] <zequence> My branch is this lp:~zequence/ubuntu/raring/jackd2/fix-for-956438
[12:21] <zequence> ah, I see ScottK was doing some work on the bug
[13:23] <jdstrand> cjwatson: hi
[13:25] <jdstrand> cjwatson: I did do the copy, yes. chromium-browser was rather horribly out of date on raring and while the armhf patches are being worked on, I decided that it was more important for our i386 and amd64 users to have the security update, and then to have the armhf fix uploaded soon
[13:26] <cjwatson> jdstrand: If you're going to do such things, please do them by the medium of britney hints, not by manual copies to the development release
[13:26] <cjwatson> Ah, you're not in ~ubuntu-release, so you'll need to get a member of that team to do it
[13:27] <jdstrand> cjwatson: I was unware of britney hints, and I don't see it documented in ArchiveAdministration. can you point me to how to do this?
[13:27] <cjwatson> jdstrand: Archive admins technically still can copy to raring, but must not
[13:27] <cjwatson> jdstrand: you'll have to get one of the release team to do it, but plenty of us are around at all kinds of strange hours ...
[13:28] <jdstrand> I don't plan on doing this regularly or anything-- I didn't know it was a horrible no no. I knew armhf was broken, and I figured we'd got an out of date for it , which would be fixed soon. I figured the security update for rariing was more important than that line item
[13:29] <jdstrand> I'm sorry if it caused a problem
[13:29] <cjwatson> It's bad because we have no way to track what it broke
[13:30] <cjwatson> With britney hints, you can override specific things ("OK, I understand that excuses says that this is wrong, but try the update anyway") and still have checks for other things
[13:30] <cjwatson> And it gives us a record in bzr of what's been done manually
[13:30] <cjwatson> In general since we have this mechanism available we shouldn't bypass it
[13:30] <jdstrand> cjwatson: can you add something to ArchiveAdminstration stating something appropriate for archive admins? I would, but probably wouldn't be able to convey what you would want me to
[13:31] <cjwatson> Well - this kind of copy isn't documented at all in ArchiveAdministration right now
[13:31] <cjwatson> So it's hard to find something to attach it to
[13:32] <jdstrand> I was thinking conceptually it wasn't any different than copying from -proposed to -updates
[13:32] <cjwatson> That isn't owned by a mechanism
[13:32] <cjwatson> So it's quite different
[13:32] <jdstrand> I'm not saying I was right, just that it seemed the same
[13:32] <jdstrand> or rather, similar
[13:33] <jdstrand> hey, my wrist was slapped (sorry) and I won't do it again. I'm just saying I didn't know I should not and that documenting it might help someone in the future
[13:36] <jdstrand> (well, I knew I shouldn't generally, but I didn't know that an aa wasn't allowed to do what I did in exceptional cases)
[13:36] <cjwatson> jdstrand: How about https://wiki.ubuntu.com/ArchiveAdministration#Other_copies ?
[13:37] <jdstrand> cjwatson: I think that works very well. thanks
[13:38] <cjwatson> Thanks - I was mostly surprised because I thought I had disseminated this information, but it's possible I only did so by IRC, which wouldn't be atypical for me :-)
[13:38]  * ogra sets up a mail redirect for all the ARM whiners to jdstrand's inbox
[13:38] <jdstrand> ogra: they are no worse off than before. the patches are actively be worked on :)
[13:39]  * jdstrand redirects the redirect to chromium devs
[13:39] <ogra> well, curerent chromium trashes all my arm desktops anyway (likely due to an incompatible cairo it ships)
[13:40] <ogra> cant be worse ... but we have a lot of people complaining since a while
[13:40] <jdstrand> ogra: if he doesn't already know, you might let chad know about that
[13:41] <ogra> jdstrand, well, what we have is horridly outdated anyway  and only broken like this in raring atm (wehich will soon get updated)
[13:41] <jdstrand> right, so hopefully once the new one is working, maybe it'll be fixed
[13:41] <ogra> if it still shows after the update i'll talk to him
[13:41] <jdstrand> fair enough. fyi, chad from the desktop team is your man
[13:41] <jdstrand> cool
[13:42] <ogra> (you can easily try on a nexus7 btw, after a while all fonts get corrupted)
[13:46] <test___> a dev told me to ping him on IRC because of a bug (he gave me his username and said on freenode. Please forgive me the stupid question but how to ping someone, if i do not know the channel?
[13:47] <mjt> test___: /msg somewhere sometest
[13:47] <mjt> someONE not someWHERE ofcourse
[13:48] <test___> mjt ist it possible to do this with http://webchat.freenode.net/
[13:48] <mjt> oh no idea.
[13:48] <mjt> i never used webchat
[13:48] <test___> what client to use on ubuntu?
[13:48] <ogra> test___,  you usually just type: <nickname> ping
[13:49] <mjt> if he's in the channel
[13:49] <ogra> directly messaging someone without asking first is usually considered kind of rude
[13:49] <mjt> yesterdays talk is more or less an agreement in this case
[13:50] <test___> orga, he asked me to do so ...  i do not know the channel, just the username and freenode
[13:50] <ogra> he said to ping him
[13:50] <ogra> and if he is an ubuntu dev he is most likely around here
[13:58] <infinity> ogra: I'm not sure which culture that "ask me in public if you can ask me in private" thing came from, but some of us find it irritating. :P
[13:59] <infinity> ogra: It's like asking if you can ask a question.  You've just wasted my time with something completely devoid of content.
[13:59] <infinity> (Now, public *questions* are better than private, cause someone else might jump in and answer, but if I ask someone to poke me, I actually prefer a direct query, easier to track)
[13:59] <ogra> infinity, well, i tend to ignore unasked pings (especially if the content just says "ping" without any question)
[14:00] <infinity> ogra: I only get completely contentless pings from people I work with.  *cough*
[14:00] <infinity> ogra: Community people are, on the whole, much better about braindumping at me in query windows.
[14:00] <ogra> heh
[14:00] <test___> okay i installed xchat and user "/msg someone test , but how can i be sure this user exists?
[14:00] <ogra> lucky you
[14:01] <infinity> test___: It should whine at you if you tried to send a /msg to no one.
[14:02] <cjwatson> Yeah, in particular the "ask me in public if you can ask me in private" thing often enough causes me to have to catch up on scrollback in some window just to find out that it lit up due to somebody who could just have queried me directly
[14:02] <cjwatson> (OK, this is a slight artifact of the way I read IRC, but still)
[14:03] <test___> it does not, i tried many random names, which cannot exist all for sure
[14:03] <infinity> cjwatson: I suspect you and I IRC very similarly. :P
[14:03] <ogra> test___, check the server tab in xchat
[14:04] <ogra> server error messages usually show up there
[14:04] <infinity> ogra: I don't use xchat, but I assume it would have opened a query tab with the user he was /msging, if it had worked, no?
[14:04] <ogra> yes
[14:04] <ogra> but it wont print errors in there
[14:04] <infinity> No, but you'd also have no tab.
[14:05] <infinity> Which is, itself, an indication of an error. :P
[14:05] <ogra> err, /msg doesnt open a tab anyway
[14:05] <ogra> i think thats /query
[14:06] <ogra>  /query ogra12345 foo
[14:06] <ogra> that properly opens an empty tab here
[14:06] <ogra> and the server tab has:
[14:06] <ogra> * ogra12345 :No such nick/channel
[14:06] <infinity> That's... Rather unintuitive.
[14:06] <ogra> thats how xchat handles it
[14:06] <ogra> server msgs go to the server tab
[14:07] <ogra> (i agree though)
[14:07] <infinity> If I chant "abra-cadabra, make me a shawarma", and lack magical skills to actually make sandwiches happen, I don't expect an empty wrapper to appear.
[14:07] <infinity> I want a sandwich, or nothing. :P
[14:07] <infinity> ogra: No, no.  The error going to the server tab is fine, it's the query tab being spawned with no query that's unintuitive, IMO.
[14:07] <ogra> but now you obnly need the sandwich, not the wrapooer anymore :P
[14:08] <ogra> in case you want to take your sandwich with you in the bus
[14:09] <davmor2> ogra: do you get drawing issues with onboard?  for example if I hit the shift button the top of the arrow disappears leaving me with a squared u.
[14:09] <ogra> davmor2, rarely but yes
[14:09] <ogra> lets see how maliit behaves in that regard, it should have entered the archive by now i guess
[14:09]  * ogra didnt check
[14:10] <ogra> its on my plan this week to test maliit integration
[14:13] <scott-work> infinity: do you have a minute to talk about a possible SRU? i wanted some advice before preceeding
[14:14] <infinity> scott-work: Sure, shoot.
[14:15] <davmor2> ogra: also I get really inconsistent keyboard popup on dash home.  First time seems fine but any time after that seems to be a 50-50 chance on it opening.
[14:15] <scott-work> after 12.04 we (ubuntu studio) added a few new metas for publishing and photography. these aren't being picked up during 12.04 -> 12.10 upgrade. we have an idea on fixing this but wasn't sure it was the "proper" way to handle this
[14:15] <scott-work> infinity: oops ^^^
[14:15] <ogra> davmor2, yeah, thats supposed to be fixed in upstream onboard already
[14:16] <scott-work> infinity: our thought was to update the -desktop meta and explicitly include these two metas, but it seemed a little hacky
[14:17] <davmor2> ogra: nice, btw if there is anything you need testing confirming I got my nexus 7 just to play with ubuntu on so feel free to ping me
[14:17] <infinity> scott-work: Well, if you want people to be able to have desktop installed, but remove the other metas, that's not a good solution.
[14:17] <infinity> scott-work: Are they meant to be there on a "default install", but readily removable?
[14:17] <ogra> davmor2, i just uploaded a fix for the sound issue, see if you have sound on boot (still muted, but should work without suspend cycle)
[14:17] <infinity> scott-work: If so, you probably want to quirk the release-upgrader to add them on upgrades.
[14:18] <scott-work> infinity: if possible, that would be prefered
[14:19] <scott-work> infinity: is there any information on how to do this that i can read or an example already being used?
[14:26] <davmor2> ogra: are you using proposed for this other wise I don't have it yet
[14:28] <infinity> scott-work: It might be as simple as adding those packages to PostUpgradeInstall in the [ubuntustudio-desktop] section of data/DistUpgrade.cfg
[14:29] <scott-work> infinity: super cool. i'll dig into that. thank you very much :)
[14:30] <infinity> scott-work: There was a "might" in that sentence for a reason, you'll definitely want to do some testing. :P
[14:31] <scott-work> infinity: oh yeah, i caught that ;)
[14:31] <ogra> davmor2, it was just uploaded, be patient until the next publisher run :)
[14:31] <infinity> scott-work: And doing only that will probably have the unfortunate side effect of reintrodcing those packages after every upgrade (when you really only want it from 12.04 to 12.10 and 12.04 to 14.04), but either that's a wart you can live with, or you get to look at more fine-grained quirking.
[14:32] <infinity> scott-work: (By "every upgrade", I mean between releases, of course, not every single time a user upgrades packages or anything silly like that)
[14:33] <infinity> scott-work: But maybe that's exactly the behaviour you want anyway, so users get reset to a known good state on each dist upgrade (which is sort of one of the primary goals of ubuntu-release-upgrader)
[14:33] <scott-work> infinity: right, right. that seem a very reasonable wart though to make sure these packages are installed upgrading from 12.04 -> 12.10
[14:37] <zequence> infinity: I wonder if it would be possible to add a query about it for the user upgrading the system
[14:38] <infinity> zequence: Anything is possible, I suppose, though release-upgrader currently tries really hard not to ask questions.
[15:17] <dholbach> stgraber, highvoltage: I didn't notice that a regular call of mine was moved permanently - I thought it was a one-off. This would mean we would have to move our hangout either an hour earlier or half an hour later - I'm sorry about that. :-/ Would that still work for you? Or would it have to be another day?
[15:29] <stgraber> dholbach: half an hour later should be fine
[15:29] <dholbach> yeehaw
[15:29] <dholbach> that'll be the last move of this hangout now :)
[15:36] <bdmurray> pitti: did you find armhf crash?
[15:37] <davmor2> ogra: still no sound fix however there are now 2 bluetooth indicators that both work and look different
[15:37] <ogra> intresting, thats a virgin image ?
[15:38] <ogra> i surely dont have that here
[15:38] <ogra> davmor2, rm /var/lib/alsa/asound.state ... reboot and see if sound works then
[15:39] <ogra> (sudo indeed)
[15:40] <Laney> cjwatson: Do I remember correctly that copyPackages doesn't generate -changes emails?
[15:40] <davmor2> ogra: this was a fresh install on friday an then updates over the weekend, I enabled proposed and backports just to pull in your sound fix and that is the only non vanilla part
[15:40] <cjwatson> Laney: Correct
[15:40] <ogra> very strange i dont have two BT indicators here
[15:40] <cjwatson> Indeed that's its purpose
[15:41] <cjwatson> Laney: What are you trying to do, though?  Generally copyPackages should only be used by auto-sync
[15:41] <ogra> though i havent changed my sources.list, using all defaults here
[15:42] <Laney> Considering using it when syncing zillions of a certain class of package at once to avoid being complained at
[15:42] <Laney> Not sure the complaints are justified though
[15:42] <davmor2> ogra: I have one that has 2 switches and one that has a list similar to quantal and precise I'll take a couple of screenshots in a second
[15:43] <cjwatson> Laney: I wouldn't, personally ...
[15:44] <davmor2> ogra: sound fix no in place and working as you say sound is still muted on start up but then is fine after
[15:44] <ogra> davmor2, right, thats known and we already have a better fix, good to know it works though
[15:44] <davmor2> s/no/now
[15:45] <Laney> well I don't consider it a problem. It would be only in the interests of inter-developer harmony
[15:50] <seb128> davmor2, ogra: unity trunk (and the upload from today) recommends the new indicator-bluetooth, that will duplicate the indicator
[15:50] <davmor2> ogra: this http://ubuntuone.com/68vJk5z8TAtGgZJdTuxtQs vs this http://ubuntuone.com/48NahUoCdw6FMvMb26TTUX
[15:51] <ogra> seb128, aaah, thanks !
[15:51] <seb128> davmor2, ogra: I need to drop the old indicator but I was waiting for unity to get upload ... do you guys run unity ppa?
[15:51] <davmor2> seb128: that would do it then
[15:51] <ogra> davmor2, so ignore it ;)
[15:51] <ogra> seb128, no, but unity entered the archive today i think
[15:51] <davmor2> seb128: I don't this was just with proposed and backport enabled
[15:52] <seb128> davmor2, oh, proposed enabled, ok
[15:52] <ogra> if i read that right between all the haskell spam
[15:52] <seb128> ogra, well, it was uploaded 50min ago, that's what I call jumping on updates :p
[15:52] <ogra> haha
[16:01] <davmor2> seb128: to be fair I was trying repeatedly to pull in the update for sound and there were no updates that made me think to add proposed and try again then I got a bunch of update
[16:04] <pitti> bdmurray: sorry, still on my list
[16:05] <cjwatson> davmor2: raring-proposed?
[16:05] <davmor2> cjohnston: yes
[16:05] <cjwatson> davmor2: I really, really don't recommend that even for QA - the point of raring-proposed is to perform automatic checks before humans have to waste their time with things
[16:05] <davmor2> cjwatson: yes even
[16:05] <davmor2> cjohnston: sorry
[16:06] <cjwatson> (And raring-backports is probably empty)
[16:06] <davmor2> cjwatson: indeed I'm going to switch it back off again now :)
[16:16] <xnox> BenC: infinity: how come powerpc is so oversized compared with the rest of desktop images? ubuntu/daily-live: raring-desktop-powerpc.iso oversized by 139128256 bytes (940128256)
[16:28] <cjwatson> tjaalton: Do you know if anyone can verify bug 804109
[16:28] <cjwatson> ?
[16:30] <cjwatson> mterry: Are you able to verify bug 1083237?
[16:30] <mterry> cjohnston, not on my current machine, and I'm in a coffee shop.  But I can tomorrow
[16:31] <mterry> cjwatson, ^ whoops
[16:31] <infinity> xnox: Probably because someone thought that shipping 4 kernels on it would be a swell idea.
[16:31] <cjwatson> Daviey: Can anyone on your team verify that the fix for bug 901600 meets your needs?
[16:32] <Daviey> cjwatson: wilco, thanks
[16:32] <xnox> infinity: =( and no magic to make them smaller / combined (e.g. is stuff for arm kernel consolidation applicable to powerpc at all?!)
[16:32] <infinity> BenC: Do you actually do desktop installs on your server kit?  Is there any value at all in having -e500* on the desktop CDs?
[16:33] <infinity> xnox: ppc/ppc64 obviously can't be combined anymore than i386/amd64 can be, as for the e500 stuff, there are apparently fundamental platform reasons why they can't be a single zImage right now, though I keep forgetting what those reasons are. :/
[16:33] <xnox> fair enough.
[16:34] <xnox> It's just 140MB oversize is excessive....
[16:34] <infinity> (It's a bit ironically tragic, given that PPC has some of the best multi-platform support in the kernel tree)
[16:34] <infinity> (And most of that was cargo-culted for the ARM consolidation)
[16:34] <bdmurray> barry: could you have a look at bug 1112496?
[16:35] <xnox> infinity: might as well build 4x images, since the test matrix has been exploded anyway. (reuse squashfs but add/rm different kernels?!)
[16:35] <infinity> xnox: Ew.  No.
[16:36] <infinity> xnox: If one image can boot on all the hardware, validating 4 images is silly.
[16:36] <infinity> xnox: That said, the e500 kit is pretty much all server kit anyway, so dropping those two kernels from the desktop image may well be sane.
[16:36] <barry> bdmurray: i've been more or less deferring that one to doko because he uploaded the pillow support and (i think) wasn't to thrilled with my previous attempts at packaging that stuff up. ;)  dunno if/when he's around (he's not right now), but perhaps we should just assign the bug to him for now and i can look at it if he's going to be away for a while
[16:36] <infinity> xnox: (There's also the part where, since we ditched CD-sized images, we have some leeway here, and can just declare that PPC gets to be bigger and be done with it)
[16:37] <bdmurray> barry: I'll assign it to him and we can talk about it Wed if need be
[16:37] <xnox> infinity:  yeah, i know. 4 ppc images would be silly =) bigger is fine, but 140MB is a bit too big. Do all of the supported systems have dvd drives & drivers?
[16:37] <barry> bdmurray: +1 thanks
[16:38] <infinity> xnox: A bit "too big", why?
[16:38] <infinity> xnox: Once it's bigger than a CD, how big is too big?
[16:38] <xnox> infinity: was quantal ppc bigger than cd?
[16:39] <xnox> infinity: i thought that somebody complained about lack of dvd, but now i can't remember if it was lack of blanks to burn or lack of dvd-drive in the powerpc box.
[16:39] <infinity> xnox: I don't see quantal/desktop for PPC at all.
[16:39] <xnox> quite a difference there.
[16:39] <infinity> xnox: Lots of old PPC kit won't have shipped with DVD drives.  This is no different from lots of old x86 kit.
[16:41] <xnox> cause e.g. pointless to have old powerpc kernels on the desktop DVD, if none of those machines had a dvd drive =)))))
[16:41] <xnox> anyway, not terribly important for now =)
[16:41] <infinity> Define "old".
[16:41] <infinity> ppc64 boots hardware that ships today.
[16:41] <xnox> kk.
[16:42] <infinity> e500 isn't "the new PPC platform", it's just "a different one".
[16:42] <infinity> And yes, ideally, it should be consolidated into the ppc32 kernel.
[16:42] <infinity> (and e6500 should be consolidated into the ppc64 one)
[16:42] <infinity> But, as I said, there are currently technical difficulties with that.
[16:43] <infinity> I'm still all for dropping those kernels from the desktop media, though, if BenC concurs.
[16:43] <stokachu> cyphermox: ping
[16:51] <bdmurray> slangasek: bug 1096022 doesn't seem to be occurring much anymore and the virtual machine I finally created is not encountering it either.
[16:51] <bdmurray> https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-universe/
[16:51] <bdmurray> the last failure was on 1/21
[16:52] <slangasek> bdmurray: well, that's vaguely satisfying then ;)
[16:54]  * infinity raises an eyebrow.
[16:54] <bdmurray> psivaa: Please let us know if that upgrade fails again.
[16:55] <infinity> I kinda want to know how we accidentally fixed it.
[16:56] <cjwatson> jdstrand: Any reason secureboot-db shouldn't be copied to {precise,quantal}-updates?  There's no verification bug for it.
[16:56] <cjwatson> Oh, yes there is, the report just isn't finding it ...
[16:56] <psivaa> bdmurray: ok, will do, but did not see this after 21st Jan
[16:57] <infinity> cjwatson: I was going to wait until we finished maining it and getting something(s) to depend on it.
[16:57] <cjwatson> infinity: I'm not sure that's going to happen for .2.
[16:58] <infinity> cjwatson: Well, you need a new grub2-signed anyway, and I'm told that was one of the things they wanted to depend on it.
[16:58] <cjwatson> But it seems potentially useful for OEMs even without that.
[16:58] <infinity> Oh, crap.  Does grub2-signed land in d-i images?
[16:58] <cjwatson> I mean, it's currently empty anyway :-)
[16:58] <cjwatson> infinity: Yah
[16:58] <cjwatson> Don't they build from -proposed though?
[16:58] <infinity> Poo.  Then that last upload was a wash.
[16:59] <cjwatson> How come?  The grub2-signed in -proposed will be fine for .2, I expect ...
[16:59] <cjwatson> Just needs the server team to get round to verifying one last bug
[16:59] <cjwatson> Which should be an easy one
[16:59] <infinity> cjwatson: grub2-signed in proposed is out of sync with grub2 in proposed...
[16:59] <cjwatson> Oh, hmm
[16:59] <cjwatson> Yeah, this secureboot-db package in -proposed is trivial.  I'm going to copy it just to make reports shorter, even though it's currently pretty useless.
[17:00] <infinity> Alright, I can promote it later.
[17:01] <cjwatson> Yeah, we should update grub2-signed.  I'll do that now.
[17:01]  * jdstrand read the backscroll but seems there is nothing to do
[17:01] <infinity> cjwatson: So, if you're doing that, you could make it pull in secureboot-db too. :P
[17:01] <cjwatson> I guess.
[17:02] <cjwatson> jdstrand: ^- confirm that that's wanted?
[17:02] <jdstrand> we want shim-signed and grub2-signed to Recommends it
[17:02] <tjaalton> cjwatson: yeah, i could..
[17:02] <infinity> Or recommends, yes. Sorry.
[17:03] <cjwatson> jdstrand: Could I have a bug report for this, please?
[17:03] <cjwatson> If there isn't one already ...
[17:03] <infinity> I was going to add tasks to the MIR.
[17:03] <infinity> Once I'd done reviewing it.
[17:03] <infinity> cjwatson: How about we don't upload grub2-signed just yet, and I'll do the MIR review first. :P
[17:06] <mterry> jbicha, heyo.  Does the GNOME Remix want to keep patches that change "..." to the proper unicode char?  (I'm going through gnome-bluetooth's patches, now that Unity will use indicator-bluetooth
[17:18] <jbicha> mterry: which patch? we might not even be using that code so it may not be worth maintaining the patch in Ubuntu
[17:19] <jbicha> I'm pretty sure GNOME would take an ellipsis patch though for https://live.gnome.org/GnomeGoals/UnicodeUsage
[17:25] <cjwatson> infinity: Well, I have grub2-signed uploads ready to go whenever you say the word; the sooner the better
[17:27] <cjwatson> bdmurray: Will you be able to verify bug 984276?
[17:33] <cjwatson> Sweetshark: Do you know how far off we are with verification of bug 1037111 for precise?  Since it's a big download, it'd be nice to have it in 12.04.2.
[17:33] <infinity> cjwatson: The last comment seems to imply it's well on its way.
[17:33] <cjwatson> Indeed, but I want to make sure it finishes :-)
[17:34]  * infinity nods.
[17:34] <bdmurray> cjwatson: yes, I'll do that now
[17:35] <infinity> cjwatson: Let me go stab secure-whoever-whatsit for you for MIR goodness.
[17:35] <infinity> Maybe after I have a midnight snack.
[17:36] <zequence> infinity: Where is the code for the ISOs, exactly? (Ubuntu, and other flavors)
[17:36] <cjwatson> bdmurray: Thanks
[17:36] <cjwatson> tjaalton: Also, do you know what's happening about verification of bug 1064192?  I think we want all the driver packages in .2 ...
[17:37] <zequence> infinity: Never mind :)
[17:40] <tjaalton> cjwatson: hum, no.. tseliot ^
[17:50] <tseliot> cjwatson: unfortunately I don't own a graphics card to test that driver
[17:50] <tseliot> tjaalton: ^
[17:52] <infinity> jdstrand: So, I only have one concern with this secureboot-db thing.  Why does the postinst ignore errors from sbkeysync?
[17:53] <jdstrand> infinity: right, I did that on purpose. let me try to rethink why
[17:54] <smoser> psusi, ping.
[17:58] <jdstrand> infinity: I have in my notes is that sbkeysync doesn't actually exit with error under certain conditions. That coupled with the fact that I tend not to want to break upgrades, I opted for '|| true'. I also thought it conceivable that sbkeysync could have updated db/dbx but grub wasn't setup yet to use the knew kernel (resulting in an unbootable system)
[17:59] <tjaalton> tseliot: does it support gf8600gt?
[17:59] <jdstrand> (plus I didn't want different postinst behavior if sbkeysync changed its error handling)
[17:59] <infinity> jdstrand: Well, given that we're upstream for sbkeysync, I'd like to think that if it ever exits with an error that's because we think something bad has happened.
[18:00] <infinity> jdstrand: And if that's not true, perhaps we should fix it. :P
[18:01] <jdstrand> infinity: "I also thought it conceivable that sbkeysync could have updated db/dbx but gru wasn't setup yet to use the knew[sic] kernel" because we exited with error
[18:01] <tjaalton> tseliot: seems like it does, so i can verify it..
[18:01] <tjaalton> cjwatson: ^
[18:01] <jdstrand> infinity: I hear what your saying, but I felt that erring on the side of caution (ie, making sure the system is at least bootable) was paramount
[18:02] <infinity> jdstrand: Assuming that's what this does, sure.  I was envisoning the opposite, I suppose.  sbkeysync tells us something went horribly wrong, we ignore it, the user has no unfriendly "egads, stuff broke" error messages and reboots into a brick.
[18:04] <jdstrand> infinity: the only way that I can imagine that a system would become unbootable is if sbkeysync ran and updated db/dbx, but we didn't finishing setting up booting the non-blacklisted new grub/shim/kernel/...
[18:04] <jdstrand> the || true was an attempt to guard against that
[18:05] <infinity> jdstrand: Fair enough.
[18:05] <jdstrand> I suppose a firmware bug would be possible there, but... /me moves hands around
[18:06] <infinity> jdstrand: Thankfully, we've not seen any UEFI firmware bugs that brick systems.
[18:06] <jdstrand> most of those would likely cause an unbootable situation regardless
[18:06] <jdstrand> hehe
[18:06] <jdstrand> true
[18:07] <jtaylor> doko: can you please comment on bug 1112496
[18:07] <smoser> infinity, what is the lkelyhood of getting a newer util-linux?
[18:08] <doko> jtaylor, later, just back from travelling
[18:08] <cjwatson> mlankhorst: while I'm nagging people about X-related updates - any chance of verifying bug 1070481?
[18:08] <infinity> cjwatson: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1087843 is a go.  I'll pre-promote now, feel free to upload grub2-signed with the recommends.
[18:08] <cjwatson> infinity: Right.  In progress.
[18:08] <smoser> ours is quite old. i'm specifically interested in gpt features and 'partx --update' (bug 1096999 and bug 1087526)
[18:08] <mlankhorst> cjwatson: oh go right ahead and close it, the patch has been tested so many times that as long as it's applied it works :P
[18:09] <infinity> smoser: I keep meaning to set up a proper shared repository so lamont and I can co-maintain it more sanely.
[18:09] <infinity> smoser: But I can certainly see about updating it in experimental/raring.  I assume you're not looking for SRU backports here, right?
[18:10] <lamont> infinity: I support this plan.
[18:10] <lamont> infinity: well, actually I support the plan where you actually create a shared repo, rather than the plan where you keep meaning to, but don't. :p
[18:10] <cjwatson> mlankhorst: tag it verification-done then :)
[18:10] <smoser> infinity, i'm not looking for SRU for those, no.
[18:11] <infinity> lamont: Heh.  Yeah, I'm terminally lazy when it comes to anything alioth-related.  I'll get to it.
[18:11] <smoser> but at the moment it looks to me that gpt support in trunk is much newer than any released.
[18:12] <infinity> smoser: Sure, I'm not averse to backporting select patches from trunk, but may as well make sure we're at a current release version first.
[18:12] <smoser> right.
[18:12] <mlankhorst> cjwatson: done
[18:12] <smoser> i was going to suggest that 2.22 would be a better starting point for cherry picking than where we are now
[18:12] <cjwatson> mlankhorst: ta
[18:12] <smoser> that said, psusi cherry picked the partx patches anad has a branch for that.
[18:13] <smoser> but i'd like the gpt support also.
[18:13] <infinity> smoser: Tell you what.  I'll get that done, if you find some free time to fix eglibc on Debian/kfreebsd.  Thanks in advance.
[18:13] <smoser> infinity, you're welcome
[18:14] <smoser> i hope i didn't sound ungrateful
[18:14] <infinity> smoser: :)
[18:15] <infinity> Ugh, 520 open util-linux bugs.  I sure do know how to pick the wrong packages to co-maintain.
[18:16] <infinity> smoser: I'll put the Debian update on my hobbyist TODO.  I'm sick of glibc this week anyway.
[18:20] <lamont> infinity: +500 - halp welcome
[18:20] <smoser> infinity, the good thing is that its such a fringe package, that an upgrade of a years worth of upstream development (2.20.1 -> 2.22.2) is not likely to cause any fallout.
[18:21] <jdstrand> infinity: thanks for the review :)
[18:21] <infinity> smoser: Yeah, no one really uses it anyway.
[18:21] <infinity> smoser: S'ok, I have a knack for adopting fringe cruft that no one uses.
[18:38] <ogra> ogra@nexus7:~$ ps ax|grep -c "udevd --daemon"
[18:38] <ogra> 17
[18:38] <ogra> hmm, that cant be right
[18:45] <mlankhorst> pgrep udevd ?
[18:46] <ogra> it had different PIDs, werent threads
[18:46] <Esokrates> hi, i have compiled both, compiz and unity. If i log in with lightdm i can only see the wallpaper, so i change to a virtual terminal and type:  env DISPLAY=:0  --replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
[18:46] <Esokrates> but what i get is different from how things are configured in default ubuntu
[18:47] <Esokrates> (workspaces all in a row, minimize animation mac -like
[18:47] <Esokrates> cannot snap windows etc. ...
[18:47] <Esokrates> how to configure to get the ubuntu default experience?
[18:55] <ogra> cjwatson, 393MB for the idling desktop (after i restarted udev to get rid of the piling up daemons) with your libgtk-3.0  \o/
[18:57] <seb128> ogra, how much was it before the update?
[18:57] <ogra> cjwatson, that should be a good 30M
[18:57] <ogra> seb128, above 400 ... somewheer around 420
[18:57] <seb128> nice
[18:58] <ogra> hmm, i have a pulseaudio daemon go crazy here
[19:04] <cyphermox> stokachu: pong
[19:09] <ogra> oh, it even dropped to 375 now
[19:09] <ogra> ah, 17M swap :P
[19:10] <xxiao> saw a few old connections leaving cannonical for linaro
[19:26] <smoser> infinity, would you be opposed to me grabbing psusi's backport for util-linux ?
[19:26] <smoser> as it seems to "work for me"
[19:27] <infinity> smoser: That has pretty much zero context.
[19:27] <smoser> well, context was provided earlier , https://code.launchpad.net/~psusi/ubuntu/raring/util-linux/cherry-pick-resize
[19:29] <infinity> smoser: Yeah, if you need that right freakin' now, that seems like a reasonably self-contained backport.
[19:29] <smoser> infinity, well even if you pulled 2.22.2, it wouldn't have that
[19:29] <infinity> smoser: I'm certainly not going to get to a new upstream tonight or anything.
[19:30] <infinity> smoser: *nod*
[19:30] <smoser> i dont need it *right now*
[19:30] <smoser> but at som epoint i want it
[19:31] <smoser> so if you're not opposed to getting it before you were to do a potential update, then i might just do that.
[19:31] <infinity> Yeah, I have no objections to it.
[19:34] <cjwatson> ogra: rock
[19:34] <ogra> yeah
[19:35] <ogra> we'll end up on 256M if it moves on like that !
[19:35] <cjwatson> I wonder if we've hit the second memory target yet
[19:36] <ogra> not yet, there is still something weird going on right after boot
[19:37] <ogra> it peaks above 500M and then goes down to the state it keeps
[19:37] <ogra> once we have that we should be able to tick off 2 and 3
[19:38] <BenC> infinity: I have no problem with e500* being left off of desktop media
[19:38] <cjwatson> ogra: does bootchart reveal anything interesting?
[19:38] <ogra> cjwatson, to me it looks like 2 and 3 are actually flipped, shouldnt the standlone desktop be 2 and desktop +app be 3 ?
[19:38] <cjwatson> I didn't set the targets :-)
[19:39] <ogra> cjwatson, not checked yet, its on my plan for tomorrow ... together with finding out why i have 17 udevd's running
[19:39] <infinity> BenC: I know we had this conversation before, and I've entirely forgotten the technical reasons given, but is there zero chance that e500* (and e6500 or whatever the 64-bit one is) will ever be able to be built into generic ppc32/ppc64 zImages?
[19:39] <cjwatson> It depends whether browser+mail-client were >512MB at the time that list was compiled
[19:40] <cjwatson> Doesn't udev keep a worker pool or something?
[19:40] <ogra> they surely were >1G
[19:40] <BenC> infinity: at this point, that's a negative
[19:40] <BenC> ppc32 will never happen
[19:40] <ogra> cjwatson, with a daemon for each of them ?
[19:40] <cjwatson> ogra: I mean on their own, without the desktop
[19:40] <infinity> BenC: Yes, I know it's not likely "at this point", I meant "in the future".
[19:40] <BenC> ppc64 will take great effort, but I'm going to push Freescale as much as I can to do the mmio work
[19:40] <cjwatson> ogra: they'll be forks of the original
[19:40] <ogra> i literally had /sbin/udevd --daemon running 17 times here
[19:40] <ogra> each with its own PID
[19:40] <cjwatson> yes, it forks to run rules
[19:40] <ogra> oh, ok
[19:41] <infinity> BenC: Kay.  In theory, if the ppc64 single zImage could happen, wouldn't the same work apply to ppc32 with some judicious cargo-culting?
[19:41] <ogra> hmm
[19:41] <BenC> infinity: Not really...
[19:41] <BenC> There's a lot more than mmio work to be done there
[19:42] <cjwatson> hm, it doesn't look as though it's supposed to keep a pool around though
[19:42] <kentb> where can I get some help with getting some packages into quantal/precise-backports from raring?  I've got the bug requests filed and done the testing, etc.
[19:42] <infinity> BenC: Irksome.
[19:43] <cjwatson> but I can't easily look through any more than small amounts of the code from here
[19:43] <xxiao> what's the benefit to get freescale e5** to zImage?
[19:43] <infinity> kentb: Did you subscribe ~ubuntu-backporters to your bugs?
[19:44] <kentb> infinity, yes. several months ago
[19:44] <infinity> xxiao: Not building and shipping several redundant kernels?
[19:44] <BenC> It's not "zImage" it's getting them to be built in the same image
[19:45] <BenC> xxiao: I think the idea is more like being able to build IBM Power kernel and Freescale Power kernels together
[19:45] <infinity> xxiao: Oh, yes, when I say "single zImage", it's the "single" part that matters.  I wasn't actually referring to the binary format.
[19:45] <xxiao> not sure if each side will ever prioritize this effort
[19:46] <infinity> And, up until recently, PPC was kinda the poster child for disparate platform support in a single kernel.
[19:46] <infinity> It's a bit sad that's now becoming gratuitously untrue.
[19:47] <xxiao> not sure who is funding fedora's ppc64 release
[19:47] <BenC> infinity: to be fair, not many platforms have a bookS and bookE type of platform seperation
[19:48] <xxiao> i don't see the point for 64bit user space, will give fedora ppc64 rootfs a try sometime though
[19:49] <xxiao> BenC: there is at least one FPU instruction difference between ibm and fsl e5500/e6500, that only matters if hard-float is used correct?
[19:53] <infinity> jdstrand: Oh, bah.  Second problem qith secureboot-db.  It depends on sbsigntool, but is arch:all, so is "broken" on non-x86.
[19:53] <infinity> s/qith/with/
[19:55] <slangasek> infinity: why does that bother us?
[19:55] <infinity> jdstrand: You've taken away my precious beer on http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html
[19:55] <slangasek> aren't there a number of such "broken" packages?
[19:55] <infinity> slangasek: Not in main, there aren't.
[19:56] <slangasek> hmm
[19:56] <jdstrand> huh
[19:56] <slangasek> I consider this an artificial requirement
[19:56] <jdstrand> I didn't realize sbsigntool was only i386 and amd64
[19:57] <slangasek> Debian has never held that rule
[19:57] <infinity> sbsigntool probably shouldn't be x86-only in the long term.  But it is for now.
[19:57]  * jdstrand wonders why, since arm is supposed to have secure boot
[19:57] <slangasek> jdstrand: IIRC it has to do with architecture dependence of the PE format we're signing
[19:57] <jdstrand> that makes sense
[19:57] <infinity> jdstrand: No ARM devices we care about (yet) have EFI or SB.
[19:57] <slangasek> bug #1020771
[19:58] <jdstrand> infinity: I can fix this in a bit, I'm training someone atm
[19:58] <infinity> jdstrand: Yeah, I'm in no rush.  Was just pointing it out.
[19:59] <xxiao> a newbie question, if soft-float and math-emulation are both turned on, which one will be used by default?
[19:59] <infinity> slangasek: And, you're right, Debian's never required that arch:all deps be satisfiable on all arches, though it is mildly irksome when they can't be.
[20:01] <infinity> slangasek: For something less strangely esoteric than secureboot-db, see usb-creator, which used to be arch:all, but it's actually really frustrating when some guide says "do this with usb-creator", and you try to install it and it's "broken" on your arch.  Better to just not have it available at all.
[20:01]  * slangasek nods
[20:24] <smoser> infinity, one other thing.. if you do ever update util-linux, change debian/source/format to something other than 1.0 please.
[20:24] <smoser> it just feels dirty to change code without quilt
[20:26] <infinity> smoser: lamont's been maintaining it in git, where 1.0 makes some sense.
[20:26] <smoser> yeah, ok. i haven't any experience with that.
[20:27] <infinity> (Basically, the same way we maintain the kernel packages in Ubuntu)
[20:27] <infinity> If your upstream is just another git remote, you can cherrypick patches to your heart's content, and have a sane history.
[20:28] <smoser> when you cherry-pick is there some git knowledge of the source ?
[20:28] <infinity> There doesn't need to be, since git hashes are unique unlike, say, bzr revisions.
[20:28] <smoser> well, bzr revisions are not, but the revision-id is in bzr
[20:29] <smoser> anyway.
[20:29] <smoser> i just uploaded psusi's branch.
[20:29] <smoser> sanity checked that it generally functioned for what i was wanting
[20:30] <smoser> (and it seems to work for gpt stuff, not sure really how)
[20:30] <lamont> smoser: do not make me get upset at you by suggesting that the VCS belongs in the source package.  source-format = 1.0 is the only sane state
[20:31] <smoser> i dont think its the *only* sane state.
[20:31] <lamont> smoser: there was a brief period where I went with 3.0 for either bind or postfix, and I've been sad about that ever since.  OTOH, hardy EOLs soon
[20:32] <lamont> smoser: for the same reason that I hate quilt and dpatch, I find absolutely no benefit to 3.0
[20:33] <lamont> of course, that's mostly because when I check out the tree, I want to actually have the patched tree, not a tree with lots of unapplied patches
[20:33] <lamont> if I were to majorly fork from upstream, that might make a differnce
[20:34] <infinity> Yeah.  I'm finding 3.0 makes some sense with glibc.
[20:34] <cjwatson> 3.0 can give you a patched tree, FIW
[20:34] <cjwatson> FWIW
[20:34] <infinity> Not that we're "majorly forked", but we carry a lot of patches.
[20:34] <smoser> right.
[20:34] <cjwatson> It always gives you a patched tree on dpkg-source -x
[20:34] <cjwatson> Whether it does on VCS checkout depends how you lay out your VCS
[20:34] <smoser> bzr with patches appplied seems to work reasonably well recently.
[20:34] <infinity> cjwatson: But that's not generally how one wants to check it into git.  Unless you really want all your patched files duplicated in .pc
[20:34] <smoser> and doesn't bother showing you the .pc/ changes.
[20:35] <smoser> its not perfect, but it is loads better than it was.
[20:35] <cjwatson> infinity: The way I run my 3.0 (quilt) trees in bzr (when not using UDD) is to commit debian/patches/ but not .pc/
[20:35] <cjwatson> Which is not without its problems but works reasonably OK
[20:35] <smoser> cjwatson, if you stop fighting UDD, its really not terrible any more :)
[20:36] <cjwatson> It does mean that to get quilt working to actually develop against the checkout you have to run a script to unapply/apply
[20:36] <smoser> i followed your lead and had the non-applied .pc
[20:36] <cjwatson> smoser: I use UDD too elsewhere so have plenty of opportunity to compare
[20:36] <smoser> now i just try to let it handle it.
[20:36] <cjwatson> I still prefer my approach :)
[20:36] <cjwatson> But it's true that you have to handhold sometimes - there's really no perfect approach without additional tooling
[20:37] <smoser> much of my battle wounds were from fighting the importer
[20:37] <smoser> as it gets all ticked off with your way
[20:37] <cjwatson> Yeah, I only do this on branches the importer doesn't touch
[20:37] <cjwatson> Fighting the importer is definitely a mug's game
[20:37] <smoser> yeah, i just wanted it to work in both ways, so people (other people) could "just upload"
[20:41] <cjwatson> My most complex package maintained this way is grub2; and my intended solution for that is to get it in sync with Debian so that I no longer have to care about the importer
[20:41] <cjwatson> (In fact I don't right now, I use a different branch, but)
[20:53] <cjwatson> pitti: TB meeting in <10/
[20:53] <cjwatson> ?
[20:54] <pitti> cjwatson: thanks for reminder, I'm back onlne
[20:54] <pitti> just with missing 'i's
[21:19] <jdstrand> infinity: ok, secureboot-db uploaded to raring-proposed. shall I also upload it to precise-proposed and quantal-proposed? (note, that -updates for precise and quantal has secureboot-db)
[21:28] <infinity> jdstrand: Yeah, please do.
[21:28] <jdstrand> cool
[21:36] <smoser> Daviey, to follow up, my initial thought on how to preseed cloud-init for nocloud wont work.
[21:36] <smoser> the way i was oding it for fast path installer also requires modification of the command line (kernel cmdline)
[21:36] <smoser> adding 'ds=nocloud'
[21:38] <smoser> hm... actually i dont know.
[21:43] <smoser> well... i suspect i can get it to work on quantal, but not on precise cloud-init.
[21:48] <tseliot> tjaalton: great, thanks!
[21:50] <jdstrand> infinity: uploaded. I'm stepping away for a couple/few hours but will be back later if you need anything else
[21:56] <xxiao> http://paste.ubuntu.com/1610479/
[21:56] <xxiao> mk-sbuild for ppc core-dump
[21:56] <xxiao> on precise
[21:57] <cjwatson> More precisely, qemu-ppc-static core dumps.
[21:57] <cjwatson> It'd be pretty surprising for mk-sbuild to core dump given that it's a shell script.
[21:57] <xxiao> u r right :)
[21:57] <cjwatson> qemu from raring might do better.
[21:58] <xxiao> a bit surprised on doing this basic thing on LTS though
[22:04] <infinity> xxiao: qemu-user-static is known-broken on a lot of architectures.
[22:05] <infinity> xxiao: As a general rule, you're better off building natively anyway, since PPC hardware is far faster than anything x86 could emulate.
[22:07] <xxiao> infinity: true, it's just my ppc boards(not Apple machines) are a little noise here :)
[22:07] <xxiao> noisy
[22:07] <xxiao> i'll live with that...
[22:07]  * xxiao puts on his Optime95
[23:54] <psusi> smoser, pong


[07:04] <ara> good morning all :)
[10:07] <stgraber> yeah, european time again :) (for 3 weeks)
[10:10] <davmor2> morning stgraber
[10:12] <stgraber> morning davmor2
[10:13] <davmor2> stgraber: what is it a fortnights holiday and then uds?
[10:13] <stgraber> yeah, 2 weeks in Swizterland, then Barcelona
[10:14] <davmor2> stgraber: see you there :)
[10:14] <stgraber> yeah, finally :)
[11:15] <xivulon> hi all, I would like to have a new release of wubi in 9.04 which fixes some localization issues that emerged post release
[11:15] <xivulon> that will affect the stand-alone download, but so far there wasn't any widespread testing for the modified codebase
[11:17] <xivulon> the relevant bugs are https://bugs.edge.launchpad.net/wubi/ bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY
[11:27] <xivulon> A build is available at http://people.ubuntu.com/~evand/wubi/karmic/wubi-r134.exe
[12:38]  * ara -> lunch
[20:15] <cgregan> cr3: ping
[20:40] <cr3> cgregan: pong


[05:57] <mup> PR snapd#7745 opened: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>
[06:25] <mborzecki> morning
[06:29] <zyga> Hey
[06:29] <mborzecki> zyga: hey
[06:30] <mvo> hey zyga
[06:31] <mborzecki> zyga: taking swap days?
[06:32] <zyga> Need to decide when first
[06:32] <zyga> mvo: how is your jet lag today?
[06:32] <mvo> zyga: horrendous
[06:33] <zyga> I feel I can only sleep for two or three hours at a time
[06:33] <mvo> zyga: couldn't sleep most of the night
[06:33] <zyga> Barely slept last night
[06:33] <mvo> zyga: same here, super nasty
[06:33] <zyga> I had dinner at 4am
[06:34] <zyga> I need to sort out my stuff and pick up the laptop from service
[06:34] <zyga> I will do H-BS-R training today if you don’t mind
[06:34] <mvo> zyga: lol@training
[06:34] <mvo> zyga: sure, go for it
[06:35] <mvo> zyga: I try to start with some simple uc20 things, like the initramfs mount helper stuff we talked about with xnox, I hope to have an initial PR up today
[06:36] <mborzecki> zyga: want to talk about the mount thing from last week later today? (i'm sitting at mcdonald's right now, car in the shop)
[06:54] <zyga> mborzecki: yeah
[06:54] <zyga> I have a 121 at 10:00
[06:54] <zyga> When would be a good time?
[06:55] <mborzecki> zyga: 12?
[06:55] <zyga> Sounds good
[06:55] <mborzecki> zyga: i should be back home around 1030 hopefully
[06:55] <zyga> I need a moment before I start work today
[06:56] <zyga> Maybe an hour of sleep
[06:58] <mborzecki> hmm wonder whther cachio managed to update the arch images on friday
[07:02] <mup> PR snapd#7739 closed: tests: moving arch linux to unstable <Created by sergiocazzolato> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7739>
[07:10] <mborzecki> duh, our spread images of debian sid have fwupd-refresh.service enabled :/
[07:10] <mvo> mborzecki: there are prs for this
[07:10] <mvo> mborzecki: 7742 fixes debian to be less unstable
[07:11] <mborzecki> mvo: right, though, we don't really need fwupd running :P
[07:11] <mvo> mborzecki: yeah, it seems to be running on a lot of the images
[07:11] <mvo> mborzecki: but yeah, I'm all for killing it :)
[07:11] <mvo> mborzecki: arch works currently btw, the degraded test is disabled there. but yeah, revreting this would be nice
[07:12] <mvo> mborzecki: fwiw, 7745 is green (fresh from this morning) and should be a super simple review *nudge* :)
[07:12] <mborzecki> mvo: already got it opened in a tab
[07:12] <mborzecki> mvo: going trough ian's PR first
[07:15] <mvo> mborzecki: sure, there is no hurry for mine, the followup will be more interessting hopefully
[07:28] <mborzecki> mvo: think we can land #7742 ?
[07:28] <mup> PR #7742: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/7742>
[07:30] <mvo> mborzecki: yeah, lets unblock the world and then fix it
[07:30] <mvo> mborzecki: I think sergio can just remove the package from the images hopefully
[07:31] <mup> PR snapd#7742 closed: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7742>
[07:32] <mborzecki> mvo: yeah, not much use for fwupd in the cloud, though there might be a spread test that checks fwupd, so just disabling/masking fwupd-refresh should be enough
[07:44] <mvo> mborzecki: +1
[07:44] <mvo> mborzecki: ok
[07:51] <mborzecki> mvo: https://paste.ubuntu.com/p/8f2MyCMSdr/ duh
[07:57] <mvo> mborzecki: fun
[07:57] <mvo> mborzecki: I think there was a recent merge for some motd-fixes, looks like the fix does not work. tests ftw!
[08:02] <pstolowski> morning
[08:10] <mborzecki> pstolowski: hey
[08:14] <pstolowski> hey mborzecki
[08:14] <pstolowski> mvo: welcome back!
[08:14] <mvo> hey pstolowski - good morning!
[08:15] <pstolowski> oh wow, i really love my flight option to frankfurt, and it is cheap
[08:29] <mborzecki> pstolowski: heh, wish they didn't kill all flights to/from LCJ
[08:29] <mborzecki> off to pick up the car and driving back home
[09:48] <mup> PR snapd#7737 closed: overlord: mock device serial in gadget remodel unit tests <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7737>
[10:18] <mborzecki> re
[10:21] <mvo> welcome back mborzecki
[10:29] <mborzecki> still wondering why people would have both docker.io and docker snap installed on a single host
[10:29] <ogra> mvo, zyga, i see some very weird system-files interface behaviour here ... i tried locally building an app using system-files giving access to a file in /etc/systemd ... connected the interface wrote the file ... purged the snap ... then i changed the snap to use a layout instead and dropped the interface completely ... the layout worked and didnt complain
[10:30] <ogra> mvo, zyga, trying teh same snap on another machine rightly complains that layouts in /etc/systemd affect the host ... yet there is no system-files interface to be seen anywhere
[10:30] <mborzecki> interesting question in the forum: https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266/13
[10:30] <ogra> i.e. the interface doesnt seem to have been disconnected when i purged the package on the original machine
[10:30] <ogra> and snap conenctions does not show it anymore
[10:31] <mup> PR snapd#7746 opened: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[10:32] <ogra> ... but i can still fully access the file on this machine
[10:32] <mvo> xnox: hey, are you around today?
[10:41] <mvo> ogra: uh, that sounds like a interessting question - maybe pstolowski can have a look, I'm way too jetlagged today. or I can dig later this weeek
[10:46] <pstolowski> mvo, ogra sure, i can take a look. ogra, can you grab state.json and apparmor profile of that snap from the original machine? can you share the snap so i can try it?
[10:58] <mborzecki> pstolowski: some comments under #7686
[10:58] <mup> PR #7686: systemd: handle preseed mode <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[10:59] <pstolowski> mborzecki: ty
[11:05] <mup> PR snapd#7730 closed: spread: fix typo in spread suite <Created by sparkiegeek> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7730>
[11:09] <ogra> pstolowski, https://github.com/slimjim777/logsync/pull/1 i first added the top three commits ... the issue occured with the fourth commit of this PR (when i found i can use a layout (which wasnt really true))
[11:09] <mup> PR slimjim777/logsync#1: some fixes  <Created by ogra1> <https://github.com/slimjim777/logsync/pull/1>
[11:10] <pstolowski> ogra: ack
[11:11] <mup> PR pc-amd64-gadget#24 opened: gadget.yaml: do not use CamelCase for names <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
[11:12] <ogra> pstolowski, https://people.canonical.com/~ogra/snappy/state.json
[11:14] <pstolowski> ogra: uh, that reveals your macaroon, better take it down
[11:15] <ogra> oops
[11:15] <mborzecki> or logout
[11:15] <pstolowski> yeah, and logout
[11:31] <ogra> cjwatson, i know there was a bug for this but i can not find it (though it might be a new issue) ... https://forum.snapcraft.io/t/getaddrinfo-enotfound-github-com-builds-failing-on-snapcraft-io-due-to-network-problems/14164
[11:31] <ogra> (seems npm doesnt pick up the proxy settings on the lp builders)
[11:36] <cjwatson> ogra: That just means some bit of their build system is ignoring the configured proxy
[11:36] <ogra> ah, so its an electron-packager bug then
[11:37] <cjwatson> Not specifically npm - you can see that registry.npmjs.org requests are working just fine and getting 200 responses
[11:37] <ogra> k
[11:37] <cjwatson> It'll be some random node module's postinstall script probably
[11:37] <cjwatson> Maybe electron-packager, I'm not sure
[11:38] <cjwatson> I'll respond on the forum
[11:38] <ogra> thanks !
[11:44] <popey> mbriza: hiya.
[11:46] <mbriza> popey: hi! i'm getting the 'system does not fully support snapd: cannot mount squashfs image using "squashfs": mount' error
[11:46] <popey> What OS?
[11:46] <mbriza> but i can't find the reason it's failing actually, there's just about 5 different possible reasons listed in the error message
[11:46] <mbriza> fedora 31
[11:47] <mbriza> is there a verbose mode or something
[11:48] <popey> there is SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 for debugging store conversations.
[11:49] <popey> systemd.setenv=SNAPD_DEBUG=1  might do it?
[11:50] <ogra> well ... does that kernel actually have squashfs support ? (grep squash /proc/filesystems)
[11:51] <mbriza> ogra: yes, i googled it for a bit and i made sure squashfs and loop devices are available
[11:52] <ogra> also, does it support loop devices ... (ls /dev/loop-control ... or ls /dev/loop*)
[11:52] <ogra> ah, snap :)
[11:53] <mbriza> popey: https://paste.centos.org/view/0919773d this is the output when running install with SNAPD_DEBUG=1
[11:53] <mbriza> i also added it to the snapd service and restarted it but there doesn't seem to be anything very interesting in the journal
[11:53] <popey> ok, so you can ignore the reexec issue
[11:54] <mbriza> i'm also running with selinux in permissive mode to be sure
[11:54] <popey> are you able to manually mount a random squashfs file? (like your own home-created snap)?
[11:54] <ogra> did you try to manually mount a snap ?
[11:54] <ogra> haha
[11:54] <popey> you type too slow :)
[11:54]  * ogra shuts up now
[11:55] <mbriza> yes, i can
[11:56] <popey> which instructions are you using to install snapd?
[11:56] <mbriza> https://snapcraft.io/docs/installing-snap-on-fedora
[11:56] <popey> oh, also `snap version`?
[11:56] <mbriza> snap    2.42.1-1.fc31
[11:57] <popey> ok, installing fedora 31 on my big machine to test
[11:57] <mbriza> i had a completely different set of issues on my f31 machine on friday though... i was at least able to install snaps :D
[11:58] <mbriza> this is a different machine
[11:59] <popey> yeah, very odd
[11:59] <popey> well, virtualbox is broken for me on 19.10, so that stops that. Bah
[12:00] <ogra> i thought you said you'D install on your BIG computer ! https://pl.wikipedia.org/wiki/Cray_X-MP#/media/Plik:EPFL_CRAY-I_1.jpg
[12:00] <popey> mbriza: what version of snapcraft built the snap you're having trouble with?
[12:00] <popey> not that big, but it's heavy :)
[12:00] <mbriza> popey: i can't install any snap
[12:01] <popey> ok
[12:01] <popey> not even "snap install hello-world"
[12:01] <mbriza> yup
[12:01] <popey> https://www.entroware.com/store/athena  - big machine :D
[12:01] <popey> ok, this is more serious. Do you have a funky kernel, or a stock Fedora supplied one?
[12:02] <ogra> popey, yeah, but it has a keyboard on the seat !
[12:02] <mbriza> nothing funky, not even closed source graphics drivers or anything
[12:02] <mbriza> i just updated the machine this morning
[12:02] <popey> hmmm
[12:02] <ogra> do you know what exactly got updated ?
[12:03] <ogra> (and did it work at any point in time on that machine)
[12:03] <mbriza> basically everything, i was gone for almost 3 weeks :) i didn't have snap installed for quite some months but i remember it working at some point in the past
[12:04] <mbriza> i think i removed it either because of a package conflict between upgrades (i upgrade rather soon in the fedora devel cycle) or disk space
[12:06] <popey> Looks like I need virtualbox test build to get this working on linux 5.3. On that then installing fedora 31 and updates to see what happens here. Will take a while. Sorry.
[12:07] <mbriza> np, i'll just lurk here or on the forums to work this out
[12:07] <popey> actually, i can install clean on my x220. will do that from a usb key.
[12:07] <mbriza> anyway, there's nothing too funky about neither of my systems, i think i'm fairly capable of keeping the system in a workable state
[12:08] <mbriza> are there any conflicts with virtual machines or something like that?
[12:08] <mbriza> i'm running something in qemu-kvm most of the time
[12:09] <popey> no, I run in all manner of distros in vm's all the time
[12:10] <Chipaca> mbriza: I'm sorry if you already answered this: can you mount a snap by hand?
[12:10] <mbriza> Chipaca: i can
[12:11] <Chipaca> mbriza: what does dmesg say when you do?
[12:11] <mbriza> Chipaca: [ 2973.344224] SELinux: security_context_str_to_sid(system_u:object_r:snappy_snap_t:s0) failed for (dev loop1, type squashfs) errno=-22
[12:11] <mbriza> but i'm in permissive mode
[12:12] <mbriza> the error message from snap itself is extremely vague, listing like 5 different possible reasons why it could be failing... pretty hard to debug from my side
[12:12] <Chipaca> mbriza: mount is very vague with its errors
[12:13] <popey> (I'm inclined to agree with that. The error about re-exec not working should be informational, but it doesn't make that clear)
[12:13] <Chipaca> mbriza: which is why that check exists in the first place (getting that vague an error during install is even worse0
[12:14] <Chipaca> mbriza: are you also able to mount a snap by hand if you put that snap in /tmp ?
[12:14] <Chipaca> popey: which error about re-exec not working?
[12:14] <popey> https://paste.centos.org/view/0919773d
[12:14] <mbriza> Chipaca: yes
[12:14] <popey> that's mbriza's output
[12:15] <popey> (I am still confused why you're getting a _multi_ snap)
[12:15] <Chipaca> ah
[12:15] <popey> it should be amd64 for your machine. Must be erroneous binaries in there somehow
[12:15] <Chipaca> popey: you get multi when you have architectures: [amd64,i386], don't you
[12:15] <mbriza> i can fetch the other one but both of them worked on the laptop
[12:15] <mbriza> and both of the machines are amd64
[12:15] <Chipaca> popey: and you'd have that architectures when it was i386 binaries for example
[12:16] <mbriza> and then again, this is failing even when i try to install hello-snap from the store
[12:17] <Chipaca> mbriza: that error you get is not about the snap
[12:17] <Chipaca> mbriza: that error is from a sanity check performed before any operation is attempted
[12:17] <Chipaca> mbriza: did you go into permissive mode after starting snapd?
[12:17] <mbriza> i restarted snapd multiple times in the meantime
[12:19] <Chipaca> mbriza: as I say, that error comes from a sanity check, and what it's trying to do is just a 'mount -t squashfs /tmp/<a temp squashfs>'
[12:19] <Chipaca> mbriza: and that is failing, with the error from mount as reported to you
[12:20] <Chipaca> oh, oh
[12:20] <Chipaca> also maybe in selinux systems there's a context= appended?
[12:21] <Chipaca> mbriza: I don't know selinux enough to know what context that is
[12:21] <Chipaca> maybe mborzecki knows
[12:21] <mbriza> it's trying to access a file called 'snap-failure'
[12:22] <popey> How ironic :)
[12:22] <mbriza> which is i guess an error reporter?
[12:22] <Chipaca> that's a thing you don't need to worry about :-)
[12:22] <Chipaca> it's an auto-reverter for snapd
[12:23] <Chipaca> for (core, or) systems with reexec
[12:24] <ogra> is setting permissive mode a runtime thing (not an selinux user here) ... i.e. did you reboot after setting it to make sure the kernel picked it up ?
[12:24] <mbriza> there are 3 selinux alerts for the time of attempting to install a snap and all 3 point to this so i guess that's not relevant
[12:25] <mbriza> ogra: permissive mode is a runtime thing, selinux won't block anything in this mode but it will report detected... uhh, breaches? don't know how to call it
[12:25] <Chipaca> mbriza: at a guess, we're adding a context=<something> to mount, because selinux.ProbedLevel() isn't "unsupported", and that is getting into trouble because of it being permissive
[12:25] <ogra> ok
[12:25] <Chipaca> mbriza: but I know nothing about selinux :) so it's a question for mborzecki
[12:25] <mbriza> Chipaca: i can run in enforcing if that's a problem
[12:26] <mbriza> still the same error
[12:26] <Chipaca> mbriza: if you add -o context=<gibberish> to the mount of the .snap, does it still work?
[12:26] <Chipaca> that was really quick for enabling enforcing + restarting snapd + trying to install something
[12:27] <mbriza> Chipaca: the daemon is not really running, it's systemd socket-activated
[12:27] <mbriza> anyway, with gibberish in the mount command i'm getting the same error as above
[12:30] <mborzecki> mbriza: hm what about selinux?
[12:30] <pstolowski> ogra: hmm i cannot reproduce the issue you saw. on same host i got "cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd" when trying your snap with layouts, after installing and then removing the one with system-files interface
[12:30] <pstolowski> ogra: i'm on 19.10
[12:31] <mbriza> mborzecki: to be honest i'm not sure what the issue is - there's a lot of repetitive information but the gist is i'm not able to install any snap on fedora 31 because `mount` fails
[12:31] <mbriza> not even sure if it's related to systemd, it fails regardless of running in permissive/enforcing mode
[12:32] <pstolowski> ogra: i suspect something got stale on your box but it's unclear how. your state.json looks sane, it doesn't have system-files connection
[12:32] <mbriza> err i mean selinux
[12:32] <mborzecki> mbriza: reading backlog, looks like snappy_snap_t isn't defined? that'd be weird it's part of the policy shipped with the pacakge
[12:33] <pstolowski> ogra: is your first box still in this state (e.g. the snap with layout succesfully installed)?
[12:33] <mborzecki> mbriza: that's 31 right?
[12:33] <mbriza> mborzecki: yes
[12:33] <mborzecki> mbriza: ok, let me check rawhide first
[12:35] <ogra> pstolowski, i'm on 16.04 here and i think the machine is still in that state ...
[12:37] <pstolowski> ogra: good. could you get me /var/lib/snapd/apparmor/profiles/snap.logsync-james.upload profile?
[12:40] <mbriza> mborzecki: just reinstalled the snap packages and rebooted to be extra sure everything is up to date but install is still failing
[12:40] <mborzecki> mbriza: same thing in dmesg as you posted before?
[12:40] <mbriza> yes
[12:41] <ogra> pstolowski, just to prove it still works ... https://paste.ubuntu.com/p/7vtsXM3Kvm/ ...  one sec, getting the file
[12:42] <ogra> pstolowski, and the apparmor profile ... http://paste.ubuntu.com/p/gz5DfScfQ7/
[12:42] <pstolowski> ogra: did you use --devmode or try at any point?
[12:44] <ogra> only in the very first run i think ... then i removed the snap, re-built, re-installed and connected system-files ... then dropped system-files for layout, removed/purged the snap and installed with the layout
[12:44] <pstolowski> ogra: ok, so the profile has /etc/systemd/journal-upload.conf mrwklix, from the layout; but it doesn't have sytem-files interface anymore in the profile
[12:44] <mup> PR snapd#7738 closed: overlord/state: panic in MarkEdge() if task is nil <Simple 😃> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7738>
[12:45] <pstolowski> it's weird it didn't complain
[12:45] <ogra> right ...
[12:45] <ogra> it complains if i copy the snap to another machine (also 16.04)
[12:46] <pstolowski> ogra: yep, got it. interesting. ok, i think i need to look at different place in the code now.. thanks
[12:46] <ogra> should oh also ...
[12:47] <ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap remove --purge logsync-james
[12:47] <ogra> logsync-james removed
[12:47] <ogra> ogra@anubis:~/datengrab/logsync:master$ cat /etc/systemd/journal-upload.conf
[12:47] <ogra> [Upload]
[12:47] <ogra> URL=http://www.example.com:19532
[12:47] <ogra> -should
[12:47] <ogra> shouldnt the file be removed whan the snap gets purged ?
[12:50] <mborzecki> mbriza: installing core snap
[12:51] <pstolowski> ogra: --purge is only for avoiding automatic snapshots, nothing else
[12:51] <ogra> well, yeah ... but remove should remove the file, or not ?
[12:52] <mborzecki> mbriza: and it installed fine, ok, so we need to debug your system
[12:52] <mborzecki> mbriza: anything useful ausearch -m AVC ?
[12:52] <ogra> i.e. i dnot think a layouted file should stay behind when removing the snap that used the layout
[12:53] <ogra> that will result in all kinds of cruft after a while
[12:53] <ogra> (at least in the case where the layout actually created the file from scratch)
[12:54] <pstolowski> ogra: yes i think you're right, i'm not sure why layout isn't cleaning after itself
[12:54] <mborzecki> mbriza: while at it, does seinfo -t |grep snappy_snap_t list anything?
[12:55] <pstolowski> ogra: something for zyga (maybe there was a reason it's like that)
[12:56] <mbriza> mborzecki: ausearch doesn't report anything new when running sudo snap install hello-world
[12:56] <mbriza> mborzecki: snappy_snap_t is not present in the output of seinfo .-t
[12:56] <mbriza> -t
[12:57] <pstolowski> ogra: one more question.. on the misbehaving box, is snapd at the current stable version?
[12:57] <ogra> checking
[12:57] <pstolowski> ogra: same version of snapd on both boxes?
[12:57] <mborzecki> mbriza: rpm -q snapd-selinux show anything?
[12:57] <ogra> ogra@anubis:~/datengrab/logsync:master$ snap version
[12:57] <ogra> snap    2.42.1
[12:57] <ogra> snapd   2.42.1
[12:57] <ogra> series  16
[12:57] <ogra> ubuntu  16.04
[12:57] <ogra> kernel  4.4.0-141-generic
[12:57] <ogra> kernel is a bit behind ... but the rest should be recent
[12:58] <ogra> the other box uses the hwe kernel but beyond this the same versions
[12:58] <mbriza> mborzecki: snapd-selinux-2.42.1-1.fc31.noarch
[12:58] <mbriza> mborzecki: there's this line in the journal though
[12:58] <mbriza> mborzecki: Nov 18 13:37:27 localhost.localdomain kernel: SELinux:  Context unconfined_u:object_r:snappy_home_t:s0 is not valid (left unmapped).
[12:58] <mborzecki> mbriza: seinfo -t snappy_home_t ?
[12:59] <mbriza> mborzecki: Types: 0
[12:59] <ogra> pstolowski, the main difference is that the system-files interface was never connected on the box that behaves correct
[12:59] <pstolowski> uhm
[12:59] <ogra> (well, i also have never used --devmode with this snap on the behaving machine)
[13:00] <mbriza> mborzecki: https://paste.centos.org/view/e51f0cc4 this is in the journal too
[13:00] <popey> fwiw, i just installed f31, and updated it to latest, and can install and run snaps fine
[13:01] <mborzeck1> wow, my really sucks today
[13:02] <mbriza> mborzeck1: https://paste.centos.org/view/e51f0cc4 this is in the journal too
[13:02] <mbriza> mborzeck1: also as for the output for seinfo-t snappy_home_t, it was Types: 0
[13:02] <mborzeck1> mbriza: right, so looks like the policy wasn't loaded for some reason
[13:03] <mborzeck1> mbriza: ok, can you try dnf history list snapd-selinux and then dnf history info <id> ?
[13:05] <mbriza> mborzecki: there's this little line in there, yes:
[13:05] <mbriza> mborzecki:   16 /usr/sbin/semodule:  Failed on /usr/share/selinux/packages/snappy.pp.bz2!
[13:05] <mbriza> mborzecki: and i get the same error when trying to reinstall the package
[13:06] <mborzecki> mbriza: yeah, i suppose if you do semodule -l |grep snappy there'll be nothing listed there
[13:06] <mbriza> mborzecki: semodule -l doesn't even start
[13:06] <mbriza> libsemanage.semanage_direct_get_module_info: Unable to read flatpak module lang ext file. (No such file or directory).
[13:07] <mbriza> now this is not related to snappy at all
[13:07] <mborzecki> mbriza: hm, did you upgrade 30 -> 31?
[13:07] <mbriza> yeah
[13:07] <mbriza> dnf reinstall *selinux*
[13:07] <mborzecki> mbriza: did you do distro-sync afterwards?
[13:08] <mbriza> mborzecki: i'm distro-syncing all the time
[13:08] <pstolowski> ogra: ok, i know what's going on and why it didn't work on second box
[13:08] <mborzecki> mbriza: tried with --allowerasing?
[13:08] <ogra> \o/
[13:09] <mborzecki> mbriza: btw. you need to use sudo/su to run semodule
[13:09] <mbriza> yeah, of course... seems there's something wrong about my selinux policies though
[13:09] <pstolowski> ogra: it only succeeds with layout-based snap if you already have /etc/systemd/journal-upload.conf in place (leftover from previous snap). trespassing-detection code is then happy. otherwise it complains. i'll pass it to zyga to decide what to do with iy
[13:09] <pstolowski> *it
[13:10] <ogra> yay, thanks
[13:10] <mborzecki> mbriza: can you post the output of sestatus somewhere?
[13:10] <ogra> so let me remoe that file ... to prove it ;)
[13:10] <mbriza> mborzecki: https://paste.centos.org/view/2e2c930d
[13:11] <ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap install --dangerous logsync-james_0.2_amd64.snap
[13:11] <ogra> error: cannot perform the following tasks:
[13:11] <ogra> - Run configure hook of "logsync-james" snap if present (run hook "configure":
[13:11] <ogra> -----
[13:11] <ogra> cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"
[13:11] <ogra> snap-update-ns failed with code 1: File exists
[13:11] <ogra> -----)
[13:11] <ogra> yay !
[13:12] <ogra> yup ... touching the file before snap install then makes it work again
[13:14] <mborzecki> mbriza: doesn't feel like it's related to snapd policy in particular
[13:14] <mbriza> mborzecki: yeah, definitely somewhere else, thank you for helping me debug this
[13:14] <mbriza> and to the rest of the channel, too :)
[13:14] <mborzecki> mbriza: last thing, can you try installing flatpak-selinux, and see if it works?
[13:14] <mborzecki> mbriza: they also ship the policy in a separate module
[13:16] <mbriza> mborzecki: i have it but it (and mysql, too) complains
[13:16] <pstolowski> ogra: good, thanks for confirming
[13:16] <mbriza> ... even after reinstalling
[13:16] <zyga> ogra: it is a bug
[13:16] <zyga> Trespassing should never surface as an error
[13:17] <mborzecki> mbriza: yeah, i'd try checking in #fedora-devel, and maybe trying .autorelabel too
[13:17] <zyga> It is a duplicate of another bug on launchpad already
[13:17] <ogra> zyga, yeah, after two days cuddling with it i guessed that much :)
[13:17] <zyga> Give us some time, we have a plan that fixes a large class of those issues
[13:18] <ogra> yeah, no worries, i'm surely not in a hurry ... just ran into it and found it weird
[13:19] <ogra> pstolowski, one other (unrelated) thing ... should "listen-stream:" still be supported ? i was trying it yesterday and snapcraft complains about things like "listen-stream: 8080" not "being an object"
[13:20] <ogra> (iirc you initially implemented it)
[13:21] <Chipaca> ogra: listen-stream: <the path to a socket>
[13:22] <ogra> Chipaca, uhm, so network sockets got removed ?
[13:23] <ogra> https://snapcraft.io/docs/snapcraft-yaml-reference thinks <port> is a valid thing
[13:26] <mbriza> mborzecki: ha, after deleting the lang files in /var/lib/selinux/targeted/active/modules/200 and reinstalling the packages, i'm able to install snaps again
[13:26] <mbriza> thank you!
[13:27] <mborzecki> mbriza: does it still work when you reboot?
[13:28] <mbriza> i just reinstalled everything with 'selinux' in its name and there were no errors so i assume it'll be fine
[13:29] <mbriza> also my app actually starts on this machine when installed from snap
[13:29] <pstolowski> ogra: i quickly grepped the code and we have tests for listen-stream: <an integer>; should work. not sure why snapcraft rejects it
[13:30] <b_b> hi
[13:30] <mborzecki> mbriza: hah, that's a good sign ;)
[13:31] <b_b> is there a problem with latest stable base core18 ?
[13:31] <ogra> pstolowski, hmm, well, then it is most likely a snapcraft bug with the yaml parser ...
[13:31] <b_b> i'm getting error about this one since yesterday
[13:31] <b_b> error: unable to contact snap store
[13:31] <b_b> An error occurred when trying to execute 'sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1.
[13:31] <ogra> $ SNAPCRAFT_BUILD_ENVIRONMENT=host snapcraft
[13:31] <ogra> Issues while validating snapcraft.yaml: The 'apps/remote/sockets/listen-stream' property does not match the required schema: 19532 is not of type 'object'
[13:31] <ogra> thats what i guess
[13:31] <pstolowski> zyga: re trespassing, shouldn't it behave consistently whether /etc/systemd/journal-upload.conf (that with bind via layout: bind-file: $SNAP_DATA/journal-upload.conf) exists or not? at the moment it is happy if it exists and you only get trespassing error if doesn't
[13:31] <ogra> *s/guess/get/
[13:32] <b_b> i've tried to clean all mutipass vms, and launched a clean snapcraft, no luck
[13:34] <ogra> aha ... https://bugs.launchpad.net/snapd/+bug/1612440
[13:34] <mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>
[13:34] <ogra> looks like the snapd task is fix-released but the snapcaft one is still new
[13:36] <mborzecki> cachio is off today, isn't he?
[13:39] <zyga> hey hey
[13:39] <zyga> pstolowski: it's a bug, it's actually diagnosed already AFAIK
[13:39] <zyga> pstolowski: yes but $COMPLEXITY
[13:39] <zyga> pstolowski: it's not what it seems at first
[13:40] <zyga> ogra: did you report a bug for this?
[13:40] <zyga> ogra: it would help with tracking
[13:40] <ogra> zyga, nope, not yet
[13:40] <zyga> ogra: no rush as I'm a zombie today
[13:40] <zyga> but please do later on
[13:40] <ogra> (it isnt only complex to splve, but also complex to explain :P )
[13:40] <zyga> yeah
[13:40] <ogra> *solve
[13:40] <ogra> ok, will do
[13:41] <zyga> thank you
[13:41] <zyga> I feel terrible today
[13:42] <ogra> must be the maple syrup withdrawal :)
[13:42] <mvo> zyga: yeah, its not a great day
[13:42] <zyga> mvo: I was sleeping between 8 and 1PM
[13:42] <mvo> zyga: uh, woah
[13:43] <mvo> I had a "short" nap in the morning of 2h, but I was already working at 4:30 or so (yay jetlag)
[13:49] <Chipaca> mborzecki: next week
[14:38] <b_b> weird, i can't get rid of this mutlipass error
[14:39] <b_b> sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1
[14:39] <b_b> snap info core18 shows me than the stable channel have a different date than the others
[15:32] <oSoMoN> ijohnson, it looks like https://github.com/snapcore/snapd/pull/7731 is good to go now (tests passed), can it be merged?
[15:32] <mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
[15:37] <b_b> see u ++
[15:39] <pstolowski> https://github.com/snapcore/snapd/pull/7727 needs 2nd review
[15:39] <mup> PR #7727: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
[16:11] <mup> PR snapcraft#2804 opened: conda plugin: simplify source url/checksum handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2804>
[17:04] <zyga> gosh, "ethics and code of conduct" is a long one
[18:00] <mup> PR pc-amd64-gadget#24 closed: gadget.yaml: do not use CamelCase for names <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
[18:15] <mup> PR snapd#7747 opened: gadget: skip fakeroot if not needed <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7747>
[18:20] <Chipaca> zyga: looooooong
[18:20] <Chipaca> zyga: nominally 30-60mins but took me just under 2h
[18:21] <Chipaca> although it wasn't interruption-free
[19:06] <zyga> Chipaca: lol, "Resisting taking vacation time – fraud is often discovered while an employee is gone"
[19:07] <zyga> Chipaca: I wonder when people will start to incorporate remote workers into generic training material
[19:07] <zyga> I feel like a woman may have felt a few decades ago
[19:51] <mup> PR snapcraft#2805 opened: plugins: address type errors for mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2805>
[20:09] <mup> PR snapcraft#2806 opened: cli: address type errors for mypy uprev  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2806>
[20:50] <mup> PR snapd#7748 opened: overlord: fix the get command help message <Simple 😃> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>
[21:07] <jkridner> ogra: I see you made an mjpg-streamer snap. have you thought about making one that includes the opencv filter features?
[21:17] <jkridner> hmmm... https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L36 seems to indicate you are pulling the sources with the opencv plugin.
[21:18] <jkridner> ah, https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L12
[21:51] <mup> PR snapcraft#2807 opened: meta: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2807>
[22:42] <mup> PR snapcraft#2808 opened: repo: fix fetch_binary()'s return type for deb repo <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2808>


[09:11] <JonathanD> Morning.
[10:51] <rmg51> Morning JonathanD
[11:02] <JonathanD> hey rmg51
[11:16] <rmg51> o/
[12:13] <InHisName> Happy drizzly day everyone
[12:50] <waltman> morning
[14:34] <teddy-dbear> hi peoples
[15:14] <ChinnoDog> sup
[19:00] <InHisName> the sky ?
[20:01] <pleia2> btw https://lists.lopsa.org/pipermail/ug-leaders/2012-September/000032.html
[23:12] <MutantTurkey> waltman: !!!!
[23:15] <MutantTurkey> OpenCv is way faster than Image magick  in my test and it's really easy to port
[23:15] <MutantTurkey> actually it's a lot cleaner
[23:16] <MutantTurkey> I find magickwands pixeliterators to be a total pita
[23:16] <MutantTurkey> image = cvCreateImage(filename, type, channels);
[23:16] <MutantTurkey> CvScalar *pixelValues = cvGet2D(image, x,y);
[23:17] <MutantTurkey> that's all it is
[23:17] <MutantTurkey> and setting is cvSet2D
[23:17] <MutantTurkey> seemd to be pretty nice
[23:18] <MutantTurkey> I was using the MagickWand interface for C though, maybe the Magick++ interface is better
[23:18] <MutantTurkey> but it is a lot faster.
[23:18] <MutantTurkey> I'm processing 18,000 images in 2 Minutes on my laptop
[23:24] <MutantTurkey> Actually I may have overstated myself on the performance, but the library seems more geared to doing research anyway
[23:45] <MutantTurkey> no definitely a good boost in performance once I kicked out all of my memory leaks