[00:58]  * mamarley mutters about people asking questions and then running off before anyone has a chance to answer…
[08:07] <ricotz> tjaalton, huh? http://www.omgubuntu.co.uk/2017/02/install-mesa-13-0-4-on-ubuntu-ppa
[08:29] <tjaalton> ricotz: huh what? it's there as you know :)
[08:29] <ricotz> tjaalton, I had the impression this is the staging part before moving it to gpu ppa
[08:30] <tjaalton> ricotz: it can still be
[08:30] <ricotz> if so then promoting it that way is misleading
[08:32] <tjaalton> I didn't write that article, only the blog post
[08:32] <tjaalton> which has had a whopping 30 hits
[08:33] <ricotz> I know, I was indirectly referring to it, but obviously it is looked at and has impact
[08:41] <tjaalton> i'm sure he'll write another one when the move happens
[09:25] <tjaalton> so I'm looking at nvidia changes to support libglvnd
[09:26] <tjaalton> why does it install stuff in /usr/lib32?
[09:32] <tjaalton> is the git repo used?
[09:32] <tjaalton> last commit is from 4y ago
[09:41] <tjaalton> HEAD points to master, which is obsolete
[10:21] <tjaalton> tseliot: hi, I'm checking nvidia for changes needed to support libglvnd
[10:21] <tjaalton> should be pretty simple
[10:26] <tjaalton> can drop lib{GL,GLES*,EGL}.so.* and just ship the _nvidia.so's
[10:29] <tseliot> tjaalton: I need to check that how things would work with hybrid graphics, and then I would have to update gpu-manager accordinglu
[10:29] <tseliot> *accordingly
[10:30] <tjaalton> sure
[10:30] <tjaalton> I also noticed that at least preinst scripts have a lot of old cruft in them
[10:31] <tjaalton> also, why doesn't it use multiarch directories but /usr/lib32?
[10:44] <tseliot> I think there was a reason for that but I can't remember
[11:19] <tjaalton> heh


