[00:11] <jelmer> Noldorin: there's a new bzr-git release (0.6.5) from a couple of days ago
[00:13] <wgz> no bed quite yet, better do travel now.
[00:14] <poolie> wgz, it doesn't have to be right now
[00:14] <wgz> will save round trips in the morning :)
[00:15] <poolie> by 'today' i meant my today, friday
[00:28] <wgz> it's done/
[00:29] <wgz> and my sis is still on the phone, so I'd not have got the extra sleep anyway :)
[00:38] <Noldorin> jelmer, oh does that fix the issue i was having with my branch though?
[00:41] <jelmer> Noldorin: no, that issue is still open
[00:41] <Noldorin> jelmer, ah, oh well...
[00:41] <Noldorin> targeting it soon?
[00:41] <Noldorin> i guess it's good news the project is still moving...thought this was a pretty crucial issue though
[00:48] <jelmer> Noldorin: your repository is the only I've seen it with so far
[00:49] <jelmer> Noldorin: it's on my list of things to work on, but I'm swamped by other stuff at the moment
[00:55] <Noldorin> jelmer, heh okay sure
[00:55] <Noldorin> jelmer, very surprising, since i isolated quite a simple reproduction case :-)
[00:56] <Noldorin> jelmer, but clearly you haven't forgotten...thanks
[00:56] <Noldorin> brb
[01:08] <poolie> GRiD, ok that still sounds pretty good then
[01:10] <GRiD> ok cool. the bzr-search change should be pretty easy too, i think. i can look at that after if i get a minute.
[01:11] <GRiD> well, easy in that i would just skip the key it's trying to add if it's too big, although i don't know if that's the right thing to do
[01:13] <poolie> i guess the question is why is the key getting so big
[01:13] <poolie> if it's just encountered a really long whitespace-delimited "word"
[01:13] <poolie> then skipping it would be reasonable
[01:13] <poolie> i don't know if that is actually the cause
[01:19] <GRiD> yeah i didn't have a chance to investigate that. but if you try to reproduce the original bug (by indexing ubiquity) with my patch, it now excepts on a key that is about a 4k (iirc) string of hex characters
[01:21] <GRiD> fwiw, if the long keys are skipped (which one of my early patches did silently), the indexing of ubiquity completes and seems to be usable.
[01:27] <poolie> GRiD, ok, so i think the main thing here is that the decision to skip is a policy of bzr-search, not bzr core
[01:27] <poolie> search may not care about indexing long strings but for other things that might lose data
[01:30] <GRiD> yep, agreed. i only meant it in that if bzr-search caught the exception and simply skipped for now (perhaps with warning), it may be sufficient. if it's not, someone who knows more about bzr-search should take a look.
[01:30] <poolie> i think that'd be good
[01:30] <poolie> thanks for fixing it
[01:30] <poolie> lifeless, ^
[01:31] <lifeless> yah, I've been following along
[01:31] <lifeless> all sounds good to me
[01:32] <GRiD> ok i'll take a look at making bzr-search skip then.
[09:15] <mgz> morning!
[11:20] <mgz> hm, it's good to know someone else is interested in maintaining paramiko, but looking at the changes 'bitprophet' has on github doesn't fill me with confidence
[11:23] <mgz> the only significant changes seem to be the rename (to 'ssh'... which seems unwise) and changing all the copyright headers(!)
[11:23] <mgz> and has done two releases to pypi without updating NEWS or otherwise indicating what's different as far as I can see
[11:33] <jam> mgz: well, having an official release channel is what we are after. We've written a few patches that have just gone ignored for long stretches of time.
[11:33] <jam> I agree that the 'ssh' thing seems a bit wonky. There can be many ssh libs around, having a unique name is nicer. Though maybe just a namespace "from paramiko import ssh"
[11:34] <jam> or 'import paramiko_ssh as ssh"
[11:35] <mgz> anyone know if github lets you issue pull requests for other people's branches?
[11:35] <mgz> ...not that they'll let me sign in, no openid support and demand js enabled.
[11:39] <jam> mgz: if you had an account, you could always 'fork' the other person's branch and propose it directly, so I would think they would allow you to propose someone elses' branch
[11:47] <mgz> jam: on your running tests against implementations in different languages thing,
[11:47] <mgz> (I don't know why but was thinking about that before going to sleep last night)
[11:48] <mgz> what people generally do is structure the cases as data as far as possible, then just write the bits they need for the runners in python/js/etc
[11:49] <mgz> eg htmllib5
[11:51] <jam> mgz: sure, but it means implementing a test-suite runner in each language
[11:51] <mgz> or it's nearly what bt.test_conflicts.TestParametrizedResolveConflicts is
[11:51] <jam> which may not be much better than implementing a test-suite in that language
[11:51] <mgz> yeah, and when you get to the point where it's nearly a mini functional language, the tests aren't very easy to read
[11:51] <jam> so far, it seems the only way if we want to ensure the *same* tests get run in each language
[11:52] <jam> mgz: we just need to port the python interpreter to vala, js, java, etc, and we'll be golden
[11:52] <jam> php will be fun :)
[11:52] <mgz> but there's probably a middle ground where the test cases are still easy enough to write, but the runners don't need to be overly complicated
[12:01] <jam> mgz: I think you meant "forwarding our existing patches" not "forwarding out existing patches".
[12:01] <mgz> ...I did
[12:02] <mgz> the keys are like, right next to each other.
[13:54] <mgz> okay, let's do the github dance
[14:09] <mgz> ha, and I don't actually have git installed here, have just been using bzr-git
[14:11] <jelmer> mgz: bzr-git should work for pushing too..
[14:11] <jelmer> :)
[14:13] <mgz> I need to do a couple of merges and thought I'd try the vanilla option first :)
[14:46] <mgz> I need to go out briefly, will be back shortly
[15:31] <mgz> back.
[16:09] <daveb_> how do I undo a merge? I want to merge from the same branch, I just wan't to do it later
[16:09] <mgz> `bzr revert`
[16:10] <mgz> if you have changes in your tree you want to keep, it's a bit harder
[16:10] <mgz> but you can tell bzr to forget the merge then undo the merged changes manually
[16:12] <daveb_> I thought revert only changed the working directory
[16:14] <mgz> it also forgets merges if you don't give specific paths, see `bzr help revert` for more.
[16:14] <fullermd> The fact of a pending merge is an attribute of the working tree.
[16:18] <daveb_> i commited the merge
[16:18] <fullermd> And other stuff since then?
[16:21] <mgz> if you haven't done other stuff, can use `bzr uncommit` then my earlier advice, otherwise you're better off... doing something clever fullermd will tell you about
[16:21] <fullermd> Oh great.  No pressure, right?
[16:22] <mgz> you're the super sub :)
[16:23] <mgz> can sit out most of the game but expected to sometimes come on and produce miracles.
[16:23] <daveb_> ok, uncommit followed by revert worked :)
[16:23]  * fullermd takes the credit.
[16:24] <mgz> see, this match we won anyway, so you just get to rest. :D
[16:24] <fullermd> Nono, too late!  You already made me cross the sideline!
[16:27] <daveb_> i guess you also have to rm -rvf any remote branches you have been pushing too...
[16:27] <fullermd> Or push --overwrite 'em.
[16:28] <mgz> only if you pushed that last change with the merge you didn't want
[16:28] <mgz> for very public locations, it's most polite to work on from mistakes, rather than trying to pretend they never happened
[16:30] <daveb_> hmm
[16:57] <fullermd> Oh no, the shame is bad enough he had to change his name.
[17:25] <croepha> lol
[18:10] <jimis> jelmer: no need to pass a source branch revno to bzr log, it should print it so we can use it with other commands, like diff
[18:10] <jimis> bzr diff -rrevno:115532:tree1
[18:10] <jimis> for example
[18:12] <jimis> bzr log should just display an extra line for each merge operation: "source branch revno: 115532"
[18:12] <jimis> in case it is expensive it should happen only with bzr log -n0
[18:17] <jelmer> jimis: that revno is specific to the source branch
[18:17] <jelmer> jimis: so you have to pass in the source branch somehow
[18:18] <jelmer> jimis: the revno displayed by log is already usable in e.g. diff
[18:18] <jelmer> bzr diff -r13423.32.1
[18:19]  * jelmer -> weekend
[20:17] <slangasek> jelmer: if and when you have some time, I could use some help with (modifying) bzr-rewrite
[21:09] <ccxCZ> I have bound branch, I did local commit and then bzr up, now the revision of the local branch was set back, how would I find the commit and push it?
[21:13] <fullermd> The local commit is now a pending merge.
[21:16] <ccxCZ> it was aggregated with uncommited changes
[21:17] <ccxCZ> I would prefer to have them as two separate commits
[21:18] <ccxCZ> I seem to be able to get the revid via bzr heads --all
[21:25] <ccxCZ> backing up working tree, updating to revid and restoring did the job


[06:24] <Yuhong> I set this bug to Fix Released:
[06:24] <Yuhong> http://us.generation-nt.com/redirect.html?url=A2wGdwV3UyQDJVQ8Di5TfwZkViUDYQB1An8IMwM3UCkMZVM1VDpaLVVhAjQIKQFsVjMCcAUvVyQPPlNxAToAeANxBiwFKFMnAzlUcw5zUzMGY1Z%2FA2oAbwI%2FCCoDLlBzDCBTNFQnWjpVLwJkCDIBN1ZmAjIFNw%3D%3D
[06:25] <Yuhong> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/455067
[06:25] <ubot2> Launchpad bug 455067 in linux (Ubuntu) "[113818.216022] BUG: scheduling while atomic: dosemu.bin/12814/0x10000004 (affects: 4) (heat: 24)" [Undecided,Fix released]
[16:31] <Quintasan> Hello, I'm having problems with Natty, after some time, with normal using, my system somehow slows down to a crawl, starting any application takes up to 10 seconds. Reading any file bigger than 20Mb is probably impossible. Right after this I manage to save dmesg, here is the output -> http://pastebin.com/s8DSWv35 . Can this be the cause of the slowdown?
[18:01] <jbarnes> apw: /sbin/installkernel is still broken in 10.10 btw :)
[18:01] <jbarnes> I still need to add lines to do the mkinitramfs and update-grub calls
[22:40] <Sarvatt> jbarnes: looks like it got some attention recently but the fix isn't commited in upstream debianutils yet - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607411
[22:40] <ubot2> Debian bug 607411 in debianutils "installkernel should run-parts /etc/kernel/postinst.d" [Wishlist,Open]
[23:43] <SamuraiAlba> How can I _FIX_ the "Cannot Reserve MMIO Region" issue?


