[04:35] <Kilos> greetings ubunteros and others
[05:00] <Squirm> hello Kilos
[05:05] <Kilos> lubuntu running. after all the questions about installing sakis3g last night i installed lubuntu from scratch and it saw the modem this time so yay
[05:06] <Kilos> nice and fast, but only 2 workspaces and sound to sort. pulseaudio prob methinks
[05:20] <Kilos> ok music works
[05:21] <Kilos> still no bloeps here but
[05:21] <Kilos> grr
[05:21] <Kilos> morning  superfly
[05:21] <superfly> hi Kilos
[05:46]  * Squirm yawns
[05:46] <Squirm> hey superfly
[06:20] <superfly> ohiya Squirm
[06:54] <jrgns> morning all
[07:01] <Kilos> hi jrgns Vince-0
[07:01] <Vince-0> Hii
[07:20] <Kilos> morning ThatGraemeGuy
[07:21] <ThatGraemeGuy> hey :)
[07:21] <ThatGraemeGuy> happy Friday!  Rock up with your mugs with the correct amount of sugar added already
[08:46] <Maaz> Coffee's ready for Kilos!
[08:46] <Kilos> Maaz, ty
[08:46] <Maaz> You are welcome Kilos
[09:27] <charl_> good morning
[09:27] <charl_> Maaz: coffee on
[09:27]  * Maaz flips the salt-timer
[09:31] <Maaz> Coffee's ready for charl_!
[09:36] <charl_> Maaz: thanks
[09:36] <Maaz> charl_: Sure
[12:23] <Squirm> ok
[12:23] <Squirm> this spammer is annoying me now :/
[12:36] <superfly> Squirm: which one? there are many :-P
[13:35] <nlsthzn> thanks for the link superfly , I had the rom on my S3 a few versions back... only reason i am now running stock is because all my hardware works kind of better (wifi, bluetooth etc.)...
[13:36] <superfly> nlsthzn: that's why I gave you the link, I knew I'd get your opinion :-)
[13:36] <superfly> nlsthzn: which build was that?
[13:37] <nlsthzn> I believe the one that was based on the original JB when it came out... but around that time...
[13:37] <nlsthzn> superfly,
[13:38] <nlsthzn> I can't say it was this rom that was not good on the phone, at that time I was jumping roms worse than distro's
[13:39] <nlsthzn> but the CM based ROM's have some hardware issues with the S3... so it isn't 100% perfect (but stock android look and feel was sweet)
[13:39]  * nlsthzn waits for an Ubuntu Touch ROM for the S3 that works well and has some more functionality (might happen...)
[13:57] <Squirm> was about to pack up and go home for the weekend
[13:57] <Squirm> but then the power came back up
[13:57] <Squirm> :/
[14:15] <Kilos> hi nlsthzn
[14:24] <nlsthzn> hiya uncle Kilos
[17:02] <theblazehen> hi Kilos
[17:13] <Cantide> hi theblazehen
[17:19] <Kilos> hi theblazehen Cantide sorry i was eating
[17:19] <Cantide> hey Kilos :)
[18:10] <inetpro> good evening
[18:10] <theblazehen> hi inetpro
[18:14] <Cantide> hello '<
[18:15]  * inetpro watching the Ubuntu TV discussion at #ubuntu-meeting
[18:15] <Cantide> oh 'o'
[18:16] <inetpro> Cantide: mhall119 basically just started with some background info
[18:16] <inetpro> not much of a discussion yet
[18:16] <Cantide> mhall119 is Michael Hall i'm guessing
[18:16] <tumbleweed> yes
[18:16] <Cantide> yeah... i'm about to go to sleep though :/
[18:17]  * tumbleweed is also enjoying this
[18:17] <tumbleweed> it would make a good blog post
[18:17] <Cantide> even though i'd like to know more about Ubuntu TV
[18:18] <tumbleweed> this is fairly enlightening (it fills in some gaps)
[18:18]  * inetpro agrees with tumbleweed
[18:19] <inetpro> very interesting stuff
[18:20] <Cantide> yeah
[18:20] <Cantide> i will stick around a bit :)
[18:24] <Cantide> could they kick mr_man / bobweaver?
[18:24] <Cantide> he's interrupting mhall119 all the time :<
[18:49] <inetpro> "spinning wheels in the mud just gets you more stuck"
[18:51] <magespawn> 'he' is not lying
[18:51] <magespawn> evening all
[18:51] <inetpro> good evening magespawn
[18:51] <Kilos> hi magespawn inetpro
[18:52] <Kilos> weed too
[18:56] <magespawn> trying to het quasseldroid working on the new phone
[18:57] <theblazehen> magespawn, advantages over androiIRC
[18:57] <magespawn> it has the client and the core seperate
[18:57] <magespawn> core runs on the server
[18:58] <theblazehen> awesome
[18:59] <inetpro> theblazehen: http://www.quassel-irc.org/
[18:59] <magespawn> means i connect to the core and the core connects to the channels
[18:59] <theblazehen> thanks. will check it out
[18:59] <magespawn> quaseldroid not working so well on the galaxy pocket though
[19:00] <theblazehen> magespawn, that sucks
[19:00] <magespawn> sorry quasseldroid is the client side for android
[19:00] <theblazehen> ok
[19:01] <theblazehen> nano /etc/mkinitcpio.conf
[19:01] <theblazehen> oops wrong keypoard :p
[19:02] <magespawn> not going to do much here
[19:02] <theblazehen> right :/
[19:02] <theblazehen> busy configuring network boot
[19:02] <inetpro> magespawn: you got a galaxy pocket?
[19:02] <inetpro> why?
[19:02] <Kilos> night all. sleep tight
[19:02] <theblazehen> not sure why though. Everything i want to boot must boot wireless
[19:02] <Kilos> see ya morrow
[19:03] <inetpro> it's a very nice small phone but not for a geek like you
[19:03] <theblazehen> night Kilos
[19:03] <inetpro> good night Kilos
[19:03] <magespawn> night Kilos
[19:06] <magespawn> inetpro have the n900 and a htc flyer, so do not really need, it was a contract renewal
[19:06] <inetpro> hmm...
[19:06] <inetpro> magespawn: even superfly is on the S3 now
[19:07] <magespawn> if i have that then i get a lot of cross over between devices
[19:07] <inetpro> the n900 has had it's day
[19:07] <Cantide> night night '-'//
[19:08] <magespawn> it can still do things the s3 cannot
[19:08] <theblazehen> magespawn, like?
[19:09] <magespawn> audio/video out to a projector
[19:09] <theblazehen> nice :)
[19:09] <magespawn> integrated skype audio and video calling from the phone, no skype software
[19:09] <theblazehen> nice :)
[19:10] <magespawn> and besides i dropped this phone off a bakkie doing about 100kms and hour
[19:10] <inetpro> magespawn: you really use that?
[19:11] <magespawn> i do, but only on wifi or 3G
[19:11] <magespawn> so a little limited out here
[19:12] <magespawn> the s3 is an awesome phone but not really something i would use to its full extent right now
[19:12] <inetpro> magespawn: with a USB to HDMI connector you can connect to any projector with an HDMI input
[19:14] <magespawn> i tend to live in section of the world were most ppl go 'HDMI, whats that?'
[19:14] <theblazehen> magespawn, unfortunately yes :(
[19:15] <magespawn> most of the equipment i come into contact with has rca though
[19:18] <inetpro> magespawn: yikes!
[19:19] <inetpro> even the Raspberry Pi connects to HDMI like that
[19:20] <magespawn> ahh the price i pay for living a stress free life
[19:46] <superfly> oh yeah, the N900 was the best phone ever
[19:46] <superfly> I'm loving my S3, but honestly there are plenty of times I miss my N900
[19:47] <superfly> though it is still lying here in my drawer
[19:47] <magespawn> ah well, good night all
[20:13] <inetpro> superfly: Samsung should build a S3 calibre phone with a keyboard like the N900
[20:14] <superfly> inetpro: no, Samsung should build a N900 calibre phone that runs Android
[20:14] <superfly> the N900 is a solid piece of phone
[20:15] <superfly> as magespawn said, it withstands incredible abuse
[20:15] <inetpro> but it needs the newer processor
[20:15] <inetpro> high spec
[20:15] <superfly> yeah, the better specs of course
[21:09] <Symmetria> heh
[21:09] <Symmetria> beware on that S3
[21:09] <Symmetria> the screens are fragile ;p
[21:09] <Symmetria> very fragile
[21:13]  * inetpro still waiting for the Note II
[22:23] <inetpro> fp


[13:05] <yano> HAPPY INTERNATIONAL CAPS LOCK DAY! https://is.gd/CAPSLOCKDAY
[13:05] <jenni> [ internetonal caps lock day home page ] - https://is.gd
[18:23] <yano> https://www.ubuntu.com/usn/usn-3341-1/
[18:23] <jenni> [ USN-3341-1: Systemd vulnerability | Ubuntu ] - https://bit.ly/2tl1ufa
[20:51] <AntonM> Hi
[20:57] <Unit193> Howdy.
[21:00] <AntonM> Is there anything that could make this group more active?
[21:09] <AntonM> Also, does the mailing list allow OpenPGP?
[21:10] <Unit193> As in, can you send a signed message?  It should do that just fine, sure.  I've used inline gpg on the Xubuntu lists.
[21:11] <Unit193> Sorry I can't answer the first question, I'm not really sure as to how one can make the group be more active.  There used to be Ubuntu Hours, but those seemed to have fizzled out a bit.
[21:28] <AntonM> Does anyone still use the mailing list much? I could ask on there for any ideas.


[03:48] -SwissBot:#ubuntu-news- ::Planet:: Utkarsh Gupta: FOSS Activites in June 2021 @ https://utkarsh2102.com/posts/foss-in-june-21/
[03:48] -SwissBot:#ubuntu-news- ::Planet:: Utkarsh Gupta: FOSS Activites in July 2021 @ https://utkarsh2102.com/posts/foss-in-july-21/
[07:31] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Where configuration management falls short: model-driven OpenStack @ https://ubuntu.com//blog/where-configuration-management-falls-short
[08:32] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: What is OpenRAN @ https://ubuntu.com//blog/what-is-openran
[09:15] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: How Kubernetes 1.22 addresses industry needs @ https://ubuntu.com//blog/how-kubernetes-1_22-addresses-industry-needs
[11:43] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: The new Ubuntu membership process @ https://ubuntu.com//blog/the-new-ubuntu-membership-process
[14:21] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Podcast from the UK LoCo: S14E26 – Amid Navigable Impulses @ https://ubuntupodcast.org/2021/09/02/s14e26-amid-navigable-impulses/
[14:46] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Launching Ubuntu 16.04 (Xenial Xerus) on Oracle Cloud Infrastructure (OCI) @ https://ubuntu.com//blog/launching-ubuntu-16-04-xenial-xerus-on-oracle-cloud-infrastructure-oci
[17:58] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Commissioning deployed machines: Request granted @ https://ubuntu.com//blog/commissioning-deployed-machines-request-granted
[20:47] <madhens> Hello!
[20:49] <Bashing-om> madhens: Uh Huh - :P
[20:56] <madhens> Sorry about that :)
[20:59] <Bashing-om> madhens: Never sorry - you almost walk on water :D
[21:06] <madhens> Bah :) So would this be a good place to meet?
[21:10] <Bashing-om> madhens: For me and UWN it is perfect - but if and only if it good too for you.
[21:13] <madhens> It is :) And if there's a time you already meet during the week I'd be happy to just join that!
[21:17] <Bashing-om> madhens: we are so scattered across the world it is seldom that all are here present at the same time. My life load depends on when I do arrive here daily :P
[21:20] <madhens> You're right - async is so much better!
[21:21] <madhens> I'll post any news bits in here and you all can just comment on them and ask any questions :) Would that work?
[21:21] <Bashing-om> madhens: Be aware this channel is logged: https://irclogs.ubuntu.com/2021/09/02/%23ubuntu-news.txt - I read the log file daily too.
[21:26] <madhens> *nods* Good to know. I am going to make dinner and sign off for the night, but thank you!
[21:27] <Bashing-om> madhens: Have a good one - I just did my dinner over the keyboard :P
[22:33] <Bashing-om> guiverc: repeat: "< madhens> I'll post any news bits in here and you all can just comment on them and ask any questions :) Would that work?" :D
[22:34] <guiverc> work for me, except I don't use bouncer, and rarely remember to read back irclogs so if I'm in room; I'd need to be told like Bashing-om just did
[22:35] <guiverc> (geting me to reliably read irclogs I'm not sure would work.. I'm forgetful & easily distracted etc)
[22:35] <Bashing-om> guiverc: Hey I can do that for you :D
[23:05] <guiverc> thanks Bashing-om !  Life saver once again
[23:08] <Bashing-om> guiverc: Again - ^ in my daily routine - No step for a stepper :D