[10:55] <nikolam> Could someone comment on this bug? Seems that 2.6.24-21 on amd64 has a problem
[10:55] <nikolam> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/287416
[13:22] <amitk> rtg: I already suggested splitting lbm into smaller parts but it is too late now. But IMO, we should do it for Jaunty
[13:25] <rtg> amitk: LBM isn't subject to SRU policies, so it may not be too late. There might be some package naming policies that get abused, but thats more a matter of getting exceptions granted.
[13:26] <amitk> rtg: cjwatson's words, not mine. Let me get him
[13:27] <rtg> amitk: there is no hurry. its not something I'm gonna do today.
[13:28] <amitk> rtg: lbm is in main and I was assured that that made things complicated
[13:28] <rtg> it probably does.
[13:29] <rtg> however, kernel packages are already special  since they get new package names with every ABI.
[13:30] <cjwatson> amitk: so what's this about splitting up lbm?
[13:31] <rtg> cjwatson: I suggested splitting out compat-wireless as a way to mitigate regressions from other drivers.
[13:32] <cjwatson> I'm really concerned about messing around with packaging at this point
[13:32] <amitk> rtg: I was suggesting even finer grained, separate out ath5k from the rest
[13:32] <cjwatson> I'd rather not
[13:32] <rtg> nor would I
[13:32] <rtg> besides, right now compat-wireless is the only thing in LBM
[13:33] <cjwatson> right, and people will probably only have one of those chipsets
[13:33] <amitk> cjwatson: given that ath5k users are going to _depend_ on lbm, how else do we ensure that we don't regress lbm during the next 18 months.
[13:34] <rtg> well, LBM has been going through the -proposed cycle, just like other kernel packages.
[13:35] <cjwatson> it's going to suck somewhat for atheros users no matter what we do. A week ago I would have agreed with you, but now? I can't say I'm so sure
[13:37] <amitk> rtg: it is a question of QAing all of compat-wireless vs. just ath5k in -proposed
[13:38] <rtg> amitk: but ath5k doesn't exist in a vacuum. its intimately intertwined with the rest of the wireless stack.
[13:39] <amitk> rest of the stack, yes. Rest of the drivers, no.
[13:39] <rtg> amitk: as cjwatson pointed out, you don't have to worry about the rest of the drivers 'cause they won't get loaded anyway..
[13:41] <amitk> rtg: so just remove in-kernel ath5k and do a best-effort on LBM?
[13:41] <rtg> amitk: thats pretty much my plan.
[13:42] <rtg> we are somewhat subject to upstream progress.
[13:42] <cjwatson> if you guys really think that splitting out a compat-wireless package from lbm is the only sane answer, then I'm willing to defer; you'll need to be really careful about the package structure, though, and it'll need a linux-meta update
[13:43] <amitk> rtg: do you forsee alsa or something else coming back into lbm?
[13:43] <rtg> cjwatson: I'm open to suggestions. Also, I don't think we need to do this before release. The current LBM is as good as it gets for awhile.
[13:43] <rtg> I don't see the need for ALSA at this point
[13:43] <cjwatson> rtg: we're going to have to document what people need to do at release time, and at the moment that's going to involve them installing LBM
[13:44] <cjwatson> rtg: so this is hard to change later - people will have LBM installed already and will upgrade it all at once
[13:44] <cjwatson> I mean, obviously in general I'm in favour of fewer things having to be changed before release now :)
[13:45] <amitk> rtg: besides users for whom in-kernel ath5k works now will complain much louder later
[13:46] <cjwatson> certainly if we're going to disable in-kernel ath5k then I think that needs to be done pre-release; it'll be almost impossible to QA after release
[13:46] <rtg> one of the drivering forces for LBM in the past has been because there was no other mechanism to get new HW support. now we have an alternative (ubuntu-next), so those folks that just gotta have support can always use that. Ubuntu-next kind of relieves to need to add a bunch of stuff to LBM.
[13:47] <rtg> I plan to upload a kernel today without ath5k support, if everyone is agreed.
[13:47] <cjwatson> ack
[13:47] <pgraner> rtg: the only that that should be in that kernel is the lack of 5k support
[13:48] <rtg> pgraner: can't parse your sentence. the only change?
[13:49] <pgraner> rtg: no other changes are allowed at this point, we have approval for just the disabling of ath5k...
[13:49] <rtg> pgraner: right. what'ya think I am? some profligate coder?
[13:50] <pgraner> rtg: just checking in the past we have had other things "slip" in due to them being committed in the tree.
[13:51] <rtg> amitk: so the mid-team plan is to go with LBM, so my job is to try not to break it with future updates, nor to add any devices that moight hose you up. correct?
[13:51] <rtg> pgraner: I'll make sure that doesn't happen this time.
[13:51]  * cjwatson appreciates it :)
[13:52] <pgraner> rtg: thanks! love ya... mean it!
[13:52] <rtg> eew!
[13:52] <cjwatson> NURSE! BRAIN FLOSS
[13:52] <amitk> rtg: yes. But rest of the distro will also depend on lbm now. They might get to you before I do if you break lbm :-p
[13:53] <rtg> amitk: I'll just point them at ubuntu-next. its my bandaid for all HW enablement.
[13:56] <cjwatson> so bug 267295 and bug 283316 -> intrepid-updates?
[13:56] <cjwatson> if so, please adjust their milestones
[13:58] <amitk> rtg: please refer to bug 284354 when disabling in-kernel ath5k
[13:59] <amitk> rtg: madwifi + ath5k racing won't disappear with disabling in-kernel and installing lbm though
[13:59] <cjwatson> uh. I thought you said in #ubuntu-release that it would
[14:01] <amitk> cjwatson: on boot ath5k (lbm) will always win. But I am worried about suspend/resume case.
[14:01] <amitk> still thinking about it...
[14:01] <rtg> amitk: but its not a race.
[14:02]  * amitk goes off to do a few tests
[14:02] <amitk> rtg: what is not a race? suspend/resume?
[14:03] <rtg> amitk: the loading sequence. ath5k only gets loaded after madwifi fails.
[14:04] <amitk> rtg: so madwifi fails gracefully is what you're saying?
[14:05] <rtg> amitk: I guess you could say that. It can't support the RF chip, so it bails out with an error.
[14:14] <rtg> amitk: I have ogra checking to make sure madwifi isn't loading when LBM is installed.
[14:14] <rtg> I remembered a bug that smb found in modprobe when 2 modules of different names claim the same PCI ID.
[14:15]  * amitk nods
[14:16] <asac> rtg: ath9k issue with eventual patch: #278190
[14:16] <smb_tp> rtg, As long as the driver bails out with an error this might be ok (if the hw isn't left in a strange state)
[14:17] <smb_tp> rtg, But err, yeah they claim the same id
[14:18] <smb_tp> rtg, So it is as long as depmod is not changed. Have you heard something from John Masters?
[14:19] <rtg> asac: this is a patch against the LBM stuff, right?
[14:19] <amitk> rtg: in-kernel module has precedence over lrm?
[14:19] <smb_tp> amitk, not ncessarily
[14:19] <rtg> amitk: no. its LBM, LRM, then kernel.
[14:20] <smb_tp> amitk, with same drivers (names) its defined in the search order of depmod.conf but for different names its random by dir creation order
[14:23]  * amitk swears at a ath5k oops
[14:28] <asac> rtg: not sure. i have no big picture about which version are where. a user just pointed me to that patch ... and since i saw that its Linville i thought it might be good crack ;)
[14:29] <rtg> asac: its definitely good crack. I'll pick it up the next time I update LBM with a new compat-wireless tree.
[14:30] <rtg> I think I'll wait until after release before I go rocking the boat. amitk will have me by the throat if I break his samsung device :)
[14:30] <asac> rtg: isnt Q1 5k and this is about 9k?
[14:31] <rtg> asac: it sure is :) I'm in an ath5k rut.
[14:32] <asac> rtg: yeah. so, taking one step back from 5k, do you think that patch would be applicable for our 9k mainline driver?
[14:32] <asac> :)
[14:32] <amitk> rtg: just got an oops from ath5k on q1. Trying to get it out to a bug
[14:32] <asac> or lbm there too?
[14:33] <rtg> asac: probably, but its gonna be an SRU.
[14:33] <asac> rtg: sure. didnt ment to have that in final ;)
[14:34] <asac> rtg: its assigned to you ... do youwant me to do anything else? e.g. like adding intrepid?
[14:34] <rtg> asac: yep - add the Intrepid so it doesn;t get lost.
[14:34] <asac> (sorry to ask now, but otherwise it will just drop from my radar and i wont be able to help remind you :))
[14:34] <asac> ok done ;)
[14:34] <asac> have fun with 5k then
[14:42] <Kano> hi, did you see the security update <IP_ADDRESS>?
[14:44] <rtg> ugh, say it ain't so.
[14:47] <lool> Hey folks
[14:47] <NCommander> o_o;
[14:47] <NCommander> oh
[14:47] <NCommander> *ow
[14:47] <lool> amitk, rtg: I'd love to fix status/description of the ath5k / Q1U / madwifi / mobile bugs
[14:48] <lool> First, wifi currently works with madwifi on the Q1U, even if you don't change anything
[14:48] <lool> At least with WPA
[14:48] <amitk> lool: doesn't for me with WPA2
[14:48] <lool> amitk reported that it doesn't work with WPA2, but it's better than using lbm (which is not possible to sustain)
[14:49] <lool> We will document ath5k in lbm as an alternative which is easy to install, but we can't install it by default
[14:49] <ogra> lool, WEP as well
[14:49] <lool> So WPA2 is broken with madwifi on Q1U; do we need to file / track this?  I'm happy to have a bug for it, but we wont do anything about it in intrepid, we will use a newer ath5k which works in all cases in jaunty
[14:49] <lool> ogra: WEP broken?
[14:50] <ogra> working
[14:50] <lool> Ok
[14:50] <lool> Another thing which is broken with madwifi is suspend resumle
[14:50] <ogra> only if ath5k is present
[14:50] <amitk> lool: madwifi future is a don't care. So no point in tracking WPA2 with a bug
[14:50] <lool> There is no race with ath5k whatsoever; the module just plain don't like suspend/resume, even when ath5k isn't around
[14:50] <ogra> works fine if you blacklist
[14:50] <lool> amitk: Exactly, I think the same
[14:50] <lool> ogra: suspend/resume works for you?  Not for me
[14:51] <ogra> hmm, let me test again
[14:51] <lool> I remove ath5k from module path
[14:51]  * ogra blacklists ath5k
[14:51] <lool> rebooted after update-initramfs -u, and wifi would break over suspend/resume
[14:51] <lool> removing and reinserting the ath_* madwifi modules, and it would work again
[14:51] <lool> So on this second madwifi issue, is it worth filing a bug?  Yes I think so
[14:52] <lool> We can help suspend/resume with madwifi for intrepid; it's old style remove the module before suspend, but will work
[14:52] <lool> Do we care for jaunty?  No
[14:52] <lool> Is this critical?  No
[14:53] <lool> Concerning the two ath5k and madwifi getting loaded; I understand why it happens, I think it's not good that we have to do this, but I don't have any magic wand to help it; it will effectively be fixed when a single driver supports all PCI ids and all their hardware
[14:54] <lool> I don't expect this will be fixed in intrepid, and intend to close the corresponding bug with "wontfix in intrepid and we don't care in jaunty"
[14:55] <lool> Finally, ath5k status in linux/linux-lpia: I didn't see ath5k working, rtg had issues with it and recommended removing it from linux/linux-lpia: I second that; it's high priority for intrepid, not critical I'd say but best to avoid half working wifi IMO; no idea how many affected people with working ath5k or half working
[14:55] <lool> We should recommend lbm or let these people try madwifi IMO
[14:55] <lool> Do I miss any issue?
[14:55] <lool> Oh yes, the madwifi wpasupplicant backend
[14:55] <ogra> lool, confirming, madwifi now asks for the passphrase after resume ... that used to work earlier
[14:56] <rtg> lool: I'm in the process if disabling ath5k in the kernel.
[14:56] <lool> That's completely irrelevant, this backend had issues and wasn't needed with some cards/madwifi versions; it's orthogonal, we can't do anything about it and don't care for either intrepid or jaunty
[14:56] <lool> rtg: Thanks; do you have a bug report for that?
[14:56] <lool> rtg: If not, copy pasting your test results which you mailed to devel would be fine as a reference point
[14:56] <rtg> lool: 284354
[14:56] <lool> rtg: or just link the thread in the kernel changelog
[14:57] <lool> rtg: 284354 is about two drivers for same PCI id getting loaded
[14:57] <lool> It kind of became "Wifi debate on Q1U/mobile/ath5k/madwifi" though   :-/
[14:57] <rtg> lool: the issues are kind of related, but I'll make it clear in the changelog.
[14:58] <lool> rtg: Do you mind not using 284354?  I can open you another bug if you like
[14:58] <lool> rtg: Or are you done already with the commits?
[14:59] <rtg> lool: still in progress. just lemme know when you've a new LP number.
[14:59] <lool> (rtg: I intend to wontfix the "two drivers for same PCI id" bug with rationale of my above monologue)
[14:59] <lool> rtg: Will open a new bug for you now
[15:03] <lool> rtg: 288148 assigned to you for the linux task
[15:03] <lool> amitk: Will you do the linux-lpia rebase dance for this bug?
[15:06] <amitk> lool: yes, I will rebase it. We should have it tomorrow.
[15:07] <amitk> I'll wait for rtg to get done with his changes
[15:08] <rtg> amitk: I think I'll test build before uploading. I'd hate to get reamed by Steve.
[15:10] <amitk> rtg: wise course of action
[15:10] <lool> amitk: assigning you to the linux-lpia task then
[15:11] <rtg> amitk: I've pushed everything except the final changelog commit.
[15:13] <lool> rtg: When I said 'this is completely irrelevant' earlier, I was speaking of the wpasupplicant madwifi backend BTW, not of what you said
[15:14] <rtg> lool: I assumed that :)
[15:15] <lool> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275423 sounds like what you reported in terms of wifi speed of ath5k
[15:15] <lool> Too issues in the same bug unfortunately
[15:16] <lool> https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275692 is the suspend/resume bug I mentionned earlier
[15:16] <lool> ogra: "
[15:16] <lool> ogra: "I added a line 'SUSPEND_MODULES="ath_pci"' to /etc/pm/config.d/01-modules and now resuming works.
[15:16] <rtg> lool: almost all ath5k issues are related to ANI failures, suspend/resume notwithstanding.
[15:17] <lool> rtg: This one mentions poor network performance which reminded me of your own testing
[15:17] <ogra> lool, right
[15:17] <ogra> lool, though we wouldnt use /etc/pm/config.d from a package
[15:17] <lool> ogra: I'm sure you're bored with all the sleep you've got; care to prepare an intrepid fix?
[15:17] <lool> Yeah of course
[15:18] <ogra> wher should that sit in ?
[15:18] <ogra> which package ?
[15:18] <lool> ogra: Good question
[15:18] <ogra> effectively it shuld be in lrm :P
[15:18] <lool> I wonder whether it makes sense in lrm
[15:19] <lool> amitk, rtg: opinion?
[15:19] <ogra> but thats something i dont really like to touch as non kernel guy
[15:19] <ogra> i can put it in pm-utils as well, but it would be moot for 90% of users
[15:20] <lool> ogra: Could you test it?  In terms of where to install what file with which contents
[15:20] <lool> No, please not in pm-utils
[15:20] <lool> We're going to forget it in there, and it will make suspend/resume slower for everybody
[15:21] <rtg> lool: I can't figure out what you want an opinion on? adding madwifi to pm-utils for suspend/resume?
[15:21] <lool> rtg: Yeah
[15:21] <lool> rtg: Adding a hint to modprobe -r ath_pci on suspend/resume in lrm
[15:21] <ogra>  /usr/lib/pm-utils/defaults would be one place to put it
[15:23] <lool> ogra: I'd have thought /usr/lib/pm-utils/sleep.d/nnmadwifi
[15:23] <lool> SUSPEND_MODULES="$SUSPEND_MODULES ath_pci"
[15:24] <lool> nn < 50 I'd guess
[15:24] <ogra> yeah
[15:24] <rtg> lool: thats the way I've done it in the past.
[15:24] <ogra> i'D suggest 10
[15:24] <lool> rtg: Someone preparing a lrm upload in the kernel team currently could include this fix?
[15:25] <amitk> lool: wouldn't that start a precendent of different  packages hacking into pm-utils configs
[15:25] <lool> amitk: I think it's the intention of this dir of modules to be extensible in this way
[15:25] <ogra> amitk, thats what the xxxx.d dirs are for
[15:26] <rtg> lool: that makes LRM dependent on pm-utils
[15:26] <Kano> rtg: why dont you blacklist ath_pci for testing?
[15:26] <Kano> my card can connect with both drivers
[15:26] <lool> rtg: Why?
[15:26] <lool> rtg: lrm just provides a pm-utils extension which is picked up if installed
[15:27] <Kano> and the standard madwifi branch is even worse than ath_pci,because only the madwifi-hal branch or ath5k can use ar2007
[15:27] <lool> rtg: Or are you suggesting you can fix this in the kernel module directly?
[15:27] <amitk> lool: ogra: are you guys getting stable wireless connections on the Q1? I am oopsing in 5 minutes today
[15:27] <ogra> i do
[15:27] <lool> amitk: I do, but then I didn't really try high traffic
[15:27] <rtg> lool: no, I was just considering whether LRM needed to be install time dependent on pm-utils.
[15:27] <lool> I did do some ubuntu updates thopugh
[15:28] <lool> rtg: I don't think this is needed, no
[15:28] <rtg> lool: ok
[15:28]  * amitk downloads a new mobile image
[15:28] <Kano> rtg: ar2007 is for example on eee pc
[15:28] <lool> rtg: Ideally, we would fix the relevant layer (kernel module) and have this quirk apply for all possible suspend/resume scenarii, but I'm not competent enough to suggest something lower level than pm-utils
[15:28] <rtg> Kano: I had no luck with sustained transfers using ath5k. I also talked to Luis and he agreed that 2.6.27 ath5k isn't ready for prime time.
[15:29] <lool> pm-utils is what is used on desktops and mobile flavours, it's good enough for us though
[15:29] <Kano> rtg: but standard madwifi is useless for lots of mobile devices
[15:29] <lool> I guess it wont work with echo mem >/sys/power/state though :-/
[15:29] <rtg> Kano: you're right, which is why we're suggesting LBM with the compat-wireless stack.
[15:30] <lool> ogra: If you have your Q1U booted, can you try the proposed SUSPEND_MODULES and confirm file pathname and contents?
[15:31] <lool> ogra: i'm not 100% sure the files are sourced, they might be exec'ed
[15:31] <lool> ogra: In which case, you need to implement it differently
[15:31] <lool> Or in a different place
[15:32] <ogra> doing now
[15:34] <lool> ogra: You might want to test what happens when SUSPEND_MODULES is set in the main config
[15:35] <ogra> lool, i'm pretty sure they need to be executable
[15:35] <ogra> so #!/bin/sh
[15:36] <lool> ogra: Then what I proposed isn't enough
[15:36] <lool> ogra: I'm not sure how do you keep state on whether ath_pci needs to be reloaded or not
[15:36] <ogra> needs an export
[15:36] <ogra> SUSPEND_MODULES is ok, thats the way to do it
[15:38] <jdong> anyone here familiar with how to kick the macbooks into AHCI mode the 'right way'?
[15:39] <jdong> they seem to boot in piix compatibility mode, but if you forcibly talk to it in AHCI it responds
[15:39] <jdong> I'm wondering if there's a more correct way to kick it into AHCI mode, as AFAIK no other Intel AHCI controller behaves in this way
[15:40] <ogra> hmm, the script seems not to work :/
[15:41] <lool> ogra: Make sure your 10something isn't parsed after the system's config where one might have set SUSPEND_MODULES="foo" (overwriting your addition of ath_pci)
[15:41] <mjg59> jdong: There is no right way
[15:41] <mjg59> And several others will behave in the same way
[15:41] <jdong> mjg59: hmm is there any way that we can get macbook users AHCI mode out of the box then?
[15:41] <mjg59> Currently? No.
[15:41] <jdong> mjg59: it seems like SATA link power management shaves off almost a watt on idle
[15:42] <mjg59> Bug Apple
[15:42] <ogra> lool, it gets reloaded if put in the default file but doesnt attempt a connect
[15:42] <mjg59> THeir firmware sets it up to be in piix mode
[15:42] <jdong> understood.
[15:42] <jdong> so there's no way to kick it back to AHCI mode from our side
[15:42] <ogra> lool, oh, sorry, my fault, there was a popunder from a former try
[15:42] <ogra> it was waiting on passphrase confirmation
[15:44] <jdong> mjg59: thanks for your insight :) I guess I'll just continue rolling my own hacked kernels then
[15:45] <ogra> lool, i by looking at pm-functions fear we have to resort to /etc unless we want it in the pm-utils package
[15:46] <Kano> rtg: btw. at least 2/5 pci ids from ath9k are enabled in ath_pci
[15:53] <rtg> Kano: thats right, I seem to remember a couple of AR5007 chips supported by ath9k.
[15:53] <lool> ogra: Uh?
[15:55] <ogra> lool, pm-functions only respects /etc/pm/config.d/ or /usr/lib/pm-utils/defaults for setting global vars
[15:56] <lool> amitk: laptop-mode-tools is an example of extending /usr/lib/pm-utils/sleep.d BTW
[15:56] <ogra> you can use /usr/lib/pm-utils/sleep.d/XXblah but it will be a rather complex script
[15:56] <lool> ogra: My problem is mostly with saving the state of whether ath_pci was already loaded or not
[15:56] <ogra> doesnt matter
[15:57] <lool> ogra: I don't think it needs to be large
[15:57] <lool> ogra: Doesn't matter?
[15:57] <ogra> the new ath5k from lbm will override it anyway
[15:57] <lool> ogra: I don't want ath_pci to be modprobed if people are using ath5k or nothing
[15:57] <ogra> no matter if its loaded or not
[15:57] <lool> ???
[15:57] <ogra> i just tested that before with rtg
[15:58] <ogra> ath5k will claim the device and manage it, no matter if ath_pci is loaded
[15:58] <ogra> with the lbm one
[15:58] <ogra> with the in-kernel one its exactly the other way round
[15:59] <lool> I'm not sure you're looking at the same bug that I am
[15:59] <lool> I'm speaking of people having lrm installed, using madwifi
[15:59] <lool> These wont get wifi on resume
[15:59] <ogra> right
[15:59] <ogra> right
[15:59] <lool> I'm looking at providing a pm-utils file to have the module modprobe -red and modprobed on suspend/resume
[15:59] <ogra> adding ath_pci to SUSPEND_MODULES solves this
[16:00] <ogra> we have two options for that, putting a one liner in /etc/pm/config.d/ or a complex script that executes functions on suspend resume into /usr/lib/pm-utils/sleep.d/XXblah
[16:00] <lool> ogra: Will the module be loaded on resume if it wasn't loaded?
[16:01] <ogra> yes
[16:01] <lool> That's not good
[16:01] <ogra> oh, wait, you mean if it was never loaded ?
[16:01] <ogra> why should it be loaded on resume if the kernel didnt load it on boot
[16:01] <lool> ogra: Actually, it wont be reloaded if you use SUSPEND_RESUME
[16:02] <ogra> SUSPEND_MODULES you mean
[16:02] <lool> _rmmod() touches a file saying whether it was modprobe -red successfully or not
[16:02] <lool> Err SUSPEND_MODULES right
[16:02] <ogra> it gets reloaded here
[16:02] <lool> ogra: Could you offer a /etc/pm/config.d/ file in the bug for the kernel team to add to lrm?
[16:02] <ogra> but why shouldnt it have been loaded by the kernel before, i dont understand
[16:03] <lool> ogra: it gets reloaded when it wasn't loaded?
[16:03] <ogra> do you have an example when exactly " it wasn't loaded" could happen ?
[16:03] <lool> ogra: People with lrm installed but not having madwifi hardware
[16:03] <lool> atheros hw
[16:04] <lool> Or people using lbm's ath5k
[16:04] <ogra> ah, well, modbprobe would surely do the same as on boot
[16:04] <lool> (I know the correct module will be used, but we shouldn't load ath_pci nevertheless)
[16:04] <lool> ogra: It wont
[16:04] <ogra> looking for the pci id and load or not load it depending on the finding
[16:04] <lool> But pm-utils doesn't look at PCI ids...
[16:05] <ogra> pm-utils is dumb
[16:05] <ogra> it calls modprobe
[16:05] <lool> Yes, not on PCI ids
[16:05] <ogra> no, it just calls modprobe
[16:05] <lool> Not only
[16:05] <ogra> if there is no atheros HW modprobe will silently die
[16:05] <lool> It also saves whether a modprobe -r failed or not
[16:06] <lool> if it succeeded, it will reload the module
[16:06] <ogra> right
[16:06] <ogra> still, if there is no atheros HW it wont do any harm
[16:06] <ogra> if lbm is there, ath5k will in any case override madwifi
[16:06]  * lool pfff
[16:07] <ogra> we shipped lrm for years
[16:07] <ogra> madwifi was always included
[16:07] <ogra> why shoulld it suddenly behave harmful if there is no atheros HW
[16:08] <ogra> there are only two intresting scenarios imho
[16:08] <ogra> ath_pci being blacklisted ... lbm being installed
[16:08] <ogra> for the first i added a fix recently to pm-utils to not probe blacklisted modules
[16:09] <ogra> for the second it was confirmed today with rtg that lbm overrides madwifi in any case
[16:09] <ogra> so i dont see any issue here
[16:12] <lool> I should have tested myself, would have been quicker: echo "SUSPEND_MODULES=loop" > /etc/pm/config.d/loop
[16:12] <lool> Suspend+resume, loop isn't loaded
[16:12] <lool> I'll verify it works fine with ath_pci when I'm done reverting to non-lbm
[16:14]  * ogra still doesnt get the issue, modprobe would care
[16:21] <ogra> lool, info added to the bug
[16:22] <ogra> erm ... did i add to the right bug ?
[16:22] <ogra> you closed all tasks
[16:26] <lool> Ok, verified the proposed fix
[16:27] <lool> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275692 I think I mentionned this earlier
[16:28] <ogra> ah
[16:28]  * ogra copy pastes
[16:28] <lool> rtg: So I confirmed the fix; is it you who's preparing the last lrm upload before release?  Could you add a /etc/pm/config.d file as described in this bug and close it?
[16:29] <rtg> lool: ok, on conf call. will deal afterwards
[16:32] <lool> rtg: Thanks
[16:46] <lool> rtg: After discussion with cjwatson, we will defer #275692 to a SRU as there's too much work to do before final already
[16:46] <lool> rtg: Will repoke you about merging it after final :-)
[16:48] <rtg> lool: agreed
[22:48] <elmo> what's responsible for telling iwl3945 that I'm in the UK and want the full spectrum of wireless channels?
[22:49] <elmo> or more relevantly; is it the kernel's problem?
[22:49] <elmo> (it's regressed for me in intrepid)


[00:00] <srandby> What about stickers?
[00:00] <skellat> Don't have a whole lotta those at this point
[00:00] <itsafork> srandby: HOORY STICKERS!!!!
[00:00] <skellat> For release, Beta 1 of Saucy Salamander hits street on September 5th
[00:01] <srandby> I'm willing to buy some
[00:01] <skellat> Okay
[00:01] <skellat> Is anybody averse to carrying this over to the mailing list before anybody begins spending money?
[00:01] <itsafork> canonical usually supplies conference packs
[00:02] <srandby> Mailing list sounds good
[00:02] <Unit193> http://xubuntu.org/news/xubuntu-stickers-now-available/
[00:02] <itsafork> can we try to get one of those skellat???
[00:02] <jenni> [ Xubuntu stickers now available « Xubuntu ] - https://j.mp/152Kpls
[00:02] <skellat> itsafork: Those have gone away, I think.
[00:02] <itsafork> skellat: :(
[00:03] <srandby> I looked at the unixstickers site yesterday.
[00:03] <skellat> itsafork: We're also considered an Unapproved LoCo, even though that distinction isn't supposed to exist anymore according to Jono.
[00:03] <skellat> itsafork: In general Canonical is pulling back on what is provided by them to the LoCo teams.
[00:03] <srandby> The Xubuntu stickers are nice.
[00:04] <srandby> I think they have other _buntu stickers too.
[00:04] <skellat> The new funding offer that is being made requires requests be made by an Ubuntu Member but that doesn't ramp up until the T cycle
[00:05]  * skellat notes that coincidentally it will force us to have to have a LoCo leader who is an Ubuntu Member is funds are ever sought from Canonical for **anything** and we have exactly 5 people who hold that status
[00:06] <skellat> Strike that "is" above and put an "if" in its place and it works
[00:06] <skellat> Okay.
[00:06] <skellat> Any further discussion on this item?
[00:07] <skellat> Okay
[00:08] <skellat> Is there any other business to be transacted at this time?
[00:09]  * skellat waits for the Launchpad query to finish and spit out the right-this-second list of those with "Ubuntu Member" status in Ubuntu Ohio
[00:10] <skellat> While we're waiting for that, would anybody be willing to volunteer to sum up the second & third issues raised tonight and put a call out on the mailing list for further input?
[00:12]  * skellat notes that with the restrictions on the Canonical funding program to where only "Ubuntu Member" persons can make requests the following persons are the only ones in Ubuntu Ohio able to do so according to Launchpad ID: skellat, jpeddicord, digitalvectorz, mrsangeld, jamesgifford, and unit193
[00:12] <srandby> Those were keysigning and stuff to pass out?
[00:12] <skellat> srandby: Yes
[00:12] <srandby> I could do it tomorrow.
[00:13] <skellat> srandby: Okay.  I'll try to get the log posted before bed tonight and a blog post up.
[00:13] <srandby> Blog address?
[00:14] <skellat> srandby: Sadly it is mine: http://erielookingproductions.info/ubuntu/
[00:14] <jenni> [ Trailblazing ] - https://j.mp/152LDwW
[00:14] <skellat> It will show up on Ubuntu Planet, though
[00:14] <skellat> I don't think we ever had ohio.ubuntu-us.org configured for a blog & I'm not ready to start tinkering with the Drupal powering such just yet
[00:15] <skellat> Alrighty.  We stand adjourned such to the call of the Leader provided he gives due notice.
[00:15] <srandby> Bye
[00:16] <skellat> s/We stand adjourned such to the call of the Leader provided he gives due notice./We stand adjourned subject to the call of the Leader provided he gives due notice./
[00:16] <jenni> skellat meant to say: Alrighty.  We stand adjourned subject to the call of the Leader provided he gives due notice.
[00:16] <skellat> yano: Thank you for this kubotu like function in jenni!
[00:16] <yano> ooh
[00:16] <yano> you're welcome
[00:16] <yano> but it doesn't do regexp
[00:32] <itsafork> skellat: give me a week while i iron out what i'll talk on, & i'll let you know what i come up with.
[00:32] <itsafork> Skellat: does that work for you??
[00:41] <skellat> itsafork: Sounds good.
[00:47] <Unit193> yano: My bot does it too, but it's a premade bot, rbot. (AKA, kubotu)
[00:47] <yano> cool
[00:48] <yano> irc bots are fun
[00:48] <Unit193> Less fun when the dang rss feeds mess up and spit out 20 lines or so...
[02:37] <skellat> I *_think_* I've got the LoCo Portal's meeting agenda function sync'ed with the irclogs.u.c logs to create effectively minutes here: http://loco.ubuntu.com/meetings/ubuntu-us-ohio/624/detail/
[02:37] <jenni> [ Ubuntu Ohio July 2013 Meeting | Ubuntu LoCo Team Portal ] - https://j.mp/15IaKGw
[02:37] <skellat> I can't say I'm really thrilled with the way it looks


[07:46] <jibel> good morning
[16:33] <SergioMeneses> hi everybody!
[16:48] <balloons> hey SergioMeneses
[16:50] <SergioMeneses> balloons, hey hey! the software center is almost done, we have to do "Sync Between Computers" section
[16:50] <SergioMeneses> I am trying to figure out how this works
[16:56] <balloons> :-)
[17:02] <SergioMeneses> balloons, do we need a new bug for this features? or what?
[17:14] <balloons> sync between computers? you mean to track that more stuff needs done or?
[17:18] <SergioMeneses> balloons, dont worry :)
[17:18] <SergioMeneses> http://www.howtogeek.com/111989/how-to-sync-quickly-reinstall-applications-on-ubuntu/
[17:19] <SergioMeneses> https://wiki.ubuntu.com/SoftwareCenter
[17:19] <SergioMeneses> it will be done in a moment :D I have to do some tests
[17:21] <SergioMeneses> lunch time here!
[17:24] <balloons> same :-)
[19:24] <SergioMeneses> balloons, around?
[19:24] <balloons> SergioMeneses, indeed :-)
[19:24] <SergioMeneses> balloons, busy? or you have a minute to make a review
[19:31] <balloons> SergioMeneses, yes
[19:31] <balloons> I can revew.. I've got another one to do as well
[19:32] <SergioMeneses> balloons, sorry I was busy but here the last changes http://people.ubuntu.com/~sergiomeneses/sandbox/Software%20Center%20Tests
[19:33] <balloons> SergioMeneses, is there an easy way to verify the sync worked?
[19:34] <balloons> perhaps by booting in a vm, and syncing to a fresh install?
[19:34] <SergioMeneses> balloons, maybe
[19:34] <balloons> ohh btw, be sure and pull the latest bzr branch before you commit
[19:34] <balloons> I did some massive spellcheck and formatting commits yesterday :-)
[19:34] <SergioMeneses> balloons, I dont put it
[19:34] <SergioMeneses> not now
[19:38] <SergioMeneses> balloons, so I think we have to add more comments about the VM and make a new installation ....and more
[19:38] <balloons> well.. I'm wondering about it
[19:38] <balloons> technically just syncing it to any other installation works
[19:39] <balloons> but you wouldn't have to go that far.. you could check and make sure it synced
[19:39] <balloons> then potently make a change on your box and resync it?
[19:39] <balloons> I've not played around with the feature
[19:39] <balloons> so I'm not sure of all the possiblities
[19:40] <SergioMeneses> balloons, I have not worked with that feature jeje but we can try
[19:42] <SergioMeneses> I'm thinking to install ubuntu 13.04 and try the feature
[19:42] <balloons> I'm on 13.04.. let's go look
[19:43] <balloons> ohh.. see I did sync this once
[19:43] <balloons> :-)
[19:43] <balloons> cool
[19:43] <balloons> I think before I upgraded I synced it
[19:43] <balloons> gave me an crash box :-)
[19:43] <balloons> so it's showing the diff between now and my last snc
[19:44] <balloons> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1151621
[19:44] <SergioMeneses> balloons, :O
[19:45] <SergioMeneses> jejeje nice bug balloons
[19:45] <balloons> anyways, so yea.. looks cool
[19:45] <balloons> so it shows I've synced 3 times
[19:45] <balloons> lol..
[19:45] <SergioMeneses> balloons, do you have the link to get ubuntu beta?
[19:45] <balloons> the image?
[19:45] <SergioMeneses> balloons, yes
[19:46] <balloons> cdimage
[19:46] <balloons> hello Letozaf_
[19:46] <balloons> alright.. I've got to get this announce out SergioMeneses .. let me know if you need anything else on this
[19:46] <Letozaf_> balloons, Hi
[19:46] <balloons> basically it shows the diff between syncs
[19:46] <balloons> no automagically re-install everything that I can see however
[19:46] <Letozaf_> SergioMeneses, Hi
[19:47] <SergioMeneses> balloons, perfect then! let me see what we can do
[19:47] <SergioMeneses> Letozaf_, hi :)
[20:02]  * balloons thinks aloud
[20:03] <balloons> SergioMeneses, Letozaf_ Noskcaj should we do the g hangout onair, via ubuntuonar>
[20:03] <balloons> ^^ ubuntuonair
[20:03] <Letozaf_> balloons, sounds good !
[20:03] <Noskcaj> balloons, might be a good idea.
[20:03] <SergioMeneses> balloons, about what?
[20:03] <balloons> SergioMeneses, for the final beta testing event
[20:03] <balloons> excellent.. done, I'll get jose to set it up
[20:03] <balloons> :-)
[20:03] <SergioMeneses> balloons, oh sure! I read your email
[20:05] <SergioMeneses> balloons, but I think I'll join to Javier's event, I can be more productive in Spanish (imho)
[20:06] <balloons> SergioMeneses, I saw that.. what's the plan for that?
[20:06] <balloons> I haven't seen him on IRC.. not sure if we could have dual hangouts.. but I want to promote both :-
[20:07] <SergioMeneses> balloons, I dont know I have to talk with Javier to see what we can do
[20:08] <balloons> maybe we could let your hangout be a bit more organic?
[20:09] <balloons> or occur as part of the "main event" but before or after the english part?
[20:09] <balloons> we have time.. we could just do back to back broadcasts..
[20:09] <balloons> you think?
[20:09] <Letozaf_> balloons, testdrive does not work on Raring fresh install have you tried it ?
[20:09] <SergioMeneses> balloons, sounds good for me :)
[20:10] <balloons> Letozaf_, :-(
[20:10] <balloons> I was planning on doing the new iso test screencast wth it
[20:10] <balloons> I *hope* it works
[20:10] <Noskcaj> has anyone else had testdrive put up 2 copies of each iso?
[20:10] <balloons> I used it last week?
[20:11] <Letozaf_> balloons, I just re-installed Raring yesterday on my notebook
[20:11] <SergioMeneses> balloons, maybe we can talk about testcases or something more
[20:11] <Letozaf_> balloons, if you install testdrive it does not work!
[20:11] <SergioMeneses> Letozaf_, ubuntu dayli?
[20:11] <SergioMeneses> daily
[20:11] <Letozaf_> SergioMeneses, yes
[20:12] <SergioMeneses> mmm... I was thinking to install it right now =/
[20:12] <Letozaf_> balloons, http://paste.ubuntu.com/5659265
[20:12] <Letozaf_> balloons, this is what I get if I type testdrive-gtk from terminal
[20:13] <balloons> ugh
[20:13] <Letozaf_> balloons, I was also thinking to use testdrive for showing ISO testing
[20:13] <balloons> runs for me still :-)
[20:13] <Letozaf_> balloons, :( testdrive hates only me ?
[20:14] <balloons> I guess?
[20:15] <Letozaf_> balloons, :P
[20:15] <balloons> SergioMeneses, so can we safely just say we'll have you and Javier on the main ubuntu-on-air broadcast, with a spanish runthrough of testing?
[20:16] <balloons> I like that plan best.. so it will be archived properly, etc
[20:16] <balloons> and people can just hangout on the main site
[20:17] <balloons> hehe.. Jose hooked us up :-) http://ubuntuonair.com/
[20:17] <SergioMeneses> balloons, sure!
[20:18] <SergioMeneses> in the ubuntu-on-air channel?
[20:18] <SergioMeneses> I think Javier is thinking on something personal
[20:18] <balloons> yea.. perhaps I won't mention it directly then
[20:18] <balloons> but I'll plan to do it if we can confirm things with him
[20:19] <SergioMeneses> balloons, do we have an schedule?
[20:20] <balloons> SergioMeneses, yes.. 2000 UTC is the hangout.. ohh you mean, an agenda for the hangout?
[20:20] <balloons> I have a loose one.. Basically I'm going to ask for those who volunteered to show off doing so tests ;-)
[20:21] <balloons> We'll do some simple ones, and then go for the exotics ;-)
[20:21] <SergioMeneses> balloons, only one hangout?... I was thinking on more sections xD
[20:21] <SergioMeneses> sessions
[20:21] <balloons> SergioMeneses, we'll have the main hangout.. if folks in the channel want some one on one help, we can spawn hangouts for them
[20:21] <balloons> and you guys can go help
[20:21] <SergioMeneses> balloons, ok then! let me talk with Javier and we can reply you
[20:22] <balloons> SergioMeneses, great!
[20:23]  * letozaf__ is rebooting PC
[20:25] <SergioMeneses> I have to reboot my pc too
[20:29] <letozaf__> balloons, I will report a bug, the same problem happens on my PC, testdrive does not install on a new Raring install
[20:29] <balloons> letozaf__, great.. bad timing for it to break
[20:29] <balloons> glad it's not broken for me
[20:29] <Noskcaj> letozaf__, i'll get a VM made and confirm for you.
[20:30] <letozaf__> Noskcaj, thanks :D
[20:36] <Noskcaj> could someone confirm bug 1095432 for me?
[20:37] <Noskcaj> and bug 1077158
[20:40] <letozaf> Noskcaj, I confirmed your bug 1077158  but for bug 1095432 I do not have a powerpc do you think I can confirm it all the same ?
[20:41] <Noskcaj> letozaf, yes, it's because qemu can show ppc in it, but ppc isn't in the testdrive repos
[20:46] <letozaf> Noskcaj, ok confirmed I have reported bug 1162027 for the testdrive problem
[20:52] <balloons> awesome :-)
[20:52] <balloons> ok, so back to merge reviews :-)
[20:52] <balloons> and then food I hope
[20:53] <balloons> I blame philballew for making me hungry!
[20:55]  * SergioMeneses is back
[20:55] <SergioMeneses> balloons, why? jeje
[21:24] <Noskcaj> Letozaf, bug didn't affect me.
[21:25] <Letozaf> Noskcaj, :( that's weired
[21:25] <Letozaf> Noskcaj, if you install python-autopilot ?
[21:26] <Noskcaj> oops, i shut out of the VM
[21:26] <Letozaf> Noskcaj, doesn't matter I will test this
[21:26] <Letozaf> Noskcaj, It must be that, I have autopilot on both machines
[21:27] <balloons> Letozaf, back on the autopilot issues
[21:27] <balloons> hahah
[21:27] <balloons> not funny.. but..
[21:27] <balloons> yea SO SO SO weird
[21:27] <Letozaf> balloons, I will try this now on a VM, I will install testdrive with and without autopilot installed
[21:27] <balloons> Letozaf, if there really is something weird, yea
[21:54] <Letozaf> balloons, this is very very very weired!! http://paste.ubuntu.com/5659544
[21:54] <Letozaf> balloons, I installed Raring on a new VM (Raring Desktop AMD 64 bit)
[21:55] <Letozaf> balloons, just after reboot, installed testdrive and got the error you see I pasted
[21:55] <Letozaf> balloons, so no autopilot but the error is there o?
[21:56] <Letozaf> Noskcaj, did you install a i386 or amd64 ISO ?
[21:56] <Noskcaj> amd64 xubuntu
[21:56] <Letozaf> Noskcaj, this happens to me on Ubuntu, so maybe that's why
[21:56] <Noskcaj> i didn't try to open it, i just installed it
[21:57] <Letozaf> Noskcaj, well the problem occurs when you try to open it, it does not open so I try in terminal and get the error
[21:58] <Noskcaj> does the cli work?
[21:59] <Noskcaj> Letozaf, i can confirm the bug for gtk
[21:59] <Letozaf> Noskcaj, ok thanks, I will try the cli now
[22:00] <Noskcaj> Letozaf, i should work fine, bt with double entries for everything
[22:01] <Letozaf> Noskcaj, the cli works fine, did you try it on your VM ? does it work ?
[22:01] <Noskcaj> yeah, cli works, but everything has two entries
[22:01] <Letozaf> Noskcaj, oh! you're right
[22:01] <Letozaf> Noskcaj, sorry I only saw that now
[22:01] <Noskcaj> it's the same in gtk, appear about 2 weeks ago
[22:02] <Letozaf> Noskcaj, didn't know about it
[22:02] <Letozaf> Noskcaj, have you a bug open on that ? I can confirm it for you if you need
[22:02] <Noskcaj> i will open a bug now
[22:03] <Letozaf> Noskcaj, fine I will confirm it
[22:09] <Noskcaj> Letozaf, bug 1162057
[22:10] <Letozaf> Noskcaj, ok confirmed!
[22:10] <Noskcaj> ty
[23:33] <SergioMeneses> Noskcaj, I have the same bug with testdrive :S
[23:34] <SergioMeneses> Although it works
[23:34] <SergioMeneses> ok, I have to go... see you later
[23:45] <phillw1> Noskcaj: what part of testdrive still works?


[21:04] <knome> slickymaster, don't know if you have had time to think aobut it, but if you have, what's the plan re: improving docs for 18.04
[21:04] <knome> slickymaster, i'm thinking about the potential new chapters/issues we want to cover, eg. adding instead of adapting
[21:05] <slickymaster> tbh I haven't think about it knome
[21:05] <knome> slickymaster, or if we want something else changed that is just not making sure we're up-to-date
[21:05] <slickymaster> the later goes without saying knome
[21:05] <knome> yeah, of course we will keep the stuff up-to-date
[21:05] <slickymaster> the former is something I'd see with good eyes
[21:05] <knome> and related to that, i don't think we should write much new documentation that needs such maintaining
[21:06] <knome> eg. rather focus on "guide" style stuff than documentation on how to use feature X/Y
[21:06] <slickymaster> agree
[21:06] <knome> (and if upstream is bad with those, we can also focus on improving the upstream documentation before 18.04)
[21:07] <knome> so we don't have much of that "how xubuntu works" kind of stuff
[21:07] <knome> though we might also want to save that for the blog
[21:07] <knome> one direction for figuring out what we'd need to document is go through ubottu's factoids
[21:08] <slickymaster> we've not been doing much of how xubuntu works, that's a fact
[21:08] <slickymaster> and that's something users always find usefull
[21:09] <knome> well for a good reason too - we've had hands full of stuff with more important things
[21:09] <slickymaster> what do you mean with going through the ubottu's factoids
[21:09] <slickymaster> see what is been asked the most on IRC?
[21:09] <knome> !panel
[21:09] <knome> !panels
[21:09] <knome> !panels-#xubuntu
[21:09] <knome> ^ sth like that
[21:10] <slickymaster> yeah, what I thought
[21:10] <Unit193> FAQ-ish stuff.
[21:10] <knome> so basically move content that is very relevant to xubuntu documentation that is outside of it currently
[21:10] <slickymaster> you're the right person to clect that data, Unit193
[21:10] <slickymaster> * colect
[21:10] <Unit193> Oh?
[21:10] <knome> Unit193, kind of, could be even a FAQ section
[21:10] <Unit193> slickymaster: collect.
[21:10] <knome> no, he means you're a cleptomaniac.
[21:11] <knome> and that he has problems with stuttering.
[21:11] <slickymaster> yeah, I have one eye in the TV set, seeing today's stage and the other in the keyboard


[03:30] <studio-user109> i have setup ubuntu studio ... it is very very slow
[03:30] <studio-user109> pls help
[03:51] <ErichEickmeyer> Not even 2 minutes.
[03:54] <OvenWerks> ErichEickmeyer: to such a person evrything is slow
[03:55] <ErichEickmeyer> LOL!
[05:19] <abid> hello
[15:01] <username12565> i got a midi keyboard and thought this might be easier than it is :}
[15:02] <username12565> if i launch qjackctl and hit "start", does that launch JACK? or do i need to launch JACK manually somehow?
[15:06] <username12565> seems like it does
[15:23] <username12565> ok, i see messages in gmidimonitor jack \o/
[15:29] <username12565> success!
[15:29] <username12565> i can hit keys and have drumvk1 play things \o/


