[05:55] <rowz> hi i just installed guest additions on xubuntu 20.4.2 but it didn't work, i tried reinstalling then i found it says system currently not set up to build kernal modules please install gcc make perl packages
[05:56] <rowz> i didn't have this issue when i tried 20.4.1
[05:58] <diogenes_> rowz, so install those.
[05:59] <rowz> i did, restarted but it still doesn't work diogenes_
[06:47] <tomreyn> rowz: question 1: you're probably referring to virtualbox? which packages are you using, those from ubuntu, or those from virtualbox?
[06:47] <tomreyn> rowz: question 2: hvae you run    sudo apt install build-essential    and then   sudo /bin/vboxconfig
[06:48] <tomreyn> rowz: question 2: hvae you run    sudo apt install build-essential    and then   sudo /sbin/vboxconfig    ?
[06:48] <tomreyn> ^ typo fixed
[07:03] <rowz> thanks


[16:00] <cpaelzer> o/
[16:00] <powersj> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Feb 28 16:00:17 2017 UTC.  The chair is powersj. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <meetingology> Available commands: action commands idea info link nick
[16:00] <rharper> \o
[16:00] <powersj> I'll wait a moment to get a few more folks
[16:00]  * jgrimm waves, but not paying attention. in another meeting
[16:01] <nacc> \o
[16:01] <rbasak> o/
[16:01] <powersj> alright let's get started
[16:01] <powersj> #topic Review ACTION points from previous meeting
[16:02] <powersj> nacc to review jgrimm's openvpn MR
[16:02] <nacc> i believe that's done
[16:02] <jgrimm> merged, done
[16:02] <powersj> great! next...
[16:02] <powersj> jgrimm to review server packages for anything new (or missed) that needs merging
[16:03] <jgrimm> ongoing. mark done
[16:03] <powersj> he may be busy as he said... I can follow up after
[16:03] <powersj> ah ok :)
[16:03] <powersj> one more...
[16:03] <powersj> rbasak to look at seeding iotop & nicstat with powersj
[16:03] <powersj> done!
[16:03] <rbasak> \o/
[16:03] <nacc> let's release already :)
[16:03] <nacc> we're so done
[16:03] <powersj> all action points done :D
[16:03] <rharper> heh
[16:03] <powersj> #topic Zesty Development
[16:03] <powersj> #link https://wiki.ubuntu.com/ZestyZapus/ReleaseSchedule
[16:03] <powersj> #subtopic blueprints
[16:04] <powersj> #https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core
[16:04] <powersj> I see 7 inprogress
[16:04] <powersj> any updates here?
[16:05] <nacc> excuses is a lot clearer now -- still working through some updates, but i think our bigger packages are through, except for openldap
[16:05] <rbasak> Don't forget to keep minuting things - easy to forget :)
[16:05] <powersj> cool!
[16:05] <powersj> ah yes
[16:06] <nacc> i'll do another sweept today -- my current unknown blocker is the log4ada regression
[16:06] <powersj> #info blueprint is looking good, big stuff done, except openldap
[16:06] <powersj> #subtopic Release Bugs
[16:06] <powersj> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-z-tracking-bug-tasks.html#ubuntu-server
[16:07] <powersj> Anything of note here? nacc you are only one with something, 2 unassigned
[16:07] <nacc> powersj: that is getting deferred to z+1
[16:07] <cpaelzer> the libvirt one will be an SRU
[16:07] <nacc> i'm workingon setting maas up for it by then
[16:07] <cpaelzer> it is super low importance
[16:07] <cpaelzer> I might even nack an SRU on a deeper look
[16:07] <nacc> cpaelzer: we may want to re-ping the release team on remving src:postgresql-9.6 on irc
[16:08] <cpaelzer> oh yeah - ack nacc
[16:08] <nacc> cpaelzer: actually, i'll do it today, if htat's ok
[16:08] <nacc> need to remove php7.1 as well
[16:08] <powersj> #action cpaelzer to ping release team on removing src:postgresql-9.6
[16:08] <meetingology> ACTION: cpaelzer to ping release team on removing src:postgresql-9.6
[16:08] <cpaelzer> absolutely
[16:08] <powersj> oops lol
[16:08] <powersj> #undo
[16:08] <meetingology> Removing item from minutes: ACTION
[16:08] <cpaelzer> nacc: highlight me on the ping and let them know that it is you-or-me to contact
[16:08] <cpaelzer> we cover almost all timezones together
[16:08] <nacc> cpaelzer: ack
[16:09] <powersj> #action nacc to ping release team on removing src:postgresql-9.6 and src:php7.1
[16:09] <meetingology> ACTION: nacc to ping release team on removing src:postgresql-9.6 and src:php7.1
[16:09] <powersj> any other release bug comments or I'm moving on....
[16:09] <powersj> #info looking good, minor issues for libvirt, otherwise covered
[16:09] <powersj> #topic Server & Cloud Bugs & SRU/Pending Uploads (caribou)
[16:09] <powersj> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server
[16:10] <powersj> caribou: any update?
[16:10] <caribou> oops, sorry forgot to prepare,just give me a minute
[16:10] <powersj> ok :)
[16:10] <cpaelzer> I have mine of the week prepped
[16:10] <cpaelzer> DONE: Strongswan (X,Y), Multipath (X), Qemu (X,Y,UCA)
[16:10] <cpaelzer> INPROG: Qemu (T), Qemu (X,Y), Libvirt (T/X/Y/Z)
[16:10] <cpaelzer> The Qemu X/Y is complex and stuck in testing and dev discussions at the moment
[16:10] <cpaelzer> The multipath is actually just helping STS so this will be in Caribous list
[16:11] <caribou> #info SRU are pending for : ceph, libvirt, sosreport, multipath-tools, python-os-brick, sssd
[16:11] <cpaelzer> caribou: can you link me the incoming libvirt SRU?
[16:11] <cpaelzer> trusty?
[16:12] <caribou> cpaelzer: LP: #1317491
[16:12] <cpaelzer> ah yeah I'm on that - thanks
[16:12] <powersj> caribou: great, thanks. Any other comments?
[16:13] <caribou> powersj: nothing else, no
[16:13] <powersj> great
[16:14] <powersj> moving on.
[16:14] <powersj> #topic Weekly Updates & Questions for the QA Team (powersj)
[16:14] <powersj> #link https://jenkins.ubuntu.com/server/
[16:14] <powersj> Last week got the JLP merge request in and merged, so we should be able to see cloud-init git based CI in the next week or two. There is a remaining piece of functionality that I do not have done yet though, but not required for our use case.
[16:14] <powersj> Lots of changes and modifications to curtin vmtests to make them more stable. I have a list of things I still need to get done and hope to do this week.
[16:14] <powersj> Worked with Christian on QEMU migration tests, however finding the LXD is really running into issues now on our main test system even launching a container. See https://github.com/lxc/lxd/issues/2814 I need to get this cleaned up as most of our tests rely on LXD.
[16:14] <powersj> questions?
[16:14] <cpaelzer> powersj: we can go on using dir instead of zfs for now
[16:15] <powersj> cpaelzer: I'd like to avoid that, as it is incredibly slower and makes some other tests time out
[16:15] <cpaelzer> powersj: that never has shown the bug - and yes slower sometimes, but better than not at all
[16:15] <powersj> true
[16:15] <powersj> #info ci for cloud-init coming soon...
[16:15] <cpaelzer> actually I have cases wher eit is faster btw, but if we have timeouts on cloud-init/curtin ok
[16:15] <powersj> #info lxd issue, slowing down/stopping testing
[16:16] <powersj> ok we can play with it after the meeting
[16:16] <cpaelzer> ack powersj
[16:16] <powersj> I would like to get the lxd guys on the system if possible though to help resolve this
[16:16] <cpaelzer> yep I suggested the same last time
[16:16] <rharper> sounds like an action
[16:17] <powersj> #action powersj to see about getting the lxd team onto torkoal
[16:17] <meetingology> ACTION: powersj to see about getting the lxd team onto torkoal
[16:17] <powersj> any other questions?
[16:17] <powersj> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee)
[16:18] <powersj> Not sure I see either of them
[16:18] <cpaelzer> ping smb he was around
[16:19] <cpaelzer> here he is
[16:19] <smb> sorry got distracted
[16:19] <smb> So, mostly to mention that 4.10 should now be in the zesty archive
[16:19] <powersj> #info zesty archive should have 4.10
[16:20] <powersj> awesome, thank you!
[16:20] <rharper> smb: I filed a bcache bug last week
[16:20]  * rharper finds
[16:20] <smb> rharper, have not seen it, maybe you could subscribe me
[16:21] <rharper> smb: ok
[16:21] <cpaelzer> ah kernel
[16:21] <cpaelzer> FYI - debugged a regression mainline 3.18.22-031822.201510031227 to mainline 3.18.21-031821.201509020527 today. Covers all that crosses that like Trusty -> Xenial.
[16:21] <cpaelzer> TL;DR for server raid arrays there might be a performance regresssion, read bug 1668557 if yu need details and a tuning fix.
[16:21] <rharper> bug 1667078
[16:21] <cpaelzer> mine is a kernel fix that "has to stay" but will cause trouble for some upgrades
[16:21] <cpaelzer> so for awareness towards smb and caribou
[16:21] <rharper> smb: subscribed; thanks
[16:22] <smb> rharper, thanks
[16:22] <smb> cpaelzer, and also thanks
[16:22] <powersj> anything else for kernel?
[16:22] <powersj> #topic Upcoming Call For Papers
[16:23] <powersj> #link https://lwn.net/Calendar/Monthly/cfp/
[16:23] <powersj> I didn't see anything here
[16:23] <powersj> anyone have something, otherwise moving on
[16:23] <powersj> #info nothing here
[16:23] <powersj> #topic Ubuntu Server Team Events
[16:23] <powersj> not aware of anything here either
[16:23] <powersj> #info nothing here
[16:24] <powersj> #topic Open Discussion
[16:24] <powersj> *crickets*
[16:25] <powersj> anything? otherwise I'll end this
[16:25] <cpaelzer> ah
[16:25] <cpaelzer> here
[16:25] <powersj> ah :)
[16:25] <cpaelzer> I was triaging a lot recently and I wondered if it might be worth to have a nginx-triaging-style page also for mysql
[16:25] <cpaelzer> rbasak: ^^
[16:25] <cpaelzer> (I know he is not here)
[16:25] <powersj> yes please
[16:26] <cpaelzer> it turns out 80% of the bugs are actually different variants of three issues
[16:26] <cpaelzer> socket not reachable, user misconfigured, old features enabled that no more work
[16:26] <cpaelzer> maybe together we can make it 5 which cover >90%
[16:26] <cpaelzer> maybe this could be an actiaon for rbasak, powersj and me
[16:26] <cpaelzer> action rather
[16:26] <powersj> agreed
[16:26] <cpaelzer> make a draft wiki page
[16:27] <cpaelzer> and on triaging link to that and be faster so often
[16:27] <powersj> #action rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has
[16:27] <meetingology> ACTION: rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has
[16:28] <cpaelzer> now even I'm silent - I know it is a rare thing :-P
[16:28] <powersj> cpaelzer: did you catch nacc up on triaging?
[16:28] <cpaelzer> I did not want to say in pub, but yes
[16:28] <powersj> well thank you
[16:28] <nacc> yes, many thanks to cpaelzer !
[16:28] <cpaelzer> ~+15 for ubunut-server to look deeper into
[16:28] <powersj> haha
[16:29] <cpaelzer> the magical Ubu  Nut - cracking
[16:29] <powersj> last call, any other topics?
[16:29] <cpaelzer> https://dudleys.files.wordpress.com/2008/02/ubunut.jpg
[16:29] <powersj> #topic Announce next meeting date, time and chair
[16:29] <cpaelzer> the ubunut
[16:29] <powersj> same time, same place, with cpaelzer as chair
[16:29] <cpaelzer> damn
[16:29] <cpaelzer> ack
[16:29] <powersj> o/
[16:30] <powersj> #endmeeting
[16:30] <meetingology> Meeting ended Tue Feb 28 16:30:00 2017 UTC.
[16:30] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-02-28-16.00.moin.txt
[16:30] <cpaelzer> o//
[16:30] <rharper> powersj: double thanks!
[16:34] <rbasak> cpaelzer: yeah, that's a good idea. Sorry, the electrician is busy electrocuting himself and tripping circuits right now )
[16:34] <cpaelzer> oO
[16:34] <rbasak> He appears to be less paranoid about I am about the wiring in this house.
[17:05] <tsimonq2> <___< ... o.o ... >___>