[04:21] <zul> @schedule montreal
[04:21] <Ubugtu> Schedule for America/Montreal: 14 Jun 08:00: Edubuntu | 14 Jun 09:30: Xubuntu | 15 Jun 10:00: Ubuntu Development Team | 15 Jun 13:00: Documentation Team | 20 Jun 16:00: Technical Board | 21 Jun 09:30: Xubuntu
[06:17] <robitaille> @topic
[09:33] <mdz> @schedule
[09:33] <Ubugtu> Schedule for Etc/UTC: 14 Jun 12:00: Edubuntu | 14 Jun 13:30: Xubuntu | 15 Jun 14:00: Ubuntu Development Team | 15 Jun 17:00: Documentation Team | 15 Jun 20:00: Edubuntu Cookbook | 20 Jun 20:00: Technical Board
[09:33] <Keybuk> nothing for today
[09:33] <mdz> looks like it's free
[09:33] <Keybuk> though where's the CC in that?
[09:33] <mdz> must have already happened?
[09:33] <Keybuk> oh, must have already happened
[09:33] <ogra> dropped for today
[09:34] <ogra> sbdfl is travelling, colin on vacation
[09:34] <mdz> so, impromptu techboard meeting to discuss topics for Paris
[09:34] <ogra> +a
[09:34] <Keybuk> there's still 27 not yet approved or declined, shall we look at those first>?
[09:35] <mdz> Keybuk: yes, I didn't have a chance on monday as planned due to being unable to stand up
[09:35] <mdz> unfortunately it looks like the trivial spec tracker changes I asked for didn't make it in, so this is still a pain
[09:35] <Keybuk> yeah, I was about to say ... I swear they promised that they would be hyperlinks this week
[09:35] <mdz> basically what I've been doing is, for each spec in the list, searching around to find the spec page for it
[09:36] <mdz> I check to see if anyone associated with the spec is actually attending the conference
[09:36] <mdz> or if it's something we ought to talk about anyway
[09:37] <Spec> oh god, a meeting of specs.
[09:37] <mdz> ogra: did you submit them all for paris last week?
[09:37] <ogra> yeps
[09:37] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/apparmor
[09:37] <mdz> Spec: you might want to leave the channel for a bit ;-)
[09:37] <ogra> lol
[09:37] <Spec> it's interesting though, i got a spec submitted/approved already :p
[09:37] <Keybuk> Holy bad-choice-of-nickname, Spec-man!
[09:37] <mdz> Keybuk: I fear, though, that sabdfl was going over that list as well, and not using the same approach
[09:38] <mdz> so there may be stuff approved where there won't be anyone to talk about it
[09:38] <mdz> s/approved/accepted/
[09:38] <Keybuk> at one point I was convinced that there was automatic processing going on
[09:38] <Keybuk> I assigned a spec to the meeting and it was *instantly* approved
[09:38] <mdz> yeah, I think that was him.  unfortunately there's no mail notification either
[09:39] <mdz> there are 126 accepted and I know I didn't do more than half of that
[09:39] <Keybuk> I did add a few specs to the meeting which nobody else had
[09:39] <Keybuk> but only where I knew they were things other people wanted to talk about
[09:39] <Keybuk> e.g. libata-for-all
[09:39] <Keybuk> that was the one, in fact, that went straight to accepted without collecting 200$
[09:40] <mdz> we also need to reset the status for specs which are being reproposed from an earlier cycle
[09:40] <mdz> I've been doing that where I see it
[09:41] <mdz> it looks like early-userspace was just edited and reproposed, though it's a different spec
[09:42] <mdz> how confusing
[09:42] <mdz> hmm, someone helpfully added my old grub2 spec to paris, which I had completely forgotten I'd entered
[09:43] <Keybuk> I'd love an activity log for specs too
[09:43] <Keybuk> can you add that to your scribbles? :)
[09:43] <mdz> er, ubuntu-meta-from-bzr was proposed and accepted when it's already implemented
[09:44] <mdz> (done)
[09:44] <Keybuk> yes, that's because Colin had a few hours
[09:44] <Keybuk> fix-mom is likely to be implemented before
[09:44] <mdz> packetcd is owned by someone who isn't coming
[09:45] <Keybuk> kooky
[09:45] <mdz> but tollef is subscribed, ok
[09:45] <lucasvo> @schedule
[09:45] <Ubugtu> Schedule for Etc/UTC: 14 Jun 12:00: Edubuntu | 14 Jun 13:30: Xubuntu | 15 Jun 14:00: Ubuntu Development Team | 15 Jun 17:00: Documentation Team | 15 Jun 20:00: Edubuntu Cookbook | 20 Jun 20:00: Technical Board
[09:45] <mdz> I'm going to ask that the spec tracker make this a hard constraint
[09:45] <Keybuk> someone attending must be attached or subscribed to the spec?
[09:45] <mdz> that there must be someone subscribed or assigned who is registered to attend the meeting
[09:45] <Keybuk> apparmor => not attending
[09:46] <Keybuk> ethical-info => not attending
[09:46] <mdz> go ahead and decline them
[09:46] <Keybuk> gnome-bling-manager => not attending
[09:47] <Keybuk> integrated-cdemu => not attending
[09:47] <Keybuk> jhbuild->dependencies => not attending
[09:48] <mdz> adept-usability is one I asked Riddell to narrow the scope on before accepting it, but someone else accepted it anyway
[09:49] <Keybuk> serverland => not attending
[09:50] <Keybuk> server-config-wizard => not attending
[09:52] <Keybuk> synaptic-packages-descriptions-localisation => not attending (mvo isn't subscribed either)
[09:52] <mdz> Keybuk: who registered it?
[09:52] <Keybuk> arch-change-i386-to-i686 => not attending (also we decided not to do this yet)
[09:52] <mdz> I think mvo may actually be interested in it
[09:52] <Keybuk> mdz: "tenshu"
[09:52] <mdz> mvo: confirm or deny?
[09:53] <mvo> Keybuk: I am interessted in this, just it should be merged with apt-ddtp, no?
[09:53] <Keybuk> ok, I'll mark it superceded by that spec
[09:54] <mdz> Keybuk: I'm also setting the assignee to be the registrant where registrant is null
[09:54] <mdz> since that's sort of the theme for edgy, and assignee shows up in the table while registrant doesn't
[09:54] <Keybuk> ubuntu-directory-server => not attending
[09:54] <mvo> Keybuk: is it on the paris spec table? I seem to be unable to find it
[09:54] <Keybuk> mvo: it was in the proposed list
[09:55] <Keybuk> hmm, usb-adsl-modems ... nobody's attending; decline, or accept anyway -- sfflaw was interested in that kind of thing?
[09:55] <mvo> Keybuk: what is the url for that list?
[09:55] <Keybuk> mvo: -EPERM for you I'm afraid :-/
[09:55] <Keybuk> (quite why you need permission to *read* it, I've no idea, but hey)
[09:56] <Keybuk> xchat-gnome-default => not attending
[09:56] <mvo> Keybuk: ok, thanks. I will be around in case something more comes up for me
[09:58] <mdz> mvo: if apt-ddtp covers the same stuff, the other one should be superseded by it
[09:58] <mvo> mdz: it does, it even links to ddtp.debian.net :)
[09:59] <mdz> Keybuk: can you mark it superseded/
[09:59] <Keybuk> mdz: done
[09:59] <Keybuk> Riddell: ping
[10:01] <Keybuk> (where there wasn't an assignee and the assignee isn't coming)
[10:01] <Keybuk> uh, registrant isn't coming
[10:02] <mdz> edgy-toolchain-roadmap needs breaking down, mailed doko
[10:02] <Keybuk> I'm buggered if I can find "rsync/zsync based synchronization tool for deb packages"
[10:03] <Keybuk> "succinct"
[10:03] <Keybuk> how, utterly, errr succint of it
[10:03] <mdz> some of these are doomed to be split up during the meeting
[10:03] <Keybuk> mvo: you like the succinct spec?
[10:03] <Keybuk> hmm, it's SoC 2006 allegedly, is that right?
[10:04] <mvo> Keybuk: yes, its a SoC project now, I think it is cool and doable
[10:04] <Keybuk> mvo: is there any point discussing it at UFK then?
[10:04] <Keybuk> given the author isn't coming
[10:04] <mvo> Keybuk: probably not, no - only if paul is coming
[10:05] <Keybuk> "paul" ?
[10:05] <mvo> paul sladen
[10:05] <Keybuk> he's listed as unlikely
[10:05] <mvo> he seems to have some more generic plans for all of it I would be interessted to talk to him
[10:05] <mvo> ok
[10:05] <mvo> I'll ask him
[10:06] <mvo> but without sladen, there is little point in scheduling the spec
[10:06] <mvo> and even with him there is no need to schedule more than a single session I guess
[10:07] <Keybuk> launchpad_prod=> select name from specification where title like 'Launchpad Account%';
[10:07] <Keybuk>         name
[10:07] <Keybuk> ---------------------
[10:07] <Keybuk>  launchpad-login-app
[10:07] <Keybuk> (1 row)
[10:08] <mdz> Keybuk: I need to get me one of those
[10:08] <Keybuk> mdz: login to drescher, become lp_archive ... psql -h jubany -U ro launchpad_prod
[10:09] <mdz> Keybuk: oh, thanks
[10:10] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/laptop-video-output-control
[10:10] <Keybuk> ^ registrant is not coming ... sivang is subscribed
[10:10] <Keybuk> accept or decline?
[10:11] <Mithrandir> that's nontrivial to implement anyway. Some of it can be done using randr, but most can't.
[10:13] <Keybuk> ok
[10:13] <Keybuk> nothing remaining in proposed
[10:14] <mdz> I'm almost finished my pass over the accepted stuff,
[10:14] <mdz> tidying it up
[10:14] <mdz> Keybuk: you subscribed to https://launchpad.net/distros/ubuntu/+spec/reboot-halt-notification, but I'm not entirely clear what it's about
[10:15] <mdz> is it notifying desktop users of reboots from non-desktop contexts?
[10:15] <Keybuk> mdz: yeah, afaik it's a graphical "wall"
[10:15] <mdz> *shrug*
[10:15] <Keybuk> I did subscribe to things on a "if they're on the list, I may want to listen in" basis
[10:15] <mdz> Keybuk: the registrant isn't going to be there
[10:15] <Keybuk> the registrant isn't coming
[10:15] <Keybuk> => declined
[10:16] <ogra> perople ask a lot about that, i never understood why (how can i send something like the termonals shutdown message to all desktops)
[10:16] <ogra> grmbl ... i need a typing course
[10:17] <Keybuk> mdz: what's the status on "needs further discussion" specs?
[10:17] <Keybuk> ie. java-roadmap where it has been explicitly unchecked
[10:17] <Keybuk> uh, "does not need further discussion"
[10:17] <Keybuk> is there any point having those for the meeting?
[10:18] <mdz> where is the 'informational' designation hiding these days?
[10:18] <Keybuk> the big (i)
[10:18] <mdz> I mean where is it  changed
[10:18] <Keybuk> and/or "Edit Details"
[10:19] <mdz> thanks
[10:19] <mdz> the "needs further discussion" flag should probably be cleared globally for paris
[10:19] <Keybuk> all specs should have an assignee, yes?
[10:19] <mdz> it's meant to be per-meeting state but isn't
[10:19] <Keybuk> "set globally", you mean?
[10:19] <mdz> Keybuk: I'm assigning where the person is a known developer
[10:19] <mdz> Keybuk: right, set
[10:20] <mdz> we will have some specs where we have a subject matter expert there leading the discussion, but they won't be implementing it
[10:20] <mdz> I'm leaving those blank
[10:21] <mdz> https://launchpad.net/distros/ubuntu/+spec/xenubuntu-livedvd is a project that someone is actually working on, but they're not attending
[10:23] <mdz> ok
[10:23] <mdz> I've finished my first pass
[10:23] <mdz> need to go back and look at the ones you accepted since we've been talking
[10:24] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/comprehensive-coherent-wireless-client
[10:25] <Keybuk> (accepted simply because he's coming)
[10:25] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/edgy-content
[10:25] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/forum-integration
[10:26] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/kde-kiosk-profiles
[10:26] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/kubuntu-accessibility
[10:26] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-settings-usability
[10:26] <mdz> what  do you think about subscribing teams to specs?
[10:26] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/kubuntu-usability
[10:26] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/kubuntu-userprofiling
[10:26] <mdz> e.g., subscribing the accessibility team to all the a11y specs
[10:26] <Keybuk> mdz: does that work?
[10:26] <Keybuk> I didn't think the e-mail notifier could handle that
[10:26] <mdz> Keybuk: I expect it does, yes
[10:26] <Keybuk> if it works, sure
[10:26] <mdz> well
[10:27] <mdz> do we want it to work?
[10:27] <Keybuk> dunno, do we? :p
[10:27] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/launchpad-login-app
[10:27] <mdz> does ti make sense to notify teams of relevant spec changes?
[10:27] <mdz> should probably ask some teams
[10:27] <Keybuk> it makes sense to me
[10:27] <mdz> I think it probably depends
[10:27] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/spoken-boot
[10:27] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/make-free-space-wizard
[10:27] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/ubuntu-on-olpc
[10:28] <Keybuk> those are the specs I accepted -- feel free to edit or decline them again
[10:29] <Keybuk> launchpad-login-app is marked "Not for us" in priority
[10:29] <mdz> ok, https://launchpad.net/sprints/uds-paris/+specs is looking pretty good
[10:30] <mdz> will need to go and hassle some folks who are short on specs
[10:30] <ogra> mdz, do you have a spec for dexconf changes ? someone subscribed me to a spec that would be superseded by it (because he found my name on a bugreport)
[10:30] <Riddell> Keybuk: pong
[10:30] <mdz> ogra: no, I don't, what's the one you found?
[10:30] <ogra> https://launchpad.net/distros/ubuntu/+spec/gene
[10:30] <Riddell> mdz: you asked me to narrow kubuntu-usability, so I changed it to adept-usability
[10:30] <ogra> i just found that i'm subscribed to that one
[10:31] <mdz> "gene"?
[10:31] <mdz> oh, that's the name of the guy who proposed it, heh
[10:31] <mdz> Keybuk: I think it's only on the distrorelease
[10:31] <ogra> the hwdb-client stuff is covered by a whishlist bugy anyway and the 3d driver stuff should be covered by a "better-x-detection" spec
[10:31] <Keybuk> mdz: talking of which, should these all be targeted to edgy?
[10:32] <Keybuk> or only after approval?
[10:32] <Keybuk> that field seems a bit of a no-op though
[10:32] <Keybuk> mdz: to be fair to "gene", he did say in the status that he was confused by the meaning of the "Name:" field
[10:32] <mdz> I think maybe we should clear the priorities, since it's only set for old specs and their priority is unlikely to be the same for edgy
[10:33] <mdz> Keybuk: I had planned to wait until the specs were written actually
[10:33] <Keybuk> mdz: seems fair (to both)
[10:33] <mdz> I don't think we have enough information yet
[10:33] <mdz> ok, I'll clear the priorities
[10:33] <Keybuk> if only we could clear it where it's already set (to dapper or edgy)
[10:34] <ogra> you need a widescreen LCD ;)
[10:35] <Keybuk> this is where we need infinity :p
[10:35] <Keybuk> "UPDATE specification SET..."
[10:38] <mdz> Keybuk: I'm leaving the priority alone on the ones with sabdfl fingerprints on them
[10:38] <mdz> e.g. the rosetta ones
[10:38] <Spec> mdz: You changed Home-User-Backup to undefined?
[10:38] <Keybuk> I can't even touch the rosetta ones
[10:38] <Keybuk> I only have Ubuntu super-powahs, not LP ones
[10:38] <LaserJock> Keybuk: hehe
[10:39] <mdz> Spec: see above
[10:40] <mdz> Keybuk: I'm done, the remaining priorities are OK
[10:40] <Keybuk> mdz: gimme a minute, just doing a pass over them all myself
[10:40] <mdz> Keybuk: https://launchpad.net/distros/ubuntu/+spec/no-more-source-packages ?
[10:41] <Keybuk> mdz: aye, informational topic for discussion
[10:41] <mdz> Keybuk: but the summary doesn't explain what the discussion will be about.  is it meant to be a surprise?
[10:41] <Keybuk> the spec as is on the wiki is more of a debate starter than a something to write
[10:41] <Keybuk> ah, sorry; the spec is actually written -- see "Read more" :p
[10:41] <Spec> mdz: see above where?
[10:42] <Keybuk> . o O { why am I paranoid about tabs hiding under the tab close button }
[10:43] <Spec> ohh
[10:43] <ajmitch> it's an interesting idea, at least
[10:43] <Spec> ne'ermind *slow*
[10:43] <ajmitch> mdz: not sure if network-authentication needs to be discussed at paris now, I'm doing it as SoC project
[10:43] <Keybuk> ajmitch: are you coming to Paris?
[10:44] <ajmitch> nope
[10:44] <ogra> why ?
[10:44] <ogra> ajmitch, thats not nice from you
[10:44] <ajmitch> ogra: hm?
[10:44] <ogra> leaving us alone there
[10:44] <ajmitch> I know, but it's a little far to swim
[10:44] <Keybuk> along ... with OGRA!
[10:44] <ogra> heh :)
[10:45] <ogra> ajmitch, hey, i even go by car ...
[10:45] <ogra> so swimming would be the least you could do for us :)
[10:45] <Keybuk> mdz: should we clear the "Basic direction approved?" flag ?
[10:45] <mdz> oh, hmm, I was looking at the wrong page, there are more priorities to review
[10:45] <ajmitch> yeah, I would have applied/begged for sponsorship, except the timing is wrong :)
[10:46] <mdz> Keybuk: not in every case, no
[10:46] <mdz> ah, no, I just got lost in my tabs. priorities are ok
[10:46] <Keybuk> mdz: the only spec which has it set is native-java-gcj
[10:47] <mdz> Keybuk: odd, I thought that was new
[10:47] <mdz> yes, that should be cleared
[10:48] <Keybuk> heh, wonder whether someone was setting their own status there <g>
[10:48] <Keybuk> I choose not to change the priority of "tab-consistency" :)
[10:48] <mdz> smart move
[10:49] <mdz> Keybuk: anything which isn't specific enough should be marked informational, with the expectation that it'll be broken down into smaller specs
[10:50] <Keybuk> it's a bit hard definining specific without seeing the spec
[10:50] <mdz> mailed iwj about package-dependency-fix
[10:50] <mdz> the summary should be good enough to know what it is about, if not, the responsible party needs to be nagged
[10:52] <Keybuk> just gonna grab some tea, brb
[10:59] <mdz> ogra: do you have a spec registered for completing the automation of the ltsp install?
[10:59] <mdz> ogra: if not, please put one in.  I know you already said you had a branch but it needs to be tracked
[10:59] <ogra> nope, i saw that as general improvement of the package and didnt see a need to spec that
[11:00] <ogra> i havent finished the work on that branch when you said i should keep it for edgy
[11:01] <ogra> andit was only changes in the ueb, it wouldnt work from the package alone, that would probably need discussion ...
[11:01] <ogra> *udeb
[11:04] <Keybuk> back
[11:05] <ogra> mdz, https://launchpad.net/distros/ubuntu/+spec/ltsp-dhcpd-autogeneration
[11:06] <Keybuk> jenda: Ubuntu Development Summit (Paris)  spec meeting
[11:06] <Spec> jenda: it's a meeting of specs
[11:06] <mdz> hmm, we should clear the release goal for those still targeting dapper
[11:07] <Keybuk> mdz: oh, Colin said he wants all of his specs to be Essential again :)
[11:07] <Keybuk> mdz: I tried, I can't clear it :-/
[11:07] <mdz> I'm doing it
[11:07] <mdz> Keybuk: did he call you during his holiday to let you know? ;-)
[11:07] <Keybuk> mdz: he told me so in London
[11:07] <Keybuk> he said "I swear, if all my specs are NOT Essential this time, I'm leaving"
[11:08] <Keybuk> hmm, maybe the "NOT" wasn't in there :p
[11:08] <mdz> Keybuk: ugh, you're right, it seems impossible to clear
[11:08] <mdz> Keybuk: could you file a bug about that?
[11:08] <Keybuk> holy cow, there's a "blueprint" product
[11:09] <Keybuk> mdz: what happens if you "decline" the spec for dapper, does it go away?
[11:10] <mdz> mvo: isn't auto-dist-upgrade-testing already implemented?
[11:10] <mdz> Keybuk: I don't know; the ones I see are Accepted, not Proposed
[11:10] <Keybuk> yeah, there does not appear to be a way to un-accept them
[11:11] <mdz> the drop-down for setting the release goal isn't even populated correctly; it's surely a bug
[11:11] <mdz> those specs are targeted for dapper, but the box defaults to (no value), which won't even validate
[11:11] <mvo> mdz: not fully/like I want it
[11:12] <Keybuk> yeah, it appears that "adds another release goal"
[11:13] <Keybuk> optimized-live-cd-layout-for-faster-boot => high ?
[11:14] <mdz> Mithrandir: around?
[11:14] <Mithrandir> yeah
[11:14] <mdz> Mithrandir: what's the relationship between livecd-sessions and livecd-write-as-you-go?
[11:14] <mdz> is write-as-you-go likely to use the same session infrastructure?
[11:14] <mdz> i.e., is it a depndency?
[11:15] <Mithrandir> yes, I think so.
[11:15] <Mithrandir> I think I have enough parts implemented already to do l-w-a-y-g, but it should at least be thought about.
[11:16] <Mithrandir> as in, -sessions and write-as-you-go will most likely share a bunch more of the code.
[11:17] <mdz> Keybuk: I think we should set the tech board as approver for all specs for now
[11:17] <mdz> so that we get notifications of changes
[11:18] <Keybuk> ok, I'll go through them and do that now
[11:19] <mdz> linky?
[11:19] <ogra> your dog ?
[11:19] <mdz> Keybuk: is that a LP screen scraper?  if so, I want a copy :-P
[11:20] <Keybuk> it's a firefox extension, has an "open all links in tabs" feature :p
[11:20] <Keybuk> damned handy for LP
[11:20] <ogra> you could just hold down ctrl all the time  :)
[11:20] <ogra> or tape it ...
[11:20] <Keybuk> ogra: that gets tedious
[11:23] <mdz> I just middle-click, and have firefox set to open tabs in the background
[11:23] <mdz> Keybuk: isn't *all* links a bit more than you typically want?
[11:24] <Keybuk> mdz: well, normally yes
[11:24] <Keybuk> it pops up a dialog and you can filter it out
[11:24] <Keybuk> so I go "open all links in tabs" -> "match /+spec/" -> ok
[11:29] <Keybuk> mdz: I can't do rosetta-oo-import-export
[11:32] <Keybuk> I like the way Mark registers specs and sets himself as the approver
[11:32] <Keybuk> (tab-consistency)
[11:34] <mdz> ok, first pass of prioritization is done
[11:35] <ogra> meh ...
[11:35] <mdz> high ~= "we should do this", medium ~= "would be cool", low ~= "other things are more important", undefined ~= undecided
[11:36] <ogra> yep, grokked that ... but i dont see student control panel as high or ltsp-management-gui as low
[11:36] <mdz> essential is only sab-override at this point; probably more things will become essential
[11:36] <mdz> ogra: student control panel is something you told me the community wants very much, while the management gui you said was a pet project of yours
[11:37] <ogra> well, yes
[11:37] <sivang> topic
[11:37] <ogra> but s-c-p is already existing and has some drive in the community, i can hand it to someone
[11:38] <Keybuk> !?! @ font-design-toolkit
[11:38] <ogra> while i wuldnt like that for ltsp-manager until the initial featureset is done ...
[11:39] <Keybuk> oh, registrant is just unconfirmed as coming
[11:40] <mdz> oh? I thought he was coming
[11:40] <Keybuk> he's french, so probably
[11:40] <Keybuk> https://launchpad.net/products/rosetta/+spec/gnome-mount
[11:40] <Keybuk> ^^ why is that a rosetta spec?!
[11:40] <ogra> and i also saw edubuntu-edgy-cd-diet as a spec what to drop and what to keep on the CD based on numbers and measurements from the BOF shrinking the edubuntu CD is also essential
[11:45] <Keybuk> mdz: most edgy specs would seem to default to "medium" ?
[11:48] <mdz> Keybuk: in what way do you mean?
[11:48] <mdz> as in, people are expected to propose things based on coolness?
[11:48] <Keybuk> well, edgy specs are developer personal itches which amounts to "would be cool" .. unless there's a particular reason that it's higher or lower
[11:48] <Keybuk> indeed
[11:51] <Keybuk> all specs (except ~4) are approver: techboard now
[11:53] <mdz> Keybuk: priority is a distro-level concept, though, rather than the registrant's perspective
[11:53] <Keybuk> true, true
[11:53] <mdz> it's also one of the main scheduling constraints
[11:53] <mdz> so it's also "how important is it that we spend face time on this"
[11:54] <mdz> simpler stuff is likely to get done on its own without a lot of discussion, or can be discussed by mail
[11:54] <Keybuk> I've done a pass over them as well
[11:57] <Keybuk> build-failure-process ... that one seems useful?  high?
[11:57] <mdz> Keybuk: oh, yes
[11:58] <mdz> I think that's one where I needed to both set it to informational and set the priority, and forgot one
[11:58] <mdz> maybe I should open two tabs in those cases :-P
[11:58] <Keybuk> I open all of the change tabs at once, and then hunt around for the thing I was looking for
[11:58] <ajmitch> I get worried when I see specs name 'edgy-content'
[11:58] <ajmitch> that has so many meanings..
[11:58] <Keybuk> ubiquity-advanced-partitioner => medium ?
[12:00] <mdz> Keybuk: yeah
[12:00] <Keybuk> hmm, package-dependency-fix worries me ... I have a feeling Ian wants to "change things" with Replaces
[12:01] <Keybuk> live-cd-stacked-filesystems -- that will let us do other cool things like a triple-arch DVD ... medium?
[12:02] <mdz> Keybuk: the idea of demanding more complexity from unionfs frightens me
[12:02] <Keybuk> unionfs hasn't proved to be the brittle link in the chain though