[14:46] <Jester-> hi
[18:47] <kklimonda> hey guys - what is the right way of solving problems with LoCo channels?
[18:47] <kklimonda> our polish channel is a joke, it's getting worse and worse for years - people aren't abiding to CoC, most of them don't use ubuntu at all..
[18:47] <kklimonda> new users are getting laugh at..
[18:48] <kklimonda> i haven't seen owner since i've joined it..
[18:51] <erUSUL> kklimonda: rise tghe issue to the irc council members/mailing list ???
[18:51] <kklimonda> ok
[18:55] <erUSUL> i do not know if someone here can give better guidance... Pricey nalioth jussi01 Pici ????
[18:57] <juliux> kklimonda: about which channel are you talking?
[18:58] <kklimonda> juliux: #ubuntu-pl
[18:59] <juliux> kklimonda: did you already contacted the ops?
[19:00] <kklimonda> juliux: I'm writing a mail to owner atm asking him to do something about it but from what I've heard it isn't the first time when someone is rising this issue.
[19:00] <nalioth> erUSUL: we try to solve issues here
[19:00] <nalioth> mailing lists  . . .
[19:01] <erUSUL> nalioth: ok noted ;P
[19:02] <kklimonda> juliux: right now people are talking about games and win2k8srv ;)
[19:04] <nalioth> kklimonda: how many active ops are there?
[19:05] <kklimonda> 4 that i know of
[19:05] <kklimonda> and one of them called a new user "it" ;)
[19:07] <kklimonda> he has also admitted that he doesn't really know what CoC contains..
[19:15] <KiFka> hey
[19:50] <asami_24> bonsoir
[19:51] <asami_24> ya t-il des français dans la salle?
[19:53] <Pici> !fr
[20:53] <brendan6223> hello