[10:49] <hito_jp> in Oneirc, /var/lib/dbus/machine-id is seems static(same value across another machine that use same installe-media), is it expected? (I think not, see also: LP#322830 )
[10:49] <hito_jp> I(and mizuno_as) tested with Oneirc semi-final daily (http://cdimage.ubuntu.com/daily-live/20111011/oneiric-desktop-i386.iso), the image have "squash::var/lib/dbus/machine-id", that has "df047b0c173fb774ce815e2c0282fb20". And, installed machine*s* too.
[10:58] <CIA-45> ubiquity: evand * r5071 trunk/ (debian/changelog ubiquity/nm.py):
[10:58] <CIA-45> ubiquity: Expand the list of wireless networks under each card automatically,
[10:58] <CIA-45> ubiquity: unless the user has explicitly collapsed the row.
[11:02] <cjwatson> hito_jp: hmmm
[11:03]  * cjwatson adds a task to bug 322830
[11:03] <ubot2> Launchpad bug 322830 in livecd-rootfs "remove /var/lib/dbus/machine-id from installed image" [Undecided,Fix released] https://launchpad.net/bugs/322830
[11:03] <cjwatson> infinity: ^-
[11:03] <hito_jp> cjwatson: In natty, that file are not included.
[11:04] <cjwatson> yes
[11:04] <cjwatson> this is because we switched to live-build in oneiric
[11:04] <cjwatson> we're considering this for a respin noww
[11:04] <cjwatson> *now
[11:08] <hito_jp> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/872788 by original reporter (mizuno-as)
[11:08] <ubot2> Launchpad bug 872788 in dbus "remove /var/lib/dbus/machine-id from installled image" [Undecided,New]
[11:09] <hito_jp> Ah, now writing the Bug Description :)
[11:11] <cjwatson> I'm going to dup that
[11:13] <hito_jp> Okay, thanks.
[11:14] <cjwatson> thank you for escalating
[11:14] <cjwatson> that was the right thing to do at the right time
[13:15] <CIA-45> ubiquity: evand * r5072 trunk/ (4 files in 3 dirs): Translate the entire wireless networking page.
[17:46] <CIA-45> ubiquity: evand * r5073 trunk/ (debian/changelog ubiquity/plugins/ubi-webcam.py):
[17:46] <CIA-45> ubiquity: Don't show the picture taking page when running in an oem-config
[17:46] <CIA-45> ubiquity: install.
[19:45] <CIA-45> ubiquity: evand * r5074 trunk/ (3 files in 3 dirs):
[19:45] <CIA-45> ubiquity: Don't show the wireless page if a wireless connection was made after
[19:45] <CIA-45> ubiquity: ubiquity started (LP: #873000).
[20:47] <bdmurray> bug 870696 is rather odd
[20:47] <ubot2> Launchpad bug 870696 in ubiquity "Oneiric pre-release ubiquity does not load all the translations" [High,Confirmed] https://launchpad.net/bugs/870696


[02:14] <krytarik> Bashing-om: "* Epic Games Store..." - there is a missing space in front of this bullet-point item, thus leading to it being printed as-is.  Otherwise looks good though!
[02:21] <Bashing-om> krytarik: Well ! could be lot's worse :P .. will fix that -- I had the feeling I was missing something there - just could not see it :(
[08:10] <guiverc> I just completed read thru of UWN576 - looks great.    (missive; haven't seen that word in decades - did you need a thesaurus to find it??)
[08:11] <Bashing-om> guiverc: Naw - just have a wierd mind :P
[08:11] <guiverc> LOL
[10:16] -SwissBot:#ubuntu-news- ::Planet:: Stuart Langridge: Three HomeSignal femtocell for bad coverage @ https://www.kryogenix.org/days/2019/04/29/three-homesignal-femtocell-for-bad-coverage/
[12:51] -SwissBot:#ubuntu-news- ::Planet:: Rhonda D'Vine: Lesbian Visibility Day @ https://rhonda.deb.at/blog/2019/04/29#lesbianvisibilityday
[13:45] <lotuspsychje> i just got softpedia rss working again on limnoria
[13:45] <lotuspsychje> https://news.softpedia.com/newsRSS/Linux-7.xml
[14:45] -SwissBot:#ubuntu-news- ::Planet:: Jono Bacon: An Example Of Open Source Community Engagement Done Well @ https://www.jonobacon.com/2019/04/29/open-source-example/
[14:45] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: How to Re-Enable Dynamic Transparency on the Ubuntu 19.04 Desktop @ https://www.omgubuntu.co.uk/?p=141607 (by Joey Sneddon)
[18:30] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Weekly News #128 @ https://fullcirclemagazine.org/podcast/full-circle-weekly-news-128/
[19:06] <Bashing-om> Pulling WIP. Target time to publish remainns the norm at 20:00 GMT.
[20:02] <Bashing-om> M/L is away .. doing the forum post next.
[20:06] <Bashing-om> Forum posted .. doing the re-directs.
[20:18] <Bashing-om> Re-directs also done. Pending is the social medias that I have no access for.
[20:40] <Bashing-om> Gone for a nap . back soonest to finish up.
[21:47] <Bashing-om> Back and lurking :P
[22:25] <guiverc> :)   Can I push UWN576 to fridge - lurkers are welcome to be a 2nd
[22:25] <Wild_Man> yes guiverc
[22:25] <guiverc> Thanks Wild_Man
[22:26] <Wild_Man> I am just waking from a nap, I am still groggy
[22:29] <Bashing-om> I am recovering from that cold - I did my spiriva for my breathing ,, and thought I was going to have a heart attack - my lungs now that clear ? - Just now settleing down after 2 hours !
[22:31] <Wild_Man> Sounds bad Bashing-om , wishing you a speedy recovery
[22:32] <Bashing-om> Wild_Man: Thanks ,, I am over my fright - able now to maintain focus :)
[22:33] <Wild_Man> That is good
[22:34] <guiverc> http://fridge.ubuntu.com/2019/04/29/ubuntu-weekly-newsletter-issue-576/
[22:35] <Wild_Man> Thanks guiverc
[22:36] <Bashing-om> guiverc: Fridge looks good and my spot check checks good too :P
[22:39] <guiverc> mewe (as me) & twitter done
[22:45] <Bashing-om> guiverc: Wild_Man:: clear now to wipe Gdoc and we start UWN577 ?
[22:45] <guiverc> fb done too now.
[22:45] <Wild_Man> Thanks guiverc
[22:48] <guiverc> yep Bashing-om.
[22:48] <Wild_Man> yes Bashing-om
[22:50] <Bashing-om> Will wipe Gdoc soonest :)
[22:58] <Wild_Man> I have to feed my cat real quick
[23:09] <Bashing-om> We do UWN577 :D
[23:10] <Unit193> https://lists.ubuntu.com/archives/ubuntu-security-announce/2019-April/004870.html and https://lists.ubuntu.com/archives/ubuntu-security-announce/2019-April/004871.html are dead links.
[23:14] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 576 @ http://fridge.ubuntu.com/2019/04/29/ubuntu-weekly-newsletter-issue-576/
[23:18] <Wild_Man> Bashing-om, are you looking at the links Unit193 posted?
[23:19] <Wild_Man> I can remove them but do you want to try to fix them?
[23:19] <Wild_Man> Thanks Unit193
[23:19] <Bashing-om> Unit193: Thanks ! will edit out .. Wild_Man : yup.
[23:20] <Unit193> Wild_Man: Sure thing, I used to check the pages before release years ago. :P
[23:21] <Wild_Man> I see, we appreciate the extra eyes
[23:22] <Bashing-om> Unit193: I can stand the instruction, how did you determine the dead links ?
[23:23] <Unit193> `linkcheck $WIKILINK`
[23:24] <Bashing-om> Unit193: Looking and learning :P
[23:34] <Bashing-om> Wild_Man: As they ^ are dead I am going to just delete them from the WIKI.
[23:34] <Wild_Man> Bashing-om, that works for me
[23:41] <Wild_Man> Bashing-om, I can remove them if you want me too?
[23:49] <Bashing-om> Wild_Man: Done the deletions to both the WIKI and the forum postings.// And linkchecker is a native package in ubuntu :)
[23:50] <Wild_Man> Thanks Bashing-om
[23:51] <Bashing-om> Wild_Man: Just taking care befor going back to support and TuG'n :P
[23:52] <Wild_Man> I have to eat real quick and do a little support as well
[23:53] <Unit193> Bashing-om: Not sure if that one works as expected, I think I remember looking into that a while ago.
[23:59] <Bashing-om> Unit193: My results are not stellar :( . I ran "linkchecker https://lists.ubuntu.com/archives/ubuntu-security-announce/2019-April" and got "That's it. 379 links in 52 URLs checked. 0 warnings found. 0 errors found.". Save me some hunting and tell me what I did wrong ?


[07:48] <alf_> duflu: for https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653 , would you mark the status for Mir Invalid or Fix Released?
[07:49] <duflu> alf_: So invalid that I would delete the Mir task :)
[07:50] <duflu> It's only useful to keep "Invalid" around if there's a chance someone else might come along and blame that project/package latert
[07:51] <alf_> duflu: unfortunately, there is no good way in LP to associate a bug with a project. We can only mark it as "also affects project", but that to LP means that the project is somehow responsible for the bug, not just affected by it...
[07:52] <duflu> alf_: I know, but technically more correct to not mention Mir or affected projects, in the absence of loose associations
[07:53] <alf_> duflu: I think it's useful to mark it as affecting at least up to a point, so we can locate issues affecting Mir easily even if they are in other projects. Anyway, I agree it makes sense to complete remove the association now, so I did so.
[07:54] <duflu> alf_: I understand the desire. Keep in mind however that LP won't return "Invalid" or "Opinion" bugs in searches
[07:54] <duflu> You have to do an Advanced search
[07:57] <duflu> alf_: Also Fix Released bugs will not appear in searches. This is why I find a good email client to be more effective in finding bugs I've seen before
[07:57] <duflu> That and LP has some substring searching issues. I forget the details
[09:21] <anpok> duflu: alan_g alf_: should I refrain from making changes in the android input stuff in 3rd_party - as we might at some point integrate a newer version of it?
[09:22] <anpok> Or is adding additional methods to some of the interfaces fine..
[09:22] <duflu> anpok: We've asked that question a few times now. I think the current answer is "modify it because we have modified it plenty already"
[09:22] <alan_g> anpok: no. It's already a fork
[09:22] <anpok> ok good
[09:23]  * alan_g reboots
[12:34] <ogra> hmm
[12:35] <ogra> so stopping unity-system-compositor on a flo device (new N7 ... our new default tablet) reboots the device
[12:43] <ogra> aha, its lightdms fault ... there is a hardcoded "clear > /dev/tty7"
[12:45] <ogra> hmm, no
[12:45] <ogra> even commanting that out doesnt help
[12:45] <ogra> *commenting
[12:47]  * ogra sees a "failed to read header" in /var/log/lightdm/unity-system-compositor.log
[14:11] <alf_> fginther: Hi! It seems that the latest changes to the CI scripts haven't reached arm build nodes (https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/678/consoleFull). Do we need to do something to deploy them there?
[14:12] <fginther> alf_, Let me check. I expected landscape to have done this, but perhaps I missed something
[14:21] <fginther> alf_, I'm manually updating the armhf builders, should be done shortly
[14:22] <alf_> fginther: great, thanks
[16:26]  * ogra files bug 1285236
[17:01] <ogra> mterry, !
[17:02] <mterry> ogra, hi, sorry, IRC issues today
[17:02] <mterry> ogra, what's up?
[17:02] <ogra> mterry, i have two bugs for you (well, it is one but i split it in two)
[17:02] <ogra>  bug 1285236
[17:02] <ogra> and bug 1285236
[17:02] <ogra> err
[17:03] <mterry> :)
[17:03] <ogra> bug 1285234
[17:03] <ogra> :)
[17:03] <ogra> mterry, so something like: restart lightdm a few times lets me end up with a bunch of u-s-c processes
[17:03] <ogra> and killing u-s-c reboots the device
[17:05] <ogra> (i actually wanted to have a pkill unity-system-compositor and rm /tmp/mir_socket in the post-stop script of the upstart job to be able to cleanly shut down these bits
[17:05] <ogra> )
[17:05] <mterry> ogra, rebooting the device is crazy
[17:05] <ogra> seems to happen on flo and mako ...
[17:05] <mterry> ogra, that seems like reasonable cleanup in the upstart job
[17:05] <mterry> ogra, are these urgent or to go on my TODO?
[17:06] <ogra> right, we might get some test at some point that tries to restart the whole UI stack or so
[17:06] <ogra> nobody noticed them until now it seems
[17:06] <ogra> so i wouldnt say urgent
[17:06] <ogra> but good if we could get them solved before trusty final
[17:06] <mterry> yar, OK
[17:06] <mterry> Thanks ogra!
[17:06] <ogra> i'm happy to take the lightdm changes once the reboot issue is fixed
[17:07] <mterry> The lifecycle management of u-s-c isn't amazing
[17:07] <ogra> i just dont have a clue where to look at for that one
[17:07] <mterry> ogra, yeah, that's an odd one
[17:13] <silenz> hey guys, i'm trying to learn more about ubuntu and linux as a whole, and i'm currently trying to wrap my head around x11 and an xindow system but i havent really seen a laymans explanation of how it works
[17:13] <silenz> could somebody explain an x window system like they would to a 10 year old? O_o
[17:14] <ogra> silenz, probably #ubuntu-x is the better channel for that
[17:14] <silenz> thanks
[18:09] <alf_> fginther: It seems that not all nodes picked up the changes: http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-trusty-armhf-ci/685/consoleFull (cyclops-node07) used the old version of the scripts :/
[18:39] <mterry> I just noticed a weird bug in my split branches.  When an app is opened, it shows as all white, *unless* I start sliding it from left or right edge, then its content shows up until I put it back to normal and it goes white again....  Any idea which component might be doing that?
[18:39] <mterry> Maybe a nested bug in Mir?  Or possibly just some goofiness in my unity8 branch...
[18:40] <mterry> I guess my question is if anyone has seen this before
[18:43] <fginther> alf_, sorry about that, I wasn't feeling well and had to lay down for a bit, should be able to finish the updates as the machines go idle
[19:06] <anpok> mterry: i found it quite easy to add goofiness today.. no but havent seen that
[19:07] <mterry> I'm sure if I ignore it, it will go away...