[08:04] <fnordahl> mnasiadka: Thank you for reaching out. Starting with wallaby we included ovn in
[08:05] <fnordahl> UCA. As soon as Impish is refreshed with a new OVN package we should be able to
[08:05] <fnordahl> provide that to the xena UCA.
[08:14] <BraveheartBSD> Anyone have a guide for setting up hardware raid?
[11:33] <webchat7> Hi. Can someone help me out with Ubuntu 20 cloud-init based unattended server installation?
[11:33] <webchat7> Unattended installation works ... It's just that cloud-init doesn't do anything afterwards, even if I reset it and remove the file that disables network configuration.
[11:37] <rbasak> webchat7: what are you expecting cloud-init to do?
[11:40] <webchat7> I expect cloud-init to initiate again when I attach a coud-init image/drive - some block device with label cidata containing user-data network configuration etc
[11:40] <rbasak> I don't think it's designed to do that, sorry.
[11:41] <rbasak> The "installer" is designed to install Ubuntu on a machine permanently. It isn't for making cloneable images.
[11:42] <rbasak> You might be able to hack something together, though.
[11:42] <webchat7> on other distibutions it does exactly that. Attach an iso with another configuration, reboot or clean and init and it's doing just fine
[11:42] <webchat7> So it's not a hack, when I get it to work
[11:43] <rbasak> cloud-init is designed to do that, yes.
[11:44] <rbasak> The installer is not.
[11:44] <webchat7> Sure, I'm talking about after the installation
[11:44] <rbasak> You'll see that behaviour work with Ubuntu cloud images. Why are you using the intsaller instead of using cloud images?
[11:44] <webchat7> The only way, I figured, was messing around with /etc/cloud/cloud.cfg
[11:45] <rbasak> I'd look into what datasource the installer sets up, if you want to hack something together. See https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
[11:45] <rbasak> Probably cloud-init is being configured to use a different datasource to your "config drive".
[11:46] <rbasak> However, I'm still pretty sure that using the installer to achieve this will be a hack. The intended way to get what you want is to use Ubuntu cloud images.
[11:46] <webchat7> I'm using the server installer, because I don't always have network access
[11:46] <rbasak> You can boot Ubuntu cloud images without network access.
[11:47] <rbasak> You might need to configure cloud-init not to time out though.
[11:48] <webchat7> I need to do a full installation on bare metal as well as VMs completely offline. Some packages I need are not in the cloud images.
[11:49] <rbasak> For the VMs, boot a cloud image somewhere else online, install the packages you want, shut down, and then clone that image.
[11:49] <rbasak> I can't help with the bare metal though, sorry. I don't think we currently provide any general mechanism to roll an installer image with additional packages embedded in it. You can hack that together using the same method we use to roll our installer images, of course.
[11:50] <rbasak> clone that image> as long as cloud-init sees a different instance-id (eg. you're providing a config drive) then it'll do the right thing there.
[11:51] <webchat7> Already added packages to the Ubuntu 18 installer - but since I use d-i preseed there, it works quite well
[11:52] <webchat7> I think I'd rather want to reset cloud-init and delete the configuration after Ubuntu 20 setup. Will require some hack, but it'll do the trick
[11:52] <webchat7> thanks
[11:57] <rbasak> webchat7: I've been looking for this link. Just found it: https://discourse.ubuntu.com/t/a-tool-to-modify-live-server-isos/22195
[11:58] <rbasak> You might find that useful.
[12:00] <webchat7> I'm alredy doing that. The cloud-init config for the unattended installer and the grub config is being added to the ISO in a similar way.
[12:01] <mgedmin> you mentioned d-i preseeds, which implies you used the alternative installer
[12:01] <webchat7> for Ubuntu 18 I do - and that works
[12:01] <webchat7> For Ubuntu 20 I don't
[12:01] <mgedmin> ubuntu 20.04 lts will not have it, and livefs-editor is a tool for customizing the new subiquity installer
[12:03] <webchat7> The installation isn't the problem. It's just that cloud-init doesn't do anything after the installation when I attach a cloud-init config
[12:07] <webchat7> I already figured the rest of it out, which was quite a bad experience btw. At that time, the Autoinstall Reference said at some points "The snap mentioned above doesn't exist yet"
[12:18] <rbasak> webchat7: specific feedback on improvements welcome please. Fundamentally I think the issue is that your use case isn't currently supported though?
[12:19] <webchat7> I'll find my way ;)
[12:19] <webchat7> just thanks for confirming, what I already thought
[14:58] <shubjero> coreycb: Re: cloud-archive and version control. Any reason why Ubuntu repositories dont keep previous versions for users to target / roll back to? Any idea on how I can obtain Neutron 16.3.0 for bionic from CA?
[15:02] <ogra> shubjero, deb packages are not really designed for rollback ... if you'd go back to a former one, that might use other dependencies ... these dependencies would have to roll back as well ... other apps depending on them would then have to be rolled back etc etc
[15:02] <ogra> that would create a giant mess in the end
[15:03] <ogra> if you want seamless rollback, this is what snap packages were designed for ... they can go back and forth at will
[15:03] <shubjero> ogra: OK but when a package contains a show-stopping bug (like bringing an entire cloud offline).. you need to roll back to a version that previously worked.
[15:03] <shubjero> And the dependency chains are usually well respected from my experience
[15:04] <ogra> no, as a packager you still go forward (you might change the contents of the package to the former ones but you still release a higher version)
[15:04] <shubjero> ogra: But if the repository has pruned the previously working version, its a quick way for your users to drop  your product long term
[15:04] <ogra> the main archive never prunes anything ... are you sure you are not talking about a PPA ?
[15:04] <shubjero> As a packager yes, you always move forward. As an operator, you use what works and avoid what doesnt.
[15:05] <tomreyn> ogra: i disagree on "the main archive never prunes anything"
[15:05] <ogra> tomreyn, well, it is true 🙂
[15:06] <tomreyn> you're saying all old package versions are kept?
[15:06] <shubjero> I just did an apt-cache policy openssl-client and I have 1 version available (latest) from the Ubuntu repositories
[15:06] <ogra> tomreyn, yes
[15:06] <tomreyn> ogra: i'm convinced that's not so.
[15:06] <shubjero> If i do the same on a 3rd party repository, like zabbix, elastic, mariadb, I  have dozens of versions I can target for use/installation. This is how all repositories should be.
[15:07] <ogra> tomreyn, here is an example https://launchpad.net/ubuntu/+source/htop/+publishinghistory
[15:07] <tomreyn> ogra: but i see how it's now up to me to proove that, and i don't want to subvert the ongoing discussion, will get bakc to it later.
[15:07] <tomreyn> ogra: oh oyu mean on launchpad, not on archive.u.c
[15:08] <ogra> launchpad *is* archive.u.c 😉 just a different representation of it
[15:09] <tomreyn> there was recently a glibc problem where a newer, boroken package, got published, then pulled a while later, because it introduced new problems. so some ended up with the newer more broken versionn , others with the older, less broken version
[15:10] <ogra> yeah
[15:10] <shubjero> ogra: https://pastebin.ubuntu.com/p/hZXgybGzkg/
[15:11]  * ogra remembers ... there was also some bad timing involved with the Packages.* file generation
[15:11] <tomreyn> and when those with the newer version tried to install debug packages, they could not, because depednencies could not be resolved.
[15:11] <tomreyn> at least one of those package version were no longer available on launchpad either
[15:12] <tomreyn> shubjero: looks like 3rd party packages
[15:12] <ogra> that only happens if someone actually manually removed something ...  normally LP does not lose any revision of any packages ever uploaded to the archive
[15:13] <ogra> the libc bug might have been severe enough to do this though
[15:13] <tomreyn> ogra: that may be so. but you originally ruled it out happening at all
[15:13] <ogra> normally it does not happen ... if there would be i.e. a bitcoin miner in a libc upload it would definitely be removed to not cause harm though
[15:14] <tomreyn> we were just talking about bug 1926918
[15:14] <tomreyn> https://askubuntu.com/questions/1315906/unmet-dependencies-libc6-the-package-system-is-broken
[15:14] <shubjero> tomreyn: Yes, I am trying to convey that many 3rd party repositories keep several versions around, protecting operators by allowing a rollback to a previous version if something bad is discovered in the new package version. It seems like any of the Ubuntu repositories (including cloud-archive).. that's just not possible and from an operator perspective its terrible
[15:15] <ogra> tomreyn, right, our system assumes that things having been tested in -proposed actually have been tested before moving to -updates 🙂 ...
[15:16] <ogra> people sometimes make mistakes and automation sometimes fails ... but these are corner cases
[15:16] <tomreyn> shubjero: okay, i tend to agree to the "everything should be preserved", as debian does it. but if a 'fixed version' (higher version number, previous package) would become instantly available after reggressions are detected, i'd be fine with this, too.
[15:17] <shubjero> Agree with you both. Also, I always test my OpenStack upgrades in our lab with the packages available at that time. If by the time I've scheduled the production roll out, newer packages are available (and untested), I'd still like to be able to install the packages I tested in the lab.. but now I can't because those versions are gone
[15:18] <tomreyn> ogra: IMO that'd be fine if (non packaging-aware) users were able to resolve the sitation on their own. but i don't want you to waste your time on this debate now. ;-)
[15:18] <ogra> if you preserve everything in archive.u.c it means that (at most voluntary) mirrors will need a lot more resources ...
[15:19] <shubjero> Turns out that what I tested in my lab was Neutron 16.3.0 and worked great but by the time I rolled out to production only Neutron 16.3.1 was available and contained a show stopping bug that took our entire cloud offline and I had to try and scramble to find an old version of Neutron to install. I managed to find 16.0.0 from Focal which seemed to work but now I'm having many other issues
[15:19] <tomreyn> you'd just need one central mirror for that
[15:19] <shubjero> which could be because I'm having to run an unexpected version of Neutron
[15:19] <shubjero> Anyways, these are operational war stories
[15:20] <tomreyn> snapshot.debian.org is actually two mirrror (or maybe 4, 2x ipv4, 2x ipv6)
[15:22] <tomreyn> i'd assume canonical has more resources at their disposal than a volunteer run project, but then debian has snaphshot.debian.org but ubuntu has not. :-/
[15:23] <tomreyn> see also deb.debian.org, https mirrors etc.
[15:23]  * tomreyn quits whining for now
[15:24] <ogra> well, Lp is our snapshot.d.net 🙂
[15:27] <tomreyn> not if it doesn't preserve everything
[15:27] <tomreyn> i'd say Lp is Ubuntus tracker.debian.org and buildd.debian.org
[15:28] <tomreyn> + salsa
[15:55] <ilpianista> anyone else is using the latest 20.04 AMI on EKS? I cannot make it work because it's missing the heptio-authenticator-aws binary apparently. The previous AMI works fine
[16:01] <tomreyn> ilpianista: aws seems to no longer recommend heptio's by default, but their own (fork?): https://github.com/kubernetes-sigs/aws-iam-authenticator#aws-iam-authenticator-for-kubernetes
[16:02] <ilpianista> yep, but the AMI has neither
[16:02] <tomreyn> see also (outdated) https://aws.amazon.com/blogs/opensource/deploying-heptio-authenticator-kops/ vs (current) https://aws.amazon.com/blogs/opensource/deploying-aws-iam-authenticator-kubernetes-kops/
[16:02] <tomreyn> oh ok
[23:12] <mwhudson> https://discourse.ubuntu.com/t/please-test-wifi-support-in-the-server-installer/22732
[23:22] <sarnold> oo cool


