[05:13] <saidinesh5> brr.. build/core/product_config.mk:227: *** _nic.PRODUCTS.[[device/xiaomi/cancro/cancro.mk]]: "device/qcom/common/Android.mk" does not exist.  Stop.
[05:13] <saidinesh5> can anyone tell me where should i be looking at for that error message for lunch ?
[07:43] <brunch875> guise guise! On rc-proposed, after update screen doesn't lock anymore
[07:43] <brunch875> and manually locking it will make screen turn black but not shut down
[07:47] <ogra> brunch875, see the second paragraph in https://lists.launchpad.net/ubuntu-phone/msg21572.html
[07:48] <brunch875> thanks oli ☺
[07:48] <ogra> (not sure if it is related though, ask sil2100 )
[07:48] <ogra> (but it sounds likely that it could)
[07:50] <brunch875> it also seems that the brightness slider doesn't do anything
[07:50] <sil2100> Yeah, actually powerd should be used back again, so I would expect less problems
[07:50] <brunch875> and the "automatic" toggle is gone
[07:50] <sil2100> brunch875: do you have the latest update?
[07:50] <brunch875> on rc-proposed, yes
[07:50] <sil2100> hmmm
[07:51] <ogra> wasnt there also a new mir ?
[07:51] <ogra> (probably the combo of rolling back one but landing the other causes this)
[07:52] <sil2100> brunch875: could you check what version of powerd is installed? (and if it's installed?(
[07:52] <sil2100> ))
[07:52] <brunch875> sure, how do I do that?
[07:53] <sil2100> brunch875: get to the terminal (either through adb, ssh or in the terminal application) and type in apt-cache policy powerd
[07:53] <brunch875> 1 se
[07:53] <sil2100> Thanks ;)
[07:54] <sil2100> ogra: I'm worried that the removal of repowerd was not enough to get rid of it from existing devices...
[07:54] <ogra> yeah, that could be an issue too
[07:55] <sil2100> Since we never really had to revert a new package before
[07:55] <brunch875> Installed and candidate: 0.16+15.04.2015219-0ubuntu3
[07:55] <brunch875> 20150219*
[07:55] <sil2100> hm, ok, looks fine
[07:56] <sil2100> brunch875: could you also try apt-cache policy repowerd
[07:56] <sil2100> ?
[07:56] <sil2100> Just to make sure it's really gone
[07:56] <sil2100> uh oh
[07:56] <sil2100> No wait, this is really an old version
[07:56] <raph_ael> Hi, I'm running OTA 11, image 20160524.1 on a Nexus 4 and it seems to be killing the battery more than precedents images
[07:56] <ogra> heh, i was about to say ...
[07:57] <sil2100> WTH
[07:57]  * sil2100 looks at the manifest
[07:57] <ogra> did you get the archive version instead of the overlay ?
[07:57] <brunch8751> sorry, internet died on me
[07:58] <brunch8751> sil2100: I got that output from apt-cache
[07:58] <sil2100> ogra: holy shit it the images DO HAVE an outdated powerd, no idea why
[07:58] <sil2100> Let me check the image build logs, but this is stupid
[07:59] <sil2100> brunch8751: obviously all the issues are caused by the image build pulling in some archaic version of powerd - the one the latest rc-proposed images have is from 2015!
[07:59] <sil2100> ogra: I think it's related to me removing repowerd from the overlay ;(
[07:59] <brunch8751> :D
[08:00] <sil2100> ogra: I think because repowerd was offering a virtual package of powerd to deprecate it, now that it's gone it also cannot install powerd from the overlay
[08:00] <sil2100> Need to consult Colin
[08:01] <sil2100> brunch8751: ok, so we'll try to resolve this issue ASAP and rebuild an image
[08:01] <brunch8751> goodluck and godspeed!
[09:18] <sil2100> brunch875: hey! We 'fixed' the problem possibly, building a new image now
[09:18] <sil2100> This should fix it hopefully
[09:20] <aquarius_> tvoss, ping about fingerprint things
[09:23] <aquarius_> tvoss, specifically this. When you enrol a fingerprint, do you enrol it on the _fingerprint reader_, or the _device_? That is, when the OS asks the fingerprint reader "what did they just scan", does it get told "here is the detail of the fingerprint that got scanned: <blah>" and it's the OS's job to work out who that is, or does the OS get told "that was enrolled fingerprint 3" and that's it?
[09:24] <brunch875> sil2100: Awesome! I'll keep an eye on the updater
[09:41] <tvoss> aquarius_, the actual fingerprint data is not accessible to the os (neither kernel nor user space) at all, the actual data is handled by a trustlet running in the mobicore TEE
[09:42] <tvoss> aquarius_, we only get an opaque, numerical handle
[09:42] <aquarius_> tvoss, ah, that's what I thought (thanks to mzanetti advising me on that).
[09:42] <aquarius_> tvoss, is trustzone available to Ubuntu phones? That is: can I store keys in the TPM?
[09:43] <tvoss> aquarius_, during enrollment, we receive information which areas have been sufficiently covered
[09:43] <tvoss> aquarius_, not yet, we don't expose the hw key store
[09:43] <aquarius_> tvoss, aha, OK. (Is that because it's just not done yet, or is there an actual restriction preventing it from happening?)
[09:44] <tvoss> aquarius_, just not done, yet. there is an open topic about establishing a chain of trust as (depending on the implementation) the hw key store might need a signed boot loader
[09:45] <aquarius_> tvoss, that makes sense, yeah.
[09:45] <aquarius_> One other question: NFC support is doubtless somewhere on the roadmap. Do you have a sense of whether it's close or not, and whether it's not done because it's difficult or not done just because it hasn't made it to priority 1 yet?
[09:46] <tvoss> aquarius_, question of priority, also: we would need a service multiplexing access to the actual hw
[09:46] <aquarius_> ah. So there's quite a bit of work to be done before NFC support arrives.
[09:46] <tvoss> aquarius_, likely, yes
[09:46] <tvoss> aquarius_, as usual, help is very welcome :)
[09:47] <aquarius_> OK, that's useful; thank you, pal!
[09:47] <tvoss> sure
[09:47] <aquarius_> help is indeed welcome. I'll let you know about that.
[09:57] <aquarius_> tvoss, oh, one other thing :) Full disk encryption? :)
[09:57] <tvoss> aquarius_, help welcome :)
[09:58] <aquarius_> ha! I knew that bit :) Was more thinking: has any thought gone into that already?
[09:59] <tvoss> aquarius_, quite some, yes. it mainly requires adjusting the auto-login approach and make user authentication/verification a part of the early boot process
[09:59] <aquarius_> yeah. I figured there would already be some thinking around this!
[11:00] <UExit> Hi
[11:23] <brunch875> Know something I'd love? To use my utouch as a "wireless trackpad" + keyboard for my desktop/laptop
[11:23] <brunch875> could be great for watching youtube or whatever
[12:03] <Miyagi_> hi, porting link do not exist.
[12:03] <Miyagi_> i have a qusetion, is it, and if how, do i chroot to a ubuntu image to set up some software before flashing the image to the phone.
[12:04] <Miyagi_> like i wanted to install ecryptfs before flashing the image to the phones
[12:17] <ogra> Miyagi_, why do you want to do that before flashing (whats the benefit of that) ?
[12:18] <Miyagi_> i want to be able to deploy a image to 100 phones
[12:18] <Miyagi_> with the ecryptfs tools
[12:18] <Miyagi_> or how to i deploy things like this
[12:18] <Miyagi_> any manpage of that?
[12:19] <ogra> nope, i dont think so, and the rootfs isnt designed to be modified ... it would break with a subsequent OTA update
[12:19] <Miyagi_> i basicly want to set up some custom tools on our phones, then flash them all with those tools
[12:20] <ogra> you could supply extra bits with a custom tarball, but i dont think that is well documented either (and i dont think you could use debian packages with it)
[12:20] <Miyagi_> with adb shell
[12:20] <ogra> (it would have to be click pacages)
[12:20] <Miyagi_> apt-get install ecryptfs
[12:20] <Miyagi_> it works on the phone, i just need a image to conatin all libs
[12:20] <ogra> wont work without making the rootfs writable ...
[12:20] <Miyagi_> before flash
[12:21] <ogra> which is very likely breaking in a future update
[12:21] <Miyagi_> maybe
[12:21] <Miyagi_> but i just need to do it at the moment
[12:21] <ogra> and makes you leave any supported upgrade paths
[12:21] <Miyagi_> is it possible
[12:21] <ogra> sure, if you dont mind your users to end up with non-booting phones at some point (or some such)
[12:22] <ogra> the OTA deltas require that the rootfs remains unchanged
[12:22] <Miyagi_> but i have tested it, install thing, there is no erro in rebootin
[12:22] <Miyagi_> i just need the ecryptfs be on a flshable image
[12:22] <ogra> then wait til encryption is supported :)
[12:23] <Miyagi_> i cant
[12:23] <ogra> if you do it for actual end users ... the only answer is *don't*
[12:23] <ogra> if you do it for tinkering on a device you re-flash anyway, go ahead ... but i promise you it will break at some OTA
[12:24] <Miyagi_> let me try
[12:24] <Miyagi_> but how
[12:24] <ogra> you cant use apt and OTA at the same time
[12:24] <ogra> and apt upgrades are not supported at all
[12:24] <ogra> so if you chage the content of the rootfs it *will* eventuall break
[12:24] <Miyagi_> i not need any upgrades
[12:25] <Miyagi_> i need a cusom software easy deployed to 100 phones
[12:25] <ogra> so you dont want security fixes and leave your users with open security hiles ?
[12:25] <ogra> *holes
[12:25] <Miyagi_> not right now, no
[12:25] <ogra> well, flash it ... make it writable, run a script via adb
[12:26] <ogra> but dont come askin for help here if your 100 users cant boot their phones anymore
[12:26] <ogra> (which will likely happen)
[12:26] <Miyagi_> :) no, i have tried it - it will boot
[12:26] <ogra> apt support is for tinkering when you develop the system and are prepared to wipe the phone regulary
[12:27] <Miyagi_> but is there not any other mass tools to fix it, adb shell on every single phone sees to hard
[12:27] <ogra> it *will* break as soon as a fil changes that you changed to
[12:27] <Miyagi_> and i not want adb enabled later
[12:27] <ogra> which might not be the nex, but the overnext OTA
[12:27] <ogra> do not give such phones to endusers
[12:28] <ogra> the system is not designed to use apt
[12:28] <Miyagi_> no, i will not give it to end users, i just want to know how i can do a massproduction of cusom software i need
[12:28] <ogra> you engage with canonical and have them create a custom tarball for you ... aftter they packaged your desired software in a click package
[12:28] <Miyagi_> if i need, lets say another software
[12:29] <Miyagi_> it must be able to add some libs
[12:29] <ogra> or you find out how to create a custom tarball yourself and create a click for ecryptfs (though i doubt in this case that is helpful)
[12:29] <Miyagi_> or when do they launch encryption, do you know?
[12:29] <Miyagi_> maybe i can wait
[12:29] <ogra> i guess afterthe switch to snappy
[12:30] <ogra> which will be after th switch to a xenial base
[12:30] <Miyagi_> i use xenial right now
[12:30] <ogra> (the xenia thing is being worked on currently ... but that will still take quite a while)
[12:30] <ogra> xenial isnt for users yet
[12:30] <ogra> completely unsupported and likely to break
[12:30] <Miyagi_> no, i not care about who it is for
[12:30] <Miyagi_> i develop
[12:31] <Miyagi_> and nned to know how to massproduce things in the future
[12:31] <ogra> the actual system developemtn happens in the rc-proposed channel
[12:31] <tsimonq2> ogra: Yakkety? ;)
[12:31] <ogra> not in xenial
[12:31] <Miyagi_> but, i read half of internet by now
[12:31] <Miyagi_> cant find any usefull info abut my problem
[12:31] <ogra> there is no useful solution to your problam
[12:31] <ogra> beyond including ecryptfs in the default rootfs
[12:32] <Miyagi_> so i am fucked
[12:32] <Miyagi_> to say it in a few words
[12:32] <ogra> i it is just for developers, use a script you run after flashing
[12:32] <tsimonq2> !language | Miyagi_
[12:32] <ogra> (adb push it ... run it via adb ... have it remove itself at the end and disable adb)
[12:32] <Miyagi_> sorry....
[12:33] <Miyagi_> ok, thi shelped me a lot anyway
[12:33] <ogra> but really, dontuse xenial
[12:33] <ogra> it is far from being ready
[12:33] <Miyagi_> not need to try more, tested a few days allready
[12:34] <Miyagi_> where can i see release info
[12:34] <ogra> (it will sonn change all bits to systemd ... it will most likely break during that to the point of being unbootable for a few updates)
[12:34] <Miyagi_> o no not systemd
[12:34] <ogra> its the default now
[12:35] <Miyagi_> that sucks
[12:35] <ogra> no way around it
[12:35] <ogra> why do you care ?
[12:35] <Miyagi_> since i need to modify it
[12:35]  * ogra doesnt think it matters much what /sbin/init you use ... effectively systemd doesnt really differ in that bit)
[12:35] <Miyagi_> and there are more easy ways that systemd
[12:36] <ogra> there are many issues with systemd ... /sbin/init surely isnt one ...
[12:37] <Miyagi_> i ust thank you for your support
[12:37] <Miyagi_> m..
[12:37] <ogra> (i agree about the systemd tree swallowing the whole pumbing layer is an awful idea ... but we're really only talking about init here ... )
[12:37] <Miyagi_> it saved me a lot of hours from now
[12:38] <ogra> oh, also note that none of the C++ apps in the store will work in xenial ... there was an incompatible ABI change ...
[12:40] <Miyagi_> so
[12:40] <Miyagi_> channel
[12:40] <Miyagi_> ubuntu-touch/stable/bq-aquaris.en
[12:40] <Miyagi_> for me
[12:40] <Miyagi_> or?
[12:52] <ogra> Miyagi_, or rc-proposed if you want to be a bit more on the edge
[12:53] <Miyagi_> edge, wasn't xenial that ?
[12:53] <Miyagi_> :)
[12:55] <Miyagi_> then maybe you know another thing. how can i map screenlock password to a stdin
[12:55] <Miyagi_> screenlockpasswrod then
[12:55] <Miyagi_> run a script on the phone like ./sctipy $1
[12:55] <Miyagi_> and $1 is as you see passwd
[13:02] <dobey> running xenial on a phone is beyond the edge.
[13:05] <brunch875> sill2100 it's all good now, clap clap ☺
[13:43] <Miyagi_> anyway
[13:43] <Miyagi_> i solved the problem with custom apps installed via apt-get och build from source
[13:44] <Miyagi_> install build essentials on a phone, build from source the tools you need in a custom folder, add that custom folder when flashing, then you have all libs you need for the ap to run
[13:45] <Miyagi_> then there is a clean phone with a flder with libs and other siftware
[13:45] <Miyagi_> it works, maybe it is not the absolute best way
[13:45] <Miyagi_> i now run stable dist in the phone with the software i needed
[13:49] <dobey> oh so you broke your phone, ok :)
[13:50] <dobey> what software is it that you "need" ?
[13:51] <dobey> oh you're trying to make a custom image with ecryptfs?
[13:51] <Miyagi_> yes
[13:53] <ogra> well, it will work if you never upgrade
[13:53] <dobey> well if you're setting up your own system-image server, and forking ubuntu to do that, you can grab the preinstalled.tar.gz, unpack it, install what you need in it, clean the apt-cache and extra junk that was created and not needed on a phone, and repack the tarball, then use that for your custom images, instead of the official preinstalled.tar.gz
[13:53] <ogra> oh, indeed
[13:53] <dobey> but you are creating a fork of ubuntu at this point, either way you do it, so might as well do it in a more manageable way :)
[13:53]  * ogra didnt think of the possibility to run your own s-i server :)
[13:54] <Miyagi_> then help me in the right direction
[13:55] <Miyagi_> i need t ofork it, and i would like to do it in the best possible way
[13:56] <Miyagi_> but
[13:56] <Miyagi_> is there not any better way to install
[13:56] <Miyagi_> can i chroot into a image and do the instalation from my laptop
[13:57] <dobey> if you need encrypted ubuntu phones, the best way is "wait for it to be implmeenmted properly"
[13:57] <ogra> right
[13:57] <ogra> thats what i sai hours ago :)
[13:57] <ogra> *said
[13:57] <ogra> but that will likely only happen after the switch to a snappy base
[13:59] <dobey> well, i suppose soemthing could be done to enable encrypted home only, before then, but i think the "best way" for that would probably be "commercial support contract"
[14:01] <dobey> a full set of requirements well beyond "just want encrypted $HOME" would be a good start, ie, what UI is needed, where, and what system integration work would be needed, etc...
[14:01] <Miyagi_> sometimes, you just cant wait
[14:01] <ogra> the prob with full encryption is that you end up with a gigantic initrd ... not sure that would even work with the current boot partition szes we have defined
[14:02] <Miyagi_> i just need home or another dir
[14:02] <ogra> encrypted home shouldnt be to hard but needs login manager integration and such
[14:02] <Miyagi_> but i need it
[14:02] <ogra> so likely a good bunch of patching
[14:02] <Miyagi_> end encryptfs
[14:03] <ogra> (and indeed integration of the crypto bits in the rootfs)
[14:03] <Miyagi_> but
[14:03] <Miyagi_> i fixed a temp working solution
[14:04] <ogra> though i wonder how safe a 4 digit passphrase can actually be and if it is worth the effort :)
[14:05] <dobey> well, it's safe enough
[14:05] <ogra> if your door lock can be opened with a paperclip it doesnt elp to have a steel door
[14:06] <dobey> ogra: steel doors are illegal anyway
[14:06] <ogra> lol
[14:07] <dobey> fire code is the backdoor to the encryption of your home
[14:08] <ogra> and likewise, if the bootloader is unlocked and your encryption only lives in a subdir of an unencrypted partition, it is easy to just grab the content and run scripts on it to decrypt
[14:08] <dobey> ogra: or if your steel door weighs 3 tons, a paperclip being able to pick a keyhole on it probably sin't too bad either :)
[14:09] <ogra> so doing home encryption in the current setup just mimics false security in the end imho
[14:10] <dobey> eh, it's all false security anyway
[14:10] <Miyagi_> why should it do false security
[14:10] <ogra> well, locked bootloader and partition based encryption with a properly long passphrase is relatively safe i'd say
[14:10] <Miyagi_> do you mean ecryptfs is broken
[14:10] <Miyagi_> if not then the security should be the same
[14:11] <ogra> no, i mean it gives you a false sense of being safe
[14:11] <Miyagi_> no it do now
[14:11] <Miyagi_> and 4 digits? my phone has passfrase so, and you not even now how i would unlock the directory
[14:11] <ogra> you only have a 4 digit pass phrase ... the bootloader is open so you can always grab the encrypted dir and push it to a PC to run decryption tools on it
[14:11] <dobey> ogra: well, agaisnt your psycho ex partner maybe, but not necessarily against someone with infinite resources after they shoot you and take your phone :)
[14:12] <ogra> right
[14:12] <Miyagi_> 4 digits, wwll by a new phone then
[14:12] <dobey> ogra: no you don't only have a 4 digit PIN
[14:12] <ogra> well, you could indeed set up password locking
[14:12] <Miyagi_> thanks dobey
[14:12] <ogra> but who does that when he still wants to conveniently use the phone :P
[14:13] <dobey> ogra: which is exactly why your argument is facile :)
[14:13] <ogra> (there are plans to de-couple the login from the passwd DB_, then you can have both)
[14:13] <dobey> even with full disk encryption, nobody is going to want to type a 32 character pass phrase onto a phone
[14:13] <ogra> no
[14:13] <ogra> but when we do FDE we will have the de-coupled stuff in place
[14:14] <Miyagi_> since you not even have an idea of what i will do, you should not think loud
[14:14] <dobey> ogra: it doesn't matter
[14:14] <ogra> for an enduser it does ...
[14:14] <ogra> my mom wouldnt use a 10 digit password
[14:14] <Miyagi_> i can here you are not so deep into the phone business
[14:14] <Miyagi_> since then you would be quiet
[14:14] <ogra> lol
[14:14] <dobey> ogra: it doesn't, because they aren't going to want to type complex secure passwords onto a phone, because it's still an incredible pain in the ass :)
[14:15] <Miyagi_> there is a lot of people who want to type 16 + chars to open a phone
[14:15] <dobey> ogra: it only matters to security nerds who think it matters. for 99% of real people, they will use the same 4 digit pin in both places
[14:15] <ogra> dobey, exactly
[14:15] <dobey> besides
[14:15] <Miyagi_> and ubuntu flash with --password=1234
[14:16] <Miyagi_> so i set the 16+ passphrase
[14:16] <Miyagi_> not the user
[14:16] <dobey> with your massive 8" phone, i can read your password in clear text from the other side of the coffee shop with ease
[14:16] <ogra> but thats because you are a decade youonger than me :P
[14:16]  * ogra wuld need goggles
[14:17] <dobey> well, more to the point, cameras are everywhere. so if i can read it, so can the NSA/GCHQ/etc... and they have even more time to parse it, being a recorded video :)
[14:18] <ogra> yay... paranoia !
[14:19] <dobey> lol, and besides, if the phone is booted, and you are using a 4 number PIN to unlock, then that's all that one needs to get access; so splitting doesn't really make the system more secure :)
[14:20] <ogra> indeed
[14:21] <ogra> yet there are plans to have lightdm not use the passwd DB anymore :)
[14:21] <ogra> and only use that for sudo and stuff ... so you can actually set a safely long PW
[14:22] <ogra> but that would indeed not help much with encryption
[14:22] <ogra> (but then again ... as long as the bootloader is fully open you arent safe anyway)
[14:23] <dobey> well, what i mean is, all i have to do is keep your phone powered, and then guess the unlock PIN, and then enable dev mode and just sync all the data off the device
[14:25] <dobey> anyway