[12:08] <juliank> cjwatson, wgrant Regarding delta indexes, I built a fake Deltas index for xenial->xenial-updates with 3 deltas per update, and I landed at 563KB for mains Deltas.xz 829 KB for a Packages.xz
[12:08] <juliank> The fields were Package, Old-ID, New-ID, Size, SHA256
[12:08] <juliank> Not convinced
[12:10] <juliank> I wonder if I should "just" inject SHA256 of complete debs in the dpkg status database
[12:11] <juliank> and then I can save one hashsum
[12:11] <juliank> because new-id = sha256 of delta
[12:11] <juliank> um no
[12:12] <juliank> I can however safe one ID, by using SHA256(old id | new id) as a field
[12:12] <juliank> brings us down to 485 KB
[12:14] <juliank> So, with Deltas index files, we'd be looking at 60% update time increase for a 80% install download-time decrease
[12:14] <juliank> There was in fact the idea to have "smart" delta indexes once
[12:14] <juliank> So update would download Packages files, then calculate upgrade download size
[12:15] <juliank> and if size(Delta indexes) < some% of upgrade size, it would fetch Delta indexes and look for deltas
[12:15] <juliank> oh, we need 4 deltas per update
[12:15] <juliank> this does not scale well
[12:16] <juliank> sizes of Deltas.xz ~ Packages.xz
[12:17] <juliank> Wondering if a bloom filter might be worht it
[12:18] <juliank> So update gets a bloom filter file for which updates have deltas
[12:18] <juliank> "might have deltas"
[12:18] <juliank> to reduce the number of fetches during install/upgrade
[12:18] <juliank> when doing a per-source-package signature
[12:22] <juliank> A SHA256 has 16 16 bit values we can use as hashes
[12:22] <juliank> we then just need 2**16 bytes for the filter
[12:56] <juliank> xenial-updates needs 12.3 KB bloom filter for a 0.75% false positive rate
[12:56] <juliank> sounds OK
[12:58] <juliank> 1.5% increase in update time to reduce failing delta lookups by about 40% or so
[14:14] <sladen> juliank: this sounds exciting.  Is there more information somewhere?
[14:15] <juliank> sladen: Yes, at https://debconf18.debconf.org/talks/66-delta-upgrades-revisited/, https://people.debian.org/~jak/dc18-deltas.pdf for example
[14:15] <juliank> sladen: unless you mean the bloom filter specifically
[14:15] <juliank> that just popped in today
[14:34] <sladen> juliank: one possibly optimisation of this to provide N diff scripts, and 1x literal data per file.  This would allow one deltadeb to match a scalable number of the last $N package versions
[14:35] <sladen> juliank: so for the moment you could just ship a 1:1 upgrade mapping, but it leaves open the possiblity for future optimisation
[14:35] <juliank> sladen: complicated
[14:35] <juliank> I mean, script is the wrong word
[14:36] <juliank> I'm not sure where you'd integrate this
[14:36] <juliank> on the ddelta level?
[14:37] <juliank> Add a CRC32 of input data to each command, and then provide alternating blocks?
[14:37]  * sladen re-finds https://www.uknof.org.uk/uknof6/Sladen-Delta-upgrades.pdf from a decade ago.
[14:38] <sladen> juliank: https://people.debian.org/~jak/dc18-deltas.pdf page 8,  each file has 1x "diff data" and 1x "extra data"
[14:38] <juliank> Yes
[14:38] <sladen> juliank: the suggestion would be that each file has Nx "diff data" and 1x "extra data".
[14:38] <juliank> An there will be a CRC for diff data eventually (for the part we are adding the data too)
[14:39] <juliank> So you could reasonably have an "or flag", too
[14:39] <sladen> juliank: where the "bitmask" for the "extra data" can be expanded to cover the last N versions of a package
[14:39] <juliank> But I think it gets too slow
[14:39]  * sladen looks confused
[14:39] <juliank> The problem is simple: If we have multiple diff data, we need to figure out which one to use
[14:40] <juliank> for that we need to read the block / try to apply it
[14:40] <juliank> if we fail, we'd have to seek back and start again
[14:40] <juliank> unless you make the choice first
[14:40] <sladen> per file, there is {1x input file (optionally validated by some hash), 1x "extra data", and 1x "diff data"}
[14:41] <sladen> this gives a there is a one-way mapping   X+Y [transform via "diff data"] => Z
[14:42] <juliank> you're still missing the point
[14:42]  * sladen listens
[14:42] <juliank> If I have n diffs for a given file
[14:42] <juliank> how do I figure out which one to apply
[14:42] <sladen> switch the question around
[14:43] <sladen> if I have a starting input file with hash 0xdeadbeef, which diff do I *choose* to reach the end point
[14:43] <juliank> you don't know anything about the file until you have started applying the delta
[14:43] <sladen> (one assumes that you're already validating the input before processing it ;-)
[14:44] <sladen> juliank: if you "don't know anything about the file", how did you find it on disk?
[14:44] <juliank> I did not
[14:45] <juliank> That's a different layer
[14:45] <juliank> The real delta layer can only apply deltas given an old file
[14:45] <sladen> yes
[14:46] <juliank> On top of that there's the tree delta layer, which figures out the old name and the new one and stuff like that
[14:46] <juliank> it's like literally a tarfile and a header with "old name" in it
[14:46] <juliank> But of course
[14:47] <juliank> we can just say "delta id 5 inside here is the delta for that combination"
[14:48] <juliank> that said, you then increase the problem of finding the delta on the server
[14:48]  * sladen raises an eyebrow
[14:49] <juliank> your file name needs to identify to which upgrade the delta belongsd
[14:49] <juliank> then you end up with pkg_id1_id2_id3_ddelta.deltadeb or something
[14:50] <juliank> I'm not sure on the exact details yet
[14:50] <juliank> the latest draft stage is at https://lists.debian.org/debian-dpkg/2018/09/msg00019.html
[14:50] <juliank> and even that is somewhat out of data
[14:50] <sladen> juliank: perhaps think of it a different way.  Lets say we have a package that is regularly (once a day updated), say the hypothetical "message-of-the-day.deb"
[14:51] <juliank> as pkg_$old_$new_$algo.deltadeb might become $pkg_$hash($old|$new)_$algo.deltadeb
[14:51] <juliank> 64 bytes less per delta
[14:51] <sladen> juliank: only '/etc/motd' is changed in this package.  the other files, such as /usr/share/message-of-the-day/README remain unchanged
[14:53] <sladen> juliank: for the last 5 versions, N .deltadebs are currently required, which at 98% the same.
[14:54]  * sladen reads  https://lists.debian.org/debian-dpkg/2018/09/msg00019.html
[14:54] <juliank> I fully understand the argument for that approach
[14:54] <juliank> I don't think it's easily doable given the requirements
[14:55] <juliank> The requirements for deltas are (1) min. seeks on old file (2) no seeks on delta (3) no seeks on new file
[14:56] <juliank> If you want each block to store $n$ diff data for $n$ old versions (or store $n$ control blocks for $n$ old versions)
[14:56] <juliank> you can easily do that
[14:57] <juliank> just assign indexes to them and map indexes to old packages in the control.tar
[14:57] <juliank> but that's not elegant
[14:57] <juliank> To get rid of that, you have to make the decision which diffs to pick in the delta itself
[14:57] <juliank> and that gets nasty.
[14:57] <sladen> can this avoid duplicating the common parts of new literal data ("extra data")?
[14:58] <juliank> sladen: Not sure, but duplication does not matter much
[14:58] <juliank> it's a very tiny overhead after zstd/xz compression
[14:58] <juliank> you could infact just include $n$ deltas I'd think for $n$ old versions
[14:59] <sladen> ahhhh, okay it relies on the enormous window size of zstd/xz/etc
[15:00] <juliank> Now, what will happen is that we get CRC32 soon for the "old" data we are adding diffs to, to ensure we are patching with the correct file
[15:01] <juliank> s/ensure/increase confidence/
[15:01] <sil2100> !dmb-ping
[15:01] <juliank> So my idea was that we could give each of these (diff, extra, seek) control triplets an "or" flag
[15:01] <cyphermox> o/
[15:01] <juliank> if the CRC does not match, we go to the next control entry
[15:02] <juliank> that works, but it's somewhat inefficient
[15:02] <juliank> because the diff block might be MBs large
[15:02] <juliank> it also does not work after all, because we'd have to undo the write to the new file
[15:03] <juliank> (i.e. seek back and truncate)
[15:03] <juliank> but: Both the patch and the new file are a pipe
[15:04] <juliank> (dpkg reads the patched file from the pipe, and calculates hashes before storing it on the system)
[15:05] <juliank> You can solve that by just picking a fixed maximum window size you can keep in memory
[15:05] <juliank> but um, for large files that slows things down a bit
[15:06] <juliank> that said, for really big files, using windows during creation is a lot more effective
[15:07] <juliank> I think  bsdiff generation is O(n^2) atm
[15:07] <juliank> if you use blocks of $B$ bytes, it becomes (n/B*B^2)
[15:07] <juliank> so it only grows linearly rather than quadratic
[15:07] <sladen> juliank: in the msg0019 spec,  "if file.mtime >= installed_version.install_time or file.mtime > file.ctime or file.size != expected_size"  <-- probably a lot better to use a checksum to match before ingesting
[15:08] <sladen> juliank: and once a checksum is used, that can become the primary matching key
[15:08] <juliank> sladen: that's the paranoid mode
[15:08] <juliank> our believe is that checksums are too slow to be practical here, and useless in most situations
[15:10] <juliank> where us is me and some other people I talked to about this
[15:10] <juliank> :)
[15:10] <sladen> checkums are really slow if done on the server (rsync), but checksums on clients are $fast (cost of checksum is > than cost of downloading precious bytes)
[15:10] <sladen> checkums are really slow if done on the server (rsync), but checksums on clients are $fast (cost of checksum is < than cost of downloading precious bytes)
[15:10] <juliank> What you already have checked is that the files, when unpacked, have the right content
[15:11] <juliank> because of the IDs identifying the content of the package, and you looking up deltas based on ids
[15:11] <juliank> I'm unsure about the implications of actually hashing the files
[15:12] <juliank> we will be reading them with a 60% probability
[15:12] <juliank> because we'll be applying a delta
[15:12] <juliank> and dpkg already hashes the files it is writing to the disk
[15:12] <juliank> so the overhead should be less than 50%
[15:13] <juliank> but let's measure
[15:14] <juliank> I spent 47 seconds checking my 3326 packages
[15:14] <juliank> on a fast Samsung SSD from this year
[15:15] <juliank> this means that for an upgrade of 300 packages, I'd spent about 5 seconds
[15:15] <juliank> *35 seconds with caches
[15:16] <sladen> that's still presumably 99% disk I/O
[15:20] <juliank> yes
[15:20] <juliank> the non-paranoid mtime check only takes 1s
[15:21] <sladen> that's not reading/checking any files, only filesystem structure
[15:21] <juliank> that's the point
[15:21] <juliank> we can be reasonably sure that the file has not been modified
[15:22] <juliank> because it requires extreme stupidness or deviousness to change your mtime back to before install time
[15:22] <juliank> or even build time
[15:24] <juliank> When does that happen?
[15:25] <juliank> Well, I'd say only if your clock is behind a few days/months, you have installed the package with the correct time, and you modify the file while keeping the bit length the same
[15:25] <sladen> check mtime sounds like an optimisation that an upgrade is /probably/ possible.  -> fetch set of hash(es) is see whether it is really truely possible
[15:25] <juliank> but we can protect against clock resets too I think
[15:26] <juliank> I think
[15:26] <sladen> juliank: is there a directory somewhere, with an extra set of .deltadebs to look at?
[15:26] <sladen> s/extra/example/
[15:27] <juliank> no
[15:27] <juliank> https://github.com/julian-klode/ddelta/tree/demo has a delta generation script
[15:27] <juliank> ./build-delta.sh $old $new $delta
[15:27] <juliank> builds a delta from $old to $new and stores it as $delta
[15:28] <juliank> * delta deb
[15:28] <juliank> it's very primitive
[15:30] <juliank> one thing it does is generate normal .deb with debian-binary instead of files with debian-delta
[15:30] <juliank> but minor details
[15:30] <juliank> ease of prototyping
[15:30] <jibel> infinity, hi, could you have a  look at bug 1794137 ?
[15:31] <juliank> sladen: I think windowing would definitely be worth it, the memory requirements go down a lot, effectively become constant. as https://github.com/julian-klode/ddelta/commit/05aecc28c2f049cad83d9c7ef2e2439d0ecae295 mentions
[15:31] <juliank> but I think fixed windows of 8 MB should not work in practice
[15:32] <juliank> you need some heuristics
[15:45] <juliank> sladen: If you want to compare with xdelta3 as the algorithm, just use ddelta_generate="xdelta3 -s" instead
[15:49] <sladen> juliank: where's the customised version of bsdiff()  (specifically the search() function)
[15:49] <juliank> It's in that repo
[15:49] <juliank> https://github.com/julian-klode/ddelta/blob/master/ddelta_generate.c
[15:51] <juliank> it's mostly just Google's bsdiff fork plus some cleanup
[15:51] <juliank> and without large file support
[15:53] <juliank> (we don't really need large file support since we are delating individual files, and it reduces memory usage by about 50%)
[15:55] <juliank> and well, memory usage with LFS is 9m + n
[15:55] <juliank> so assuming you actually need large files >= 4 GB
[15:55] <juliank> you end up with at least 36 GB of memory requirements
[15:56] <juliank> unless you use the windowed branch then you only need 50 MB (or well, 6w for window size w)
[15:57] <sladen> well, some (variable) window should probably be used, and that should be stated in the debdelta
[15:58] <sladen> so that eg. an old ARM/whatever maschine with 16MB of RAM can use to choose to only look at deltadebs that declare as only using a 1MB window
[15:58] <sladen> and if not, download everything
[15:58] <juliank> memory use when applying is already constant
[15:59] <juliank> the memory requirement here is when generating
[16:00] <juliank> not counting stdio, memory use is 64 KB of stack memory for the data blocks
[16:00] <juliank> + a few bytes here and there, and three levels of recursion or so
[16:01] <juliank> there are no heap allocations in the program (except for whatever libc does)
[16:01] <juliank> I suggest reading the ddelta_apply.c (https://github.com/julian-klode/ddelta/blob/master/ddelta_apply.c), it's quite easy to follow
[16:03] <juliank> there's some wicked vectorization magic in apply_diff(), but apart from that, it's quite easy
[16:04] <juliank> the be64toh is a bit ugly too
[17:37] <sladen> juliank: this stuff is drastically simplier than what was being looked at ~10 years ago, which failed because of a desire to bit-for-bit recreate the target .deb; and the checksums to prove that were only available on the recompressed .deb, rather than purely the contents
[17:38] <sladen> juliank: there did not seem to be an appetite for writing directly to the filesystem, partly because of the inability to roll back to the previous state on failure
[17:40] <sladen> juliank: is there an appetite for directly writing, verses, re-creating the .deb and getting dpkg -i to apply that?
[17:45] <juliank> sladen: the rollback ability is exactly the same as for out of space errors and roughly the same as for failing preinsts
[17:46] <juliank> After all, we apply the delta not to the file itself, but write the .dpkg-new file as before
[17:46] <juliank> so if some delta fails, dpkg will revert precisely as it does with other unpack failures
[17:46] <juliank> Or rather try to revert
[17:47] <juliank> that is, it deletes the .dpkg-new files and calls some maintainer scripts which hopefully work
[17:48] <juliank> With some modifications to dpkg and apt, it should be possible to make apt download the full deb if installing the delta fails
[17:48] <juliank> For that, dpkg needs to communicate a failing unpack due to delta
[17:48] <juliank> via status fd
[17:49] <juliank> apt needs to interpret that and acquire the full thing
[17:49] <juliank> sladen: Also, the algorithm does support regenerating the .deb file bit-by-bit
[17:50] <juliank> well, except for compressor changes, if any
[17:51] <juliank> But the problem with regenerating the full deb is that you end up with a lot of space usage
[17:51] <juliank> there is the intermediate step where you regenerate the tar while you're piping it to dpkg
[17:51] <persia> juliank: most compression tools can be used reproducibly with some set of flags.
[17:52] <juliank> persia: not really
[17:52] <juliank> Well, for a given point in time, they can
[17:52] <juliank> But let's compress our deb now, and then try to regenerate it 5 years later
[17:55] <persia> juliank: I meant gz, xz, bz, etc., for which time is less important.  For tar, etc. things like "--mtime @$$SOURCE_DATE_EPOCH" work.  5 years is trickier.  Anyway, not important.
[17:56] <juliank> persia: I think pristine-gz ships like 2 copies of different gzip versions now to enable that use case :)
[17:56] <persia> :(
[17:57] <sladen> theoretically one needs to know every choice made by the encoder, and the problem is $impossible.  In practice, it can be achieved in 99% of cases, but 90% of those of gzip -9, and there is code around that eg. has snapshots of the different versions of bzip2
[17:57] <juliank> yeah, like pristine-gz
[17:57] <juliank> :)
[17:58] <juliank> Now you can do bitwise regeneration of most debs
[17:58] <juliank> but as they use xz it's quite slow
[17:58] <juliank> ...
[17:58] <juliank> If you don't care about bitwise, then you can go nuts
[17:58] <juliank> e.g. regenerate full debs without compression
[17:58] <juliank> or with zstd -1 if we do zstdf
[17:58] <juliank> which would not really be noticeable
[17:59] <sladen> what should be better (and is the same case as 10 years ago), would be to store the hash of the uncompressed tar.deb  then the compression algorithm becomes irrelevant (and can be changed as required)
[17:59] <juliank> you can do that, yeah
[18:00] <sladen> juliank: somewhere, there is the 'apt-sync' / 'apt-zsync' package code, with provides an APT-Method using zsync.  It should be possible to copy and adapt that and have a more rounded and working demonstration system
[18:00] <juliank> also, tardelta (or deltatar; aka a tarball of my deltas) is very easy to regenerate.
[18:00] <juliank> sladen: Such stuff does not work
[18:00] <persia> Probably want to store multiple hashes (maybe the same set as in dsc files) to make it harder to game.
[18:00] <sladen> juliank: why not?
[18:01] <juliank> sladen: You cannot use rsync/zsync algorithms for binaries
[18:01] <juliank> also, debs are not built rsyncable
[18:01] <juliank> Now the first argument is a bit complicated, but should be easy to understand
[18:02] <juliank> If you add a few bytes at the beginning of your file, all offsets change by that amount
[18:02] <juliank> the entire file becomes unsyncable
[18:02] <sladen> juliank: in this case, it is the apt-sync *APT method* that might be usable to get a more complete demonstration of this proposed *debdelta* system working
[18:02] <juliank> I have a working dpkg that can install deltas directly, and I played around with that
[18:03] <sladen> juliank: thus making the whole proposed *debdelta* system more denonstratable
[18:03] <juliank> but yes, you can also builod a method that reconstructs debs
[18:03] <juliank> but we also need a repository layout anyway
[18:03] <juliank> a PoC would not have any signature checks I think
[18:03] <juliank> although
[18:04] <juliank> the method could do that itself
[18:07] <sladen> juliank: [regarding zsync]  the gzip --rsyncable is about repeatedly restarting the gzip stream, limiting the window size, in order to better re-use existing literal data.  In the proposed *debdelta*, that literal data is provided in the "extra data" block anyway.  This already presumes that server-side disk space is no longer an issue
[18:09] <sladen> if server-side disk-space is indeed no longer a issue, then this makes the zsync side of stuff a lot easier (it becomes zsync minus the z); in addition to the compressed .deb, store an uncompressed .deb  on the server, and allow HTTP/1.1 Range: Partial-Content access to this for missing pieces not available in the "extra data" (which could now be zero-length)
[18:10] <juliank> sladen: rsyncable was about rsync/zsync
[18:10] <juliank> obviously
[18:10] <juliank> 2nd, the name is not debdelta
[18:10] <juliank> 3rd, server-side disk space is an issue
[18:10] <sladen> deltadeb?
[18:11] <juliank> sladen: yeah, for now, but it's super confusing
[18:11]  * sladen happy to use any name preferred
[18:11] <juliank> would have called them ddebs, but we already have those :(
[18:12] <juliank> pdeb was in the round as well (patch deb)
[18:12] <juliank> debdiff and debpatch are both used as well
[18:12] <juliank> naming software is *hard*
[18:13] <ogra> call it "frank"
[18:13] <juliank> I could call it voyager
[18:13] <juliank> after all, related to delta
[18:14] <juliank> well, the delta quadrant
[18:14] <ogra> :D
[18:32] <sladen> juliank: --rsysncable does two (unrelated) things.  (1) resets the encoding/compression state on a particular input (zeros in the input stream);  (2) more reset points in the stream where it can be entered without knowing state [back-reference window state + current Huffman tree in use].
[18:33] <juliank> I don't care
[18:33] <sladen> one *can* jump into the stream at any point if the current Huffman table is known, and the contents of the backreference window is available
[18:34] <juliank> How's that relevant to the topic of deltas?
[18:35] <sladen> chosing whether, and how much literal data to duplicate, vs. trying to fetch the literal data from the original .deb
[18:35] <sladen> (server side disk space vs. bandwidth tradeoffs)
[18:48] <joelkraehemann> hi all
[20:42] <xnox> @help
[20:42] <udevbot_> (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
[20:42] <xnox> @help pilot
[20:42] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[20:42] <xnox> @pilot in
[20:42] <xnox> cyphermox, i think that keeping the patch-pilot name should be fine to be honest =)
[20:42] <xnox> @pilot out
[20:43] <cyphermox> xnox: *shrugs* either way. I was asking, since I figured only dholbach (or very few people) knew where the code was at all
[20:43] <cyphermox> @pilot out
[20:48] <xnox> cyphermox, right, but i only had the calendar code, not the irc-bot codes. and i think the feedback was that calendar code is not wanted.
[21:31] <cyphermox> I don't know
[21:31] <cyphermox> soem people like being scheduled, that way they know to do it at a specific time
[21:31] <cyphermox> but I guess that works better for patch piloting that other things, maybe?
[21:31] <cyphermox> brb
[21:32] <nacc> ahasenack: congrats!
[21:33] <mwhudson> ahasenack: congrats!
[22:32] <joelkraehemann> is this channel anyhow related to snapcraft.io?
[22:33] <wxl> joelkraehemann: #snappy
[22:35] <joelkraehemann> wxl: thank you
[23:14] <stgraber> c
[23:14] <stgraber> oops
[23:34] <mwhudson> hmm is there an easy way to update to a new upstream with a git ubuntu clone-ed repo?
[23:34] <mwhudson> uupdate is almost right, apart from the way it creates a new repo
[23:34] <mwhudson> gbp import-orig similarly almost but not quite what you want
[23:40] <nacc> mwhudson: yeah, there's not a great way
[23:40] <nacc> i think we have a bug for it
[23:40] <nacc> mwhudson: here's what i've done in the past, it's not ideal
[23:41] <nacc> mwhudson: clear out all non-debian/ directories and files from the git-ubuntu repo, move all the uupdate'd repo's files over
[23:41] <nacc> mwhudson: `git add .` (should just be non-debian changes)
[23:42] <nacc> mwhudson: insert a changelog entry (you can use the topmost from the uupdate'd one as a template for the version)
[23:42] <nacc> mwhudson: i *think* that mostly works, that's how i would do the php updates by hand
[23:42] <mwhudson> ah yeah
[23:42] <mwhudson> i am reading how gbp import-orig is implemented now :)
[23:42] <nacc> and i imagine is actually similar to what gbp does, with probably more smarts.
[23:42] <nacc> it's basically 'stash debian, update everything, unstash debian)
[23:42] <nacc> (in my mind)
[23:43] <mwhudson> it creates a new tree out of the tarball contents, commits that, then mashes the debian dir from the packaging branch into it
[23:43] <nacc> yeah, that make sense
[23:43] <mwhudson> (with vaguely appropriate hashes as commit parents)
[23:43] <nacc> we could do something similar, tbh, we have git-tree representations of any directory (or can) and can do temporary directory things)
[23:44] <mwhudson> i have an implementation of gbp's debian directory mashing in shell
[23:44] <mwhudson> but not the other bit
[23:44] <mwhudson> https://paste.ubuntu.com/p/qfd6wVksDy/
[23:44] <nacc> there's LP: #1649940
[23:45] <nacc> and LP: #1706219
[23:45] <nacc> i had some scaffolding in a branch to do the latter
[23:45] <nacc> i think it's a 'future' item, because we are still stabilizing the importer ABI
[23:47] <mwhudson> it's slightly frustrating that gbp has all the bits required for this
[23:47] <mwhudson> but can't actually do it
[23:48] <nacc> mwhudson: yeah, gbp has some very specific branch requirements, iirc. We were trying to avoid coding too much of that policy yet
[23:52] <rbasak> You can hack it by messing around with GIT_WORK_TREE
[23:52] <rbasak> Unpack the tarball somewhere
[23:52] <nacc> ah good point
[23:52] <nacc> yeah, that's what my scaffolding started to do
[23:52] <nacc> basically, did uupdate in a specific place
[23:52] <nacc> and took that working tree
[23:52] <rbasak> GIT_WORK_TREE=$there git add -A
[23:52] <nacc> yep
[23:52] <nacc> rbasak: could you spit that into one of the two bugs?
[23:53] <rbasak> Then some messing around with "git reset debian" (I'd have to think about it exactly)
[23:53] <mwhudson> heh ok i have half a shell script for this now too
[23:54] <nacc> rbasak: right, that was about where i got
[23:54] <nacc> yeah, you want to commit changes to non-debian as part of the uupdate
[23:54] <rbasak> Done
[23:54] <nacc> but it would be a nice feature :)


