[07:00] <ara> good morning!
[11:53] <ara> schwuk: ping
[15:23] <cr3> hey folks, I would appreciate your feedback to improve the concept of attachments in Checkbox!
[15:24] <cr3> currently, attachments can be expressed either as a filename or a command. the problem is that a command makes for a horrible download filename
[15:25] <cr3> so, we need to find a way to still make it possible to express commands but also relate a name to that command somehow
[15:25] <fader> cr3: There are a couple of things that immediately come to mind...
[15:26] <fader> cr3: 1. Add an (optional?) parameter to attachments to provide a filename
[15:26] <cr3> fader: attachments are currently expressed this way in a test definition file: attachments: cat /foo
[15:26] <fader> cr3: 2. Generate the filename by some simple method, e.g. "$SYSTEM_ID-$DATE-$TESTNAME"
[15:27] <cr3> fader: also, a single test definition can define multiple attachments
[15:28] <cr3> aha! what if we had attachment definition files!?
[15:28] <fader> cr3: So could you say: attachments: filename cat /foo ?
[15:29] <cr3> fader: what if filename contains a space?
[15:29] <fader> cr3: "Don't do that" :P
[15:29] <fader> cr3: Seriously, didn't you just write some escaping code?
[15:30] <cr3> fader: currently, the values for definitions do not support the concept of a dictionary, ie key/value pairs such as filename/command
[15:31] <cr3> what if we introduce another type of definition, like: type: attachment; filename: foo; command; cat /foo
[15:31] <fader> Hey, I like that... it leaves flexibility for future expansion
[15:32] <cr3> fader: only type and filename would be required, command would be optional
[15:32] <cr3> furthermore, in order to link an attachment to one or more tests: tests: foo bar baz
[15:32] <fader> If you don't provide a command it just attaches the filename specified?
[15:32] <cr3> fader: right
[15:33] <fader> cr3: Hmm, I'm not sure if that's a good idea.  You have the same keyword performing two fairly different functions
[15:33] <fader> 1. grabbing a file, 2. specifying a filename for output of a command
[15:34] <cr3> fader: ok, so you'd have this then, where parts in square brackets are optional: type: attachment; name: foo; [filename: /tmp/foo;] [command: cat /tmp/foo;] [tests: foo bar baz;]
[15:34] <cr3> fader: filename and command would be mutually exclusive
[15:35] <fader> cr3: I like it.
[15:36] <cr3> I think I'm comfortable with that too. there is one caveat though: if tests are specified, this means that filename or command needs to be evaluated immediately when the test is finished, not at the end of running all tests
[15:37] <fader> Why is that?
[15:37] <cr3> so, it is possible that the same attachment definition will produce different attachment instances
[15:37] <cr3> fader: this was a problem raised by eeejay where mago overwrites the same log file for every test, or somesuch
[15:37] <fader> cr3: Oh.  That's ugly :(
[15:38] <cr3> fader: this is a valid concern though, an attachment should indeed attempt to capture the state of the system immediately after the test was run
[15:38] <fader> I won't argue with you... you're the one who has to code it ;)
[15:39] <cr3> fader: heh, it does indeed put additional burden on the coding, the result should be transparent to everyone else
[15:40] <fader> cr3: See, this is why everybody puts up with you working through weekends and national holidays.
[15:40] <fader> Wait, hang on, that doesn't make sense...
[15:48] <cr3> fader: I think I finally understood the purpose of national holidays: it's not so that I can have a holiday, it's so that other people can have a holiday from me.
[15:48] <fader> Hehe
[17:04] <fader> Is there a way to see what image an installed system was built from?  Something more specific than /etc/lsb-release?
[18:29] <cr3> eeejay: yo, got a minute to bounce ideas?
[19:42] <cr3> fader: what would think of changing the requires field in a test definition to explicit: packages and devices?
[19:43] <cr3> these would still take registry expressions so that I can do something like: packages: package.name == 'firefox' and int(package.version) > 2
[19:43] <fader> cr3: Only those two specifically?  What if I want to require e.g. processor scaling support to do a test?
[19:43] <fader> Or does that fall under 'devices'?
[19:44] <cr3> fader: is that information available in lshal or only in cpuinfo?
[19:44] <fader> cr3: Good question.  Let me check.
[19:45] <fader> Looks like it's in lshal:   info.capabilities = {'cpufreq_control'} (string list)
[19:45] <cr3> all the use cases I have so far relate to either packages and devices. so, that's why I'm thinking that from our experience it might make sense to be explicit about both
[19:45] <cr3> but requires is pretty powerful though, maybe I should keep it
[19:45] <fader> cr3: What about existence of a file?
[19:46] <cr3> the existence of a file is not necessarily contained in the registry
[19:47] <fader> cr3: Ah, so one could still express requirements for things that are not specifically contained within the registry then, right?
[19:47] <cr3> no, the other way around: one could not express requirements for things...
[19:48] <cr3> or, to avoid the double negative: one can only express requirements for things specifically contained within the registry
[19:48]  * fader tries to think of a use case where this would be a problem.
[19:48] <cr3> typically, when this has posed a problem, a new registry was created
[19:48] <fader> Heh, y'know, that's obviously the right way to handle it :)
[19:50] <fader> I'm just concerned that there might potentially be a case where you'd want some information that's not from the package manager or lshal et al.  But I can't think of a specific case.
[19:50] <cr3> coming back to my grid testing idea to take over the world, I just remembered that some job description languages support the concept of expressing requirements as a form of boolean query. so, I'm going to keep "requires"
[19:50] <cr3> fader: right, it's not because our current limited experience has not come up with a valid use case that there are none
[19:51] <fader> cr3: Yeah, that.
[19:51] <cr3> fader: however, I am tempted to remove "architectures" and "categories" which are basically just shorthands for requirements. those seem to just add noise to the test definition format
[19:51] <cr3> and I don't even recall architectures ever being used
[19:52] <fader> cr3: So you'd just formulate them like e.g. "requires: category=server"?
[19:52] <fader> I can imagine cases where architecture would be useful, especially with e.g. LPIA devices
[19:52] <cr3> fader: something that correlates to the registry in a boolean expression
[19:52] <cr3> so that would use "==" rather than "=" :)
[19:52] <fader> Hehe
[19:53] <cr3> dpkg.architecture == "i386"
[19:54] <cr3> there is a difference between the architecture of the system and the architecture of the packages installed on the system, dpkg.architecture is already provided in the registry to return the latter information
[19:54] <cr3> so for the rare times a test might care about the architecture, having to specify that boolean expression should not cause anyone carpel tunnel syndrome
[19:59] <fader> cr3: Cool, I like it.
[20:45] <cr3> fader: another question for you: do you think that timeout should be part of the test definition format or part of the command: timeout 10 some_command
[20:46] <fader> cr3: Hmm... I'm assuming it would be optional?
[20:49] <cr3> fader: it's optional, but does it belong as an attribute of the test definition or as the command itself
[20:49] <fader> cr3: Would Checkbox terminate the test if it runs over the timeout value?
[20:50] <cr3> fader: yes, but the timeout command could do the same
[20:50] <fader> cr3: It seems to make more sense to me at the test level.  If you have multiple commands that should each have a timeout, then you should either split them into separate tests or handle that inside your test itself IMO
[20:51] <cr3> the only potential reason to make it an attribute of the test definition is whether we care to formalize the difference between a failure because the test failed or because it timed out
[20:52] <cr3> fader: what do you mean by "handle that inside the test itself"?
[20:53] <fader> cr3: I mean that if the conditions of your test are complex enough that multiple different timeout values are required but you still can't split the test into multiple tests, you can't expect Checkbox to do it all for you :)
[20:53] <fader> cr3: Yeah, the difference between 'failed' and 'timed out' seems important to me
[20:54] <cr3> fader: when you say "the test", do you mean the command being called?
[20:54] <fader> cr3: Yes, the script that is being called
[20:54] <cr3> fader: timeout 10 the_script
[20:55] <cr3> fader: the "timeout" script can essentially do the same: first argument is the timeout in seconds, the rest is the command to run and it's arguments
[20:56] <fader> cr3: Right, either way works for simple cases.  It's only cases where you might want to say "this test will run 3 commands.  Let the first one run for 10s, the second for 30s, the third for 10s" that I am saying it should be handled inside the test script
[20:56] <fader> Which if the timeout is defined at the test definition level and is optional, everything is fine
[20:57] <cr3> fader: or that timeout command could actually relieve the script for that responsibility: timeout 10 first_one && timeout 30 second_one && timeout 10 third_one
[20:57] <cr3> but then, in that complex situation, you lose that granularity of 'failure' vs 'timed out'
[20:57] <fader> cr3: Good point.  But it doesn't seem to give the ability to track the difference between 'timed out' and 'failed'
[20:57] <fader> Heh
[20:58] <fader> It seems cleaner to me to do it at the test definition level, but that's just an aesthetic distinction
[20:59] <cr3> referring to my test-result-codes blog post, I'm starting to agree with the importance between 'failure' and 'timed out'. I think the latter might fall under the code UNRESOLVED or INCOMPLETE
[21:00] <cr3> I'm really glad I took the time to enumerate all those darn test result codes, good reference for myself :)
[21:00] <cr3> ok, I'm convinced, timeout stays
[21:01] <cr3> fader: for your example of three tests, they should be expressed with dependencies between each other so that if one times out, the others aren't run
[21:01] <fader> cr3: Ooh, slick
[21:01] <cr3> and they should use the timeout feature of the test definition to distinguish 'failure' from 'timed out'
[21:01] <fader> Man, you've thought about this stuff :)
[21:02] <cr3> I did some things right, but there's plenty I did wrong too :)
[21:02] <fader> And your blog posts are really in-depth.  It's good for me to read them... maybe I can learn something.
[21:02] <fader> :)
[21:03] <cr3> I've learned a lot myself in the process :)
[21:03] <cr3> yesterday, I was googling for some test related problem and my blog actually came up as the third result :)
[21:06] <fader> Hehe
[21:07] <fader> You'll end up writing a book.  Just wait.
[21:09] <cr3> fader: I already have a few people lined up for a book about my little humiliating stories :)
[21:09] <fader> cr3: Not *quite* what I had in mind, but that works too.
[21:09] <fader> You need to start including those on the blog as well!
[21:10] <cr3> fader: maybe I can combine both: Testing in underwear
[21:10] <fader> You know, you can tag the entries so only the testing related ones get syndicated on planet.u.c... :)
[21:11] <cr3> fader: I've made it a point that my blog and micro-blog posts will be strictly testing related, I didn't want to fall into inanities like where I'm scratching myself right now
[21:12] <cr3> fader: besides, you already know where I'm scratching most of the time...
[21:13] <fader> cr3: You don't know how often I lay awake at night wondering what you had for breakfast or how often you went to the bathroom today.  Enquiring twitterers want to know!
[21:14] <cr3> I think that crosses the fine line between twitterers and just twits
[21:23] <fader> cr3: I know we've been over this but I've confused myself.  Checkbox executes tests as root whether run interactively (e.g. checkbox-gtk) or not (e.g. kicked off after boot from certify-web) right?
[21:26] <fader> (I ask as some of the security qa-regression-test tests refuse to run as root and explicitly call sudo in the scripts, which will have to change if everything is run as root)
[21:26] <cr3> fader: checkbox-(gtk|cli) runs tests as the user unless overridden by a specific user in the test definition. checkbox-(compatibility|certification)* runs everything as root
[21:26] <cr3> fader: calling sudo in scripts run as the normal user won't work either
[21:27] <cr3> fader: if the script prompts, we're screwed. I need to create a bug to disable all interactivity possibly assumed by scripts
[21:27] <fader> cr3: It seems like the best way to handle this is to remove any prompts in the script, which means we may end up maintaining our own version of some tests :(
[21:27] <cr3> fader: or maybe they weren't written well in the first place...
[21:28] <fader> cr3: Heh, I'll let you have that fight with kees :)
[21:29] <cr3> tests simply shoved in a directory are probably not written properly in the first place. if the same tests were written within any test suite like checkbox, subunit, or whatever, these problems would've been caught early on
[21:29] <cr3> tests in a directory are scripts, not tests
[21:30] <cr3> it's not really a fight that I'm looking for, it's just that the sru team was probably under pressure to just get something done which implies some eventual migration process
[21:30] <cr3> if we can help with this migration process, I'm sure it will be much appreciated
[21:34] <fader> cr3: Right, I'm trying to migrate some of those myself and wanted to make sure I was on the right track
[21:35] <fader> It'll just be a question of if we can make the tests in checkbox the authoritative source for those tests
[21:39] <cr3> fader: it doesn't have to be though, any test suite could be integrated. however, checkbox is one of the rare ones which supports interactive testing in addition to automated testing, so that might be the deciding factor
[21:39] <cr3> the only problem is that the author is a real pain to deal with
[21:40] <fader> cr3: The author of checkbox you mean? :)
[21:40] <cr3> yeah, avoid him if possible
[21:40] <fader> He's not so bad... you just have to rough him up a little.
[21:41] <fader> But anyway, it seems like anything that refuses to run as root but explicitly calls sudo will need to be modified.  It's just a question of whether we can push those modifications upstream or if we have to maintain them
[21:42] <fader> And/or make our version the authoritative version and accept patches for other changes
[21:43] <sbeattie> fader: I don't have a problem merging them with upstream.
[21:43] <sbeattie> fader: tricky bit will be the tests for sudo itself.
[21:43] <fader> sbeattie: Yeah, there are some that are obviously ill-suited for this treatment.  I'm taking baby steps right now :)
[21:43] <sbeattie> fader: excellent. How can I help?
[21:44] <sbeattie> do you have work-in-progress stuffed anywhere?
[21:44] <fader> I'm also starting right now by purposefully ignoring any destructive tests (those which overwrite config files, etc.)
[21:45] <fader> sbeattie: Just my laptop right now.    I'll try to have something to point you at next week though.
[21:46] <fader> = was aiming for this week but that didn't happen :(
[21:46] <fader> s/=/I/
[21:46] <sbeattie> fader: alright, but I'm keenly interested in getting this going, so I don't mind looking at junk that needs to be thrown out.
[21:48] <sbeattie> (I briefly started on it at one point, but operator error prevented me from getting my tests noticed by checkbox)
[21:58] <cr3> interactive tests as for sudo perhaps could be wrapped in an (py)expect script to be fully automated
[21:58] <cr3> or, they could remain a manual test by asking the user to perform a series of steps
[22:00] <fader> cr3: I'd rather keep them automated and just remove the requirement for sudo for the ones that will work when run as root
[22:01] <fader> sbeattie: Maybe we can come to an arrangement where you can beat on the test scripts and I can work on the suite definitions and make everything run from Checkbox :)
[22:01] <fader> (Or more likely annoy cr3 until he tells me what I'm doing wrong, but whatever.)
[22:32] <fader> sbeattie: I cleaned up what I've been playing with a bit so you can at least see what I'm doing, but it will still make the baby cr3 cry so don't show it to him
[22:32] <fader> sbeattie: https://code.launchpad.net/~fader/checkbox-certification/security-tests
[22:32] <fader> This is just the glibc test; I've also poked a bit at the gcc test but I'd rather hold onto it for a day or two
[22:33] <fader> (As it's in worse shape and doesn't run right at all)
[22:34] <fader> NB that you'll need build-essential installed to run the test.  That's not in a 'requires' field for the suite yet.  (Another reason not to tell cr3)
[22:54] <sbeattie> fader: cool, thanks.
[22:55] <fader> sbeattie: I'll be interested to hear if it works for you.  :)
[22:56] <fader> You can look at ~/.checkbox/submission.xml when it prompts you to enter a secure ID, which you probably don't have
[22:56] <fader> A quick and dirty way to see if the glibc script ran is to look for /tmp/glibc-security, which I haven't bothered to clean up at the end of the script yet :(
[23:00] <fader> Okay, time to find food and be interactive in meatspace for a bit... sniff you jerks later :)