[00:45] <JPeterson> is bzr switch -b ther same as git checkout -b?
[00:45] <lifeless> effectively
[00:45] <JPeterson> but git checkout -b is instant, bzr switch -b has so far moved 1 g
[00:48] <JPeterson> it seems to copy the entire source to .bzr\checkout\limbo\new-18
[00:48] <JPeterson> after 3 min it returned
[00:48] <JPeterson> bzr: ERROR: Cannot switch a branch, only a checkout.
[00:52] <JPeterson> this http://stackoverflow.com/questions/1645672/local-branches-with-bazaar seems to say branches are not supported
[00:56] <jelmer> JPeterson: it's only supported in bzr 2.6
[00:56] <jelmer> and you'll need to use --force if you're using it in a location that doesnt contain branches already
[00:56] <jelmer> *colocated
[01:18] <lifeless> JPeterson: a shared repository will let switch -b be ~instant.
[01:19] <JPeterson> ah
[08:09] <bacon000> In bzr, is history sacred as in Mercurial, or can it be rewritten as in Git?
[08:10] <bob2> don't think that's a good characterisation
[08:10] <bob2> but bzr-rewrite exists
[08:12] <bacon000> is that a plugin?
[08:13] <lifeless> yes
[08:13] <bob2> git lets you create new history, same as mercurial or bzr
[08:15] <bacon000> I'm coming from the position that history can't be rewritten in Hg without a plugin.  Sounds like bzr has a similar philosophy on this?
[08:17] <bob2> that's a mischaracterisation of hg, but i guess bzr and hg are the same
[08:18] <lifeless> bob2: its the popular understanding.
[08:18] <lifeless> bob2: I think you're being just a little pedantic :)
[08:19] <bob2> heh
[08:20] <lifeless> bacon000: the bzr community treat changing the tip of a public branch to a revision that doesn't include the previous tip as a thing to avoid at nearly-all costs.
[08:20] <lifeless> bacon000: which is I think the key thing you're referring to as being 'history is sacred'
[08:21] <bacon000> yes, i think we're on the same page
[08:26] <bacon000> I don't suppose anyone here is on Windows, are you?  I'm trying to figure out why .bzr.log is stored in my Documents folder.
[08:27] <lifeless> Thats the default, your $HOME
[08:30] <bacon000> I would have thought it would go in \users\bacon000 instead of \users\bacon000\documents.
[14:05] <clyon> Hi! I have some random problems when I try to checkout a branch of GCC or GDB.
[14:05] <clyon> After 20 to 25 minutes, I get: Connection Timeout: disconnecting client after 300.0 seconds
[14:05] <clyon> some other times, it works well.... Any clue?
[15:19] <InvertedVantage> hi everyone
[15:20] <InvertedVantage> I have a question
[15:20] <InvertedVantage> what does it mean when bazaar cannot aquire lock "(local)"?
[15:53] <InvertedVantage> hello?
[16:06] <InvertedVantage> hello! can you help me with something please? how do I release a lock on a file using the GUI interface?
[18:38] <idnar> so I was thinking of hacking my zsh prompt to show me which branch I'm in when I'm in a bzr-colo workspace
[18:38] <idnar> is there a fast way to determine that, though? running bzr every time a prompt is printed probably doesn't count