[06:10] <mborzecki> morning
[07:04] <zyga> Good morning
[07:21] <mborzecki> zyga: hey
[07:21] <mborzecki> zyga: do you know who controls strace-static snap?
[07:22] <mborzecki> is it only mvo?
[07:22] <zyga> I believe so
[07:22] <zyga> What do you need?
[07:23] <mborzecki> well, it doesn't work on fedora, something about unexpected wait status value, i believe it's the recent kernel that's causing this
[07:23] <mborzecki> the edge version is 4.23 and stil not good enough
[07:23] <mborzecki> fedora ships strace 4.24 and that one works
[07:23] <mborzecki> i've worked around it in the spread suite, but we'll need to update the snap at some point
[07:27] <zyga> Mmm
[07:28] <zyga> Is 4.24 compatible with other distributions?
[07:32] <mborzecki> zyga: we'll see when we end up using it in the spread suite
[07:32] <mborzecki> zyga: fwiw i have 4.25 in arch
[07:34] <mborzecki> one last spread run and i'll be opening a PR with Fedora 29
[07:50] <zyga> Ok
[07:51] <zyga> I will be around in 30 minutes
[07:53] <zyga> As usual, worked late last night
[08:12] <pstolowski> heyas
[08:20] <mborzecki> pstolowski: hey
[08:35] <zyga> back now
[08:35] <zyga> good morning pawel
[08:36] <zyga> how are you guys?
[08:39] <zyga> sorry for being sleepy, I was pushing some things last night
[08:40] <zyga> are we still affected by the issue where our logs are too long for travis?
[08:45] <mup> PR snapd#6264 opened: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
[08:47] <zyga> mborzecki: what is your stance on the repackaging issue?
[08:47] <zyga> I have not read the PR yet so if it is stated there please refer me instead
[08:50] <mborzecki> zyga: imo it's benign as long as we don't reexec on those system, i think we could easily not repack the core snap on such systems
[08:50] <zyga> why is it related to reexec?
[08:50] <zyga> like it happened with snap-device-helper, some things are always used from core
[08:51] <mborzecki> zyga: oh, w8, it's not, right reexec would still pull the libs from host so that's fine
[08:51] <zyga> or am I mistaken, that the issue was that repackaged, incompatible script was used
[08:51] <pstolowski> zyga: the spread test for dns error (#6222) is driving me crazy.. been trying a couple of tweaks yesterday evening. sounds crazy, but it looks like iptables-save+restore on debian doesn't actually restore the rules sometimes - some other test fails and when poking around in the system after failure i see the rule is active..
[08:51] <mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[08:51] <mborzecki> zyga: so it's probably only snapctl at this point
[08:51] <mborzecki> which we could easily build statically
[08:52] <zyga> mborzecki: would the issue also surface on future ubuntu 20.04 distribution testing a core16 snaps?
[08:52] <zyga> pstolowski: can you dump the rules to compare them in text form?
[08:53] <zyga> mborzecki: when snap-confine, reexecuting, is linked to libc not present in core16
[08:54] <mborzecki> zyga: afaict only tools that are executed inside snap mount ns would be affected, those are snapctl and snap-device-helper, snap-update-ns (but that's already linked statically)
[08:54] <zyga> indeed
[08:54] <zyga> that's a good observation
[08:54] <mborzecki> snapctl can be linked statically, it's go :)
[08:55] <zyga> as other tools will still execute on the outside
[08:55] <zyga> thanks
[08:57] <mborzecki> zyga: that shebang being rewritten from #!/bin/sh to #!/usr/bin/sh is probably some usr-merge thing again
[08:58] <zyga> yes
[08:58] <pstolowski> zyga: iptables-save dumps them in txt form; let me actually inspect that when some other test fails
[08:58] <zyga> pstolowski: yeah, just dump them in prepare and restore
[08:58] <zyga> and compare what we get
[08:58] <zyga> guys, I'm almost convinced there's something seriously broken
[08:58] <zyga> so consider, when inspecting magic failures, that set -e is indeed not working
[08:59] <zyga> so perhaps something failed earlier on and the script nonetheless advanced
[08:59] <zyga> though I still don't grasp the details
[09:04] <mborzecki> pstolowski: silly thought, maybe we should start our own dns server for that test
[09:04] <pstolowski> mborzecki: hmm but we would need to modify the test environment anyway, so potentially effect something else?
[09:05] <pstolowski> mborzecki: it seems like a primitive approach with just iptables -I .., followed by iptables -D ... works. or maybe i'm just lucky.
[09:05] <mborzecki> hehe :) if it works then it's fine
[09:15] <pstolowski> mborzecki, zyga: ha, reproduced. run all spread tests. a radom test failed (not the one that messes up with iptables). the rules dump file created by iptables-save is empty, but iptables has the dns reject rule
[09:16] <zyga> intriguing, how do you save and observe the tables?
[09:16] <zyga> and where do you store the dump?
[09:16] <pstolowski> mborzecki, zyga grr, ignore me. the rules should be empty :D
[09:16] <zyga> ah
[09:16] <pstolowski> mborzecki, zyga apparently iptables-restore didn't work or wasn't invoked
[09:19] <pstolowski> hmm, ok, not even that. rules dump is empty (as completely empty), but it should actually have some iptables-save noise
[09:19] <pstolowski> weird...
[09:19] <zyga> how do you dump the rules?
[09:20] <mborzecki> pstolowski: were there any rules in place when iptables-save was called?
[09:22] <pstolowski> mborzecki: no (and in such case iptables-save creates a kind empty file with empty chains)
[09:23] <zyga> is the file overwritten somewhere?
[09:23] <mborzecki> pstolowski: hm empty? shouldn't there be a timestamp and a list of all chanins (all empty)
[09:24] <pstolowski> mborzecki: yes
[09:24] <pstolowski> zyga: interesting theory
[09:25] <pstolowski> trying without iptables save/restore now, if it works i'm gonna leave it like that
[09:30] <mborzecki> #6264 is green :)
[09:30] <mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
[09:45] <mborzecki> damn, hitting unrelated errors in the PRs
[09:45] <mborzecki> appstream-id, refresh-all :/
[09:45] <mborzecki> and mount thing obviously too
[09:50] <zyga> yes
[09:50] <zyga> bane of random failures
[09:50] <zyga> eh :/
[09:50] <zyga> I really encourage everyone to attack them
[09:50] <zyga> they are crippling our ability to make progress
[10:09] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6261 ?
[10:09] <mup> PR #6261: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6261>
[10:09] <mborzecki> it's finally green
[10:10] <pstolowski> k
[10:17] <mborzecki> zyga: about that xdg-desktop-portal: https://paste.ubuntu.com/p/nkFc5FJ3Qc/
[10:18] <zyga> mmm
[10:18] <mborzecki> but i don't see what requires that really
[10:18] <zyga> we require it
[10:19] <mborzecki> zyga: well, it's not listed anywhere in the spec
[10:20] <zyga> hmm
[10:20] <zyga> perhaps I was mistaken
[10:20] <pstolowski> #6222 green as well; kicking it again to double check
[10:20] <zyga> but I recall something like that
[10:20] <mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[10:21] <zyga> pstolowski: ack
[10:21] <mborzecki> zyga: https://paste.ubuntu.com/p/Yf3bRmcjBr/
[10:21] <zyga> pstolowski: is it safe to merge or do you anticipate tests breaking in the future?
[10:21] <zyga> hm
[10:21] <zyga> mborzecki: then I have no idea
[10:22]  * zyga -> tea
[10:24] <pstolowski> zyga: the test is dead simple and doesn't shouldn't have any side-effects, but you never know. i'll give it one more run to see. if it causes problem in the future i'll disable it
[10:24] <zyga> ok
[10:25] <mborzecki> zyga: heh i can actually remove xdg-desktop-portal and none of snapd components are removed
[10:42] <mup> PR snapd#6261 closed: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6261>
[10:49] <mborzecki> pstolowski: if you could do this one too: https://github.com/snapcore/snapd/pull/6260
[10:50] <mup> PR #6260: spread, tests: use checkpoints when dumping audit log <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6260>
[10:51] <mborzecki> zyga: no clue what's happening with dependencies there, left a note in the PR for now
[10:51] <zyga> sounds good
[10:57] <pstolowski> random mount failure on 6222 -  Mount snap "test-snapd-tools_instance" (7) ([start snap-test\x2dsnapd\x2dtools_instance-7.mount] failed with exit status 1: Job for snap-test\x2dsnapd\x2dtools_instance-7.mount failed.
[10:58] <mborzecki> heh
[11:01] <zyga> on whihc system?
[11:01] <zyga> *which system
[11:01] <zyga> moved downstairs to the office
[11:01] <zyga> sorry, I don't feel well today
[11:08] <pstolowski> zyga:  google:ubuntu-18.04-64:tests/main/refresh-all
[11:08] <zyga> 18.04
[11:08] <zyga> mmm
[11:08] <zyga> has anyone seen this on 18.10?
[11:20] <mup> PR snapd#6265 opened: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[11:21] <mup> PR snapd#6260 closed: spread, tests: use checkpoints when dumping audit log <Simple 😃> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6260>
[11:24] <mborzecki> pstolowski: thanks!
[11:27] <cachio> zyga, hey, I tested the systemd fix but still failing
[11:27] <pstolowski> yw
[11:27] <cachio> there is a test interfaces-hostname-control
[11:28] <cachio> which found that error
[11:28] <cachio> which still fail
[11:29] <zyga> cachio: can you report on the SRU bug please
[11:29] <zyga> cachio: and talk to xnox about the details
[11:29] <cachio> sure
[11:29] <zyga> thank you
[11:29] <cachio> zyga, np
[11:29] <cachio> I have a branch with the change I did to check that
[11:29] <ackk> hi, is there a "hook" to do stuff like push files/configs to the multipass VM snapcraft uses?
[11:29] <cachio> if you want to take a look just tell me
[11:31] <zyga> cachio: that's fine, unless you want me to
[11:32] <cachio> ok, I'll explain more during the standup
[11:51] <pstolowski> #6222 is green again, merging
[11:51] <mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[11:52] <mup> PR snapd#6222 closed: cmd/snap: handle DNS error gracefully <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[11:53] <zyga> jdstrand: 6244 is read
[11:53] <zyga> *ready
[11:53] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6251 needs a 2nd review
[11:53] <mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
[11:54] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6149 needs a partially second review
[11:54] <mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[11:54] <mborzecki> k, looking
[11:54] <zyga> thank you :)
[11:56] <zyga> mborzecki: any action needed on F29 PR in light of the weak dependency fact?
[11:57] <mborzecki> zyga: i'm running the fix under spread right now
[11:57] <zyga> ok
[12:01] <mborzecki> that umask thing keeps popping up
[12:01] <zyga> hmmm
[12:01] <zyga> tests leaking
[12:01] <zyga> or something else?
[12:02] <mborzecki> zyga: the test that passed on travis and locally before failed right now
[12:04]  * cachio afk
[12:04] <zyga> I'm back to debugging set -e bug
[12:11] <zyga> waaat?!!?
[12:17] <jamesh> zyga: would it be possible to get this change merged? https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/360118 -- this test package isn't currently used in snapd master, and I needed to update it a bit for the new version of the dbus activation changes
[12:17] <zyga> looking
[12:18] <zyga> if this is merged and published to the store, would snapd tests be affected straight away?
[12:18] <zyga> I mean, would any tests that used to pass start to fail?
[12:19] <jamesh> zyga: there is no reference test-snapd-dbus-service in the tests/ directory of snapd master
[12:19] <zyga> ok
[12:20] <jamesh> it originates from mvo's old abandoned PR
[12:22] <zyga> jdstrand: is there a merge service running against that BZR branch?
[12:22] <zyga> er
[12:22] <zyga> jamesh: ^
[12:22] <zyga> sorry, bad tab completion
[12:23] <jamesh> zyga: I don't think so.
[12:23] <zyga> ok, I'll merge it manually then
[12:24] <jamesh> thank you.  I think I'm getting close to being able to remove that "WIP" tag from my PR
[12:24] <jamesh> (and I understand it might take a while to get reviewed)
[12:25] <zyga> hopefully more reviews will resume next week
[12:26] <jamesh> I'm sure there's still problems to discover once my spread tests run on all distros
[12:32] <zyga> hmm
[12:32]  * zyga doesn't recall bzr specific weirdness
[12:32] <zyga> jamesh: I _think_ it is merged
[12:33] <zyga> yep
[12:43] <zyga> mborzecki: can you re-review https://github.com/snapcore/snapd/pull/6259/files
[12:43] <zyga> the set -e mystery is solved
[12:43] <mup> PR #6259: tests: reduce verbosity around package installation <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6259>
[12:43] <zyga> I was so stuck looking at why dpkg-query failure was ignored
[12:43] <zyga> it was not
[12:43] <zyga> it was never executed
[12:43] <zyga> the exit above made sure of that
[12:43] <zyga> so the test would fail but it was returning early
[12:58] <mborzecki> zyga: something fishy about tests, i have no idea how that fedora 29 pr is green
[12:58] <zyga> haha
[12:58] <zyga> in which sense
[12:58] <zyga> maybe it is manual?
[12:59] <mborzecki> omg, damn, it is
[13:03] <mup> PR snapd#6250 closed: data: set KillMode=process for snapd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6250>
[13:06] <zyga> advice welcome on https://github.com/snapcore/snapd/pull/6190
[13:06] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[13:06] <zyga> is that good as is
[13:06] <zyga> or should I iterate on some aspect
[13:06] <zyga> should I split some parts out to land quicky
[13:31] <mup> PR snapd#6259 closed: tests: reduce verbosity around package installation <Simple 😃> <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6259>
[13:31] <mup> PR snapd#6266 opened: tests: make security-device-cgroups-{devmode,jailmode} work on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6266>
[13:34] <zyga> updated https://github.com/snapcore/snapd/pull/6149#discussion_r239058308
[13:34] <mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[13:42] <zyga> mborzecki: do you mean to make F29 non-manual in https://github.com/snapcore/snapd/pull/6264
[13:42] <mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
[13:43] <mborzecki> zyga: yes, running with the latest batch of fixes, i'll label the PR as blocked for now
[13:43] <zyga> thank you
[13:43] <mup> PR snapd#6267 opened: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
[13:43] <zyga> mborzecki, pstolowski:  I pushed a very simple PR to shrink my other feature PR, could you guys please look ^
[13:51] <zyga> pstolowski: need a 2nd review on https://github.com/snapcore/snapd/pull/6149  :)
[13:51] <mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[13:51] <zyga> feel that this is finally moving forward :)
[13:53] <pstolowski> zyga: ok, will do
[14:16] <mborzecki> zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
[14:24] <zyga> xnox: hey, what going to happen now that the SRU verification of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 is failed?
[14:25] <mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936>
[14:30] <cachio> zyga, https://github.com/sergiocazzolato/snapd/tree/tests-validate-lp-1778936
[14:30] <zyga> cachio: can you add a note to that bug please, that explains how to reproduce the results of that test
[14:31] <zyga> cachio: specifically how to build a system image with core18 which contains systemd from proposed
[14:31] <cachio> ok
[14:31] <zyga> thank you :)
[14:32] <zyga> cachio: I'm not sure how what you changed there tests systemd form proposed
[14:32] <zyga> since our testing process doesn't involve unpacking systemd into the repackaged core18 snap
[14:32] <zyga> cachio: so you would still get the vanilla core18 from the store
[14:32] <zyga> which has systemd from stable
[14:32] <zyga> (well, from the archive)
[14:33] <zyga> cachio: may I ask how you checked the version of systemd that you observed?
[14:34] <zyga> cachio: in the effective image built with ubuntu-image?
[14:34] <cachio> when the test fails
[14:34] <cachio> zyga, it is possible to check systemd version in a debug session
[14:34] <zyga> mhm
[14:34] <zyga> and what is the version you saw?
[14:35] <cachio>  237-3ubuntu10.10
[14:35] <zyga> and how does that relate to the version in main and in proposed?
[14:35] <cachio> in main is 237-3ubuntu10.7
[14:35] <cachio> irrc
[14:35] <zyga> the version that is mentioned in the bug report as containing the fix is different
[14:36] <zyga> it is 239-7ubuntu7
[14:36] <cachio> basically, what I do it to enable proposed and refresh systemd during the project preparation
[14:36] <zyga> or 237-3ubuntu10.8 in bionic
[14:36] <cachio> Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.10
[14:36] <zyga> cachio: but that changes the starting throwaway image
[14:36] <zyga> not the core18 image you build
[14:37] <zyga> I don't see how the changes you did affect the core18 _snap_ that is used to build the image where tests execute
[14:37] <zyga> it may be that this is correct
[14:37] <zyga> but I don't understand it yet
[14:37] <zyga> and I want to since the verification failed and this is an urgent issue
[14:38] <cachio> let me create a debug session
[14:38] <cachio> zyga, perhaps it works
[14:38] <cachio> to understand better
[14:38] <zyga> you can create one but can you argument how this is expected to  work
[14:38] <zyga> I want to see how the proposed package ends up in the core18 snap
[14:40] <cachio> so, we build core18 snap we use the deb snapd.deb we already created
[14:41] <zyga> how do we build the core18 snap? can you show me please?
[14:41] <cachio> zyga, sure, 1 sec
[14:41] <zyga> thanks
[14:42] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/6244 is ready, if you have some time to look at the last patch I would love to land that and have that bug fixed :)
[14:42] <cachio> https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L339
[14:42] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[14:42] <cachio> zyga, ~
[14:42] <zyga> cachio: looking
[14:43] <zyga> so
[14:43] <zyga> we unpack the _snapd_ snap
[14:43] <zyga> right?
[14:43] <cachio> yes
[14:43] <zyga> does the snapd snap contain systemd?
[14:44] <zyga> AFAIK systemd is inside the core18 snap
[14:44] <zyga> unless we are repackaing that one elsewhere, and based on the package from the host
[14:44] <zyga> I don't see how this was testing proposed
[14:45] <cachio> zyga, what I did is to enable proposed on this instance
[14:46] <cachio> and add a dependency on snapd.deb to the package on proposed
[14:46] <zyga> Sorry, in which instance?
[14:46] <cachio> so then if we build the image based on out .deb
[14:46] <cachio> instance is the ubuntu-18.04-64 that we use to create the image
[14:46] <zyga> The test was checking snapd on core18 or on Ubuntu 18.04?
[14:47] <cachio> zyga, the test checks on core 18 instance
[14:47] <cachio> which is build on the fly using a ubuntu bionic image
[14:47] <zyga> So explain how the choice of the host instance affects the system image built with Ubuntu image that is eventually tested?
[14:48] <zyga> My understanding is that the core18 snap is coming from the store
[14:48] <zyga> And that it contains systemd
[14:49] <jlorenzo> kenvandine: oSoMoN: hi guys! a mozilla employee found an odd behavior regarding assertions (even though he installed the snap with `--dangerous`). He left more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1297531. Would you know who would be suited to help him out?
[14:49] <zyga> And because we do not alter it in the test, that is the core18 snap is as-is from the store then the changes ran against the same systemd version as before
[14:49] <cachio> mmm, I see in the code that we modify the snapd snap to use what we have in the snapd.deb
[14:49] <zyga> Yes
[14:49] <zyga> But snapd snap does not contain systemd
[14:49] <kenvandine> hey jlorenzo
[14:51] <oSoMoN> hey jlorenzo
[14:51] <oSoMoN> reading that bug
[14:51] <cachio> I though that by setting a dependency for the snapd.deb to use the systemd from proposed is enough to force the image gets this systemd
[14:51] <cachio> but based on the code I am not 10% sure
[14:51] <cachio> 100%
[14:52] <zyga> It would if this was using apt
[14:52] <zyga> But we unpack just snapd.deb
[14:52] <zyga> Still
[14:52] <zyga> I believe you saw the right version of systemd
[14:52] <zyga> Can you tell me which channel of core18 was used in the test
[14:53] <zyga> Was it edge?
[14:53] <zyga> And is core18 edge using main or proposed?
[14:53] <cachio> we use edge
[14:53] <zyga> Perhaps you tested the SRU despite making changes that have no effect on the produced image
[14:53] <kenvandine> oSoMoN: thanks
[14:54] <zyga> Can you please check the core18 edge snap recipe
[14:54] <zyga> It should have this information
[14:54] <cachio> sure
[14:54] <zyga> Thank you :-)
[14:56] <oSoMoN> jlorenzo, no need for an assertion, for local tests the browser-support interface can be manually connected, I'll comment on the bug to explain
[14:59] <diddledan> who can kick the store review thingy for me? gog-galaxy-wine revision 62 is stuck
[15:01] <cachio> zyga, at least core is not built from proposed
[15:01] <cachio> zyga, I can't see the recipy for core18
[15:02] <jlorenzo> oSoMoN: got it! thank you very much for the help :)
[15:03] <oSoMoN> jlorenzo, you're welcome
[15:03] <cachio> zyga, so, I'll try to build a snapd.snap with systemd from proposed
[15:03] <cachio> zyga, that should work right?
[15:06] <zyga> re
[15:06] <zyga> cachio: no, build core18 with systemd from proposed
[15:06] <zyga> cachio: snapd.snap version is irrelevant
[15:07] <zyga> cachio: can  you ask foundations for help, they should be able to point you to the recipe
[15:07] <cachio> zyga, great, thanks
[15:07] <cachio> I'll try that
[15:07] <zyga> sure, let me know if you cannot find the recipe, I can look as well
[15:08] <zyga> cachio: and please add a comment to the bug report that testing is still ongoing
[15:08] <zyga> so that xnox doesn't take action on incomplete information
[15:11] <cachio> zyga, sure, comment left
[15:11] <zyga> super, thank you
[15:11] <cachio> zyga, thanks for the help
[15:23] <xnox> cachio, if you give me something i can boot in a VM, i'm happy to validate things =)
[15:23] <xnox> w.r.t. etc-writable stuff.
[15:29] <zyga> xnox: who builds the core18 images now, is that foundations?
[15:29] <zyga> sorry, I was imprecise, I meant core18.snap
[15:31] <zyga> xnox: looking at the core18 snap in edge, it ships with systemd 237
[15:31] <zyga> but it doesn't have a manifest that I can look at
[15:31] <cachio> xnox, still trying to build the correct image, I'll let you know when the image is ready for validation
[15:32] <cachio> zyga, I searched on launchpad and couldn't find it
[15:32] <cachio> at least in our projects
[15:33] <cachio> so, foundations should be creating it, or mvo in same place
[15:33] <cachio> zyga, the last core18 images which I tested were share by mvo
[15:35] <cachio> zyga, I see this in the store -> core18 – Shared by canonical<EMAIL_ADDRESS>[15:35] <cachio> so foundations should be creating them
[15:35] <zyga> I found this repository: https://launchpad.net/snap-core18
[15:35] <zyga> but not sure if that's used
[15:36] <zyga> sil2100: hey
[15:36] <zyga> sil2100: can you shed some light on core18 snap
[15:36] <cachio> https://code.launchpad.net/~ubuntu-core-service/+snap/core18
[15:37] <zyga> do you know where the source repository is and where the build recipe is (if it is built with a snap recipe)?
[15:37] <zyga> cachio: nice, looking
[15:37] <zyga> https://code.launchpad.net/~ubuntu-core-service/+snap/core18 says it is using primary archive for ubuntu
[15:37] <zyga> so that doesn't look like it uses proposed
[15:38] <zyga> and the publised snap goes to beta and edge
[15:38] <zyga> this is using the updates pocket
[15:38] <zyga> so not proposed
[15:38] <zyga> so we need to repeat the test
[15:38] <zyga> cloning that recipe
[15:38] <cachio> zyga, is it possible to unpack core18 and manually replace systemd?
[15:38] <zyga> cachio: yes but for correctness we should just rebuild it with different archive
[15:38] <zyga> that's supposedly easy
[15:39] <zyga> cjwatson: hey, could you please help us with one thing, we'd like to build https://code.launchpad.net/~ubuntu-core-service/+snap/core18 but switch the archive to proposed
[15:39] <zyga> what's the easiest way to do that?
[15:40] <zyga> we don't need to upload it to the store (though uploading to edge is ok)
[15:40] <zyga> ideally edge could be out of proposed for real but we are after one-off test
[15:45] <cjwatson> zyga: I'm on holiday today and tomorrow.  You should be able to work that one out from the apidoc though, I think
[15:45] <zyga> thanks, looking!
[15:45] <zyga> enjoy the holidays and don't worry :)
[15:47] <xnox> zyga, cachio - even if foundations build it, it's not built with proposed on..... i don't think.....
[15:48] <xnox> but it is not I =/
[15:48] <zyga> xnox: yeah, I checked, it's built with updates
[15:48] <zyga> xnox: trying to build it now
[15:54] <cachio> zyga, do you have a way to build it?
[15:54] <zyga> yes, I think so
[15:54] <zyga> building now
[15:54] <zyga> I will share what I did if this works
[15:57] <cachio> zyga, great, thanks
[16:00] <zyga> cachio: ok, I have a core18 now
[16:00] <zyga> cachio: can you try this locally please:
[16:01] <mup> PR snapd#6268 opened: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
[16:01] <zyga> git clone -b master https://git.launchpad.net/snap-core18
[16:02] <zyga> sed -i -e 's/current/pending/g' Makefile
[16:03] <zyga> use snapcraft from the debian pacakge
[16:03] <zyga> not from the snap:
[16:03] <zyga> sudo snapcraft
[16:03] <zyga> once built you can use that core18 snap to build an image
[16:05] <zyga> after building you inspect the file dpkg.list found in /usr/share/snappy/dpkg.list
[16:05] <zyga> for me it contains:
[16:05] <zyga> ii  systemd                    237-3ubuntu10.10        amd64        system and service manager
[16:05] <zyga> this corresponds to the proposed update that xnox wanted tested
[16:05] <zyga> xnox: ^ can you please confirm that systemd 237-3ubuntu10.10 is the version that is under SRU?
[16:05] <zyga> cachio: using that snap just build and boot a KVM image
[16:06] <zyga> cachio: then you can run a test against that
[16:08] <cachio> nice
[16:08] <cachio> on that
[16:09] <zyga> excellent, thank you!
[16:09] <zyga> sergiusens: question about snapcraft the deb vs the snap
[16:09] <zyga> I got a failure where snapcraftctl was not on PATH and the build failed
[16:09] <zyga> is that expected with 3.x?
[16:09] <zyga> should I file that as a bug
[16:09] <zyga> the snap in question is core18 from the repository mentioned above
[16:13] <cachio> zyga, in the building logs I see systemd is downloading from proposed
[16:13] <cachio> so far no errors
[16:13] <cachio> it is still building
[16:14] <zyga> cachio: you can verify the manifest to be sure as well
[16:14] <cachio> zyga, yes,
[16:19] <zyga> pstolowski: some failures on that  hotplug PR
[16:19] <zyga> https://www.irccloud.com/pastebin/vcIZiRRm/
[16:19] <zyga> https://github.com/snapcore/snapd/pull/6268
[16:19] <mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
[16:19] <pstolowski> zyga: ok, interesting, looking
[16:21] <zyga> pstolowski: if you can please review https://github.com/snapcore/snapd/pull/6267
[16:21] <mup> PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
[16:21] <pstolowski> zyga: will do; just finishing 6251
[16:21] <zyga> thanks :)
[16:21] <cachio> zyga, ii  systemd                    237-3ubuntu10.10        amd64        system and service manager
[16:21] <zyga> cachio: great
[16:21] <zyga> that's the new version
[16:22] <zyga> right?
[16:22] <cachio> yes
[16:22] <cachio> thanks
[16:22] <cachio> I am running the test now
[16:22] <cachio> using the core18 snap just built
[16:22] <cachio> zyga, it is gonna take time because it needs to upload 47 MB
[16:23] <zyga> let me know if you have issues
[16:23] <zyga> I can probably build a kvm image and test locally
[16:32] <zyga> pstolowski: can you explain what you meant on https://github.com/snapcore/snapd/pull/6251#discussion_r239132132 ?
[16:33] <zyga> ah
[16:33] <mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
[16:33] <zyga> I see it on the 3rd comment :)
[16:33] <zyga> thanks, I'll add an explanation of SNAPD_DEBUG=x :)
[16:33] <pstolowski> zyga: sorry :)
[16:33] <zyga> nothing to be sorry about :)
[16:33] <zyga> thank you
[16:38] <zyga> pstolowski: more errors
[16:38] <pstolowski> zyga: uhm, thanks, checking
[16:38] <zyga> https://www.irccloud.com/pastebin/Bg0hqSL4/
[16:39] <zyga> pstolowski: if you can review https://github.com/snapcore/snapd/pull/6149 before EOD it would make my day,
[16:39] <zyga> more progress on user mounts than all of last week :)
[16:39] <mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[16:40] <zyga> jdstrand: hey
[16:40] <zyga> jdstrand: not sure if you are sprinting this week, I just need a quick look at https://github.com/snapcore/snapd/pull/6244/commits/29301fca5a7a465305421e4633b9488b64942adc which I believe implements spirit of what you asked for in https://github.com/snapcore/snapd/pull/6244#discussion_r238677532
[16:40] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[16:42] <pstolowski> interesting it doesn't panic locally, yet clearly its missing locking
[16:42] <zyga> huh
[16:42] <zyga> that's odd
[16:42] <zyga> that lock panic should be deterministic?
[16:42] <zyga> are you missing anything from master?
[16:43] <pstolowski> yes, if this code was not hit then the asserts around order would fail at the end of the test
[16:43] <pstolowski> anyway, pushed a fix
[16:44] <zyga> thanks
[16:44] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6262 needs a 2nd review
[16:44] <zyga> small trivial branch from jamie
[16:44] <mup> PR #6262: apparmor: allow snap-update-ns access to common devices <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6262>
[16:45] <zyga> and I'd love a review on this one https://github.com/snapcore/snapd/pull/6267
[16:45] <mup> PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
[16:45] <zyga> +9,-5 :)
[16:45] <pstolowski> 6149 +1
[16:45] <zyga> woot, thanks
[16:45] <pstolowski> reviewed it yesterday and forgot to conclude
[16:45] <mup> PR snapd#6149 closed: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6149>
[16:46] <mup> PR snapd#6262 closed: apparmor: allow snap-update-ns access to common devices <Simple 😃> <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6262>
[16:47] <zyga> we'll  be at 39 PRs soon
[16:54]  * cachio lunch
[17:02] <xnox> zyga, yes.
[17:02] <zyga> xnox: great
[17:02] <zyga> xnox: cachio is confirming this, we should get the result today
[17:02] <xnox> zyga, whoop whoop
[17:02] <zyga> :-)
[17:18] <ackk> hi, I'm hitting an issue with the python plugin. I have a dependency in the requirements.txt which is pulled from a git repo. so pip complains about finding stuff in the src/ dir, which I so far had workarounded with "rm -rf $SNAPCRAFT_STAGE/../src/*" in override-pull. This doesn't seem to work anymore when building in multipass as the srcdir is in a different location. is there a way to handle both cases?
[17:34] <kyrofa> Content interface question: can the default provider include a specific track?
[17:35] <kyrofa> (zyga I suppose that's a question for you)
[17:47] <zyga> kyrofa: I don't think so, it's not as unified yet
[17:47] <zyga> I'm afk now (grocery) but I can check for sure later
[17:47] <kyrofa> Thanks zyga
[17:47] <zyga> kyrofa: seems sensible to say default-provider: foo=edge
[17:47] <zyga> or something like that
[17:48] <zyga> we have that syntax (new syntax) in one place and will probably grow it
[17:48] <kyrofa> Or foo/edge ;)
[17:48] <kyrofa> Yeah... I know
[17:48] <zyga> no, the syntax is really foo=edge
[17:48] <zyga> not foo/edge
[17:48] <kyrofa> Haha, I know
[17:48] <zyga> ok :)
[17:57] <cachio> zyga, works
[17:57] <cachio> :)
[17:57] <cachio> https://paste.ubuntu.com/p/z4Vjz2jYYG/
[17:58] <cachio> xnox, hey, I confirm that the fix works
[17:58] <cachio> I'll add steps to reproduce the test in the lp
[17:59] <xnox> cachio, cool, state so / comment on the bug report, including the version number of systemd that is included in your self-built core18 snap.
[17:59] <xnox> cachio, sru team want that there.
[18:00] <cachio> xnox, good, already adding that info
[18:00] <cachio> thanks
[18:05] <cachio> xnox, please tell me if it is ok the validation steps which I added
[18:16] <cachio> xnox, now I am gonna run the whole test suite to check there are no regressions
[18:51] <pitfd> join /galliumos
[19:26] <zyga> Thank you cachio!
[19:26] <cachio> zyga, np
[20:27] <sergiusens> zyga we do not support the Deb anymore. Maintenance mode only, do not expect new features there. I was off today and will be off tomorrow too so light weight answers is what you get 😂
[20:52] <katamo> ha, so I'm feeling defeated today trying to move from the dump plugin to the proper python plugin. Error complains the executable in the bin/ directory does not exist
[21:08] <zyga> sergiusens: cool, thank you for sharing that
[21:09] <mup> PR snapd#6251 closed: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6251>
[21:12] <zyga> jdstrand: hello
[21:12] <zyga> jdstrand: I saw the feedback, thank you :)
[21:15] <zyga> jdstrand: I left some ideas for discussion
[23:46] <zyga> jdstrand: hey, pushed again, I think this time is it :)
[23:46] <zyga> it is it :)
[23:48] <zyga> now we clarly differentiate things with 0 features from not having things