[10:39] <pyrobisqit> hello, I haven't connected in like a year or so, and I don't remember my password, could an operator drop my nick or send me a password recovery email please?
[10:40] <ikonia> you need to be in #freenode
[10:40] <ikonia> this channel only deals with ubuntu channels, your nickname is part of freenode, not ubuntu
[10:40] <ikonia> try /join #freenode and ask for a staff member (with a + by their name) to help
[10:40] <pyrobisqit> sorry, I thought there would be operators in this channel
[10:40] <pyrobisqit> thank you I will!
[10:41] <ikonia> no problem
[17:11] <SnapDragon_> hi
[20:04] <SnapDragon_> hi
[20:05] <k1l_> hi
[20:08]  * SnapDragon_ is going to idle in here
[20:08] <ikonia> wow - it's almost as if you are trying to provoke a problem
[20:08] <ikonia> SnapDragon_: why are you here ?
[20:09] <k1l_> SnapDragon_: please see the /topic we have a no idle policy except for team members.
[20:09]  * SnapDragon_ does not care
[20:10] <k1l_> so its hfsplus again
[20:10] <ikonia> I see no point in wasting any time with him
[20:10] <ikonia> her/it/whateer
[20:10] <ikonia> ever
[20:11] <k1l_> yes, he clearly ruined his 2nd chance. and his<PHONE_NUMBER>525532nd chance too
[21:16] <cheesedude> hi
[21:20] <cheesedude> how do i become an op
[21:21] <cheesedude> !ops
[21:21] <cheesedude> hi
[21:21] <cheesedude> how do i become an op?
[21:21] <k1l_> cheesedude: aka hfsplus. first i would start with not trolling and making trouble
[21:21] <cheesedude> we are like family
[21:22] <cheesedude> by the way
[21:22] <cheesedude> how come we dont even talk even more
[21:22] <cheesedude> this bullshit cant be true
[21:29]  * cheesedude Baby, baby, baby oooh Like baby, baby, baby nooo Like baby, baby, baby oooh I thought you'd always be mine (mine)
[21:48] <IAmNotThatGuy> lol