[07:57] <ppisati> moin
[09:24]  * apw struggles on with pants internet
[09:24]  * apw struggles on with pants internet
[09:25]  * smb struggles with pant sleepiness
[09:26] <RAOF> Better than pantsless internet!
[09:27] <smb> RAOF, As long as I don't have to see that. :-)
[09:28] <cking> smb 96433f6ee49032d7a8bda76de2b05cfde2914354
[09:40]  * cking offers apw some of his spare internet connection capacity
[09:40] <apw> RAOF, i would settle for using it pantless if it went faster
[09:50] <ppisati> brb
[10:26]  * henrix reboots
[10:41] <jpds> Hey, can someone tell me if linux-image-lts-quantal / so stops being updated for precise after the next LTS is released?
[10:43] <apw> jpds, i believe that is the plan, people there will be updated to the TT kernel on PP and can stay there
[10:43] <jpds> apw: So there'll be a linux-image-lts-t kernel for precise?
[10:44] <apw> jpds, that is my understanding indeed, that we offer an 14.04 kernel as the hwe kernel on 12.04, and the other lts kernels will roll to that one
[10:45] <jpds> apw: What about people on precise, that want to enable hardware that's enabled... after T?
[10:57] <apw> jpds, they need to be on T
[12:14] <BenC> rtg, apw: You're going to want commit 829a337c48b835c322e625e390b0bb07769e913b from my ppc tree
[12:14] <BenC> UBUNTU: SAUCE: 8250: Wrap ACPI calls with ifdefs for non-ACPI systems
[12:15] <BenC> All the commits you cherry picked trashed that driver for anything non-x86
[12:31] <BenC> infinity: Fixed linux-ppc is waiting to build
[12:48] <rtg> BenC, I had some trouble getting that to build on armhf (so I turned off 8250 for armhf IIRC). Have you sent that patch upstream yet ?
[12:48] <BenC> rtg: No, I'm hoping the person that keeps cherry picking for stable kernels will do it for me eventually :)
[12:49] <rtg> I guess it fell off my todo list.
[13:05] <rtg> BenC, see 053fac36b1d9f76adde96a2f731965aaab3c632b in Linus repo. I'll see about getting that fixed in Raring
[13:13]  * henrix -> lunch
[13:37] <apw> rtg, thanks
[13:37] <rtg> apw, uh, for what ?
[13:38] <apw> handling BenC's issue
[13:38] <rtg> ah, no problem
[13:38] <BenC> rtg: that fix does it…I'll disappear my commit from ppc branch next time I sync to ubuntu/master
[13:38] <rtg> build testing armhf right now
[14:01] <apw> rtg, just pushed a bit more fixing for the linaro -> nexus7 rename
[14:01] <rtg> apw, oh, did I push that without testing ? I got distracted I think before it was finished
[14:02] <tjaalton> hum, ideas why i915.ko built from a dkms package is not loaded on haswell, but i915_hsw.ko
[14:02] <apw> rtg no i think what you pushed would build fine, it is reconfiguration and the like which needed more tweaks
[14:02] <rtg> apw, cool, thanks.
[14:02] <rtg> tjaalton, PCI IDs ?
[14:02] <apw> tjaalton, well i think it would load both and whichever binds get sit ?
[14:02] <apw> gets the device
[14:03] <tjaalton> hmm right
[14:03] <apw> tjaalton, also where is i915_hsw.ko, is that in updates/ or just in the normal place
[14:03] <tjaalton> normal place
[14:03] <apw> and the dkms where is that, updates ?
[14:03] <tjaalton> yeah I see in dmesg that it's probably trying to load both
[14:03] <tjaalton> yep
[14:04] <apw> as i think i expect updates to be loaded first, but probe is async i think
[14:04] <tjaalton> lspci shows i915 being used, but lsmod shows i915_hsw
[14:04] <tjaalton> so I think lspci lies
[14:04] <apw> so ... perhaps the dkms package should include an /etc/modprobe.d/stop-haswell.conf which blacklists i915_hsw.ko
[14:04] <tjaalton> yep
[14:05] <tjaalton> probably the cleanest way out of this
[14:05] <apw> but that is a bit pants
[14:05] <tjaalton> :)
[14:06] <tjaalton> rtg: the dkms version supports all, _hsw only haswell. so the dkms package works for !HSW. anyway, blacklist it is then
[14:07] <rtg> tjaalton, ack. Is this going to be your preferred solution for Haswell platforms ?
[14:08] <tjaalton> rtg: until i915_hsw is rebased, but the dkms is needed right now
[14:09] <rtg> tjaalton, so you're still gonna send a pull request for quantal eventually ?
[14:09] <tjaalton> yeah I hope so :)
[14:09] <rtg> k
[14:09] <tjaalton> been fighting fires so didn't get to it yet
[14:11] <rtg> tjaalton, my kid fights fires in the summer. it pays pretty well.
[14:12] <tjaalton> hehe
[14:37] <seiflotfy> guys
[14:38] <seiflotfy> centrino 6300 on raring has a big issue with disconnecting then becoming unavailable
[14:39]  * ogasawara back in 20
[14:48] <jsalisbury> bjf, fyi, bug bots are broken again on cranberry due to an upgrade :-/
[14:48] <bjf> jsalisbury, that's special
[15:12] <ogra_> ppisati, so the plan is to leave the panda desktops as is and dont touch thzem at all
[15:30] <ppisati> ogra_: then i'll sync up R/omap4 wrt to Q/omap4
[15:30] <ppisati> rtg: ^
[15:30] <rtg> ppisati, ack
[15:30] <ogra_> yep
[15:30] <ogra_> and then let it rot :)
[15:31] <rtg> ppisati, ogra_: if omap4 is now only for the builders, then why bother with an omap4 in Raring ?
[15:33] <ogra_> rtg, we want the community to still have builder options ... and (worse) still want to have them for dogfooding desktop stuff on arm
[15:33] <ogra_> i would have gone with server images from mainline kernels ...
[15:33] <rtg> ogra_, can we still do that with the device tree kernel in raring ? I'd still like to rename it to something more generic.
[15:34] <ppisati> ogra_: +1
[15:34] <ppisati> rtg: doing it now
[15:34] <ppisati> rtg: s/omap/multiarm/g
[15:34] <ogra_> rtg, i dont care what you guys do as long as pvr still works for desktop
[15:35] <ogra_> well, s/i/they/ (whoever) :)
[15:42] <rtg> ogra_, can you find the bit of build magic for the N4 kernel ? there has to be a bit more to it then just using arch/arm/configs/mako_defconfig
[15:43] <ogra_> i have never built any official phablet image ... only ported to my own devices and they definitely use a cm_*_defconfig
[15:43] <ogra_> but i dont see a cm_mako_defconfig in the tree
[15:44] <rtg> cm_x2xx_defconfig  cm_x300_defconfig
[15:44] <ogra_> yep i see them
[15:45] <ogra_> kernel/lge/mako/AndroidKernel.mk ...
[15:45] <rtg> ogra_, looking at the git repo implies that mako_defconfig is in use 'cause that where some config options have been changed for the phablet image
[15:47] <ogra_> did you try running a fresh repo sync ?
[15:49]  * ogra_ doesnt really see where KERNEL_DEFCONFIG gets defined
[15:51] <ogra_> aha device/lge/mako/BoardConfig.mk
[15:51] <ogra_> yeah its mako_defconfig, you are right
[15:53] <ogra_> rtg, so i suspect you have to mimic whatever kernel/lge/mako/AndroidKernel.mk does to get a proper config
[15:54] <ogra_> there seems to be a bunch of perl touching it
[15:55] <rtg> ogra_, that lge directory does not exist in git://phablet.ubuntu.com/CyanogenMod/lge-kernel-mako.git
[15:58] <ogra_> weird, must be something repo does merge then
[15:59] <ogra_> likely from CyanogenMod/android_device_lge_mako
[15:59] <ogra_> thats whats defined in the top level manifest.xml here
[16:00] <ogra_> http://paste.ubuntu.com/5631532/
[16:00] <ogra_> thats the AndroidKernel.mk in my tree
[16:01] <rtg> ogra_, cool, thanks
[16:01] <ogra_> line 14 and 15 look like they touch it
[17:13] <rtg> apw, git://kernel.ubuntu.com/ubuntu/ubuntu-nexus4.git - can you give me a hand and tell me why  config-check wants to run debian.master/config/enforce ? The N7 script is identical, yet I don't have that failure.
[17:16] <rtg> apw, oh, well actually now I _do_ have the same failure. its part of your patch 'UBUNTU: [packaging] Rename from linaro to nexus7 -- part 2'
[17:29]  * rtg -> lunch
[17:31] <ppisati> rtg: could you refrain from touching R/master-next abi today?
[17:34]  * ppisati -> workout
[17:34] <ppisati> later
[18:02] <cking> bah, ESTA and visas. what a pain
[18:03] <ogra_> and visas ?
[18:03] <ogra_> do you need both in the UK ?
[18:11] <rtg> ppisati, why just the abi ?
[18:57]  * henrix -> EOD
[20:06]  * rtg -> EOD
[20:35] <jbaron> q: i'm trying to build a kernel out of the git tree, and have noticed that a number of the firmware files are dropped -
[20:36] <jbaron> is there an easy way to figure out what I need to pull in from linux-firmware?