[07:37] <kjackal> Good morning Juju world!
[08:24] <botwanker> jam,  jcastro,  marcoceppi,  mgz:
[08:24] <botwanker> Your mother is available, for sex?
[08:37] <botwanker> admcleod_,  ahasenack,  aisrael,  ajmitch,  alexlist,  aluria,  Ankammarao,  anrah,  anthonyf,  arosales,  axino,  axw,  babbageclunk,  Baqar,  bcsaller,  bdx,  beisner,  bildz,  bitchecker,  BjornT,  blackboxsw,  BlackDex,  bladernr`,  blahdeblah,  bloodearnest,  blr,  bodie_,  bogdanteleaga,  bradm,  bryan_att,  cargill,  cargonza,  caribou,  cdeyoung,  chris38,  ChrisHolcombe,  chrome0,  cmars,  coreycb,  cory_fu,  cppforlife_,  CyberJacob,  Cynerva,
[08:37] <botwanker> frobware,  geekgonecrazy,  gnuoy,  gsamfira,  hackedbellini,  hatch,  hazmat,  hecliunyx,  higgins,  hloeung,  iatrou,  icey,  ionutbalutoiu,  iptable,  jacekn,  jamespage,  jasondotstar,  jcsackett,  jhegge,  jhobbs,  john51,  jose,  josvaz,  jrwren,  junaidali,  kadams54,  karlthane,  khyr0n,  kina_,  kirkland,  kjackal,  kragniz,  kwmonroe,  lamont,  larrymi,  lathiat,  lazyPower,  lezbar,  lifeless,  LiftedKilt,  lukasa,  lutostag,  macgreagoir,  magi
[08:37] <botwanker> neiljerram,  niemeyer,  nihas,  nottrobin,  ociuhandu,  Odd_Bloke,  pcdummy,  perrito666,  petevg,  pjdc,  plars,  pmatulis,  psivaa,  rbasak,  rcj,  redir,  rektide_,  rharper,  rick_h,  rockstar,  Roconda_,  rogpeppe1,  rvba,  ryebot,  ryotagami,  saibarspeis,  SaltySolomon,  SaMnCo,  sarnold,  scuttle|afk,  SimonKLB:
[08:39] <blahdeblah> thanks aluria - I was just trying to find the old one :-)
[08:39] <aluria> cheers
[08:39] <blahdeblah> Why they let 12-year-olds make bots, I'll never know...
[08:39] <aluria> :)
[08:56] <magicaltrout> bring back the chap who keeps talking about Allah at least he's not just listing nicks
[09:50] <Ankammarao> Hi mattyw,
[09:53] <mattyw> Ankammarao, good morning
[09:53] <Ankammarao> mattyw,Good morning
[09:54] <Ankammarao> i have tried with your given commands for pushing terms but it was giving error
[09:54] <Ankammarao> mattyw, error: cannot get discharge from "https://api.jujucharms.com/identity/v1/discharger": third party refused discharge: cannot discharge: user is not a member of required groups
[09:55] <Ankammarao> mattyw, any idea about this error
[09:55] <mattyw> Ankammarao, what was the name of the term you were trying to push?
[09:55] <mattyw> Ankammarao, it's likely that you aren't a member of the group you're pushing the term to
[09:56] <Ankammarao> mattyw,ibm-platform-ac term
[09:56] <Ankammarao> matty,which group it is refering to
[09:58] <mattyw> Ankammarao,  that name needs to be a group in launchpad - for example https://launchpad.net/~ibmcharmers
[09:58] <mattyw> Ankammarao, so ibm-platform-ac would need to be a launchpad group
[09:58] <mattyw> Ankammarao, or you could upload terms to ibcharmers/ibm-platform-ac
[10:00] <Ankammarao> mattyw, yes i am trying that way only /snap/bin/charm push-term ibm-platform-ac.txt ibmcharmers/ibm-platform-ac
[10:00] <mattyw> Ankammarao, are you a member of the ibcharmers group on launchpad?
[10:00] <mattyw> Ankammarao, I think that error is because you aren't
[10:02] <Ankammarao> mattyw, i'm not added to the group
[10:03] <mattyw> Ankammarao, you'll need to contact one of the admins for https://launchpad.net/~ibmcharmers
[10:03] <mattyw> Ankammarao, and they should be able to get you added to that group
[10:04] <Ankammarao> mattyw,ok i'll request to them to add my name
[10:05] <mattyw> Ankammarao, I'll talk to some folk about improving that error message :)
[10:05] <Ankammarao> mattyw,thank you
[10:32] <Mmike> marcoceppi, 1.25.8 is still not in the archives - sorry to bother you like this, but customers.... :/
[10:32] <Mmike> (that is juju1.25.8)
[11:41] <deanman> Hello, after managing integrating juju with a private OS Mitaka i've noticed that the security groups cannot be automatically harvested when destroying applications/models. Has anyone else exprienced that?
[14:57] <jose> Mmike: Mmay be a good idea to ping over at #juju-dev, they should be able to help about that :)
[14:58] <Mmike> jose, thnx, will do :)
[15:31] <junaidali> Guys! I'm facing an issue where setting a config value isn't working. It appears that Juju has old config value cached somewhere and returning to charm
[15:32] <junaidali> I'm using the latest juju 2.0.1
[15:48] <admcleod_> junaidali: so if you type 'juju config application_name' what do you see, the new value or the old one?
[16:14] <junaidali> admcleod_: yes, it shows the new value
[16:16] <junaidali> The config be an IP in my charm and will raise a value error if an invalid IP is entered. I mistakenly set invalid IP while deploying.
[16:18] <junaidali> I put a print statement in the code, which shows the config has old invalid IP causing a value error.
[16:44] <admcleod_> junaidali: if 'juju config app' shows the new value, then i guess the way you are retriving the config value before printing may be the issue?
[17:57] <ChrisHolcombe> bdx, is your vault charm published?
[19:01] <ChrisHolcombe> i think i hit a reactive bug
[19:01] <ChrisHolcombe> my fn is firing but the state is not setting for some reason