[20:21] <Guest30362> I guess I need to check into tmux vs screen?
[20:21] <Guest30362> Which, I guess the first step, I need to actually *install* tmux.
[20:25] <Guest30362> well there we go, now I have my terminal split into 4 sections, hah
[20:28] <Guest30362> AAMOF, some of these training sessions I've done with screen that jack up my display when the other user is using something bigger...may get replaced with tmux
[20:28] <Guest30362> hah


[06:01] <pitti> Good morning
[11:44] <Bluefoxicy> awesome
[11:44] <Bluefoxicy> vendor incompatibilities and fragmentation
[11:45]  * Bluefoxicy manually edits /etc/libvirt/qemu/*.xml because 16.10 breaks thanks to a machine type of "pc-i440fx-vivid" instead of just "pc"
[11:49] <sarnold> Bluefoxicy: please talk with cpaelzer if something feels wrong; he's put a lot of effort into making libvirt nice, including some machine type changes
[11:51] <sarnold> Bluefoxicy: oh, I'm sorry, it's Christian Ehrhardt
[11:52] <sarnold> Bluefoxicy: see e.g. https://lists.ubuntu.com/archives/ubuntu-server/2016-September/007411.html
[11:59] <Bluefoxicy> sarnold: nice
[12:03] <Bluefoxicy> sarnold:  the problem with all that is eventually they apparently drop support for machine types, so a machine created 5 releases ago suddenly stops working unless you tinker with it.  There's nothing that says, "Oh, it's like 3 releases back; should we change it to -xenial?"
[12:03] <Bluefoxicy> then you get to -yak and it's dropped -vivid and it goes "OMG WHAT IS THIS?!"
[12:04] <Bluefoxicy> I'll have to file a bug or raise this on the devel-discuss list for further comment
[12:18] <rbasak> Bluefoxicy: FYI cpaelzer is out today and tomorrow so I expect he may not reply until Monday.
[12:19] <rbasak> Bluefoxicy: but please do raise your concerns on the thread. Feedback appreciated.
[12:20] <Bluefoxicy> rbasak:  I might need to use gmane or something to respond to that thread on ubuntu-server since i'm not subscribed
[12:21] <Bluefoxicy> "We're going through a complete rebuild, so some things are very broken. Please see our blog at http://home.gmane.org/ for news."  XD
[12:21] <coreycb> rbasak, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates?  bug 1608934
[12:21] <Bluefoxicy> anyway, I have to go to what is allegedly "work" now
[12:21] <Bluefoxicy> so I'll do that later, after I finish reading web comics for 8 hours.
[12:23] <sarnold> Bluefoxicy: actually it's probably sad news about gmane :( https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/
[12:39] <rbasak> Bluefoxicy: I moderate the list fairly regularly so that shouldn't be a problem - I can let it through. I can also add you to the whitelist when I do that.
[12:40] <rbasak> Bluefoxicy: in general, if you don't want to subscribe to a mailman list but post to it, you can subscribe and immediately disable deliveries. Then you don't hit moderation even if it's subscriber-only. No need for ubuntu-server though.
[12:40] <rbasak> coreycb: I don't have the powers yet. Sorry!
[12:41] <coreycb> rbasak, np :)
[12:41] <rbasak> gmane> :-(
[12:41] <coreycb> pitti, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates?  bug 1608934
[12:42] <pitti> coreycb: not right now; can do another SRU shift tonight, but if it's urgent please ask around for others
[12:42] <coreycb> pitti, it's not urgent, later would be fine
[13:04] <xnox> Laney, http://baturin.org/docs/iproute2/#Delete a link
[13:26] <smoser> nacc, fixing
[13:38] <TheMuso> Anybody have any idea why sbuild is slow for me? I'm using directory based chroots with overlay fs and have both tmpfs and disk based overlay chroots set up. Sbuild takes ages to start downloading deps and building... This on yakkety.
[13:39] <sarnold> 'ages to start' sounds vaguely like dns; there's six second delays if there's failures talking to dns servers in /etc/resolv.conf
[13:40] <smoser> TheMuso, i've seen similar behavior
[13:40] <TheMuso> Nope, not that. I have the same problem at home on another box. Sbuild used to be rather quick in processing build deps required and downloading/buidling.
[13:40] <smoser> not debugged. i suspected kernel upgrade. :-(
[13:40] <smoser> it seems really slow on yakkety.
[13:40] <TheMuso> smoser: Hrm possible... I think I saw it ona 4.4 kernel, but don't have that kernel here to test with. Something to test when xenial has 4.8 I suspect.
[13:40] <smoser> although i can't rule out sarnold's suggestion.
[13:41] <pitti> TheMuso: archive.u.c. seems quite loaded these days, I also get long hangs tryign to download Pacakges.gz or debs (after DNS resolution)
[13:41] <TheMuso> pitti: This is before even starting to download deps, and when at home, I use a mirror in Australia.
[13:41] <smoser> i dont think its archive related.
[13:41] <smoser> yeah.
[13:41] <pitti> well, I wrote it off as post-release slowness; maybe it indeed is something else
[13:41] <smoser> sarnold's suggestion seems plausible to me
[13:42] <smoser> with addition / usage of systemd-resolvd
[13:42] <TheMuso> Well, I am here at the sprint using archive.conference... and its still slow.
[13:42] <pitti> the other day I had three dozen dnsmasq instances spawned by NM which made DNS slow -- can you check?
[13:42] <TheMuso> i.e I changed my chroots to use archive.conference directly.
[13:42] <sarnold> 12 packets transmitted, 8 received, 33% packet loss, time 11041ms
[13:42] <sarnold> ow
[13:42] <TheMuso> Still one instance.
[13:42]  * sarnold hugs mosh
[13:43] <TheMuso> i.e only one instance of dnsmasq.
[13:44] <TheMuso> I don't *think* its network, unless sbuild does a lot of network stuff at the beginning while its working out deps to download.
[13:45] <TheMuso> And I think its not even schroot created, because I can update my chroots just as quickly as I have been able to in the past.
[13:45] <TheMuso> related*
[13:45] <TheMuso> Anyway, I *may* have a 4.4 kernel on my yakkety install at home, so will check when I get back and test if so.
[14:27] <pitti> TheMuso: oh right -- when I start sbuild, my load goes up to 50; might be another fallout of bug 1626436
[15:48] <smoser> pitti, around ?
[15:48] <smoser>  https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=ifupdown
[15:49] <smoser> what shal i do about that ? i can just upload it to zesty..
[15:50] <pitti> smoser: yeah, sounds better now; we have a new gcc, binutils etc, and zesty is fully open
[15:50] <pitti> so we shouldn't do binary copies any more at this point (just for the 0-day ones)
[15:53] <smoser> pitti, then go ahead and NACKK that
[15:54] <pitti> smoser: why that? the fix is good?
[15:55] <smoser> becuse i would update the ubuntu3 to zesty
[15:55] <smoser> so the one in yakket-proposed need to have version adjusted
[15:55] <smoser> no ?
[15:56] <pitti> smoser: or just upload to zesty as ubuntu4?
[15:57] <pitti> smoser: I mean, I'm fine with rejecting if you prefer "nicer" version numbers, but I don't think it's a requirement
[15:57]  * pitti needs to go AFK for a bit
[16:02] <smoser> pitti, thats fine too.
[16:02] <smoser> i'll upload as ubuntu4 "no change rebuild" ?
[16:10] <pitti> smoser: or "* upload to zesty" (and use -v to include the previous record)
[16:11] <smoser> pitti, i dont understnd that.  i need the new version, right?
[16:18] <nacc> rbasak: do we want upload/ tags to be annotated to the developer or the uploader?
[16:22] <sinzui> hallyn: Do you have any sight into this lxc1 error on s390x? https://pastebin.canonical.com/168526/
[16:33] <rbasak> nacc: the person running the importer, I think.
[16:33] <rbasak> Since it's both a confirmation of the version but also how it was done.
[16:33] <sinzui> stgraber: ^ mayeb you have insight into https://pastebin.canonical.com/168526/
[16:33] <rbasak> Whereas a commit tries to be exactly what the person uploaded.
[16:35] <stgraber> sinzui: you shouldn't use pastebin.canonical.com for public pastes
[16:35] <nacc> rbasak: ack, the upload tag itself is created outside the importer, though
[16:35] <nacc> rbasak: import tags will be annotated to the user running the importer, to be clear
[16:35] <nacc> rbasak: but upload tags are part of the review process now, in theory
[16:35] <sinzui> stgraber: sorry, the paste has circulated. I can redo in ubuntu. nothing secret in it
[16:36] <stgraber> sinzui: if you want hallyn to be able to see it, you'd have to since he's not at Canonical anymore :)
[16:36] <stgraber> sinzui: anyway, that error usually comes from lack of seccomp support in the kernel
[16:36] <sinzui> stgraber: well that aligns with the fact we got a new kernel
[16:37] <sinzui> stgraber: do you recommend I look for a downgrade?
[16:38] <stgraber> sinzui: I'm looking at something real quick, it could be that this is caused by LXC 2.0.5 now supporting seccomp on s390x
[16:38] <stgraber> just confirming that it's indeed something that was "fixed" in 2.0.5 (lack of seccomp support on s390x) which could cause this regression
[16:38] <sinzui> stgraber: 2.0.5-0ubuntu1~ubuntu16.04.1 was installed recently
[16:39] <stgraber> sinzui: right, confirmed that s390x seccomp support was added to LXC 2.0.5, previous one was skipping seccomp entirely which would explain why it was working
[16:40] <stgraber> sinzui: checking when s390x seccomp support was added to the kernel, to see if it's just a missing config in our kernel that'd fix that cleanly or if we'd need it backported to 4.4 which would be a bit more annoying
[16:41] <stgraber> hmm, that was the 3.6 kernel supposedly, so a bit confused as to why we wouldn't have it in our 4.4
[16:42] <stgraber> sinzui: config-4.4.0-45-generic is what you're running right?
[16:43] <stgraber> hmm, so I see it enabled in that kernel, not sure what's going on then
[16:43] <sinzui> stgraber uname-a says 4.4.0-45-generic
[16:43] <stgraber> ok, let me reboot my s390x system to run on that kernel and LXC and see what's going on
[16:46] <stgraber> sinzui: reproduced the issue here
[16:47] <sinzui> I suppose I could cheer
[16:48] <stgraber> sinzui: you can workaround it by putting a file with lxc.seccomp= in /usr/share/lxc/config/common.conf.d/, that should get you going again
[16:48] <sinzui> stgraber: I will try
[16:49] <stgraber> sinzui: got one of my guys looking at it now
[16:51] <sinzui> thank you stgraber : have a working container. I will let the build scripts try to do the same
[16:52] <stgraber> obviously once we sort it out, it'll be good to remove that file as seccomp is a useful security feature
[16:52] <stgraber> but since 2.0.4 didn't support it at all, it's no worse at least :)
[16:54] <smoser> Subject: [ubuntu/zesty-proposed] ifupdown 0.8.13ubuntu4 (Waiting for approval)
[16:54] <smoser> is that by design ?
[16:55] <smoser> "waiting for approval"
[17:02] <stgraber> smoser: see topic, not open yet
[17:03] <smoser> fudge.
[17:04] <smoser> well, i have two waitin for approval.
[17:29] <stgraber> slangasek: looks like LP is returning those OOPS right now, turned off cron
[17:29] <stgraber> slangasek: trying to get an LP URL from import-images
[17:33] <stgraber> slangasek: ok, so LP does return a 500, so someone will need to fix the importer to properly detect and deal with those, since apparently urlretrieve doesn't trigger an exception on those
[17:33] <stgraber> slangasek: the URL that's failing to import is https://git.launchpad.net/~device-release/turbo/+git/device_tarball/plain/device.tar.xz?h=candidate
[17:33] <stgraber> sil2100: FYI ^
[17:34] <stgraber> so current state is cron disabled and sil2100's e-mail address marked as the target for cron mail when re-enabled
[17:35]  * stgraber gets back to being off
[17:35] <nacc> slangasek: have a quick q for you re: a package in 16.04 that was technically unmaintained upstream at the time (mkstutil). There is LP: #1568714 for it, and a fix provided. However, that fix is not what upstream did (because upstream removed the feature completely (https://sourceforge.net/p/msktutil/code/ci/19066f9777a19b6fda8c62e7774b4bb2157eb32a/)). I feel like there are three options: 1) SRU the
[17:35] <nacc> maintained version from yakkety back to xenial; 2) just take the submitted patch, although it's not identical to upstream's changes, as it has been tested to fix the issue; 3) backport the upstream fix, but that changes the supported features for the package (even if the supported feature was arguably buggy per upstream).
[17:35] <nacc> slangasek: not urgent to provide input, but any advice you could give on which would be preferred would be appreciate it
[17:39] <stgraber> sinzui: status update is that it's not a LXC or kernel bug, xenial's libseccomp was patched to add s390x support but apparently incorrectly so, so LXC detects support, uses it but then the library fails to set things up somehow. We're still digging and will most likely send a SRU for libseccomp in xenial
[17:40] <koike> cjwatson, hey, you are one of the grub2 maintainers right? In debian we need to create a monolithc version of grub in the arquives to be able to sign it with all its modules, is it ok if I change the packages like grub-efi-amd64-bin_2.02~beta3-1_amd64.deb to build a monolithic version of grub? Or maybe to create something like grub-efi-monolithic-amd64-bin_2.02~beta3-1_amd64.deb ?
[17:49] <koike> cjwatson, so I would like your opinion about the solution before I start working on it
[17:55] <slangasek> stgraber: AFAICS the HTTP code isn't even returned at all by urlretrieve(), I don't see it as part of the returned headers struct
[17:56] <slangasek> nacc: was this upstream feature usable at all, or was it completely broken by the above bug?
[17:57] <nacc> slangasek: it's hard to say; the above bug is a stack smash that makes the tool itself unusable regarldess of the feature (ldaps + tls). It seems like the upstream feature (ldaps + tls) never worked, though.
[17:58] <slangasek> nacc: I don't object to an SRU that removes a broken and unusable feature in order to leave the package usable for other purposes.  I would object to an SRU removing a feature that might be broken for some people in some circumstances, but usable in others
[17:59] <nacc> slangasek: ack, that makes sense, i'll do some more examination
[18:08] <sinzui> stgraber: Is there a bug I can track so that I know when to remove my hack?
[18:18] <stgraber> sinzui: we'll file one on LP once we're sure where the problem is
[18:18] <stgraber> slangasek: right, but my (clearly wrong) expectation was that it'd raise an exception as it does for the other error cases (timeouts and such)
[18:43] <smoser> why does this not work?
[18:43] <smoser>
[18:43] <smoser> # hostnamectl status
[18:44] <smoser> in a container doesnt work.
[18:44] <smoser> horay
[18:50] <stgraber> smoser: looks like a systemd thing
[18:50] <stgraber> Oct 20 18:49:36 yak systemd[6322]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied
[18:50] <stgraber> [62189.667647] audit: type=1400 audit(1476989376.082:576): apparmor="DENIED" operation="file_lock" profile="lxd-yak_</var/lib/lxd>" pid=19491 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none
[18:51] <stgraber> so maybe an apparmor bug actually because I can't think of why our profile would block this
[18:54] <jgrimm> stgraber, smoser: confirmed xenial container behaves that way.  trusty container worked tho
[18:55] <stgraber> jgrimm: would make sense since trusty wasn't using systemd
[18:55] <jgrimm> yep
[18:55] <stgraber> jgrimm: running hostnamed directly by hand works fine too
[18:56] <smoser> stgraber, running hostnamed ?
[18:56] <stgraber> smoser: in a shell, run "/lib/systemd/systemd-hostnamed", in another, run hostnamectl :)
[18:58] <slangasek> xnox: yay, new jitsi is dep-wait ;)
[18:59] <smoser> what a pit
[18:59] <smoser> pita
[19:12] <pitti> smoser: yes, but use -v...ubuntu2 to include the ubuntu3 revision to
[19:13] <smoser> pitti, i did. thanks
[19:27]  * pitti goes for a round of SRU review
[19:41] <pitti> cyphermox: so your initramfs-tools 0.125ubuntu6.1 in the unapproved queue refers to bug 1631474 which is already closed (fixed by the previous SRU)
[19:41] <pitti> cyphermox: typoed the bug #? if the reversion should use the same bug, can you please reopen and adjust the description?
[22:08] <cjwatson> koike: no, don't do that, I'll be switching on the Ubuntu patch set to implement signed GRUB builds as soon as Debian has the necessary signing implementation in place; you'd be wasting your time working on it since it's already implemented
[22:10] <koike> cjwatson, but in Ubuntu the grub2 package doesn't publish a monolithic version, does it? To make grub-signed build reproducible we need this available, so grub-signed can depend on it
[22:11] <cjwatson> koike: yes it does, debian/build-efi-images produces that as a custom upload
[22:11] <cjwatson> koike: I'm not going to add another binary package, it's already complicated enough!
[22:12] <cjwatson> koike: we shouldn't need another binary package for reproducibility, we just need grub-mkimage's output to be reproducible given the same inputs
[22:13] <cjwatson> koike: which if it's not the case today shouldn't be far off
[22:15] <cjwatson> koike: I'm totally happy to take patches to improve reproducibility BTW, I think that's an excellent goal, just want to make direction clear
[22:17] <koike> cjwatson, sure, thanks for your feedback, I am checking some other things that I am not entirely sure about, I'll also get some opinion at #debian-efi too
[22:18] <cjwatson> koike: the other thing I want to do is integrate Mathieu's Ubuntu patches for better MOK integration, which I think can be done in Debian as well now and would make it possible to require signed kernels
[22:18] <cjwatson> but ETIME
[22:24] <koike> cjwatson, I see, ETIME is a problem indeed. Could you send me a link to these patches (I am having some trouble finding them)
[22:26] <cjwatson> koike: I think they're in people/cyphermox/<somethingorother> in the Debian git repository, though not sure if they're up to date; the current Ubuntu source package can be found at https://launchpad.net/ubuntu/+source/grub2
[22:26] <cjwatson> I'm hoping I can nag cyphermox into submitting them in a form I can easily apply :)
[22:26] <cjwatson> (possibly simpler after rebasing on 2.02~beta3-1)
[22:27] <cyphermox> there is that
[22:27] <cyphermox> you mean the patches for the new shim filenames?
[22:27] <cjwatson> cyphermox: I meant the whole mokutil workflow with the extra debconf questions and such
[22:27] <cyphermox> ah, ok
[22:28] <cyphermox> that's removed from grub, actually. here's hoping there isn't anything left
[22:28] <cyphermox> all moved to shim-signed
[22:28] <cjwatson> and obviously anything else that seems relevant, I'd like to get back in sync but of course with cherry-picked patches and such it's a fair bit of source to compare
[22:29] <cyphermox> if beta3 is ready in the git branch I can get you the other patches ready
[22:29] <cjwatson> cyphermox: it's in unstable, though indeed in git too
[22:30] <cyphermox> ok, I hadn't noticed, been busy with other things
[22:30] <cyphermox> I'll want to get beta3 in zesty anyway though
[22:43] <nacc> is it a known bug in `apt-get changelog that when a source package lives in main but has binaries published in universe (e.g., qemu), it tries to load a changelog from universe?
[23:32] <nacc> I noticed just now that there is a 'new' -u option for rmadison to look at the debian new queue. Is the ubuntu new queue exposed similarly?