[09:15] <jink> Why doesn't do-release-upgrade offer me 20.04 LTS?  I'm on 18.04.5 LTS and the system is fully up-to-date.
[09:18] <lotuspsychje> jink: the upgrade path sint open yet due some bugs the devs working on
[09:18] <lotuspsychje> jink: keep an eye on: https://discourse.ubuntu.com/t/focal-fossa-20-04-1-lts-point-release-status-tracking/17604
[09:19] <jink> Bedankt weer. ;)
[09:19] <lotuspsychje> np ; ) we assume it will get fixed soon
[09:19] <jink> 👍
[14:19] <KaiH> Hi, which tool can you recommend to use update servers? I use usually aptitude, but heard it's not really good for Ubuntu.
[15:08] <jayjo_> Is using KVM, libvirt,and qemu manually a suitable replacement for production VMs on ubuntu server? Compared to something like proxmox ? I've been trying to virtualize pfsense on a server in a way to that will reboot automatically. I've been able to test with my desktop through other environments, but i'm having a harder time finding non-interactive solutions
[15:12] <cpaelzer> jayjo_: it is perfectly fine to be used just through libvirt/qemu with CLI+XML files
[15:12] <cpaelzer> the amoutn of management stacks on top that you want depends on your preferences
[15:13] <cpaelzer> I mean you can go up to full openstack which underneath still will use the same qemu/libvirt but certainly is quite dfferent :-)
[15:49] <rbasak> jayjo_: in what sense are you considerned that the stack you propose isn't suitable for production VMs?
[15:49] <rbasak> jayjo_: in what sense are you *concerned* that the stack you propose isn't suitable for production VMs?
[15:55] <jayjo_> rbasak: I'm just in the weeds getting things functional. I'm trying to document the init procedure, or get it to an 'always-restart' point
[15:55] <jayjo_> I've used virt-manager, i"m trying to port that method that I had working on a desktop to the ubuntu-server
[15:59] <jayjo_> RHEL uses qemu/kvm as well. Will their resources have diverged from debian/ubuntu? (Just interested in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/index - is there an ubuntu equivalent?)
[16:07] <cpaelzer> jayjo_: every distribution has diverged from upstream a bit as on any package that is so heavily used - but never the less they are still (in terms of docs) used mostly the same
[16:07] <cpaelzer> jayjo_: you can look at the virtualization chapters of https://ubuntu.com/server/docs
[16:08] <cpaelzer> it is not re-explaining every bit of the manpages to make more pages :-), but it is a start
[16:13] <jayjo_> cpaelzer: thanks for your feedback - I appreciate the help
[17:18] <rbasak> cpaelzer: how do you want to triage https://bugs.launchpad.net/qemu/+bug/1894804 ?
[17:24] <rbasak> ahasenack: you triaged https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1897153 previously and seem to understand the reported problem, but there aren't steps to reproduce given and I don't follow. Mind taking a look please? Is the issue Invalid now that the reporter has confirmed back?
[17:24] <ahasenack> rbasak: yes, local config problem
[17:25] <ahasenack> rbasak: not to say we can't improve it
[17:25] <ahasenack> rbasak: he had a working autofs config, then for unknown reasons installed sssd with its own autofs map, but without configuring it, and that broke his local autofs setup
[17:25] <ahasenack> rbasak: he doesn't know why he had sssd installed
[17:26] <ahasenack> I left it as is because he said we would try an upgrade or fresh install of his apps, and see if something pulled in sssd when it shouldn't
[17:32] <rbasak> ahasenack: maybe Incomplete then, pending his response? Because there's nothing actionable for us to do unless he gets back to us, is there?
[17:33] <ahasenack> well, we could investigate if there is something to be done regarding the interaction of an unconfigured sssd and an existing autofs setup
[17:33] <rbasak> OK thanks. I'll note that then, mark Low and add to the backlog