[14:25] <ogra> ii think using the open bootloader to copy the whole disk to a PC to run scripts on it is more efficient than having a robot punch in 4 digits til you hit it
[14:25] <dobey> you don't even need to copy the whole disk
[14:26] <ogra> well, the shadow db and the encrypted folder ...
[14:26] <dobey> you just need to copy the encrypted key, and then run password attacks against it
[14:26] <ogra> right in the end just the db
[14:26] <dobey> because the key will have to be encrypted with the password
[14:27] <ogra> yeah
[14:27] <dobey> i wouldn't expect a shadow db to be outside the encrypted disk
[14:27] <ogra> so any encryption you can do in todays setup is just obscuring the data a bit ...
[14:27] <ogra> false feeling of safety after all ... like i said
[14:29] <dobey> also mr robot is a horrible show. i don't understand why people think it's so great
[14:30] <ogra> because it doesnt use kirklands byobou-hollywood setup in every second scene ?
[14:31] <ogra> having computers that make *blip* *blip* *beep* at every keystroke ...
[14:31] <dobey> because it's literally just fight club meets hackers
[14:32] <ogra> well, it is slightly more realistic than the others
[14:32] <ogra> thats all i guess
[14:32] <dobey> not really :)
[14:32] <ogra> slightly :)
[16:26] <ogra__> bregma: hmm, after weeks i tried my unity8 session on my desktop again today ... i cant seem to be able to launch any libertine apps anymore
[16:27] <bregma> ogra__, check if cgmanager is running, we've had spurious complaints about that
[16:27] <ogra__> (system is up to date, syslog shows some zeitgeist errors when i click on teh installed hexchat icon in the libertine launcher)
[16:27] <ogra__> seems to be running ...
[16:28] <bregma> ChrisTownsend, was there something else we've seen lately? ^^^
[16:28] <ogra__> saldy teh keyboard is still completely broken so i cant type a pipe or at
[16:28] <ogra__> (which makes grepping in output a bit awkward)
[16:28] <ChrisTownsend> ogra__: Do any apps start?
[16:29] <ogra__> well, i only have hexchat and vim installed ... hexchat flashes a black screen and is gone again
[16:29] <ChrisTownsend> ogra__: Aside from libertine apps
[16:29] <ogra__> and syslog shows some zeitgeist complaints
[16:29] <ogra__> oh, yeah
[16:29] <ogra__> i'm typing that in the kiwi irc webapp
[16:29] <ogra__> the terminal runs and i have G+ open in its webapp too
[16:30] <bregma> anything in the ~/.cache/upstart logs?
[16:30] <ChrisTownsend> ogra__: Ok, so not cgmanager.
[16:31] <ogra__> bah... clicking teh vim icon gets me an uncloseable terminal with vim icon and spinner
[16:31] <ogra__> bregma: what would i look for ?
[16:32] <ogra__> i see compressed libertine-lxc-manager logs ...
[16:32] <ChrisTownsend> ogra__: Look for something like application-legacy_${container_id}_${exe_name}_0.0.log
[16:33] <ogra__> ah, found it
[16:33] <ogra__> http://paste.ubuntu.com/19511536/
[16:33] <ogra__> note tht i created a fresh container today
[16:34] <ogra__> and also freshly installed hsxchat in there
[16:34] <ogra__> *hexchat
[16:34] <bregma> mmm, I thought that code was replaced a while ago.......
[16:34] <ogra__> oh, wait, that could be from a manual attempt ...
[16:35] <ChrisTownsend> Yeah, that seems like an old libertine...
[16:35] <ogra__> let me wipe that long and try again to see that it actually comes from teh desktop launcher
[16:35] <bregma> I'm seeing the same spinning vim right now, but it was working a couple of hours ago...  ChrisTownsend how do I check LXC status again?
[16:36] <ChrisTownsend> Oh, wait, manual attempt, that would cause that, but that code still looks old...
[16:36] <ogra__> ok, i seethe same error in a fresh log
[16:36] <ChrisTownsend> bregma: Hmm, I've never had luck w/ Vim.
[16:36] <ogra__> just wiped it and clicker open (why do we have that and not just launch the app when clicking the icon)
[16:36] <ChrisTownsend> bregma: But, lxc-ls --fancy -P ~/.cache/libertine-container
[16:37] <ogra__> *clicked
[16:37] <ChrisTownsend> ogra__: That is fixed.  I think you need to update.
[16:37] <ogra__> i dist upgraded 20min ago
[16:37]  * ogra__ checks again
[16:37] <ogra__> how teh heck do i get rid of that vimm window ..
[16:37] <ChrisTownsend> ogra__: Look for the Xmir process and kill it.
[16:37] <bregma> ah, right, I'mm seeing the terminal-only vim, I assumed I had installed gvim in that container
[16:38] <ogra__> vim seems to be preinstalled
[16:38] <ogra__> and brings a terminal .desktop file
[16:38] <ogra__> nothing interesting in the dist upgrade
[16:38] <bregma> yes, it but we currently don;t support terminal applications in libertine
[16:39] <ChrisTownsend> ogra__: But your Libertine is old and the fact that single click won't just launch tells me you have old software.
[16:39] <bregma> it's on the list, it's stuck waiting for me to do something
[16:39] <ogra__> ooooh !!!
[16:39] <ogra__> during my snapcrafting i disabled the overlay PPA ...
[16:39] <bregma> *schwing*
[16:39] <ChrisTownsend> ogra__: Some other package pulls in vim, not anything we do.
[16:39] <ChrisTownsend> lol
[16:39] <ogra__> since that messes up stuff
[16:39]  * ogra__ enables it again and uppgrades
[16:40] <bregma> on the upside, supertux runs fine in my container
[16:40] <ogra__> hmpf ...
[16:40] <ogra__> i guess i cant get the sw-sources UI up under mir now
[16:40] <ogra__> <- lazy ... i like the UI tools :P
[16:42] <ogra__> aha ... 20M updates coming down the drain
[16:45] <ogra_> ok, it starts but all my themeing is gone now ... sniff
[16:45] <ogra_> also complains that it has no access to ~/.config/hexchat
[16:47] <ogra> aha, better
[16:47] <ogra> adding a bind mount to the config helped
[16:48] <ogra> now to get the awful win95 look sorted ...
[16:48] <ogra> oh !
[16:48] <ogra> ||||@@@@
[16:48] <ogra> the kbd is fixed
[16:48] <ogra> yay
[16:50] <ogra> hmm, can i install evolution ? i guess that wont be happy regarding all its background services
[16:53] <ogra> WOW
[16:53] <ogra> that was unexpected
[16:54] <ogra> evolution just works ... including all my data
[16:57] <ogra> hmm, only half ... doesnt display any message
[16:57] <Laney> that bit is webkit
[17:00] <ogra> no, that bit is evo re-syncing 4GB of email for "offline mode" ... it is just busy
[17:00] <ogra> silly stuff
[17:00] <ogra> seems it found my config but not my ~/.evolution folder ...
[17:00] <ogra> so it tries to re-download the world
[17:02] <dobey> hmm
[17:03] <ogra> thats better ...
[17:03] <dobey> what happens if you run a libertine container inside a unity8 that's running inside a libertine container, that's running under unity8?
[17:04] <ogra> try it
[17:04] <ogra> ARGH
[17:04] <ogra> no keyboard repeat in X apps
[17:04] <ogra> and i have atlGr in X apps but not in unity or th terminal
[17:04] <ogra> GRR
[17:04] <bregma> dobey, see if you can do that from Unity 7 running on Bash for Windows
[17:05] <bregma> ogra, yes, the keyrepeat is a low-priority fix in Xmir we're waiting on
[17:05] <ogra> well, that makes me go back to unity8
[17:05] <bregma> altGr on the other hand, is a Mir fix wending its way through
[17:05] <dobey> bregma: i guess it would be the same, you just end up having to run the child unity8 session under xorg
[17:05] <ogra> i cant really work without that
[17:06] <ogra> bregma, well, it works in libertine, but not in Mir
[17:06] <ogra> which is rather weird
[17:06] <ogra> i cant type a pipe sign in the terminal app
[17:06] <ogra> but here i can ... |||
[17:06] <bregma> something about keymaps
[17:07] <ogra> kind of the wrong way around for me to be helpful :)
[17:07] <ogra> crap ... evo is really evil ... even with the bind mounted evo folder in place it still tries to re-download
[17:10] <davmor2> ogra: you just figuring this out now
[17:14] <ogra> hmm ... my pinned libertine apps are gone from the launcher after re-login
[17:15] <dobey> ogra: you should move to the US where we've been teaching that evolution is wrong, the whole time
[17:16] <ogra> how do you read your mail in that country then ?
[17:17] <ogra> grrr, that broken tap to click makes working really unbearable
[17:17] <davmor2> ogra: they pine lots and lots of pine
[17:18] <dobey> ogra: e-mail doesn't evolve, it was simply created.
[17:18] <ogra> ah yeah
[17:18]  * ogra shakes head
[17:18] <davmor2> ogra: just use dekko like any sane person
[17:19] <ogra> add threading to it and i will
[17:19] <dobey> and gpg
[17:19] <dobey> and s/mime
[21:32] <raph_ael> I've read the discussion about powerd, will there be an image for common users ?