[08:55] <geser> tseliot: Hi, randomaction found a new issue with mesa over the weekend. in short: libgl1-mesa-swx11 is missing the ld.so.conf snippet
[08:56] <tseliot> geser: is there a bug report about it?
[08:57]  * tseliot reboots (brb)
[09:04] <tseliot> geser: what was the error, exactly?
[09:07] <geser> tseliot: no bug was filed (as far as I know). the problem is that rss-glx build-depends on libgl1-mesa-swx-dev which pulls in libgl1-mesa-swx11 but as it also has libGL1.so in /usr/lib/mesa but no ld.so.conf config the lib don't get found
[09:09] <tseliot> geser: I think we can easily get rid of this problem by removing the abi-note tag from mesa and putting the libraries back in /usr/lib/
[09:09] <tseliot> I think I'll do it after alpha 3 though as I need to focus on plymouth now
[09:10] <geser> what ever works, should I file a bug for tracking?
[09:10] <tseliot> geser: yes, please and assign it to me
[09:20] <geser> tseliot: bug #522048
[09:21] <tseliot> geser: thanks
[10:21] <ara> tseliot, hey, have a couple of minutes for a chat?
[10:22] <tseliot> ara: sure
[16:30] <Sarvatt> tseliot: if they help any - http://sarvatt.com/downloads/patches/0001-Add-100_no_abi_tag.patch.patch  http://sarvatt.com/downloads/patches/0001-Install-alternatives-for-libgl1-mesa-swx11-as-well.patch
[16:31]  * tseliot has a look
[16:39] <tseliot> Sarvatt: both patches are appreciated :-) I'm extremely busy with plymouth and I couldn't have worked on them until alpha 3. Feel free to push/upload them. Thanks
[16:50] <tjaalton> but only one of them is needed, right?
[16:51] <tjaalton> hmm no, the alternatives is needed anyway
[16:52] <Sarvatt> the abi tag one doesn't interfere with anything for now at least, i'm unsure what tseliot wants to do with mesa alternatives after having that so i didn't mess with that yet
[16:55] <tseliot> Sarvatt: the abi tag is fine. As regards the other one, it should fix a bug (reproducible when libgl1-mesa-swx11 instead of libgl1-mesa-glx is installed)
[16:55] <tseliot> right?
[16:55] <Sarvatt> would be nice if we could get rid of the alternatives from mesa and move them to the things that provide an alternative libGL :D
[16:56] <tseliot> but then you would have to uninstall the other packages that provide that alternative in order to switch back to mesa
[16:56] <tseliot> which is not what we want
[16:56] <Sarvatt> what if they provided both alternatives?
[16:57] <Sarvatt> i need to build mesa with these changes to see if it needs more work, not sure i got everything there for swx11
[16:57] <tseliot> do you mean, each nvidia driver and the fglrx driver should provide the alternative for mesa in addition to their own?
[16:57] <jcristau> sounds like a mess
[16:58] <jcristau> they don't depend on the mesa libGL so you might end up with dangling symlinks
[16:58] <tseliot> Sarvatt: the latter can be a temporary fix as, thanks to the former, I should be able to move the mesa libraries back to their original location
[16:58] <jcristau> or a missing libGL.so.1
[16:58] <jcristau> (or maybe i'm missing something)
[16:59] <tseliot> jcristau: I was asking to see if I was understanding things correctly
[16:59]  * tseliot is still jet-lagged
[17:05] <tseliot> Sarvatt: in conclusion the 1st patch should be ok. The 2nd should be ok (if well tested) as a short term fix (you might as well wait for my long term solution, it's up to you).
[17:19] <Sarvatt> mesa is building in here with the libgl1-mesa-swx11 change - https://edge.launchpad.net/~sarvatt/+archive/bugfixes
[17:21] <Sarvatt> need to figure out why mesa master stopped building for the past 3 days now :( https://launchpad.net/~xorg-edgers/+archive/ppa/+build/1508637/+files/buildlog_ubuntu-lucid-i386.mesa_7.8.0~git20100214.db18996d-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[17:21] <Sarvatt> hmm dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/libglu1-mesa/usr/lib/libGLU.so.1.3.070800 (ELF format: 'elf32-i386'; RPATH: '').
[18:04] <Sarvatt> so yeah libgl1-mesa-swx11 removes libgl1-mesa-dev libgl1-mesa-glx libglu1-mesa-dev libsdl1.2-dev ubuntu-desktop
[18:05] <Duke`> :/
[18:07] <Sarvatt> geser: http://paste.ubuntu.com/377015/
[18:08] <Sarvatt> looks like libgl1-mesa-swx11 needs to be providing libgl1 as well also?
[18:08] <geser> Provides: libgl1, libgl1-mesa-swrast, mesag3 (from the package in the archive)
[18:10] <Sarvatt> yep same, odd
[18:11] <Sarvatt> the changes i pushed in git seem to be fixing the steps to reproduce in your bug at least, don't know what else I should check
[18:11] <geser> the dpkg output is because libgl1 is temporarily not installed until libgl1-mesa-swx11 is installed later
[18:14] <geser> Sarvatt: if you want another test case for your mesa changes: try rebuilding rss-glx as it build-depends on libgl1-mesa-swx11-dev
[18:15] <Sarvatt> doing that now
[18:16] <Sarvatt> alternatives look fine still after installing the build deps, package is building now
[18:17] <Sarvatt> configure: error: GL library was not found.
[18:17] <Sarvatt> make: *** [config.status] Error 1
[18:29] <Sarvatt> alternative is working fine from what I can see but autoconf doesn't like the non standard location?
[18:33] <geser> have you looked at the config.log what exactly failed?
[18:36] <Sarvatt> it does a AC_CHECK_LIB([GL],[glNewList]) and can't find glNewList in -lGL or -lMesaGL so it fails
[18:37] <Sarvatt> that mean we need to install gl.pc in another package as well?
[18:44] <Sarvatt> it's there though - 00224d20 T glNewList
[19:48] <BUGabundo> hey
[19:49] <BUGabundo> last night updates, manage to get 2.6.32-13-generic to boot fine (no 3D), while -12 stop starting X with high resolution


 Please begin moving over here: https://matrix.to/#/!JQQLEcNFoKzwphpTzR:ubuntu.com?via=ubuntu.com

 This channel will eventually be removed in favor of that one. Consider this your depreciation notice.
 (re @tsimonq2: Please begin moving over here: https://matrix.to/#/!JQQLEcNFoKzwphpTzR:ubuntu.com?via=ubuntu.com

 This channel will eventually be removed in favor of that one. Consider this your depreciation notice.)
[03:27] <Eickmeyer> Imagine @tsimonq2 getting lubot +q 'd for posting a deprecation notice.
 What about kgpg? I am trying to use that as I find gui easier but I still cannot find a way to take the the keyring and export from gpg4usb to kgpg. None of this explains why in windows is can view all my keys and in Ubuntu when I open gpg4usb they all but disappeared. (re @teward001: if I am reading my docs on gpg4usb right it has keyring files for all your keys that tomb or gpg on the systen natively can open.  Havent tested that t
 Too much spam on here, I agree. (re @tsimonq2: Please begin moving over here: https://matrix.to/#/!JQQLEcNFoKzwphpTzR:ubuntu.com?via=ubuntu.com

 This channel will eventually be removed in favor of that one. Consider this your deprecation notice.)
 The only major blocker to hard-moving everything over is federation between smaller servers
 If you have a matrix.org account or an ubuntu.com account as an Ubuntu Member, those work. We've been given an ETA of < 2 weeks for the others. I know linuxdelta.com, Fedora, Altispeed, and a few others are allowlisted, but that isn't 100% finalized yet.
 That being said, the more eyes, the better. Truly open platform, server, client, and protocol. There will be snags, our goal is to find them and fix them ASAP
 Easy to understand guide from a colleague of mine: https://frontpagelinux.com/tutorials/beginners-guide-how-to-get-started-with-element-matrix/


[15:00] <infinity> o/
[15:01] <sil2100> o/
[15:04] <cyphermox> o/
[15:04] <rbalint> o/
[15:04] <cyphermox> yay meeting!
[15:05] <tdaitx> hmm, steve is away?
[15:09]  * xnox wonders if i can reboot back into applying windows updates
[15:13] <cyphermox> let's have the meeting anyway?
[15:13] <rbalint> i would love to talk about reviewing the current Ubuntu delta for packages
[15:13] <infinity> cyphermox: Is that you volunterring to run it?
[15:13] <cyphermox> yeah
[15:13] <cyphermox> #startmeeting foundations
[15:13] <meetingology> Meeting started Thu Apr 27 15:13:25 2017 UTC.  The chair is cyphermox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:13] <meetingology> Available commands: action commands idea info link nick
[15:13] <bdmurray> hooray for cyphermox
[15:13] <cyphermox> echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox tdaitx xnox chiluk mwhudson rbalint)
[15:14] <cyphermox> robru caribou sil2100 bdmurray rbalint tdaitx infinity chiluk barry slangasek doko mwhudson xnox cyphermox
[15:14] <cyphermox> maybe this list is out of date.
[15:14] <sil2100> Yeah
[15:14] <bdmurray> :-(
[15:14] <cyphermox> :(
[15:14] <tdaitx> damn =(
[15:14] <cyphermox> sil2100: you go
[15:14] <sil2100> Need to find my list
[15:14] <caribou> yeah, just dropped by to say hi :)
[15:14] <sil2100> caribou: hey ;)
[15:14] <sil2100> - Bileto:
[15:14] <sil2100>   * Forced clearing the lru_cache for Bileto to enable artful
[15:14] <sil2100>   * Looked into missing GPG key errors, filled RT, helped resolve with webops
[15:14] <sil2100> - ubuntu-image:
[15:14] <sil2100>   * Helping out in debugging broken github PR test result reporting, filled RT
[15:14] <sil2100>   * Filled RT for upload rights for snap
[15:14] <sil2100>   * Prepared existing branches for merging
[15:15] <sil2100>   * Started work on the hook mechanism - planning and experimental phase
[15:15] <sil2100> - Kernel SRUs
[15:15] <cyphermox> hey caribou!
[15:15] <sil2100> - Regular SRU reviews
[15:15] <sil2100> - Cleanup on uvp-monitor test packages, reading up on xenstore - first builds
[15:15] <sil2100> - DMB meeting
[15:15] <sil2100> - walinuxagent published to -proposed, waiting for SRU validation
[15:15] <sil2100> (done)
[15:15] <bdmurray> Wrote up test case for LP: #1676547
[15:15] <bdmurray> Foundations infrastructure meeting
[15:15] <bdmurray> Discussed an approach to get Package info on ubuntu core
[15:15] <bdmurray> Started work on having Package written client side
[15:15] <bdmurray> Modified snapport to have apport.cli command not apport.apport-cli
[15:15] <bdmurray> Updated StableReleaseUpdates wiki page re: dev release being closed
[15:15] <bdmurray> added artful to errors, daisy code
[15:15] <bdmurray> added artful to lp-retracer-config, updated osageorange
[15:15] <bdmurray> updated u-r-u for artful, uploaded it
[15:15] <bdmurray> updated meta-release-development for artful, updated server
[15:15] <bdmurray> reported / investigated u-r-u bug LP: #1686117
[15:16] <bdmurray> added artful to the official bug tags
[15:16] <bdmurray> resolved issue with daisy not cleaning up core files (LP: #1686135)
[15:16] <bdmurray> submitted RT regarding updating daisy in staging w/ core file fix
[15:16] <bdmurray> tested update of daisy in staging, submitted RT for production
[15:16] <bdmurray> foundations bug triage
[15:16] <bdmurray> irc discussion re LP: #1681231 and LP: #1676547 (using -security for upgrades)
[15:16] <bdmurray> investigation into LP: #1682934 re local python3 and upgrade failure
[15:16] <bdmurray> ✔ done
[15:16] <rbalint> * Finished my core-dev application
[15:16] <rbalint> * Prepared unminimize script, under review:
[15:16] <rbalint>   https://code.launchpad.net/~rbalint/livecd-rootfs/minimize-unminimize/+merge/323157
[15:16] <rbalint> * Started checking each package with delta in main and noticed that Ubuntu history
[15:16] <rbalint>   is not available anymore in bzr: LP: #1686100
[15:16] <rbalint> * Packaging guide also lists gone lintian result server: LP: #1686096
[15:16] <rbalint> * grab-merge with also geting Debian's packaging repo/source with dgit works nicely for packages not in usd-importer yet
[15:16] <rbalint> * Sent Ubuntu deltas to Debian:
[15:16] <rbalint>   main-menu #861237
[15:17] <rbalint>   libdebian-installer #861241
[15:17] <rbalint>   cdrom-detect #861300
[15:17] <rbalint> * Proposed fix for MoM to let people find the comment box to fill
[15:17] <rbalint>   LP: #1686640
[15:17] <rbalint> * I would like to go through the page and provide Debian bug numbers for the forwarded delta or an explanation for not forwarding all of it
[15:17] <rbalint> eof
[15:17] <tdaitx> Short week: holiday on Friday
[15:17] <tdaitx> = JCK
[15:17] <tdaitx>   * Waiting on 8u131
[15:17] <tdaitx> = OpenJDK
[15:17] <tdaitx>   * No more test regressions
[15:17] <tdaitx>   * Preparing package for the security team
[15:17] <tdaitx>   * Backporting patches to OpenJDK 7
[15:17] <tdaitx> = Other
[15:17] <tdaitx>   * National strike on Friday, I will be working
[15:17] <tdaitx>   * Yet another holiday on Monday, I might decide to swap it
[15:17] <tdaitx> (done)
[15:18] <infinity>  * Archive opening for Artful:
[15:18] <infinity>    - toolchain mangling
[15:18] <infinity>    - dpkg/debhelper merges
[15:18] <infinity>    - open archive
[15:18] <infinity>    - update cdimage, debian-cd, snakefruit, etc for artful
[15:18] <infinity>    - update d-i
[15:18] <infinity>    - enable image builds
[15:18] <infinity>  * snakefruit and nusakan upgrades to xenial
[15:18] <infinity>  * investigate LP: #1682934
[15:18] <infinity>  * Misc SRU/AA bits
[15:18] <infinity>  * On vacation all next week \o/
[15:18] <infinity> (done)
[15:19] <gaughen> o/
[15:19] <sil2100> \o
[15:19] <tdaitx> o/
[15:20] <xnox> is it me?
[15:20] <tdaitx> yeah
[15:20] <cyphermox> doko isn't here?
[15:20] <gaughen> only you know if it is you, xnox
[15:20] <cyphermox> oh yeah
[15:20] <xnox> cloud images for onmetal fun
[15:20] <xnox> apt timers bug fun
[15:20] <xnox> wsl fun
[15:20] <xnox> upstart removal fun
[15:20] <xnox> open-vm-tools sru fun
[15:20] <xnox> systemd artful & sru fun
[15:20] <xnox> ...
[15:20] <tdaitx> oh, fun status, yay!
[15:20] <cyphermox> MIR:
[15:20] <cyphermox>  - review gjs and mozjs38 (both for GNOME Shell)
[15:20] <cyphermox> netplan:
[15:20] <cyphermox>  - merging and testing rharper's MTU work
[15:20] <cyphermox> grub2:
[15:20] <cyphermox>  - reworking fbx64.efi's installation process / location
[15:20] <cyphermox>  - handle upgrade / moving fbx64.efi
[15:21] <cyphermox>  - install to /EFI/BOOT too (reworking a patch from Debian)
[15:21] <cyphermox>  - ship BOOTX64.CSV (fallback instructions) to rebuild BootOrder.
[15:21] <cyphermox> d-i:
[15:21] <cyphermox>  - starting d-i merges: installation-report, tzsetup.
[15:21] <cyphermox>  - coordinating merges with rbalint.
[15:21] <cyphermox> shim / fwupdate:
[15:21] <cyphermox>  - some discussion about signtool.exe being broken (would break new shim signatures from MS)
[15:21] <cyphermox>  - coordinating fwupdate updates to Yakkety and Xenial.
[15:21] <cyphermox> (done)
[15:21] <cyphermox> that's it for the lightning rounds subtopic I forgot to start.
[15:21] <cyphermox> #subtopic AOB
[15:21] <cyphermox> err
[15:22] <cyphermox> any AOB anyway?
[15:22] <rbalint> sorry, what is AOB?
[15:22] <cyphermox> [TOPIC] AOB
[15:22] <cyphermox> any other business?
[15:23] <cyphermox> other random stuff we need to talk about
[15:23] <rbalint> oh, I would like to ask how we should coordinate visiting all the packages with delta
[15:23] <rbalint> i would happily go through each of them
[15:23] <cyphermox> what do you mean by how to coordinate?
[15:24] <rbalint> should I ping the last uploader before i check each package?
[15:24] <bdmurray> rbalint: There's an easy u-r-u bug if you want to have a look.
[15:24] <rbalint> bdmurray: ok, i'll check that too, but looking forward
[15:25] <cyphermox> my understanding was that one should ping the last uploader listed on merges.u.c and make sure before claiming a merge
[15:26] <nacc> [lurking, not on foundations, but what cyphermox said was what i was told as well]
[15:26] <cyphermox> partly because some may *look* easy, but aren't, and missing some bit in a merge because it looks like it's not needed can break things.
[15:28] <rbalint> ok, then probably i'll ping owners of a block of 20 packages then i'll process them next day as i get green light
[15:28] <rbalint> if that's ok
[15:29] <bdmurray> Can I stop reviewing Precise SRUs?
[15:29] <xnox> no
[15:29] <xnox> lol =)
[15:29] <cyphermox> rbalint: I think I can already give you green light for any d-i package I was the last to touch; but don't hesitate to ask questions if something isn't obvious
[15:29] <cyphermox> anything else?
[15:30] <rbalint> cyphermox: thanks
[15:30] <bdmurray> cyphermox: Is that X to Y upgrade verified?
[15:30] <cyphermox> bdmurray: yes.
[15:31] <cyphermox> I'll go update the bug
[15:31] <cyphermox> that's all for the meeting I guess
[15:31] <cyphermox> #endmeeting
[15:31] <meetingology> Meeting ended Thu Apr 27 15:31:19 2017 UTC.
[15:31] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-04-27-15.13.moin.txt
[15:32] <sil2100> o/
[15:32] <sil2100> Thanks cyphermox !
[15:32] <infinity> rbalint: Some of these deltas forwarded to Debian don't make much sense.
[15:32] <rbalint> infinity: which one?
[15:33] <infinity> rbalint: Well, cdrom-detect is the first one I looked at, and you're forwarding deltas that change Debian to Ubuntu. :P
[15:33] <cyphermox> infinity: I looked too, but it's confusing, it's a patch of a patch.
[15:33] <rbalint> infinity: it is applied conditionally
[15:34] <nacc> rbalint: also, i assume you'd check any notes at https://merges.ubuntu.com/main.html or otherwise
[15:34] <infinity> rbalint: It... Is?
[15:34] <rbalint> nacc: sure
[15:35] <cyphermox> +ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes))
[15:35] <cyphermox> +	patch -p1 < $(CURDIR)/debian/patches/ubuntu-installer.patch
[15:35] <cyphermox> +endif
[15:35] <infinity> Oh, gross.
[15:35] <cyphermox> there is that
[15:35] <cyphermox> I wonder if it's not better to just keep delta for that.
[15:35] <infinity> rbalint: I'd really rather keep deltas than introduce patch systems for native packages. :P
[15:36] <infinity> rbalint: And deltas like this are ones we need to touch regularly anyway, there's no value in pushing them back to Debian.
[15:36] <rbalint> cyphermox: i think accepting syncs is way easier than merging
[15:37] <cyphermox> rbalint: it's not "really" going to be easier for the regular "new release is named XYZ" process
[15:37] <infinity> Right, for a new release, I'm not going to push to Debian and sync.
[15:37] <infinity> That's a delay I can't be bothered with.
[15:37] <cyphermox> you still need to touch the package, so that you're adding a step
[15:37] <infinity> So we'll get a delta every 6 months on that hunk.
[15:38] <infinity> rbalint: So, perhaps this answers your other question, yes you should ask the "owner" of the delta before forwarding it. :P
[15:39] <rbalint> infinity: ok
[15:40] <infinity> rbalint: In some cases, it really is less hassle to maintain a small delta than to shift to maintaining a dpkg-vendor delta in Debian via bug reports.
[15:40] <infinity> rbalint: In other cases, we intentionally carry a delta to gate flow into Ubuntu (dpkg and debhelper come to mind here, I could reduce both to 0, and I won't)
[15:40] <cyphermox> infinity: not really maintaining via bug reports though
[15:41] <infinity> cyphermox: For d-i, sure, I can commit.  That's not true of everything.
[15:41] <cyphermox> I think we (you, me, maybe rbalit too)
[15:41] <cyphermox> yeah, for d-i
[15:41] <infinity> cyphermox: I can upload everything because DD, but Debian doesn't have the same weak maintainership policy and people aren't generally happy with you uploading their stuff. :P
[15:41] <cyphermox> definitely not true for everything, but it's not as much as issue for non d-i.
[15:41] <cyphermox> no, I know that
[15:42] <cyphermox> I meant specifically for d-i where we can already commit to the tree; and it's more likely to get such branding issues
[15:42] <cyphermox> I don't expect to see much branding or "totally not applicable to debian" changes in say, miniupnpc, to pick something randomly.
[15:43] <rbalint> infinity: not pushing changing Ubuntu codenames makes sense
[15:44] <rbalint> infinity: i think if Debian's maintainter accepts the vendor-based changes they can be offered
[15:44] <cyphermox> rbalint: it's also about using a custom patch system on a native package... which *is* quite yucky
[15:44] <rbalint> rbalint: i gladly merged raspbian changes
[15:44] <infinity> Very.
[15:45] <infinity> I think adding a patch system to d-i packages is a non-starter for me.
[15:45] <cyphermox> perhaps for branding (not release names), it could be argued that proper application of db_subst in the templates could do a better job.
[15:45] <rbalint> infinity: ok
[15:46] <rbalint> .in file processing would be a no-go, too?
[15:46] <infinity> It's a lot of added complexity to a package you're not maintaining. :P
[15:46] <infinity> rbalint: I understand that you find it's less hassle for you to sync instead of merge, but if no one's asking you to do either of those things...
[15:59] <rbalint> ok, won't push for pushing


[11:40] <lotuspsychje> xs: did your issue from yesterday got resolved?
[12:38] <mybalzitch> why do I need 10 digits past the decimal for my load avg
[17:40] <kinghat> in my logs for systemd-networkd-wait-online.service im getting: Failed to start Wait for Network to be Configured.
[17:42] <kinghat> on startup:  https://irc.kinghat.xyz/uploads/dc8995a7fd63ddee/Screenshot_20220911_123103.png
[17:45] <kinghat> this is the netplan config: https://paste.debian.net/hidden/bb7f1498/
[17:47] <kinghat> the interfaces are not static but i have my router assigning an ip to them. i think via their mac addys.
[17:50] <kinghat> i believe the second interface is the ipmi. some suggest setting the interfaces to optional: true. i have no idea if thats correct with my setup though.
[17:50] <kinghat> or if that will allow the service to start properly.
[17:57] <kinghat> even if i try to start the server after the server as booted, it wont stay on: https://irc.kinghat.xyz/uploads/a65e42673034bb57/image.png
[18:33] <kinghat> actually, just setting: renderer: NetworkManager and removing the optional property fixes the service and the cockpit updates issue.


[08:48] <xnox> I would like to contribute to UTAH, I want to work on installation/reboot testing with unusual filesystem's setup. How do I get started? Where are the current installation tests?
[09:56] <gema> xnox: we are in the process of migrating them, but we haven't really started yet.
[09:57] <xnox> gema: ok. so where are the current ones? are they for jenkins?
[09:57] <xnox> gema: or should I just fiddle/start with UTAH?
[09:57] <xnox> are there any good existing UTAH examples?
[09:57] <gema> xnox: the current ones are here http://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/files
[09:58] <gema> xnox: but if I were you I'd start with utah directly, nuclearbob is finishing off the part where you can preseed installation and we are adding automated testing for utah for that to jenkins this week
[09:58] <gema> xnox: so early next week we should be in a good position to start adding that kind of tests
[09:59] <xnox> sounds good to me =)
[09:59] <gema> xnox: you are welcome to work with us on the moving current tests to utah
[09:59] <xnox> we'll see =) if the work overlaps with my goals then sure ;)
[09:59] <gema> xnox: cool, let us know your goals so that we can figure that out
[10:00] <gema> our goals are to have existing smoke testing working with utah
[10:00] <xnox> my goals is to add more smoke tests for raid, lvm, btrfs
[10:01] <xnox> across all affected images
[10:01]  * xnox grammar fail "my goals are"
[10:01] <gema> xnox: ok, so whenever we get to migrate those cases, I will ping you
[10:01] <xnox> =)))))
[10:01] <gema> we should have a clearer view on how to do it properly by then
[10:02] <gema> expect a ping either during this week or early next ;)
[10:02] <gema> xnox: we don't have the capacity to train everyone individually, so we are going to be working with you guys to get all the testing off the ground as we go
[10:04] <xnox> I was hoping I will be able to learn by myself from the migrated scripts and make changes/additions & merge proposals for additional tests
[10:57] <gema> xnox: then you'll have to wait two/three weeks
[19:10] <balloons> phillw, you about?
[19:10] <phillw> balloons: yup :)
[19:11] <balloons> did you notice something about http://iso.qa.ubuntu.com/?
[19:12] <phillw> I'm on http://iso.qa.ubuntu.com/qatracker/milestones/219/builds and have not noticed anything?
[19:12] <balloons> http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/17439/testcases/4/results
[19:12] <balloons> look a bit different? :-) Anyways, the new build has landed.
[19:13] <balloons> I was hoping it would land today, and boom.. it's live
[19:13] <stgraber> balloons: told you they wouldn't notice ;)
[19:13] <balloons> stgraber, it's a good thing in many ways!
[19:13] <balloons> so what that means now is we've got to get the help pages revamped for user facing help, and convert the testcases out of the wiki and into the tracker
[19:14] <balloons> which is awesome.. I'm super excitied
[19:14] <balloons>  and while "converting" we get to verify the testcases, and enhance their presentation by putting them all into the templated format, and have them be easy to use
[19:18] <phillw> looks good,  few typos to correct :)
[19:19] <phillw> +a
[19:20] <balloons> Have a look at this: http://packages.qa.dev.stgraber.org/qatracker/milestones/223/builds/16266/testcases/1300/results
[19:20] <balloons> notice we can do things in the "Link to the installation instructions", and "Link to bug reporting instructions"
[19:21] <balloons> also, the testcase is in our templated form, and has a bolierplate on the bottom for quicklinks to record what happened


[05:34] <mborzecki> morning
[06:13] <mborzecki> https://github.com/snapcore/snapd/pull/6992 needs a 2nd review and can land
[06:54] <zyga> good morning
[06:54] <zyga> coffee and work
[07:01] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/6992 just needs a 2nd review and we can land it
[07:01] <mborzecki> should be easy, just some test cleanup
[07:04] <pstolowski> morning
[07:10] <mborzecki> pstolowski: hey
[07:10] <pstolowski> +1
[07:15] <mborzecki> yay
[07:27] <zyga> mborzecki: looking
[07:27] <zyga> hey pawel :)
[07:27] <zyga> 9:30
[07:27] <zyga> better than yesterday
[07:27] <zyga> 26C and looking great
[07:29] <mborzecki> zyga: nice
[07:30] <mborzecki> zyga: sorry to keep poking you :) https://github.com/snapcore/snapd/pull/6922
[07:30] <zyga> doing now
[07:32] <mborzecki> anyone managed to order pi4 4GB variant?
[07:38] <zyga> mborzecki: I was considering
[07:38] <zyga> but
[07:38] <zyga> mborzecki: here I can get the es keyboard layout (I wanted the desktop kit)
[07:39] <zyga> mborzecki: in poland I can get the .pl keyboard layout
[07:39] <zyga> mborzecki: in both cases I'd have to wait up to a month
[07:39] <zyga> mborzecki: apart from micro-hdmi (WHY!?!) it is ok
[07:39] <zyga> mborzecki: I'd prefer to have 3 usb-c instead
[07:39] <zyga> nobody loves micro hdmi cables
[07:40] <zyga> mborzecki: reviewing, should be done soon
[07:40] <mborzecki> zyga: i checked a couple of places but sold out
[07:40] <zyga> mborzecki: yeah
[07:40] <zyga> they flew from the shelves
[07:40] <zyga> just wait, GBP/PLN is favourable :)
[07:43] <mborzecki> zyga: maybe availability was like amd's vega cards ;)
[07:49] <zyga> mborzecki: at this price point they will fly off any store
[07:50] <zyga> mborzecki: I read a funny tweet yesterday, cannot remember it exactly but it roughly read "how many people will buy it just to put it on the shelf next to older pi's, also unused'
[07:51] <pstolowski> heh, was considering it a few days ago (botland.com.pl). out of stock already
[07:53] <zyga> pstolowski: preorder, they are the only official reseller
[07:53] <zyga> pstolowski: others buy from them
[08:40] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6922#pullrequestreview-255050272
[08:41] <zyga> mborzecki: I'll task switch to work on the feedback from both you and jstrand
[08:41] <zyga> I think this will land today
[08:42] <mborzecki> zyga: ok, great
[08:44] <mborzecki> zyga: i think i'll leave a todo about preserving file permissions, osutil.CopyFile can do that but in a funny way by calling cp, and while it's ok for a scenario when you build an image, it feels fragile when you update :/
[08:44] <zyga> mborzecki: I think it's not needed now but it'd be worth making this explicit (as in, this is not supported and is documented as such)
[08:45] <mborzecki> zyga: mhm, sounds fair
[08:47] <zyga> mborzecki, pstolowski: desktop set or just bare pi4? (hard questions)
[08:49] <mborzecki> zyga: i'll try getting the regular one, the keyboard/mouse look like toys tbh
[08:50] <zyga> yeah but OMG shiny :)
[08:50] <pstolowski> zyga: bare
[08:50] <mborzecki> zyga: and the desktop set is what $100+? :P
[08:51] <zyga> it's not much, case + psu
[08:51] <zyga> + cables you'd otherwise how to source separately (2$ a piece)
[08:51] <zyga> + keyboard / mouse (with only one usb port)
[09:05] <Chipaca> xnox: 00-ꜱɴᴀᴘᴅ-ᴄᴏɴꜰɪɢ.ʏᴀᴍʟ
[09:11] <valentind> zyga, It is not straight forward to bind mount /usr from the snap application. Snapd bind mounts several things within /usr, but it does it before the layout binding. So those paths disappear. I would need to make a script to generate all the paths to mount in order not to mount over those paths.
[09:11] <zyga> valentind: yeah, mounting all of usr is tricky :/
[09:11] <zyga> valentind: can you help me understand why you'd need that?
[09:12] <zyga> valentind: I assumed that the freedesktop runtime would be much like flatpak runtime model
[09:12] <zyga> valentind: with / being a full read only image (mostly)
[09:12] <zyga> valentind: and /app being the application image
[09:12] <zyga> valentind: with extra places for writable data
[09:12] <valentind> Yes.
[09:12] <zyga> valentind: in this model, can you not keep the runtime as the base snap, with /usr and all the other suspects as-is
[09:12] <valentind> Well, if we cannot run commands from /usr/bin it is annoying.
[09:13] <zyga> valentind: perhaps that's what we should fix, we could change snapd to generate different apparmor template for if the base snap is the freedesktop runtime
[09:13] <valentind> I could also just mount /usr/bin from the app with the files copied from the runtime.
[09:13] <valentind> zyga, Yes, this is what I would like.
[09:13] <valentind> But I do not know how much time it would take to get there.
[09:14] <zyga> valentind: perhaps not that much, can you tell me if what you are missing is simply
[09:14] <zyga> (in apparmor terms)
[09:14] <valentind> I do not mind providing a apparmor template for freedesktop sdk, this is fine.
[09:14] <zyga>  /usr/bin/** ixr,
[09:14] <zyga> perhaps coupled with something similar for /usr/lib
[09:15] <valentind> This would be enough I think.
[09:15] <zyga> I think we can do that then, is there a thread I can reference in the pull request?
[09:15] <valentind> I think we need run only for ld.so, and it is already there.
[09:15] <zyga> valentind: can you make that modification locally?
[09:15] <valentind> Libraries do not need execution otherwise. Just that the dynamic loader can be executed.
[09:15] <valentind> Sure, I can do that.
[09:16] <zyga> valentind: you can install a snap, edit /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.$APP_NAME, reload that using apparmor_parser -r /path/to/profile and see if that fixes it
[09:16] <zyga> valentind: once you have the set of changes I can make a quick PR
[09:16] <zyga> thank you!
[09:18] <valentind> Ah libexec as well
[09:18] <zyga> I'm sure there's a small list you can find by iterating
[09:18] <xnox> Chipaca:  ship it!
[09:18] <xnox> Chipaca:  i should totally do that somewhere sometime, as the defualt filename.
[09:20] <valentind> zyga, yes that works. I will check a bit more to see what makes sense to add.
[09:20] <zyga> thanks!
[09:20] <Chipaca> xnox: that's the output of 'unifonter -k k 00-snapd-config.yaml' fwiw
[09:25] <zyga> brb, short walk to the library
[09:25] <zyga> (free wifi, ac and super quiet)
[09:42] <zyga> re
[09:42] <zyga> I forgot how nice this place was
[09:43] <valentind> zyga, I have found few other places than /usr/bin/ and /usr/libexec/ where there are binaries. But I think I will change freedesktop sdk to move them to libexec. Not sure why they are there.
[09:52] <zyga> valentind: what kind of executables were those?
[09:52] <valentind> It is in the library directory.
[09:52] <valentind> They look like libexec things.
[09:57] <zyga> valentind: in /usr/lib?
[09:57] <zyga> valentind: I think it's okay to add to the template instead of changing the base snap too much
[09:57] <valentind> OK, then.
[09:59] <valentind> So yes, {,/usr}/bin/* {,/usr}/libexec/** and {,/usr}/lib/**. Should I make a mr? Or will you take care of that?
[10:04] <zyga> valentind: I can do that
[10:04] <zyga> valentind: I have some ideas where that should be
[10:04] <valentind> OK Great.
[10:31] <Chipaca> could I have a second review of a very very simple but important pr, #7040 ?
[10:31] <Chipaca> https://github.com/snapcore/snapd/pull/7040/files
[10:39] <mborzecki> Chipaca: do you know if we're doing another . release?
[10:45] <zyga> mborzecki: can you do another pass over infofile subset of https://github.com/snapcore/snapd/pull/7026/files
[10:45] <zyga> mborzecki: I will address the remaining comments now
[10:47] <mborzecki> zyga: sure
[10:50] <zyga> I need to take a break, the library is closing soon
[10:50] <zyga> see you soon
[11:06] <wieczorek1990> Can I get any love in the reviews? https://snapcraft.io/gitl
[12:00] <mborzecki> zyga: added some comments about new info scanner
[12:06] <zyga> Thanks
[12:06] <zyga> Resuming work now
[12:09] <wieczorek1990> How often are review-tools updated?
[12:21] <zyga> wieczorek1990: on demand, I think
[12:34] <mborzecki> wieczorek1990: jdstrand likely knows best
[12:37] <zyga> brb for lunch
[12:38] <zyga> wieczorek1990: or roadmr also knows AFAIK
[12:49] <wieczorek1990> mborzecki: jdstrand told me to wait :)
[12:54] <jdstrand> wieczorek1990: the review-tools are updated. roadmr is getting them to production as we speak. it should be soon
[12:54] <wieczorek1990> cool
[13:01] <zyga> mborzecki: trying to join standup
[13:23] <jdstrand> wieczorek1990: it seems likes you may have auto-uploads setup for gitl? if so, you may want to pause them for the next day or so until they start passing automated review
[13:24] <wieczorek1990> just let me find that option :)
[13:25] <wieczorek1990> jdstrand: removed from the build list
[13:25] <jdstrand> wieczorek1990: I'll ping you when the tools are in proc then
[13:26] <wieczorek1990> jdstrand: thanks
[13:51] <dot-tobias> Ping kyrofa / sergiusens: https://forum.snapcraft.io/t/cmake-part-with-build-snaps-gets-mangled-include-parameters/ → any quick hint what's going wrong here?
[13:52] <ogra> dot-tobias, what did you break again ?
[13:52] <ogra> :)
[13:55] <dot-tobias> ogra: Just one of my user-errors again, I hope 😄
[13:55] <dot-tobias> Holding It Wrong™
[13:56] <ogra> must be the heat
[13:56] <dot-tobias> most definitely
[14:37] <jdstrand> wieczorek1990: ah, the update is in prod now and gitl passes automated reviews :) (see r141). all the other revisions are now being scanned and passing (up to r147 now)
[15:01] <zyga> jdstrand: hello, I sent several updates to https://github.com/snapcore/snapd/pull/7026 -- could you do another pass please
[15:01] <zyga> jdstrand: I'm still doing a few changes to the comments as you suggested but the "essence" of the changes are good now IMO
[15:19] <jdstrand> zyga: ok
[15:34]  * zyga moved closer to home
[15:38] <jdstrand> Saviq: is is possible to adjust the mirror when using snapcraft with multipass? (maybe that is a question for sergiusens... hi to both of you!)
[15:38] <jdstrand> I'd like to use something other than archive.ubuntu.com
[15:39] <Saviq> jdstrand: not easily with snapcraft, no - it doesn't give you a way to modify the cloud-init
[15:39] <Saviq> today, only option would be to `snapcraft pull` a part, then get into the instance and switch the mirror
[15:40] <Saviq> long-term, we're working on configurable cloud-init defaults in Multipass, which could help with this (although snapcraft provides a cloud-init, I wonder if we should mess with it…)
[15:40] <Saviq> jdstrand: one way or another, yes I'd say it's a sergiusens question :)
[15:41] <Saviq> b/c I'd rather see snapcraft allowing you to specify a mirror rather than you hacking the instances under its feet :)
[15:41] <Saviq> there's also an option of a snapcraft plugin…
[15:42] <Saviq> but you'd need to modify each snapcraft.yaml to make it use the plugni
[15:42] <Saviq> so yeah, I really think this kind of thing would be a snapcraft one :)
[15:45] <ogra> jdstrand, you can easily do that by adding an extra part to your snapcraft.yaml that calls add-apt-repository ... i.e. pilibs here adds a PPA (but any proper deb archive should actually work here), pistream (the part afterwards) then uses a package from there (libraspberrypi-bin) https://github.com/ogra1/picamera-streaming-demo/blob/master/snap/snapcraft.yaml#L37
[15:46] <ogra> that way should work in any build env (multipass, launchpad buildd etc)
[15:48] <ackk> hi, is it possible for a snap to know if it's installed with --devmode?
[15:51] <Chipaca> ackk: what for?
[15:51] <ackk> Chipaca, basically conditional logic in hooks as you can do stuff like chown if in devmode
[15:52] <ogra> given that devmode isnt something you should/would use permanently you should really not do any permanent hacks in your hooks for it
[15:54] <Chipaca> ackk: if you really really need to do this, try snap list $SNAP_INSTANCE_NAME
[15:54] <Chipaca> ackk: if you can do that, you're in devmode*
[15:54] <Chipaca> * or you have snapd-control
[15:55] <ackk> Chipaca, ah, interesting trick :)
[15:55] <ackk> Chipaca, thanks
[15:56] <Chipaca> actually it works also if you have snapd-control :)
[15:56] <Chipaca> because you can't run snap :)
[15:56] <ackk> heh, cool
[16:42]  * zyga -> nap
[16:42] <zyga> zzzz
[17:04] <wieczorek1990> https://www.irccloud.com/pastebin/3kyusPpM/
[17:04] <wieczorek1990> So, I've been trying to enable aliases in gitl run using snap, and I'm kind of blocked. Getting this error:
[17:04] <wieczorek1990> error: could not lock file /home/luke/.gitconfig: Permission denied
[17:04] <wieczorek1990> Thought there won't be errors after adding the personal-files interface
[17:04] <wieczorek1990> Here's my snapcraft.yaml: https://github.com/wieczorek1990/gitl/blob/master/snap/snapcraft.yaml
[17:04] <wieczorek1990> Here's the function in git causing problems: https://github.com/git/git/blob/ab15ad1a3b4b04a29415aef8c9afa2f64fc194a2/lockfile.c#L73
[17:04] <wieczorek1990> Any hints?
[17:07] <wieczorek1990> Other thing is that normal aliases don't work, they exit with a message like this:
[17:07] <wieczorek1990> expansion of alias 's' failed: 'status' is not a git command
[17:07] <wieczorek1990> but they work if written as "s = !git status", strange
[17:08] <ogra> did you actually connect the interface ? it surely doesnt automatically connect
[17:09] <wieczorek1990> it's there when I run `snap connections gitl`
[17:10] <ogra> and connected ?
[17:10] <ogra> (did you explicitly run snap connect for it after install)
[17:10] <wieczorek1990> No, I ran install from the store
[17:11] <ogra> yeah, that wont connec it
[17:11] <ogra> you need to explicitly run snap connect <snapname>:<plug>
[17:11] <ogra> (i never used personal-files so i dont know where to you need to connect)
[17:14] <wieczorek1990> connecting did not change a thing
[17:24] <wieczorek1990> Did not expect so much work for deploying app with snap :)
[17:29] <ogra> well, the good thing about snap packaging is that once you figured it out you usually do not need to touch it again
[17:53] <zyga> store is somewhat red
[17:54] <zyga> https://www.irccloud.com/pastebin/YI8ilsRW/
[17:54] <zyga> noise][: ^ https://status.snapcraft.io/ is green, should I see anything ?
[17:56] <noise][> nothing alerting but let me take a look
[17:59] <zyga> it's not all the stuff I do but I've restarted tests over small one-off failures a few times
[18:01] <Paddy_NI> Will the "Gnome Software" ever be gaining support for displaying markdown read from a snap apps description properly?
[18:01] <noise][> zyga: we are seeing some elevated err rates, coinciding with a deploy, investigating and will update status page in a minute
[18:02] <Paddy_NI> Ascii cast and video support would also be awesome
[18:02] <zyga> as always, thank you for keeping the store running :)
[18:13] <noise][> zyga: all fixed now, was 1 bad unit in a pool, monitoring caught it but as a low-prio so nobody had looked at it right away
[18:13] <noise][> we will fix that as well :)
[19:04] <zyga> noise][: super, thank you
[20:13] <jdstrand> Saviq: ack, thanks
[20:14] <jdstrand> ogra: thanks. the thing is I want to change the mirror (not a ppa) only for local builds, not LP builds
[20:17] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7026 is green
[20:17] <zyga> I have some more tests piled up but I'll wait for your review first
[20:17] <zyga> jdstrand: the only significant change I'd like to introduce is to allow to define a memory cap so that unbound input cannot happen
[20:25] <jdstrand> zyga: is that in a subsequent PR or this one?
[21:41] <zyga> jdstrand: perhaps subsequent since this is green now
[21:42] <zyga> jdstrand: or either if you'd like to see that earlier
[21:42] <zyga> jdstrand: I'm mainly trying to be practical and land it soon
[21:43] <jdstrand> zyga: I'd prefer to review 7026 if you're done with it. I think that improvement could come in a subsequent PR (we do control the file after all, so I consider this landable without it (sans my 2nd review))
[21:43] <zyga> jdstrand: +1
[21:43] <zyga> jdstrand: I'm happy with that
[21:44] <jdstrand> zyga: put another way, I didn't want to review it and then have you add more :)
[21:44] <zyga> sure
[21:44] <jdstrand> if we could avoid it (can't always)
[21:44] <jdstrand> ok, so I'll take a look at it after a couple things. might be tomorrow morning
[21:45] <zyga> thank you, I'm heading to bed anywa
[21:45] <zyga> I'll work with maciej to get it re-reviewed
[21:45] <zyga> hopefully it could land tomorrow
[21:45] <jdstrand> zyga: good night! :)
[21:45] <zyga> good night :)


[14:28] <teward> did anyone get an "Encryption Test" email from Alberto yesterday other than me...? o.O
[14:28] <teward> hate to ask but it's a valid question :/