[03:00] <bigjools> jtv: what else did you need to know?
[03:01] <jtv> What exactly it is we're not doing.  Multiple worker packages?
[03:02] <bigjools> jtv: right, single worker per rack
[03:02] <jtv> Regardless of arch?  Good.
[03:02] <bigjools> indeed
[03:02] <bigjools> it's a little mad to have multiple ones
[03:03] <bigjools> but I suspect that thought arose due to intimate lack of knowledge of our new architecture
[03:04] <jtv> Nicely put
[03:05] <bigjools> s/intimate lack of/lack of intimate/
[03:06] <jtv> Shame.  You had a nice pattern going there.
[03:07] <jtv> Oh, about the anonymous-metadata issue: my preference is to have a config setting (dev/demo, not production) that would open up a mirror to the metadata tree keyed by MAC address: /metadata-by-mac/<version>/<mac>/…
[03:08] <jtv> The way I see it, the MAC address is about the most reliable knowledge the node has at the beginning of the provisioning stage, and conversely MAAS knows all its MAC addresses, so it makes a good key.
[03:10] <bigjools> jtv: I asked Francis for confirmation on this bug
[03:11] <bigjools> ie. why was it escalated
[03:11] <bigjools> and we'll fix that problem now rather than one that doesn't exist (yet)
[03:13] <jtv> What is the existing problem and what is the non-existing problem?
[03:17] <bigjools> exactly what I want to clarify
[03:19] <jtv> So… put this one on ice until we have an answer?  Or start doing work that'll be needed either way?
[03:20] <jtv> Actually, one thing that needs to be done either way is proper coffee.
[03:21] <bigjools> jtv: if you can see common work, by all means do it
[03:22] <jtv> but
[03:25] <jtv> no but?
[08:07] <allenap> Morning.
[08:08] <jtv> Hi there allenap
[08:09] <allenap> \o jtv
[13:54] <cheez0r> criminy, on a freshly loaded MaaS server node I can't even get cobbler system dumpvars to run
[13:56] <cheez0r> "cannot marshal None unless allow_none is enabled"
[14:52] <allenap> Daviey: Do you have experience with iPXE? James Page was saying that it's Good Stuff.
[14:53] <Daviey> it is very good stuff.
[14:53] <Daviey> And i do.
[14:54] <Daviey> allenap: The 'maas without controlling infrastructure' story, was initially going to be ipxe based.
[14:55] <allenap> Daviey: I'm not familiar with that story, unless I know it under a different name.
[14:58] <Daviey> allenap: user doesn't have control over dhcp
[14:59] <allenap> Daviey: Ah, right. Is there any reason to not use ipxe for all scenarios?
[15:00] <Daviey> allenap: doesn't work on arm
[15:00] <allenap> Daviey: Blast.
[15:06] <Daviey> it would make me very happy if it did
[15:06] <Daviey> would provide a nice abstraction
[15:06] <Daviey> and support iscsi out of the box
[18:12] <Aaton> so anyone have a good write up for setting up maas in a virtualbox test env.  Setting up the network right is the main thing I'm looking for
[18:31] <robbiew> Aaton: marcoceppi might
[18:32] <marcoceppi> Aaton: try this: http://marcoceppi.com/2012/05/juju-maas-virtualbox/ it's not a perfect experience, but you can get MaaS running
[18:56] <hazmat> marcoceppi, nice!
[20:12] <Aaton> thanks!
[20:30] <marcoceppi> Aaton: it's kind of a chronicling, so I'd recommend reading the whole thing through before starting, half-way through I got smart and figured a bunch of things out. Wiki page for VirtualBox should be done this weekend
[22:25] <Aaton> marcoceppi: yea, just read it over. so did you create a second interface. I want to connect to the bridged interface but boot the other servers inside virtualbox. I don't have control of the dhcp server.
[22:30] <marcoceppi> Aaton: I didn't create a second interface, I used a VM to put the MaaS main node on
[22:30] <marcoceppi> If you install the main node as a VM, then install maas-dhcp ( didn't have access to my offices dhcp server, but it worked anyways ) it *should* work
[22:39] <Aaton> marcoceppi: I'll be giving that a try