[09:47] <bdrung> udev and upstart can be dropped from sync-blacklist (they use propor -0ubnutX Debian revisions for quite some time)
[11:37] <cjwatson> Anyone looking at the Xubuntu build failures?
[11:38] <knome> cjwatson, at least not from the xubuntu side, since i wasn't aware we had those
[11:38] <cjwatson> infinity,slangasek: The above grub2/grub2-signed were from debugging a failure reported by PES, but I have a suspicion that they may fix stgraber's installation failure too
[11:38] <Laney> there's a branch on the im-config bug to switch the seeds
[11:38] <cjwatson> knome: Should you be on the e-mail list for image build failures?
[11:39] <cjwatson> It's currently Cody and Lionel
[11:39] <knome> cjwatson, maybe, but i don't even know what that list is...
[11:39] <knome> cjwatson, right, that should probably be lionel and micahg (if he wants)
[11:39] <Laney> you get mailed when the images fail to build
[11:39] <cjwatson> It's maintained by ubuntu-cdimage - it's not a mailman list or anything
[11:39] <knome> i mean, i'm useless there.
[11:39] <cjwatson> OK, I'm not adding people without their explicit consent so it's up to micahg then
[11:40] <cjwatson> (Also tend not to remove people without their consent)
[11:40] <knome> i can only pass on the message, but if lionel gets those mails anyway, then i'm just an extra hand
[11:40] <knome> cody hasn't been active with xubuntu for a long time, but i'm not complaining if he wants those mails
[11:42] <knome> just a note that i'm not too actively monitoring this channel; only on highlights, which are knome and xubuntu for this channel
[11:42] <knome> so if you want my attention... use either
[11:43] <knome> or if you think i should add more words to highlight, let me know
[11:44]  * cjwatson merges that seed branch
[11:44] <cjwatson> knome: no, that's fine
[11:45] <knome> cjwatson, ok, cheers :) and thanks for all the hard work. i probably should have come and said hi and thanks to you in uds, but somehow that slipped.
[11:45] <cjwatson> no worries :)
[11:46] <knome> mmh, i'm sure you were busy enough without that too :)
[11:46] <knome> anyway, i got to move again, see you later!
[11:47]  * cjwatson runs a xubuntu-meta update
[11:49] <infinity> cjwatson: No bug ref in that grub2{,-signed} upload.
[11:50] <infinity> Oh, you're just piggybacking it on the catch-all SB bug.
[11:50] <infinity> That's fair.
[11:50]  * infinity gets all accepty up in here.
[11:50] <cjwatson> infinity: I was sort of uncomfortable about including FourDollars' bug in it because that bug isn't present in precise{,-updates} right now
[11:50] <cjwatson> including a reference to that bug, that is
[11:51] <cjwatson> I kind of feel that SRU bugs should be present before and absent after
[11:51]  * infinity nods.
[11:52]  * infinity reinstalls bzr first...
[12:05] <cjwatson> infinity: ?!
[12:05] <cjwatson> (reinstall)
[12:06] <infinity> cjwatson: Wiped out my laptop over the weekend.
[12:07] <cjwatson> Ah
[12:32] <infinity> I'm guessing kdegames got split out? :P
[12:37] <xnox> infinity: lolz =) also gnome-games got split upstream as well. I guess splitting games is trending right now =)
[13:37] <ScottK> KDE is splitting ALL the things.
[14:11] <stgraber> cjwatson: I'll retry once we have a build with the new grub2. I was installing from a usb stick onto another usb stick, so problems specific to removable devices may well affect me.
[14:21] <cjwatson> stgraber: Even aside from that, there was a misbackport that wasn't specific to --removable
[14:21] <cjwatson> And, hmm.  Did 12.10 work in that configuration?
[14:22] <stgraber> that's a good question. I did my 12.10 testing on external drives, but with a different one that may not export the removable flag properly (I have a few of those)
[14:22] <cjwatson> Because we have no code to call grub-install --removable if you're doing that, and I'm not sure that it'll work without
[14:22] <cjwatson> It would be more about whether UEFI thinks it's removable
[14:23] <cjwatson> Specifically whether it goes for \EFI\ubuntu\BOOTX64.EFI per efibootmgr, or \EFI\BOOT\BOOTX64.EFI per the defaults for removable devices
[14:24] <cjwatson> I think I mean \EFI\ubuntu\shimx64.efi there
[14:25] <stgraber> I'm 90% sure it was updating the boot list with efibootmgr in 12.10 and I'm 100% sure it did with that last precise install (as I had to fix it manually to boot from my internal disk)
[14:26] <cjwatson> OK, so then it could still be the config_opt(_file) fix
[14:31] <cjwatson> stgraber: running an image build now
[15:01] <micahg> cjwatson: I'd be fine getting Xubuntu image mails
[15:08] <cjwatson> micahg: your wish is my command.  preferred address?
[15:08] <micahg> cjwatson: micahg @ ubuntu
[15:09]  * xnox kind of wants to receive cd image build failures as well for: ubuntu [desktop|server] @ i386, amd64, armhf-any
[15:09] <xnox> ... cause I am usually the last one to find out about stuff.
[15:09] <cjwatson> xnox: I can't make them arch-specific
[15:09] <cjwatson> (right now, anyway)
[15:10] <xnox> cjwatson: ok, then all ubuntu emails please =)
[15:10] <cjwatson> xnox: preferred address?
[15:10] <Laney> poor kde
[15:10] <xnox> cjwatson: launchpad @ surgut.co.uk
[15:11] <cjwatson> micahg,xnox: done
[15:11] <xnox> thanks.
[15:11] <xnox> ... for all the spam =)))))
[15:11] <xnox> cjwatson: I do wonder if it should have an archived mailing list as well. for all fails.
[15:13] <cjwatson> xnox: *shrug* they're all archived in *-build-logs anyway
[15:14] <xnox> fair enough.
[15:15] <micahg> cjwatson: thanks
[15:16] <infinity> Oh crap, is queuebot going nutty again?
[15:17] <stgraber> it seems to be kde-only, so I'm not sure :)
[15:17] <cjwatson> infinity: Those look like genuine rejects/reuploads
[15:17] <stgraber> nope, according to the queue, it's fine, just the kde guys flooding the queue as usual :)
[15:17] <infinity> Oh, indeed.  1m old in the queue.
[15:27] <ScottK> infinity: FYI, one of the two packages holding old libs in raring got fixed yesterday.
[15:27] <ScottK> So we didn't forget.
[15:34] <infinity> ScottK: \o/
[16:35] <stgraber> slangasek: QATracker change landed, we can now enable/disable manifest entries at http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/32/manifest
[17:09] <slangasek> stgraber: thanks much
[17:10] <stgraber> slangasek: mumble?
[17:10] <slangasek> oh, I forgot we moved to mumble
[17:10] <slangasek> I've been trying to get into G+!
[17:10] <stgraber> :)
[17:10] <slangasek> (without success)
[17:34] <infinity> cjwatson: So, yeah, following up on mumble, I'm happy to poke at the oversize/duplication madness a bit, though if you want to switch from tasks to metapackages, that might sort of Just Work.  Ish.  Not sure what that does to the autoinstall profile of a .1 versus a .2 install.
[17:35] <cjwatson> Yeah, that would be my concern
[17:36] <cjwatson> I guess the answer is to build two squashfses and diff them
[17:36] <infinity> Yep.
[17:36] <infinity> I have that all set up here anyway, so I can fiddle a bit.
[17:36] <cjwatson> If you want to do that I certainly don't object
[17:36] <infinity> So gracious of you.
[17:37] <cjwatson> :-)
[17:37]  * cjwatson tries to figure out why ubuntu-zh_CN/precise/amd64 has been failing
[17:37]  * infinity tries to figure out why he's depserately craving potato chips.
[17:38] <cjwatson> Because you haven't eaten in 36 hours?
[17:38] <infinity> Oh, yeah.  Could be that.
[17:39] <ScottK> I attempted to copy cups-pk-helper to -security as requested, but got rejected.
[17:39] <ScottK> What's the process for that?
[17:39] <ScottK> Do copy package and let a security person accept it?
[17:39] <micahg> weird, I would think an AA should be able to do that
[17:40] <ScottK> Security is "special"
[17:41] <stgraber> cjwatson: running yet another precise SB install during my lunch break, hopefully this one will work ;)
[17:42] <ScottK> micahg: I copied the over again.  Would you please take care of accepting them?
[17:42] <micahg> ScottK: yeah, let me log into LP, I'm not on my dev machine
[17:42] <ScottK> Thanks.
[17:50] <infinity> Wait.
[17:50] <infinity> ScottK: Was that built in -proposed?
[17:51] <ScottK> infinity: It was.  And the security team said in the bug to copy it to security after it was released.
[17:51]  * ScottK assumed they thought that bit through.
[17:52] <infinity> We don't copy from updates to security for a reason.  I hope they audited the deps closely before they requested that...
[17:52] <ScottK> Err, I think it was.
[17:52] <ScottK> Yeah.  Me too.
[17:52] <infinity> Yeah, it was from proposed. :/
[17:54] <micahg> huh?  I thought it was copied from the security PA
[17:54] <micahg> *PPA
[17:54] <infinity> micahg: No.
[17:54] <infinity> Oh.
[17:54] <infinity> Wait.
[17:54] <infinity> Yeah, it went from the PPA to proposed to updates.
[17:54] <infinity> You're right.
[17:54] <infinity> False alarm, it's all good.
[17:54] <ScottK> Excellent.
[17:54] <ScottK> Sorry for not checking first.
[17:55]  * micahg accepts quantla
[17:55] <infinity> quantla was my favourite release.
[17:56] <micahg> yay, I did something useful...
[17:57] <Laney> you're always useful to me ♥
[18:17] <stgraber> cjwatson: I'm typing this on a shiny new precise install using secureboot ;)
[18:18] <xnox> \o/
[18:18] <cjwatson> stgraber: \o/
[18:18] <cjwatson> Best news I've heard all week
[18:18] <cjwatson> Any problems?
[18:19] <stgraber> not that I can see, media booted fine, install looked good, grub booted directly after reboot
[18:20] <cjwatson> Awesomesauce
[18:21] <cjwatson> So I think the remaining thing I need to do is fix that ubuntu-defaults-image failure visible in zh_CN
[18:21] <cjwatson> And then we call it good
[18:22] <stgraber> cjwatson: ah, one small detail, not sure if we want to bother fixing for .2, memtest86 is listed in grub and shouldn't be on efi systems
[18:22] <cjwatson> Yeah, I fixed that in quantal, I guess we should backport that
[18:22] <cjwatson> Let's make it a separate bug though - this one is big enough
[18:22] <cjwatson> And it's not SB-specific
[18:23] <stgraber> right
[18:23] <infinity> So, wait, do we get to promote this whole mess to -updates soon, is that what I'm hearing?
[18:23] <cjwatson> Hm, in bug 883017 somebody claims to have made it work on EFI
[18:23] <ubot2`> Launchpad bug 883017 in memtest86+ (Ubuntu) "memtest86+ fails on efi systems" [Medium,Triaged] https://launchpad.net/bugs/883017
[18:24] <cjwatson> infinity: It's looking close.  I think there are other ubiquity bugs to verify though
[18:25]  * xnox can do most of them. Now that cd's are not going to be respun again.
[18:25] <cjwatson> my hero
[18:26] <cjwatson> well, I mean, they are, they're on daily builds - just not for a new ubiquity
[18:26] <xnox> ack.
[18:26]  * xnox off to argos & back and then'll poke them.
[18:29] <ScottK> micahg: FYI: I got accepts for oneiric and quantal, but not precise.
[18:30] <infinity> cjwatson: Can I get you to review the flash-kernel in q-proposed?
[18:34] <cjwatson> Looking (modulo slow internet due to running ubuntu-defaults-image)
[18:35] <cjwatson> infinity: what guarantees that linux-base is installed
[18:35] <cjwatson> ?
[18:35] <cjwatson> Since I don't seem to have it installed here
[18:36] <infinity> cjwatson: f-k depends on it.
[18:36] <cjwatson> Aha
[18:36] <cjwatson> OK, that'll do :)  I was looking at rdepends on x86
[18:41] <cjwatson> accepted
[18:42] <cjwatson> and fixed queuediff to cope better with you using just quantal there :)
[19:01] <micahg> ScottK: [11:47] -queuebot/#ubuntu-release- Unapproved: accepted cups-pk-helper [sync] (precise-security) [<IP_ADDRESS>-1ubuntu0.1]
[20:59] <ScottK> micahg: Thanks.
[23:28] <ScottK> If any of the other archive admins feel like reviewing some of the several dozen KDE games packages, that would be lovely.  Riddell did me the favor of being the uploader, so he can't.
[23:28] <jbicha> https://launchpad.net/builders/peryton is pretending to be an armel builder
[23:32] <infinity> ScottK: Gee, I'd really like to, but I have to floss my cat this evening.
[23:33] <ScottK> Is it a big deal if copyright statements lack a date?
[23:33] <ScottK> i.e. copyright (c) foo vice copyright (c) 2012 foo
[23:34] <slangasek> depends on whether reproduction of the copyright notice with date is a requirement of the license, IMHO
[23:35] <infinity> A copyright statement without a date is legally meaningless in many jurisdictions.
[23:35] <ScottK> It's GPL 2+
[23:35] <slangasek> then yeah, I'd say that's a problem
[23:35] <ScottK> Thanks.
[23:36] <ScottK> Riddell: ^^^ look in players/neutralplayer.cpp in konquest and weep.  Rejecting (I did not check to see if it was just the one file or others too).
[23:39]  * Riddell weeps
[23:40] <slangasek> ohwait, this is the upstream copyright notice?
[23:40] <slangasek> I assumed you were looking at debian/copyright; in general, whatever upstream offers as a copyright statement is good
[23:41] <slangasek> because if they don't care enough to make sure copyright is enforceable on their work, who are we to stop them
[23:41] <slangasek> (not that the countries where you still need the copyright statement are particularly relevant, the Berne convention supersedes this)
[23:44] <infinity> slangasek: Hrm, does plymouth really need a dependency on "libdrm-intel1 | libdrm-radeon1 | libdrm-nouveau2"?
[23:45] <slangasek> infinity: I recently wondered that, having seen it in the backport; I don't know why it's there at all
[23:45] <infinity> slangasek: Doesn't seem to make much sense, since that doesn't in any way enforce that you have the plugin for your hardware.
[23:47] <slangasek> infinity: just checked, that predates my involvement in the package
[23:47] <slangasek> infinity: axe it - it's obsolete now anyway, because we're now using the generic kms backend for everything (by accident, but it seems to have held up)
[23:47] <infinity> slangasek: Axing away.
[23:48] <ScottK> slangasek: So it's OK then?
[23:48] <infinity> That'll knock a few more bits out of required.
[23:52] <slangasek> ScottK: it's ok for upstream to put whatever they want for a copyright statement, as long as it's clear to us that they aren't stealing code they can't actually give us a license to.  Debian policy still requires debian/copyright to include proper (i.e., with date) copyright statements; and some licenses, GPL included, require that "an appropriate copyright notice" accompany the work when we distribute it.
[23:53] <slangasek> ScottK: do you want more eyeballs on debian/copyright?
[23:54] <ScottK> I think it needs to be redone in any case as not all the copyright attributions are included in debian/copright.
[23:54] <ScottK> copyright even.
[23:54] <slangasek> ok
[23:55] <ScottK> Thanks for offering.


[00:00] <rbasak> I guess the easiest way to deal with this is to port the lot :-/
[03:56] <Skuggen> Hm, the MySQL dep8 test being so slow on arm64 is a pretty general problem
[06:23] <alkisg> xnox: good morning, could LP #1840945 be caused by mkinitramfs and not by the kernel decompression code? Should I put initramfs-tools in the affects list?
[06:40]  * alkisg tests all compressions to see
[07:00] <Unit193> alkisg: How'd you find that, anywho?
[07:01] <alkisg> Unit193: I redesigned/rewrote the new ltsp, so that all its code is sent via an additional initramfs; it worked in ALL debian/ubuntu based distros/versions that I tested (like 20 of them) except eoan :)
[07:01] <alkisg> It's like putting the casper code in an extra initrd, not embedding it into a single one
[07:06] <Unit193> alkisg: I mess around with ISOs, have been for quite some time.  That broke in Eoan and I'm wondering if it's related.
[07:07] <alkisg> Unit193: sorry I didn't get which part broke and which one is related
[07:07] <Unit193> (I'm testing that now)  I got dumped to busybox, sooo.
[07:34] <alkisg> I did an extensive comparison between eoan and bionic; xz still works, gzip/bzip2 regressed, lz* never worked : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840945/comments/3
[07:38] <Unit193> alkisg: I can't remember what all I'd tried, but using gzip for initramfs didn't help.  Makes sense though.
[07:39] <alkisg> Unit193: what is the error message that you see in the initramfs? For me, only .xz works in eoan
[07:40] <Unit193> Most of the time I get no error message.  xz initramfs is the one that works?  Huh.
[07:40] <alkisg> In my case, where I either concatenate 2 initrds, or send 2 different ones, yes, xz is the only one that works in eoan; while gzip/bzip2 worked in bionic too; and lz* never worked
[07:41]  * alkisg is seeing the strange new login screen of gdm currently
[07:41] <Unit193> Cool, trying that now.
[07:43] <alkisg> Unit193: if you think I might help, `cat /proc/cmdline` when you get the busybox failure, and upload a screenshot if you're using a vm... e.g. I also had netplan issues that broke initramfs
[08:08] <Unit193> alkisg: 'file=/cdrom/preseed/xubuntu-core.seed initrd=/casper/initrd quiet splash ---'
[08:10] <alkisg> Unit193: ok, so nothing related to networking or initrd concatenation; it sounds like a different issue. Are you just trying to boot the daily .iso? How, e.g. with kvm?
[08:11] <Unit193> `kvm -m 512 -cdrom myownfile.iso`, which should be good enough to get it to boot, but alas..
[08:11] <alkisg> Unit193: ah, do try kvm -m 1024...
[08:12] <alkisg> Crazy as it sounds, I think I needed more than 512 in one case
[08:12] <Unit193> This isn't GNOME, so it should be fine.  An error I sometimes see is more related to squashfs.
[08:12] <Unit193> (But trying it anyway.)
[08:13] <alkisg> I had the problem while the initramfs decompressed; not later on when services are starting
[08:13] <Unit193> This, as noted before, isn't a daily ISO but one I mess around with.
[08:13] <Unit193> 1024 still dumped me at busybox.
[08:14] <alkisg> busybox usually states the reason, so a screenshot and/or dmesg should probably help
[08:14] <alkisg> *initramfs-tools usually states the reason...
[08:15] <alkisg> Although if it's a custom iso, it might be unrelated to #ubuntu-devel, and we should go to some other channel or use pms...
[08:17] <Unit193> https://unit193.net/dmesg.png https://unit193.net/initial.png
[08:19] <alkisg> Unit193: and if you `cat /init` you see the /usr/share/initramfs-tools/init file?
[08:20] <Unit193> Yep.
[08:20]  * alkisg is puzzled about the (initramfs) prompt of the first picture, that doesn't mention anything at all from the initramfs-tools init script
[08:20] <alkisg> Why 2 pictures? What changed to get from the first to the second one?
[08:21] <Unit193> One is initial startup, the other is, as the name indicates, `dmesg`
[08:21] <alkisg> Aaaah ok so you just didn't get to see the busybox error message because busybox cleared your screen
[08:21] <alkisg> Put `break=bottom` etc so that you get a chance to see it
[08:21] <Unit193> Removing 'quiet splash' gets me 'No root device specified.  Boot arguments must contain root='
[08:22] <alkisg> True, if there's no root= in your /proc/cmdline, it can't mount it
[08:23] <alkisg> Your boot loader (isolinux I presume) should have provided it
[08:23] <alkisg> Unit193: let's go somewhere else, I don't think this is related to #ubuntu-devel...
[08:25] <mwhudson> Unit193: do you have anything in your initrd that sets BOOT to casper
[08:26] <mwhudson> e.g. this random casperized initrd i have lying around has conf/conf.d/default-boot-to-casper.conf
[08:26] <Unit193> mwhudson: Looking at the scripts, it should pick that up.  I believe..
[08:27] <alkisg> Unit193: sorry, mwhudson is right, the casper code takes care of mounting root so root= isn't passed in live cds; i was mistaken
[08:28] <Unit193> mwhudson: Appending BOOT=casper didn't seem to assist.
[08:29] <mwhudson> Unit193: boot= not BOOT=
[08:29] <mwhudson> the other thing could be mismatched uuids but i think that fails differently
[08:30] <LocutusOfBorg> cpaelzer, #1840749 can't you just use the upstream binaries?
[08:30] <LocutusOfBorg> just to understand if it is a packaging issue, or to understand when it broke
[08:31] <LocutusOfBorg> https://forums.virtualbox.org/viewtopic.php?f=6&t=89392
[08:33] <Unit193> mwhudson: ...Welp, that worked.  Now to figure out why it's not automatically picking that up anymore.
[08:33] <Unit193> Sorry.
[08:33] <mwhudson> Unit193: heh i've spent rather too long with my head in the initramfs code lately
[08:35] <Unit193> Now I feel stupid...  Anyway, let's see if I can't get CASPER_GENERATE_UUID to work.
[08:45] <LocutusOfBorg> tjaalton, did you upload of python-yubico fail?
[08:45] <LocutusOfBorg> http://launchpadlibrarian.net/436704667/python-yubico_1.3.2-2_1.3.2-2.1.diff.gz
[08:45] <LocutusOfBorg> +X-Python-Version: >= 2.8
[08:45]  * LocutusOfBorg fixup this
[08:46] <tjaalton> fail how?
[08:46] <LocutusOfBorg> X-Python-Version: >= 2.8
[08:47] <LocutusOfBorg> I don't think doko is planning to ever upload a python2 2.8 :D
[08:47] <tjaalton> explain
[08:47] <tjaalton> ok
[08:47] <LocutusOfBorg> python-yubico-tools/amd64 unsatisfiable Depends: python:any (>= 2.8~)
[08:47] <tjaalton> I didn't touch that part
[08:47] <LocutusOfBorg> it didn't migrate in debian and ubuntu
[08:47] <cjwatson> Also note that current Debian practice is to remove the X-Python-Version header entirely
[08:47] <tjaalton> or did I
[08:47] <LocutusOfBorg> and moreover you upload contained a binary, so it won't migrate in debian because of this
[08:48] <LocutusOfBorg> tjaalton, the signature on NMU is your :)
[08:48] <LocutusOfBorg> I can drop them both and reupload as nmu
[08:48] <tjaalton> oh I did
[08:48] <tjaalton> yes please
[08:48] <tjaalton> it had to go via NEW...
[08:49] <cjwatson> https://bugs.debian.org/934861 too FYI
[08:49] <tjaalton> bah
[08:50] <RikMills> as libmysqlclient-dev is now 8.0.16-0ubuntu3, there is no way of building anything against 5.7?
[08:51] <LocutusOfBorg> thanks cjwatson I'll update to that
[09:00] <Unit193> alkisg, mwhudson: Anyway, thanks.  One way or another I'll get it to work now. :)
[09:00] <mwhudson> Unit193: np, good luck
[09:04] <alkisg> yw Unit193; /me continues struggling with COMPRESS=...
[09:05] <Unit193> alkisg: Unfortunately, I can't really help you there as I guess that never gave me issues, even though I did adjust which compressor I used.  Next up: Being able to use zstd there too. :P
[09:05] <alkisg> :)
[09:07] <Unit193> Reminds me that I need to file a bug in mkinitramfs/initramfs-tools.  If you specify a compressor that's not available, it'll silently default back to gzip.  If you use verbose it'll warn you "No ${compress} in ${PATH}, using gzip"
[09:09] <LocutusOfBorg> vorlon, haskell needs sourceful uploads, not just rebuilds
[09:11] <The_LoudSpeaker> Hey! Does ubuntu 19.04 doesn't support steam?
[09:11] <The_LoudSpeaker> A friend of mine Installed steam but when he runs it. It doesn't start.
[09:12] <The_LoudSpeaker> Any help is appreciated.
[09:12] <EoflaOE> The_LoudSpeaker: 19.10 I think should support steam. How did he install it? Best to ask in #ubuntu.
[09:12] <LocutusOfBorg> The_LoudSpeaker, is that the client with a lot of security issues and a team who bans people reporting them?
[09:12] <The_LoudSpeaker> He installed using terminal. apt install I guess.
[09:13] <LocutusOfBorg> oh and then retract... https://it.slashdot.org/story/19/08/22/211245/valve-says-turning-away-researcher-reporting-steam-vulnerability-was-a-mistake
[09:13] <LocutusOfBorg> nice
[09:13] <The_LoudSpeaker> LocutusOfBorg: ?
[09:13] <LocutusOfBorg> The_LoudSpeaker, their bug-bounty program is scary
[09:13] <LocutusOfBorg> one person reported a security vulnerability and got banned instead of rewarded
[09:13] <The_LoudSpeaker> Lol!
[09:13] <LocutusOfBorg> so he gave a 0 day to the world a few days ago
[09:14] <LocutusOfBorg> https://it.slashdot.org/story/19/08/21/1928259/researcher-publishes-second-steam-zero-day-after-getting-banned-on-valves-bug-bounty-program
[09:15] <xnox> alkisg:  well append works for me.....
[09:16] <xnox> alkisg:  but i also failed to see any benefits to lz4 =/
[09:16] <LocutusOfBorg> The_LoudSpeaker, how did he install it?
[09:16] <LocutusOfBorg> what happens if he runs from command line?
[09:16] <alkisg> xnox: how are you testing?
[09:16] <LocutusOfBorg> wget http://repo.steampowered.com/steam/archive/precise/steam_latest.deb
[09:16] <LocutusOfBorg> this one might work
[09:16] <The_LoudSpeaker> Okay. I will try it in a bit and let you know.
[09:17] <xnox> alkisg:  bare metal reboots
[09:17] <xnox> alkisg:  so a lot more ram at least
[09:18] <LocutusOfBorg> The_LoudSpeaker, and tell him to use a VM, otherwise somebody might hack his laptop LOL
[09:18] <alkisg> xnox: no I mean, are you using the cpio date.img that I mentioned in the bug report? And cat initrd.lz4 date.img > initrd.img ?
[09:18] <cpaelzer> LocutusOfBorg: yes I can and will use the upstream binaries
[09:18] <xnox> alkisg:  as i commented on your bug report, the lz4 call you do is invalid.
[09:18] <The_LoudSpeaker> We have a strong firewall. LocutusOfBorg
[09:18] <cpaelzer> didn't know they are provided
[09:18] <alkisg> xnox: ah, I wasn't notified yet; refreshing/reading...
[09:19] <LocutusOfBorg> thanks cpaelzer , it might be really trivial to bisect, avoiding lots of rebuilds
[09:19] <LocutusOfBorg> The_LoudSpeaker, it was a joke, I don't really care :D
[09:19] <alkisg> xnox: so the additional initrd needs to be compressed using the same algorithm? Can't it be a cpio with no compression?
[09:20] <The_LoudSpeaker> LocutusOfBorg: same here.
[09:20] <xnox> alkisg:  kernel only knows how to read certain formats of lz4, which is not the default.
[09:20] <alkisg> xnox: date.img isn't lz4; it's cpio; I'm not compressing it
[09:20] <xnox> alkisg:         -l     Use Legacy format (typically for Linux Kernel compression)
[09:20] <xnox>               Note : -l is not compatible with -m (--multiple) nor -r
[09:20] <xnox> alkisg:  well, your bug description says you are.....
[09:21] <alkisg> xnox: I mean in my tests in #3
[09:21] <xnox> # echo date.txt | cpio -oH newc | lz4 > date.img => will never work
[09:21] <alkisg>  echo date.txt | cpio -oH newc > date.img
[09:21] <LocutusOfBorg> The_LoudSpeaker, it might be premature to run valve on devel systems, unless you know how to debug issues
[09:21] <LocutusOfBorg> 19.10 is not even released yet
[09:21] <LocutusOfBorg> still under development, and valve team I doubt are caring right now about it
[09:21] <xnox> alkisg:  but how was initrd.lz4 created? with or without -l ?
[09:21] <LocutusOfBorg> and I also doubt any ubuntu developer is caring about fixing it :)
[09:22] <LocutusOfBorg> I might care if it breaks on 18.04 :D
[09:22] <alkisg> xnox: with update-initramfs -u; whatever code that has, I believe should be fine
[09:22] <The_LoudSpeaker> LocutusOfBorg: ummm what valve? Can't get the context here.
[09:22] <xnox> alkisg:  depends on the release and if the tools were installed ;-)
[09:22] <alkisg> xnox: I changed COMPRESS= and ran update-initramfs -u for each case; it's yesterday's eoan build
[09:22] <xnox> alkisg:  mixed compression i would expect to work, because early initrds are all uncompressed
[09:22] <LocutusOfBorg> The_LoudSpeaker, steam/valve, same thing
[09:22] <alkisg> The initial lz4 was the one from the live cd, I didn't re-generate it
[09:23] <LocutusOfBorg> valve is the corporation providing steam
[09:23]  * LocutusOfBorg can say that his ubuntu 18.04LTS with steam works
[09:23] <xnox> alkisg:  why are you using a livecd initrd?
[09:23]  * LocutusOfBorg starts a game and blames The_LoudSpeaker for this!
[09:23] <alkisg> xnox: I'm going to test "same compression", which I haven't tested in #3, but even if that works, it doesn't help ltsp much as we'd need one ltsp.img image per chroot then...
[09:23] <xnox> alkisg:  what are you doing anyway?
[09:24] <alkisg> xnox: I rewrote a netbooting software called ltsp.org; the new technique is to send all the netbooting code as an additional initramfs, from ipxe or grub or wherever
[09:25] <alkisg> But either "second initramfs" or "concatenated initramfs" didn't work in eoan, while it worked anywhere else (tried 20 distro/versions from jessie and 16.04 to recent versions)
[09:25] <The_LoudSpeaker> LocutusOfBorg: ohh! Yeah forgot steam is provided by valve.
[09:25] <The_LoudSpeaker> Also, I haven't really tried steam on ubuntu myself. This is the first time I am(we are) trying. Coz a couple of days ago windows gave us a bigg BT.
[09:26] <Unit193> mwhudson: The mismatch uuid is 'unable to find a medium containing a live filesystem', isn't it? :)
[09:26] <mwhudson> Unit193: yes, that sounds like it
[09:26] <alkisg> xnox: if you plan to revert from lz4 to gzip, then ltsp isn't affected and we can postpone this issue for a later release... :)
[09:27] <Unit193> mwhudson: So yes, the issue I fixed tonoght I'd already fixed, but in doing so "fixed" nothing as I got that and mistook it for a similar issue.  Coolio!
[09:41] <alkisg> xnox: thanks; indeed lz4+lz4 or gzip+gzip work fine; it's lz4+cpio that have the issue. Where would that bug be, in the kernel decompression code or in mkinitramfs?
[10:13] <xnox> alkisg:  i do not know, but it's unlikely to be mkinitramfs. especially for the uncompressed cased.
[10:13] <xnox> alkisg:  you could try prepending, i.e. cpio+lz4
[10:13] <xnox> alkisg:  as that is how early initrd works
[10:13] <alkisg> xnox: ty, trying
[10:17] <alkisg> xnox: that indeed works! The mixed compression issue is still there but LTSP isn't affected anymore. Thanks again :)
[10:45] <xnox> alkisg:  yeah early initrd (ie. prepend uncompressed) is a kernel initrd implementation feature and should work (that's how microcode loading works) mixed compression initrds is interesting, and i would call it a linux kernel feature request, as initramfs-tools doesn't create those by default (it only does (multiple uncompressed) + 1 single compressed)
[11:16]  * alkisg will create a ltsp.gzip file and put it inside an uncompressed cpio, for maximum compatibility, and gunzip it inside the initramfs..
[13:56] <alkisg> xnox: hrm, although, putting ltsp.img as the first uncompressed cpio, will break microcode loading, won't it? :/
[13:57] <alkisg> "At boot time, the kernel performs the followings: If an uncompressed cpio archive exists at the start of the initramfs, extract and load the microcode from it to CPU. "
[13:57] <xnox> alkisg:  it should not
[13:57] <xnox> alkisg:  check dmseg to see if microcode update was applied on baremetal machine or not.
[13:57] <alkisg> ty, will do
[13:58] <xnox> alkisg:  we have verified this before, but worth double checking, by default we ship two early initrds + one compressed one, and we do observe microcode being loaded from the second early initrd on intel platforms.
[13:59] <alkisg> Great; will have to check tomorrow as I can only connect remotely to the office now; ty
[16:02] <The_LoudSpeaker> LocutusOfBorg: Thanks! The deb file you gave as a link worked. Playing CSGO at 250 fps now. :p
[16:44] <vorlon> rbasak: have you seen that some packages' autopkgtests seem to be unhappy with mysql-8.0 becoming the default? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-defaults
[17:00] <rbasak> vorlon: that's odd. I will follow up but it will be next week.
[17:01] <vorlon> rbasak: ack
[20:37] <evaluate> Hello.
[20:38] <evaluate> Are the scripts which generate for example the ubuntu-18.04-live-server-amd64.iso open sourced? And if yes, where can one find them?
[21:09] <Skuggen> vorlon, rbasak: There's also a recurring issue with the mysql-8.0 dep8 on arm64 timing out
[21:10] <Skuggen> e.g. for openssl, libaio and lsb
[21:12] <vorlon> Skuggen: do you know why the mysql-8.0 tests take so much longer than mysql-8.0 did?
[21:15] <Skuggen> There are more tests, but not that many more. I think maybe it's because of the amount of times the test suite needs a "clean" install, since --initialize takes longer in 8.0 than 5.7
[21:17] <Skuggen> I'll see if I can find out more next week, as well as look at the mysql-defaults failures. Mediawiki might be the same as cacti: Uses a native php connector that doesn't supporth the new default auth plugin in 8.0
[21:24] <vorlon> Skuggen: if the increased testsuite runtime is legitimate, then we can whitelist the package on the infrastructure to change the timeout; I just prefer someone to have analyzed it first to confirm it's legitimate
[21:28] <Skuggen> I'm _almost_ sure it's legitimate, but I can try to get confirmation, and see if maybe there are ways to improve it