[04:40] <mup> PR snapd#8374 opened: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
[05:39] <mup> PR snapd#8375 opened: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
[05:43] <mborzecki> morning
[06:15] <mborzecki> hmm core20 hangs in spread tests again?
[06:16] <mborzecki> looks like it's hitting job kill-timeout when rebooting during prepare
[06:21] <mborzecki> hmm perhaps https://github.com/snapcore/snapd/pull/8373 fixes that
[06:21] <mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
[06:26] <zyga> o/
[06:26] <jamesh> morning zyga
[06:26] <zyga> hey james
[06:27] <jamesh> zyga: here's a simple PR for the github actions CI: https://github.com/snapcore/snapd/pull/8375
[06:27] <mup> PR #8375: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
[06:27] <jamesh> make the cleanup run even if the tests fail
[06:27] <zyga> super nice
[06:27] <zyga> thank you James
[06:27] <zyga> I didn't know about the implicit if
[06:28] <jamesh> I also had a go at adding a problem matcher: it adds the error to the annotation list, but doesn't jump to the log line as I thought it did: https://github.com/snapcore/snapd/pull/8374
[06:28] <jamesh> (maybe I was misremembering how that worked)
[06:28] <mup> PR #8374: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
[06:28] <zyga> I love this :)
[06:29] <zyga> little by little but even this is so much better than what we had before
[06:29] <zyga> that's fantastic
[06:29] <zyga> I think we could move more stuff over this week
[06:29] <zyga> let's see what we can get
[06:30] <mborzecki> zyga: jamesh: hey
[06:30] <jamesh> hi mborzecki
[06:32] <mborzecki> wish the uc20 spread job actually worked
[06:32] <mborzecki> mvo: hey
[06:32] <zyga> hey mvo
[06:33]  * zyga is pre breakfast still so will go away for a while
[06:33] <jamesh> zyga: Longer term, it might make sense to have Spread output error annotations when it thinks it is running under the Github runner
[06:33] <jamesh> it could provide extra info like the task file name
[06:34] <mborzecki> jamesh: hopefully the runner makes it easy to detect such scenario
[06:34] <zyga> jamesh: yeah, I think that would be great, spread has specific travis features, it could have github features
[06:34] <zyga> I think the goal should be to phase out travis
[06:34] <zyga> so that nobody is stuck waiting
[06:34] <zyga> then optimize
[06:34] <mborzecki> otherwise it's ugnly job level  env vars again or somesuch :/
[06:34] <jamesh> mborzecki: there are environment variables it is documented to set, similar to Travis
[06:36] <jamesh> https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables says it will always set GITHUB_ACTIONS=true
[06:38] <mborzecki> ha nice
[06:38] <mvo> hey mborzecki and zyga !
[06:39] <zyga> how are you doing? it's quite cold today
[06:39] <zyga> yesterday was both +18 and -2 at night (and snow)
[06:40] <mborzecki> zyga: it was ~13C before noon, then 2 with a snow/rain mix in the afternoon here
[06:40] <mborzecki> felt like the afternoon was a completely different day
[06:51] <zyga> breakfast time
[06:53] <mup> PR snapd#8375 closed: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8375>
[06:58] <mup> PR snapd#8365 closed: seed: add Info() method for seed.Snap <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8365>
[07:03] <pstolowski> morning
[07:04] <mvo> hey pstolowski - good morning
[07:04] <mvo> fwiw lxd tests are broken right now
[07:04] <mvo> not sure why yet, but it seems pretty consistent
[07:12] <mup> PR snapd#8374 closed: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8374>
[07:18] <jamesh> mvo: thanks for doing the merges.  I think the problem matcher is about as good as it can get: further improvements would probably need to happen in Spread itself
[07:19] <mvo> jamesh: yeah, I was thinking that we might need to modify spread
[07:19] <mvo> jamesh: that's fine, thanks again for this, it's so much better than what we had before
[07:19] <jamesh> mvo: e.g. it would be nice to tie the error to the task.yaml file, but the problem matcher can only use information present in the error message
[07:24] <mborzecki> power outage :/ moved to my parent's
[07:31] <mborzecki> travis job failed again in #8373
[07:31] <mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
[07:31] <mvo> mborzecki: probably the lxd issue
[07:31] <mvo> mborzecki: also, does it have two reviews?
[07:31] <mborzecki> kill-timeout reached after mar300623-305765 (google:ubuntu-core-20-64:tests/regression/) reboot request
[07:32] <mborzecki> mvo: all test suites failed on uc20
[07:32] <mborzecki> (on prepare)
[07:32] <mvo> mborzecki: uh, no that then :)
[07:32] <mvo> mborzecki: right, because of the kernel/initramfs issue?
[07:32] <mborzecki> wish the console was easily accessible
[07:32] <mborzecki> mvo: yeah
[07:32] <mvo> mborzecki: does it only fail in gce or also with qemu?
[07:33] <mborzecki> mvo: haven't tried qemu yet, i'll try to obtain the image from gce
[07:33] <zyga> re
[07:33] <mvo> mborzecki: yeah, qemu should give a lot more visiblity into this, so we still don't know what is going on :( ?
[07:33] <zyga> sorry, it's hard to organize kids still
[07:58] <pedronis> mvo: hi, #8325 has a conflict now also as we know needs a bit more work
[07:58] <mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[07:59] <mvo> pedronis: thanks, look today (many meetings this morning unfortunately)
[08:29] <mborzecki> any clue why it's no longer possible to connect via ssh to a spread node?
[08:30] <mborzecki> spread can do it, but once i got the debug shell, i cannot establish any new ssh connections
[08:39] <pedronis> mborzecki: hi, I made a comment in the stand up notes about a thing that landed Friday, also did review some of your open PRs
[08:39] <mborzecki> pedronis: thanks!
[08:40] <zyga> re
[08:42] <mborzecki> pedronis: also wondering whether we should support GET on /v2/systems/{label}, but there does not seem to be any potential use cases atm
[08:42] <pedronis> mborzecki: we can add it later, but yes would leave it alone for now
[08:42] <mborzecki> ack
[08:48] <mup> PR snapd#8376 opened: daemon: make POST /v2/systems/<label> root only <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8376>
[08:52] <pedronis> degville: hi, could you look at this when you have a moment: https://github.com/snapcore/snapd/pull/8372#discussion_r400026498
[08:52] <mup> PR #8372: [RFC] devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8372>
[08:54] <degville> pedronis: morning - looking now!
[09:08] <mborzecki> sooo when i apt install openssh-server to pull in the update of sshd, i can log in over ssh again
[09:28] <zyga> Brb
[09:35] <mborzecki> i pulled the uc20 image built from master branch and it seems to work
[09:58] <zyga> mborzecki: cgroup code I mentined yesterday is in 8377
[09:58] <mborzecki> zyga: ack
[09:58] <mup> PR snapd#8377 opened: sandbox/cgroup: add ProcessPathInTrackingCgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/8377>
[10:47] <zyga> I'll get some mint
[10:47] <zyga> brb
[10:52] <mborzecki> moving back home
[10:53] <zyga> shit, I forgot about the mint/tea
[10:53] <zyga> brb
[10:53] <zyga> really
[10:53] <zyga> I'll push a fix for session-tool, sorry for annoying failures everyone
[11:06] <mup> PR snapd#8378 opened: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[11:12] <mborzecki> and back
[11:21]  * zyga stresses session-tool to see if the issue is gone
[11:43] <pedronis> mvo: commented on #8325 also there is stil a conflict
[11:43] <mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[11:55] <mup> PR snapcraft#2997 opened: specifications: progressive delivery <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
[11:56]  * zyga is surpsised by the surge of snow outdoors!!!
[12:00] <thresh> since https://snapcraft.io/docs/personal-files-interface says it requires snapd 2.37+, how can I check for snapd version in the wrapper script that launches my app?
[12:00] <zyga> thresh: don't use assumes: [snapd2.37]
[12:01] <zyga> https://snapcraft.io/docs/snapcraft-yaml-reference and search for "assumes"
[12:01] <thresh> zyga, will that force user to upgrade to the needed version if they somehow fetch my snap on an older machine?
[12:01] <zyga> thresh: it will prevent installation on an older snapd
[12:01] <thresh> that is not something I would want, then
[12:01] <zyga> thresh: but we're not seeing old snapd's in the wild
[12:01] <zyga> thresh: why?
[12:02] <zyga> thresh: snapd has a self-update mechanism
[12:02] <thresh> OK
[12:02] <zyga> thresh: virtually everyone runs the current stable version
[12:02] <thresh> I mean, I assumed not everyone updates
[12:02] <thresh> Thanks
[12:02] <zyga> good luck :)
[12:02]  * zyga cannot reproduce session-tool failure on ubuntu, I'll try some other distro and send a PR next
[12:10] <mborzecki> well, there are those that use snapd from distro repositories
[12:10] <mborzecki> but most major distros should be covered and have something quite recent available
[12:12] <pedronis> mvo: this is fixed, right? https://bugs.launchpad.net/snapd/+bug/1867755
[12:13] <mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
[12:42] <mvo> pedronis: yes, let me close it
[12:42] <ijohnson> morning folks
[12:42]  * ijohnson is super tired today for some reason
[12:53] <cwayne> ijohnson: same here, but i think just cause it's rainy and gloomy and monday
[12:53] <ijohnson> cwayne: since this is happening to both of us I think it's totally fair to blame the CDG airport
[12:53] <cwayne> way ahead of you
[12:53] <ijohnson> (in addition to the mondayness of today)
[12:54] <cwayne> it is pretty peak monday
[12:54] <ijohnson> how's your treadmill working out
[12:55] <cwayne> not too badly, averaging about ~4mi per day so far on it i think
[12:55] <ijohnson> nice
[12:55] <cwayne> everyone laughed at me for panic buying a treadmill, then they closed the gyms the next day and now i'm supposed to stay home so HA
[12:55]  * ijohnson has gotten really bad at not exercising more with the lockdown and all
[12:56] <cwayne> i've been exercising more since hte lockdown, but ive also eaten everything on planet earth.
[12:56] <cwayne> like my wife keeps stockpiling food
[12:56] <cwayne> and them im like OH SHIT FOOD
[12:56] <cwayne> and then its gone.
[12:57] <ijohnson> it's a good thing you're not in MN otherwise we both would have eaten all the food here, it'll probably take us a while to eat our way through the eastern US and new england before there's none left
[12:59] <cwayne> christina goes "that should last us a week" and then im just like "lol sure watch this"
[12:59]  * ijohnson imagines cwayne going "hold my treadmill"
[13:00] <cwayne> total re-emergence of 2012 vintage fat cwayne
[13:00] <cwayne> fun times
[13:02] <mborzecki> cmatsuoka: cachio: standup is now ;) tz was switched over the weekend
[13:04] <cachio> ah
[13:04] <cachio> ok
[13:05] <cmatsuoka> oh ouch
[13:33] <mup> PR core20#22 closed: run-snapd-from-snap: don't try to load a snapd snap from the seed anymore <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/22>
[13:42] <zyga> brb, coffee
[13:42] <zyga> amazing sun + snow experience toda
[13:43] <ijohnson> mvo did you see that folks responded on the lxd bug ?
[13:56] <ijohnson> zyga: ackk what's the special mount ns experimental setting I need to set to let the maas snap refresh ?
[13:56] <ijohnson> `snap set system experimental.<something> true` ?
[13:57] <ijohnson> nvm I see that it's `robust-mount-namespace-updates`
[13:57] <zyga>  ijohnson snap set core experimental.robust-mount-namespace-updates=true
[13:57] <ijohnson> yep that's it
[13:58] <mvo> ijohnson: I did not, let me check
[14:03] <zyga> wall of snow outdoors!
[14:07] <roadmr> yay! I want snow, all we have had is 2 crappy days of rain (even indoors, stupid roof leak)
[14:24] <cachio> mvo, I tested the lxd test installing lxd from edge and hte error is the same
[14:25] <cachio> mvo, I still see + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside
[14:25] <cachio> Error: EOF
[14:37] <mvo> cachio: nice, let's add this to the LP bugreport
[14:39] <cachio> I already did ti
[14:39] <cachio> it
[14:42] <cachio> mvo, I forgot to ask about 2.44.1 to stable today
[14:42] <cachio> it is ok to strart the pregressive release today?
[14:42] <mvo> cachio: either today or tomorrow, if all looks good
[14:43] <mvo> cachio: fine to start phasing today
[14:43] <cachio> mvo, nice, thanks
[15:00] <mborzecki> pedronis: we want /var/lib/snapd/seed RO, but /run/mnt/ubuntu-seed is TBD
[15:01] <pedronis> yes
[15:01] <mborzecki> ok, cool
[15:06] <mup> PR pc-amd64-gadget#39 opened: Drop no longer used snap_kernel fallback <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
[15:22] <mup> PR snapd#8379 opened: many: comment or avoid cryptic snap-ids in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/8379>
[15:23] <alan_g> cachio, looks like the rawhide image needs refreshing: https://api.travis-ci.com/v3/job/308689304/log.txt
[15:25] <cachio> alan_g, hui, fedora refresh is scheduled for today, it is gonna happen in few hours
[15:26] <cachio> alan_g, I'll let you know when it is ready
[15:26] <alan_g> :)
[15:32] <mup> Issue core20#29 opened: core20 ubuntu-seed mount point should be read only <Created by xnox> <https://github.com/snapcore/core20/issue/29>
[15:34] <mup> PR core20#30 opened: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <https://github.com/snapcore/core20/pull/30>
[15:35] <zyga> brbb
[15:50] <mup> Issue core20#29 closed: core20 ubuntu-seed mount point should be read only <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/issue/29>
[15:50] <mup> PR core20#30 closed: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/30>
[15:51] <mup> PR pc-amd64-gadget#39 closed: Drop no longer used snap_kernel fallback <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
[15:52] <thresh> so I've been rereading the snapcraft.yaml syntax docs, and found out I didnt set license: and title:.  I did, but now I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('title', 'license' were unexpected)"
[15:53] <thresh> yml is at https://code.videolan.org/thresh/vlc/-/blob/snap-fixes/extras/package/snap/snapcraft.yaml#L6
[15:56] <thresh> it's on snapcraft, version 2.43.1+18.4
[15:59] <thresh> and an unrelated question, do I need an avahi-observe interface if I already have network?
[16:02] <zyga> re
[16:02] <zyga> mborzecki: I've reduced the failing case and added logging to the tool itself
[16:03] <zyga> mborzecki: now it doesn't fail, I wonder if that's because of (perhaps) synchronization due to logging and set -x
[16:03] <zyga> thresh: I think license has a long-standing issue, as for title, I think it's gone (but I could be wrong)
[16:03]  * zyga goes away to eat dinner
[16:20] <zyga> re
[16:20] <zyga> INFURIATING it keeps working
[16:24] <zyga> mvo: as for debian snapd package, you didn't commit the change to vcs
[16:24] <zyga> mvo: the salsa git repo seems out of date (2.37 vs 2.44.1)
[16:27] <thresh> how do I set the license that is shown in snap info vlc then?
[16:27] <thresh> now it's "unset"
[16:27] <zyga> thresh: you can set it but I don't know if this will fly through the store,
[16:28] <zyga> CC degville ^ do you know if licenses work?
[16:28] <pedronis> it's meant to be set through the store atm
[16:28] <thresh> It's set in the store: License GPL-2.0+
[16:28] <thresh> as from https://snapcraft.io/vlc
[16:30] <degville> zyga / thresh: yeah, it's in the store page for a snap (https://snapcraft.io/docs/using-the-snap-store)
[16:32] <thresh> degville, thanks, I see it's set in the store: https://i.imgur.com/WKFIOLz.png, but I don't see it in "snap info vlc": https://i.imgur.com/uwIGcd8.png
[16:33] <mup> PR snapd#8380 opened: tests: add LXD_CHANNEL environment <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8380>
[16:33] <pedronis> thresh: snapd takes it from the snap
[16:34] <pedronis> not all the dots are connected here
[16:34] <thresh> that sounds like a mess :-)
[16:34] <thresh> where do I file a bug to get it fixed?
[16:35] <pedronis> thresh: well, snapcraft should let you set a license
[16:35] <pedronis> the snapd side is this: https://bugs.launchpad.net/snappy/+bug/1853670
[16:35] <mup> Bug #1853670: snap always shows license as 'unset' after install <Snappy:Triaged by pedronis> <https://launchpad.net/bugs/1853670>
[16:35] <pedronis> there's a long forum thread as well
[16:35] <pedronis> pointed by that bug
[16:36] <thresh> snapcraft doesnt let me set one, I get "Additional properties are not allowed" when providing it
[16:36] <thresh> so I guess the consensus moved to setting it on the store only
[16:36] <mvo> zyga: I did commit to my repo I think
[16:37] <mvo> zyga: and iirc there is a MP for my repo to the shared one
[16:37] <zyga> ah, I see
[16:37] <zyga> I guess that's why
[16:37] <pedronis> thresh: there is no final consesus yet
[16:37] <zyga> thresh: so I just checked
[16:37] <zyga> thresh: I made a snap last weekend
[16:37] <zyga> and I did set a license
[16:37] <zyga> when I don't have it
[16:37] <zyga> snap info ...
[16:38] <zyga> doesn't show the license (it says unknown)
[16:38] <zyga> when I install it
[16:38] <zyga> I *do* see the license
[16:39] <zyga> thresh: I set the top-level "license" field to a valid SPDX expression
[16:39] <mup> PR snapd#8381 opened: tests: skip lxd test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8381>
[16:39] <thresh> hmm
[16:40] <thresh> thanks for your help
[16:49] <ijohnson> thresh: also note that you may have an older version of snapcraft which doesn't understand new keys, are you using snapcraft from the deb or from the snap ?
[16:49] <zyga> ok, 20K iterations of the tool, I suspect there's something I did that fixed this bug
[16:49] <zyga> now let me think what I did
[16:49]  * zyga checks diff
[16:50] <thresh> ijohnson, I'm using the snapcraft version from Ubuntu bionic, 2.43.1+18.04
[16:50] <thresh> from a .deb
[16:50] <zyga> thresh: snap install snapcraft --classic
[16:51] <mup> PR snapd#8382 opened: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[16:51] <ijohnson> thresh: then your snapcraft is certainly out of date
[16:51] <ijohnson> see zyga's comment
[16:51] <thresh> not sure that's possible since my build environment is in a docker container
[16:52] <thresh> but we'll see
[16:52] <zyga> ah
[16:52] <zyga> then probably not
[16:52] <zyga> can you not use docker?
[16:52] <thresh> not really, VLC CI uses it extensively
[16:52] <zyga> hum
[16:52] <zyga> thresh: please ask in #snapcraft
[16:52] <zyga> I don't really know
[16:53] <ijohnson> thresh: there are ways to use modern snapcraft inside a docker container
[16:54] <zyga> I haven't tried docker in years
[16:54] <zyga> and not following the set of current trends
[16:54] <zyga> as to which fork to use
[16:55] <zyga> thresh: note that there _is_ one thing that may help you
[16:55] <zyga> thresh: snapcraft has a mode where it "destroys" the environment by installing deps directly onto the system
[16:55] <thresh> I assume those ways are: setting up systemd inside, and dropping all security boundaries docker (might) provide
[16:56] <zyga> thresh: but please ask in #snapcraft for details
[16:56] <thresh> thank you zyga!
[17:00]  * zyga reproduced the error and has more logs
[17:10] <zyga> ha
[17:10] <zyga> I see where it's failing in pam
[17:13] <zyga> enabled debug in pam_systemd.so and should see the "warning" that makes it fail
[17:13] <zyga> I'm so happy
[17:13] <zyga> I know why it fails :)
[17:14] <zyga> and better yet, I think I know how to fix it (or work around it at least)
[17:14] <zyga> I'll make one last coffee of the daty
[17:14] <zyga> *day
[17:35] <zyga> brb, going for that coffee now
[17:44] <ijohnson> thresh see https://snapcraft.io/docs/build-on-docker
[17:45] <ijohnson> sorry bad internet connection right now, keeps cutting out on me
[17:48] <thresh> ijohnson, thanks!  is that image already published somehwere on docker hub?
[17:58] <zyga> mvo: reading now
[18:00] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-384099150
[18:00] <mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[18:00] <mvo> zyga: looking
[18:00] <zyga> ha
[18:00] <zyga> I have the proof of what is failing
[18:01] <zyga> https://pastebin.ubuntu.com/p/sGjFSkdMJh/
[18:01] <zyga> session startup is cancelled
[18:02] <zyga> because of session termination
[18:02] <zyga> I've reduced my test case to simple session-tool -u test true # twice
[18:02] <zyga> without synchronization it will fail
[18:02] <zyga> adding synchronization fixes it
[18:03] <zyga> but I need to think how to expose that to session-tool
[18:03] <zyga> specifically since it is needed to run in the background for some tests
[18:03] <zyga> one way of solving that would be to alter the shutdown time
[18:03] <zyga> via logind configuration
[18:03] <zyga> this way session-tool -u test foo; session-tool -u test bar; could run in one session
[18:05] <zyga> uh, the relevant part was cut
[18:05] <zyga> er-l:session): Failed to create session: Start job for unit user-12345.slice failed with 'canceled'
[18:14] <mup> PR snapcraft#2997 closed: specifications: progressive delivery <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
[18:20] <ijohnson> alright I'm back from lunch and hopefully my internet is stable again
[18:30] <mup> PR snapd#8270 closed: store: support for search API v2 <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8270>
[18:32] <mup> PR snapd#8381 closed: tests: skip lxd test <Simple 😃> <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8381>
[18:33] <mup> PR snapd#8383 opened: store: support for search API v2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8383>
[18:38] <mup> PR snapd#8384 opened: tests: run "lxd" test again (reverts PR#8381) <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8384>
[18:39] <mup> PR snapd#8380 closed: tests: add LXD_CHANNEL environment <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8380>
[18:41] <mup> PR snapd#8379 closed: many: comment or avoid cryptic snap-ids in tests <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8379>
[18:50] <cachio> zyga, hey, I see this in bionic https://paste.ubuntu.com/p/KfDCxsxTcS/
[18:50] <zyga> checking
[18:51] <cachio> this is the branch which tests the image weekly update
[18:51] <zyga> (except it does not load)
[18:52] <cachio> zyga, same errror for mount-ns:inherit
[18:52] <zyga> hmm
[18:52] <zyga> ok, now it loaded
[18:52] <ijohnson> zyga: cachio: looks like there's a new mount for efivars, is this with a new / different image ?
[18:52] <zyga> oh
[18:52] <zyga> efivars
[18:52] <zyga> you've booted a efi system
[18:53] <cachio> it is a new image
[18:53] <cachio> ijohnson, not sure if efi is enabled on that one
[18:53] <ijohnson> hmm I wonder if we need a different set of expected mount ns data files for this new bionic image
[18:53] <ijohnson> cachio: how is the bionic image different? is it just updated ?
[18:53] <mup> PR snapcraft#2998 opened: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
[18:54] <cachio> I'll check because ubuntu cloud is enabling efi in many new images
[18:54] <zyga> cachio: were we booting in legacy bios before?
[18:54] <zyga> cachio: I'm pretty sure this is not specific to bionic
[18:54] <zyga> it's been there forever (since 2004) if you used efi
[18:54] <cachio> checking focal
[18:54] <zyga> I could be wrong but just check you systems
[18:54] <zyga> do you have that mounted?
[18:54] <ijohnson> hmm yeah if that's the case it's easier to change the singular bionic image dataset, it would be annoying though if we get different images and have to have different datasets
[18:55] <cachio> focal works well
[18:55] <zyga> I'm happy to have a efi vs legacy bios dataset for specific releases assuming it's a one way trend
[18:55] <ijohnson> I mean I have that mounted but I also use a UEFI system so I don't think that's representative
[18:55] <zyga> cachio: can you run "bootctl"
[18:55] <zyga> cachio: on that new image
[18:55] <zyga> and tell me what it prints?
[18:55] <ijohnson> cachio: is this happening on all bionic images now?
[18:56] <cachio> I just saw that in the new one
[18:56] <cachio> which I created to update the image
[18:56] <cachio> ijohnson, let me check on travis
[18:57] <zyga> cachio: can you please check bootctl
[18:57] <zyga> cachio: are images somehow packaged with information on how to boot them
[18:57] <zyga> ?
[18:57] <cachio> in that image, I am creating it again
[18:59] <cachio> zyga, I am starting the instance
[18:59] <cachio> to run bootctl
[18:59] <zyga> thanks
[18:59] <zyga> cachio: when you start the instance, do you use GCE dashboard?
[18:59] <zyga> cachio: I wonder if there's any information about how it boots there
[19:00] <zyga> (I'm not familiar with GCE)
[19:00] <cachio> I can check that
[19:00] <zyga> that FS would for sure not be mounted on legacy boto
[19:00] <zyga> *boot
[19:00] <zyga> and since we've never seen it before it's the only explanation I can think of
[19:00] <cachio> zyga, https://paste.ubuntu.com/p/yqqsVTRyPR/
[19:01] <zyga> yeah
[19:01] <zyga> this is botoed in efi mode
[19:01] <zyga> can you boot the previous image?
[19:01] <zyga> I mean, that's not bad, we can adjust the test to just expect this
[19:01] <zyga> if you want to take it forward in EFI mode
[19:01] <cachio> zyga, yes
[19:01] <zyga> please just let me know if we know how this happened
[19:01] <zyga> if this is something GCE changed
[19:01] <zyga> or we (ubuntu publishing the images) changed
[19:01] <zyga> or what?
[19:01] <zyga> and let me know
[19:02] <zyga> it's late so I won't touch this today
[19:02] <zyga> but I can adjust this easily tomorrow
[19:02] <cachio> ubuntu is publishing the images with that chagne
[19:02] <cachio> I just install some dependencies on top of that
[19:02] <zyga> can you ask the cloud team about this change
[19:02] <cachio> and do some other configurations
[19:02] <zyga> is this an accident
[19:02] <zyga> or something they did on purpose
[19:03] <cachio> zyga, this is the old one https://paste.ubuntu.com/p/nW94yvZKV6/
[19:04] <zyga> hmmm
[19:04] <zyga> so it's also booted with efi
[19:04] <cachio> zyga, do you know who is the main contact for asking that?
[19:04] <zyga> I don't know
[19:04] <zyga> but it seems that there's more to it than that
[19:04] <zyga> ah
[19:04] <zyga> sorry
[19:04] <zyga> I'm blind
[19:04] <zyga> wrong tab
[19:04] <zyga>     Not booted with EFI
[19:04] <zyga> so the old image was legacy
[19:04] <cachio> yes
[19:04] <zyga> new image is EFI
[19:05] <zyga> ask around in ubuntu-server maybe
[19:05] <zyga> or check the directory for a contact person that will redirect you
[19:05] <cachio> ok
[19:05] <zyga> you can file a bug and assign it to me to fix the test to handle EFI
[19:05] <zyga> just include that diff from the test
[19:05] <zyga> and if you can, a way to run against the new image to confirm
[19:05] <cachio> zyga, sure, thanks
[19:05] <zyga> thank you for bringing this up :)
[19:15] <mup> PR snapcraft#2998 closed: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
[19:18]  * zyga fires up final test and goes home
[19:18]  * zyga waves
[19:18] <zyga> see you tomorrow ijohnson, cachio and cmatsuoka
[19:18] <ijohnson> have a good night zyga
[19:19] <cmatsuoka> good night zyga
[19:24] <cachio> zyga, see you
[19:24] <cachio> zyga, lp:1869788
[19:25] <cachio> thanks
[19:35]  * cachio afk
[20:00] <mup> PR snapcraft#2999 opened: requirements: uprev python-apt to 1.6.0 (bionic package) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2999>
[20:57] <mup> PR snapcraft#3000 opened: repo: use python-apt's fetch_binary implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3000>
[21:21] <mup> PR snapcraft#3001 opened: repo: type annotations and mypy fixes for base <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3001>
[21:30] <mup> PR snapcraft#3002 opened: repo: use functools.lru_cache for dpkg -L queries <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3002>
[22:36] <mup> PR snapcraft#3003 opened: repo: always use host source lists and remove those found in plugins <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3003>


[20:25] <slashd> I have a preseed trying to configure two differents disks, I haven't been able to make it works until I configure the second disk using the 'late_command' ref: http://askubuntu.com/questions/542327/how-do-i-preseed-partman-recipe-two-disks
[20:25] <slashd> is there a bug or preseed limitation to configure two disks ?
[20:36] <slashd> I think I found my answer : B.4.6. Partitioning
[20:36] <slashd> Using preseeding to partition the harddisk is very much limited to what is supported by partman-auto. You can choose to partition either existing free space on a disk or a whole disk. The layout of the disk can be determined by using a predefined recipe, a custom recipe from a recipe file or a recipe included in the preconfiguration file. It is currently not possible to partition multiple disks using preseeding.
[20:36] <slashd> https://www.debian.org/releases/lenny/ia64/apbs04.html.en
[20:37] <lborda> slashd, sweet :)


[01:26] <DB42> to whoever fixed the usb quirk for the "microsoft sound system 80" thanks, it works perfectly now
[08:03] <Johninky> hello all
[08:03] <Johninky> Can I ask a quick question please, might take a long answer
[08:04] <Johninky> How can I take .inf file and create a driver for ubuntu 8.04
[08:05] <Johninky> or would it work, I have tried ndisgtk and  ndiswrapper
[08:24] <mjg59> Johninky: You can't
[08:24] <Johninky> I can what
[08:24] <Johninky> cant^^
[08:25] <Johninky> oh never mind I was a little slow on that one
[08:25] <Johninky> sorry
[09:02] <kraut> moin
[16:43] <DB42> i moved from 7.10 to 8.04 in my laptop and now i have no wifi and no ethernet
[16:44] <DB42> can i downgrade to ipw3945 ?
[16:44] <DB42> ipl is giving me lots of errors and isn't working
[16:46] <DB42> is there a ipw3945 .deb i can d/l for 8.04 ?
[16:53] <DB42> is there an IPW3945 PACKAGE for UBUNTU 8.04 ??
[16:57] <rtg> DB42: install linux-backports-modules in order to get iwlwifi 1.2.25
[17:00] <DB42> ok i've submitted bug report with my problem: https://bugs.launchpad.net/ubuntu/+bug/219268
[17:00] <ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New]
[17:01] <DB42> rtg: hmm
[17:02] <rtg> DB42: support in 1.2.25 for the 3945 is a little better.
[17:02] <DB42> rtg: which one is for the -generic ?
[17:02] <DB42> rtg: is there a way to revert to ipw /
[17:03] <DB42> for the time being ?
[17:03] <DB42> (without moving to 2.6.22)
[17:03] <rtg> DB42: ipw is gone.
[17:03] <DB42> no .deb package ? :|
[17:03] <DB42> i tried compiling it, no go
[17:03] <DB42> rtg: which backports do i need to install for 2.6.24-16-generic ?
[17:04] <rtg> DB42: try 'sudo apt-get install linux-backports-modules-hardy'
[17:05] <DB42> installing now
[17:05] <DB42> rebooting laptop, let's hope for the best
[17:06] <DB42> i need to do anything after instaling and before rebooting ?
[17:06] <rtg> DB42: nope
[17:08] <DB42> btw this is a backport from what ? 8.10 ?
[17:08] <DB42> :( same error
[17:08] <DB42> problem still there
[17:09] <DB42> it's 1.2.25
[17:10] <DB42> rtg: any other idea ?
[17:10] <rtg> DB42: looking...
[17:12] <DB42> btw, using wicd as network manager if it's of any use
[17:14] <rtg> DB42: what kind of AP connection are you trying to make? WPA Enterprise? Add that to the LP report as well as any noise from /var/log/syslog. Attach it to the LP report, not pastebin. I'll make sure Intel sees the bug report.
[17:14] <DB42> WPA yes
[17:15] <DB42> hmm.. i'll try an unsecure one, and see if it works
[17:15] <rtg> DB42: personal or enterprise?
[17:15] <DB42> personal
[17:18] <mdz> BenC: is it possible to do sysrq-like actions programmatically, e.g. through sysfs or proc?
[17:18] <DB42> rtg: another problem
[17:18] <DB42> my ethernet card isn't working in 2.6.24-16-generic as well ...
[17:18] <mdz> there's /proc/sysrq-trigger...
[17:18] <DB42> hwlist -C networ tells me it's disabled
[17:19] <BenC> mdz: probably, but if the hang is "system", then I'm not sure that would help
[17:19] <mdz> BenC: yeah
[17:20] <rtg> DB42: the rt8139 is well supported. Is this an HP laptop?
[17:20] <mdz> is it possible to serially debug our kernel without modifications?
[17:20] <BenC> I'm getting a base install so I can run the erase command from command line
[17:20] <DB42> rtg: check the bug report, lenovo 3000 n100
[17:20] <DB42> it's an 8139too driver
[17:21] <DB42> i connect a ethernet cable and i don't get in dmesg "link up or down" but the module for 8139too is loaded
[17:21] <rtg> DB42: i see it now. Is the cable plugged in (since you've been using wireless) ?
[17:21] <DB42> yeah
[17:22] <rtg> DB42: never mind
[17:22] <DB42> it's plugged in, but doesn't apear in ifconfig
[17:22] <DB42> and nothing in dmesg
[17:22] <BenC> cjwatson, soren: does blockdev-wipe run on the physical drive, or on the encrypted lvm?
[17:22] <mdz> BenC: the former
[17:23] <rtg> DB42: 'ifconfig -a' ?
[17:23] <BenC> So the fact that this happens for encrypted is just that blockdev-wipe gets run when it normally doesn't
[17:23] <mdz> BenC: well, it runs on the device underlying the encrypted one, AIUI
[17:23] <DB42> rtG: i see eth0 and eth1
[17:23] <mdz> not the physical drive but an unencrypted block device
[17:23] <BenC> mdz: so the wipe isn't being encrypted, right?
[17:23] <rtg> DB42: eth0 is likely the realtek controller.
[17:23] <DB42> yeap
[17:23] <BenC> ok
[17:23] <DB42> check my dmesg on the bug report
[17:24] <mdz> BenC: I think not, but I don't have it in front of me
[17:24] <DB42> it has the RealTek anme there
[17:24] <mdz> alt+f2 during the erase and ps
[17:24] <rtg> DB42: what happens if you 'sudo ifconfig eth0 up'
[17:24] <DB42> rtg: i need to go to a place with ethernet connection and check :)
[17:24] <DB42> sec
[17:25] <mdz> BenC: lib/crypto-base.sh:crypto_wipe_device in partman-crypto
[17:26] <mdz> BenC: seems to say it is in fact writing through dm-crypt when it does the wipe
[17:26] <DB42> rtg: thanks, eth works now
[17:27] <rtg> DB42: so, pluggin it in to a switch fixed it?
[17:27] <DB42> no
[17:27] <DB42> ifconfig eth0 up did
[17:27] <rtg> DB42: hmm. Are you running NetworkManager?
[17:27] <DB42> no, as i said i'm using wicd
[17:27] <rtg> DB42: wicd only works on wireless, right?
[17:27] <DB42> NM didn't work well with my wireless card in 7.10
[17:28] <DB42> nop, wired as well
[17:28] <rtg> DB42: you ought to try NM again. maybe it'll work better with the i3945.
[17:29] <DB42> rtg: i'm trying to conect unencrtyped now and see if it's ok
[17:29] <DB42> how so ? the problem is in the microcode..
[17:29] <DB42> and when i boot to 2.4.22 for wifi now (on 8.04) i still need the wicd
[17:29] <DB42> and i can't have them both
[17:29] <rtg> DB42: indeed, but it could be a function of the kind of packets being transmitted. who knows.
[17:29] <BenC> mdz: so does d-i call blockdev-wipe for this progress?
[17:30] <mdz> BenC: yes
[17:30] <rtg> DB42: you could boot with the lice-cd and try it. that way you don't have to re-install.
[17:30] <rtg> s/lice-cd/live-cd/
[17:30] <DB42> rtg: i rather d/l it when the final is out :|
[17:31] <mdz>         /bin/blockdev-wipe -s 65536 $dev > $fifo &
[17:31] <DB42> also don't have media to burn it on
[17:31] <mdz> [...]        while read x <&9; do
[17:31] <mdz>                 db_progress STEP 1
[17:31] <rtg> DB42: the RC was announced an hour ago.
[17:32] <DB42> btw, i reported a bug in my sound card and did a system update 2 days after, and the bug disappered :)
[17:32] <DB42> that was pretty cool
[17:32] <rtg> DB42: probably a function of updated ALSA in LUM.
[17:33] <BenC> mdz: I can't get blockdev-wipe to reproduce from command line
[17:33] <DB42> the model i had needed to be added to usbquirks.h or so
[17:33] <DB42> (it worked ok in 7.10, but not in 8.04)
[17:34] <mdz> BenC: soren was trying that as well
[17:35] <BenC> The fact that blockdev-wipe output is useless after 24 lines doesn't help either
[17:35] <BenC> wonder if I can easily wrap it in some shell script to put the asterisks on a single line instead of separate
[17:36] <CYREX> I see that the release candidate includes the 2.6.24-16.30 of Ubuntu but will the final version include Kernel 2.6.25 since it came out yesterday
[17:36] <mdz> BenC: | grep -n --line-buffered ''
[17:36] <DB42> CYREX: how so ?
[17:36] <rtg> CYREX: no
[17:36] <DB42> CYREX: 8.04 is freezed already
[17:37] <CYREX> is frozen mean no kernel changing
[17:37] <DB42> mean no change at all besides bug fixes
[17:37] <DB42> mean no change at all besides bug fixes
[17:37] <CYREX> oki thank you
[17:38] <BenC> mdz: not particularly supported by busybox grep
[17:38] <BenC> :)
[17:38] <mdz> oh, you're in d-i
[17:38] <BenC> figure that's the best way to repro it
[17:38] <mdz> BenC: |while read x; do date; done ?
[17:39] <mdz> or similar
[17:40] <DB42> rtg: i'm trying a manual connection, how do i list SSIDs ?
[17:43] <rtg> DB42: sudo iwlist wlan0 scanning
[17:44] <DB42> i get "Failed to read scan data: Resource temporarily unavilable"
[17:45] <rtg> DB42: probably because the firmware has crashed.
[17:46] <DB42> tried removing / reloading the iwl, didn't help ..
[17:47] <DB42> i'll try restarting with no wifi, seing if it helps
[17:47] <DB42> how do i blacklist auto-loading of iwl3945 @ boot ?
[17:47] <DB42> (in kernel boot lie)
[17:51] <BenC> mdz: | while read x; do echo -n "$x"; done
[17:51] <rtg> DB42: add it to /etc/modprobe.d/blacklist
[17:51] <BenC> that worked
[17:52] <DB42> rtg: yeah i wanted it in boot though (since i already reboot)
[17:52] <DB42> but nm, i did a check
[17:52] <DB42> it happens as soon as i type in CLI "iwlist eth1 scan" without even using a network manager
[17:52] <DB42> i updated my bug report to reflect it
[17:53] <DB42> https://bugs.launchpad.net/ubuntu/+bug/219268
[17:53] <ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New]
[17:54] <DB42> welp for now i guess i'll go back to 2.4.24
[17:54] <DB42> i mean 2.6.22 ... :)
[17:54] <DB42> rtg: no .deb package no backport no nothing for ipw ? :|
[17:55] <rtg> DB42: nope. the regulatory daemon is gone.
[17:57] <DB42> what is "LBM" and "LUM" ?
[17:57] <rtg> linux-backports-modules, linux-ubuntu-modules
[17:58] <DB42> k
[17:58] <DB42> now for the big test, checking if hibernation is fixed in 8.04 for my laptop :)
[18:06] <DB42> yippy
[18:06] <DB42> cool, the cpu fan seems to work after hibernation
[18:06] <DB42> it didn't in 7.10
[18:08] <DB42> so rtg need anything else for my report ?
[18:08] <DB42> will the intel people respond on the bug report itself ?
[18:09] <rtg> DB42: they might, but I think they are losing interest in 3945 in favor or more recent adapters (4965)
[18:10] <DB42> ouch :(
[18:11] <DB42> well if this isn't a specific case of mine, there are still lots of people with 3945 out there (the lenovo 3000 n100 is popular i belive)
[18:11] <DB42> i also think it might be tramuatic for some users that load ubuntu and won't have wifi
[18:11] <rtg> DB42: it doesn't fail for everyone, but I have seen the microcode issue before.
[18:12] <DB42> is there any documentation of the chipset that can tell me what is that specific error ?
[18:12] <rtg> DB42: not that I'm aware of
[18:13] <BenC> mdz: I'm starting to wonder if this is a blockdev-wipe issue...from one run to the next, it goes at different speeds
[18:13] <BenC> like now I'm at 47%, and it would have been done by now on the run before this
[18:14] <mdz> BenC: what are you using for the source? urandom?
[18:16] <mdz> BenC: there's some debugging available if you recompile it, but it's pretty dead simple
[18:17] <BenC> mdz: the stock d-i one, so it's /dev/zero
[18:17] <BenC> mdz: does d-i use default /dev/zero, or does it -f=/dev/urandom?
[18:17] <mdz> BenC: urandom, I believe
[18:17] <BenC> where is the d-i log kept nowadays?
[18:18] <mdz> BenC: oh, nm
[18:18] <mdz> it's using /dev/zero, but writing through a random cryptoloop
[18:18] <BenC> ok
[18:18] <mdz> so blockdev-wipe writes zeros, but what gets written to the device should be random
[18:18] <BenC> ok
[18:18] <mdz> maybe the intervening cryptoloop is what's getting hung up
[18:19] <mdz> are you setting that up in your test environment?
[18:19] <BenC> well, what gets written isn't really random, just encrypted 0's
[18:20]  * BenC chuckles at encrypted 0's
[18:21] <rtg> BenC: maybe it would go faster with unencrypted zeroes :)
[18:22] <BenC> -f=/dev/unencrypted-zeroes
[18:22] <BenC> ENODEV
[18:27] <BenC> mdz: I'm using the devices setup by d-i
[18:27] <BenC> switching to console
[18:28] <BenC> ...after partman runs
[18:30] <mdz> BenC: well, it's encrypting with a random key from /dev/urandom, so it should be pretty random
[18:30] <mdz> I wonder why it does it this way rather than just writing random data to the device
[18:30] <BenC> Ok, I just got a completely different hang
[18:30] <mdz> straight from /dev/urandom to whatever without going through device-mapper
[18:30] <BenC> during dhcp...keyboard started it up again...
[18:31] <BenC> wonder if that's a red herring, or for real hang like we are seeing otherwise
[18:32] <BenC> whoope, nope, same hang repeated
[18:32] <BenC> mdz: Ok, this isn't blockdev-wipe related then
[18:33] <BenC> I got network dhcp screen to hang twice in a row
[18:33] <BenC> stayed at 100% until I hit shift key
[18:33]  * BenC starts to blame kvm
[18:34] <BenC> and note that even though nothing in d-i uses the mouse, the kernel and kvm both pay attention to it, so that would explain the kickstart from it as well
[18:34] <mdz> BenC: others (including jdstrand) have reported hangs in other parts of the installer
[18:34] <BenC> 3 times dhcp hung...
[18:34] <mdz> even before partitioning
[18:35] <BenC> shift key reliably starts it back up
[18:35] <mdz> there is, as far as I know, only one unconfirmed report of this happening outside of KVM
[18:35] <BenC> right, so I'm thinking these are two separate bugs
[18:36] <BenC> One in kvm (dunno if it's userspace or kernel), and one on that specific bit of hardware
[18:36] <BenC> I'm going to try this -server install on some hardware to try and reproduce
[18:37] <mdz> BenC: dendrobates said that mathiaz experienced some mysterious unreproducible hangs on real hardware when doing server enablement, but I have no information
[18:37] <BenC> Bringing dendrobates here, hopefully hash this out a bit more
[18:37]  * BenC summons the frog
[18:38] <mdz> I pasted him a log excerpt
[18:41] <dendrobates-> BenC: here
[18:41] <mdz> dendrobates-: I can always tell when you're here because my xchat-gnome window resizes to accomodate your nick
[18:45] <mdz> kirkland: are you able to reproduce this easily?
[18:45] <kirkland> mdz: I have not reproduced this at all
[18:45] <kirkland> mdz: I've only tried on real hardware
[18:45] <mdz> ah, I see
[18:45] <BenC> dendrobates: I reproduced the hang...but, I was able to reproduce it during dhcp as well as during crypt erase
[18:46] <kirkland> mdz: and with a 300G drive, the device zero'ing takes FOREVER
[18:46] <mdz> Ben and I are starting to think that the primary bug here is kvm-specific
[18:46] <mdz> and there may be a separate issue or two which are hardware-specific
[18:46] <mdz> kirkland: you can manually adjust the size of the device to mitigate that; I did it yesterday
[18:46] <BenC> dendrobates: so this isn't specific to blockdev-wipe usage...which leads to believe even more than what we are seeing in kvm is not likely the same bug as what was reported on real hw
[18:47] <kirkland> BenC: have you given any thought to the empty entropy suggestion one commenter gave?
[18:47] <dendrobates> even in kvm it is not limited to blockdev-wipe.
[18:47] <BenC> kirkland: blockdev-wipe uses /dev/zero, and a key, so there's no entropy involved
[18:48] <BenC> kirkland: plus, it's not just during that operation
[18:48] <kirkland> BenC: right, my question is probably more d-i specific...  anywhere else in the installer that might rely on /dev/random?
[18:48] <mdz> kirkland: not on a recurring basis
[18:48] <dendrobates> both jdstrand and I are seeing it appear at various places during the install, but it always occurs during blockdev-wipe.
[18:48] <kirkland> particularly something that might have been introduced in hardy, since this is looking like a regression since gutsy
[18:49] <mdz> I think the encryption aspect is a red herring
[18:49] <dendrobates> mdz: I do as well.
[18:49] <mdz> the installer just spends a lot of time (and makes a lot of system calls) there
[18:50] <dendrobates> All I know for sure is that it is easy to reproduce with lvm+crypt.
[18:53] <BenC> I'm going to try and reproduce under kvm on gutsy
[18:53] <BenC> that should give us a reliable answer
[18:54] <dendrobates> we have already tried to reproduce it installing Gutsy on a Hardy kvm, with no success.  That seems to point to someting in Hardy.
[18:55] <BenC> dendrobates: Ok, I'll try the other way (install hardy on gutsy)
[18:55] <BenC> dendrobates: but yeah, that's an interesting point too
[18:56] <dendrobates> I am going to try a pre-beta hardy image.
[18:57] <dendrobates> I have a daily build from dec-5
[18:58] <BenC> All I have are 32-bit 7.10 CD's
[18:58] <BenC> Where are the gutsy live cd's?
[18:59] <mdz> BenC: http://releases.ubuntu.com/7.10/
[18:59] <dendrobates> BenC: can't you reproduce it in 32bit?
[18:59] <BenC> thanks
[18:59] <BenC> dendrobates: I'm sticking with what soren told me...haven't tried 32-bit yet :)
[19:00] <BenC> well, I did on my laptop, but it wouldn't repro there
[19:00] <dendrobates> BenC: OK, it does not seem to matter though.
[19:04] <BenC> That's an interesting regression
[19:04] <BenC> hardy nv driver only does 800x600 on my plasma screen, while gutsy starts up at 1280x1024
[19:07] <BenC> Ok, I happen to have 32-bit handy, so I'll try that
[19:12] <dendrobates> I was not able to reproduce it with an older hardy iso, but,  the hardy daily from Dec does not do the erase on lvm+crypt, which is the most reliable way I have found to reproduce it.
[19:13] <dendrobates> mdz: do we have an archive of the daily builds somewhere?
[19:14] <dendrobates> or the alpha releases?
[19:15] <mdz> dendrobates: slangasek would know
[19:15] <mdz> I'm sure we do, but I don't know where
[19:15] <mdz> (of milestones at least)
[19:54] <BenC> hmm
[19:54] <BenC> This might not be possible to test
[19:55] <BenC> Gutsy kvm doesn't support the gfx boot it seems
[19:56] <JanC> BenC: there is a sed line to "fix" the gfxboot issue
[19:56] <JanC> (if that's useful)
[19:56] <BenC> Sure
[19:57] <dendrobates> B$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso
[19:57] <BenC> dendrobates: thanks
[19:57] <dendrobates> a little brutish, but it works.
[19:57] <BenC> can I hexedit it instead? :)
[19:58] <JanC> it's documented on https://wiki.ubuntu.com/KvmVirtManagerEtc#head-80f0e334a1de270252f62ac69183da2ed58edf3f
[19:58] <JanC> (the sed line)
[19:58] <JanC> BTW: does anybody know when vmware server & which version will be available for hardy?  (question from someone I know who uses it professionally)
[20:02] <BenC> yep, hexedit is much faster, it solved it, thanks
[20:07] <arcticpenguin380> what processor is ubuntus kernel optimized for?
[20:08] <JanC> arcticpenguin380: depends on which kernel you mean  ;)
[20:08] <arcticpenguin380> hardys.
[20:09] <JanC> hardy has several kernels included
[20:09] <JanC> but -generic kernel is optimized for 686 IIRC
[20:09] <arcticpenguin380> are all hardys kernels 2.6.24?
[20:09] <JanC> yes
[20:11] <arcticpenguin380> oh and is ext4dev compiled?
[20:14] <JanC> I don't think so
[20:15] <JanC> well, /proc/filesystems doesn't list it
[20:43] <BenC> soren: is there supposed to be a way to make kvm emulate 64-bit when running under a 32-bit kernel?
[20:44] <BenC> otherwise, I gotta download a 32-bit -server CD :/
[21:13] <soren> BenC: No can do.
[21:35] <BenC> Ok, I'm off, and will return in a few hours to continue tracking this down (and over the weekend)
[21:47] <DB42> rtg: here ?
[21:48] <DB42> rtg: http://ubuntuforums.org/showthread.php?p=4612681 fixes the problem
[22:26] <sn9> is anybody actively working on Bug #88746? if so, i'm willing to provide needed info
[22:26] <ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [Undecided,Invalid] https://launchpad.net/bugs/88746
[22:27] <sn9> having usb2 broken in feisty, gutsy, _and_ hardy is a bit much
[22:31] <sn9> for perspective, i've had the very same issue on a different machine with a different chipset, a different usb device, and a different distro
[22:31] <sn9> the common element appears to be multifunction usb devices
[22:32] <crimsun> do any of the workarounds ... work for you?
[22:33] <sn9> modprobe -r ehci-hcd
[22:33] <crimsun> so in the absence of a fix that works for everyone, you at least have a viable workaround
[22:34] <sn9> the rest are a bit hard to keep track of
[22:34] <sn9> and that workaround is NOT viable, just like the bug comments say
[22:35] <sn9> after all, apparently that workaround _does_ work for _everybody_
[22:36] <crimsun> that's precisely what I mean.
[22:36] <crimsun> /you/ have a viable workaround.
[22:36] <sn9> huh?
[22:36] <crimsun> I asked if any of the workarounds work for /you/, and you responded with "modprobe -r ehci-hcd"
[22:37] <crimsun> (obviously it's not preferable)
[22:37] <sn9> but you said "in the absence of a fix that works for everyone" -- either there's no such absence or there's no such fix
[22:39] <sn9> there's a reason ehci-hcd isn't just blacklisted by default
[22:39] <crimsun> as we're both well aware, and I have no interest in arguing
[22:40] <sn9> so far, i have not encountered any machine with an amd cpu where ehci-hcd works with a multifunction usb device
[22:40] <sn9> strangely, it seems ok on p4's
[22:45] <sn9> what i'm interested in is contributing to whatever efforts to fix this issue once and for all
[22:45] <tjaalton> crimsun: any fix on the horizon for snd_hda_intel suspend/hibernate issue (needs to be removed after resume, otherwise no sound)?
[22:47] <crimsun> tjaalton: I don't head up sound anymore (and haven't for a year).  What's the issue?
[22:47] <crimsun> tjaalton: meaning, I need to know what HDA codec/model is affected
[22:47] <tjaalton> crimsun: oh sorry.. let's see..
[22:48] <tjaalton> crimsun: 8086:293e I guess
[22:48] <crimsun> need the line afterward.
[22:48] <crimsun> (`lspci -nv|grep -A1 0403')
[22:49] <tjaalton> Subsystem: 1043:829f
[22:50] <crimsun> I can guess that's a Realtek, but can you confirm by looking in /proc/asound/card0/codec#0?
[22:51] <tjaalton> yeah.. Realtek ALC883
[22:51] <tjaalton> shame on intel..
[22:52] <crimsun> tjaalton: ok, please pastebin that codec spew.
[22:53] <tjaalton> crimsun: http://pastebin.ubuntu.com/7440/
[22:53] <crimsun> thanks, looking
[22:53] <tjaalton> does it need some hal/suspend quirk?
[22:54] <sn9> hmm, i just tried a suspend, and no more sound...
[22:54] <sn9> ALC885
[22:58] <crimsun> interesting, there's no unmute for autoconfig
[22:58] <crimsun> tjaalton: I presume you're not passing a model= in /etc/modprobe.d/* ?
[22:59] <tjaalton> crimsun: nope
[22:59] <sn9> i know i'm not -- it gets config from the bios
[23:04] <crimsun> tjaalton: ok, I'll ping you.  Looking closer.
[23:05] <tjaalton> crimsun: excellent, thanks


[08:29] <oSoMoN> good morning
[08:37] <Saviq> hello
[08:49] <apinheiro> njpatel, one question, looking at this method QuicklistView::IsMenuItemSeperator(int index)
[08:50] <apinheiro> and at the objects
[08:50] <apinheiro> it seems that a quicklistmenu item can have a label, no matters if it is a quicklistmenuitemlabel or  not
[08:50] <apinheiro> right?
[08:51] <apinheiro> hmm, the question is not really clear
[08:52] <apinheiro> can I assume that only quicklistmenuitemseparator will be a separator?
[09:16] <njpatel> apinheiro, yes, you can assume that safely :)
[09:27] <apinheiro> njpatel, ok, thanks
[09:35] <nigelb> njpatel: Heya! Do you think you'd have time to give a session at User Days about Unity Lenses? https://wiki.ubuntu.com/UserDays
[09:35] <nigelb> (Mostly about using)
[09:39] <njpatel> nigelb, I _should_ be able to, but I'm not sure if I'm away those days, let me find out and get back to dyou
[09:43] <nigelb> njpatel: Great! Thanks. Once you're sure you can pick a slot yourself or just let me know whats a convinient time :)
[10:35] <Saviq> any comments on whether that's a sane approach http://pastebin.ubuntu.com/689057/ to fix https://bugs.launchpad.net/unity-2d/+bug/801073 ?
[10:36] <Saviq> what I'm yet unsure how to follow on, are custom shortcuts for other LauncherItems
[10:37] <Saviq> and now that I think about it, it won't help with shortcuts interpreted outside of the launcher :/
[10:37] <Saviq> e.g. what's mentioned on the bug - using Super+Tab to switch between windows
[10:53] <Saviq> Kaleo: ^
[11:07] <Kaleo> Saviq: that won't do it unfortunately
[11:07] <Kaleo> Saviq: it has to work for any key press happening at the same time as the super tap
[11:07] <Kaleo> Saviq: that is, for keys that Unity 2D does not control
[11:07] <Saviq> yeah I know
[11:08] <Kaleo> Saviq: just read your comment :)
[11:08] <Kaleo> Saviq: ok :)
[11:08] <Saviq> ah so you mean if during SuperkeyHeld
[11:08] <Saviq> any other key is pressed
[11:08] <Saviq> just ignore that
[11:08] <Kaleo> Saviq: yes
[11:08] <Saviq> so we need to monitor all the other keypresses
[11:08] <Kaleo> Saviq: for example, some laptops for some reason use Super+L for switching video output
[11:08] <Kaleo> Saviq: that's right
[11:09] <Kaleo> Saviq: and we don't want the dash to show up when the user presses Super+L quickly
[11:09] <Saviq> yeah obviously
[11:09] <Saviq> ok, on it
[11:10] <Kaleo> Saviq: thanks
[12:02] <smoser> my unity-2d-panel right now is taking up 865M resident
[12:04] <smoser> I'm running 'system-load-indicator', could that possibly causing leaks in unity-panel-2d ?
[14:44] <greyback> mardy, hey would you like me to review the grid_view stuff you did?
[14:44] <mardy> greyback: sure, you're most welcome! :-)
[14:45] <greyback> mardy, ok, I wasn't certain what "Abstain" meant
[14:47] <mardy> greyback: I accidentally set it on "resubmit" myself, then I didn't find a way to remove my own review, so I changed it to "abstain" :-)
[14:48] <greyback> mardy: aha, see :)
[14:50] <greyback> mardy, interestingly, you've also managed to fix something I just logged: bug:850036
[14:51] <mardy> greyback: good to know! :-)
[14:51] <greyback> mardy: hmmm, no, not quite :(
[14:51] <mardy> greyback: I hope it doesn't make it worse, at least :-)
[14:52] <greyback> mardy: it's working a lot better anyway. That was a nasty bug
[14:55] <greyback> mardy: oh you're really gonna hate me now!
[14:56] <mardy> greyback: maybe ;-)
[14:57] <davidcalle> Kaleo, hi
[14:58] <Kaleo> davidcalle: hi
[14:59] <davidcalle> Kaleo, are you the one who implemented the HorizontalRenderer in Unity-2D?
[15:01] <Kaleo> davidcalle: yep
[15:02] <davidcalle> Kaleo, great, I have a small problem with it, non square images are enlarged to fit the tile http://ubuntuone.com/4hJIk1CeAboeNXsKv0T1ZP
[15:02] <davidcalle> Kaleo, do you want a proper bug report on this?
[15:10] <Kaleo> davidcalle: I'm not sure I see the non square case in that screenshot
[15:10] <Kaleo> davidcalle: definitely, a bug report would be grand
[15:12] <greyback> Kaleo: "would be grand" :P
[15:12] <davidcalle> Kaleo, silly me, it sure could be useful to provide you a reference... Same icons with the vertical renderer http://ubuntuone.com/1SSTc5J23VFLFK5piS9GAD Bug report on its way, thanks a lot :-)
[15:14] <Kaleo> greyback: :p
[15:14] <Kaleo> davidcalle: got it :)
[15:14] <Kaleo> davidcalle: excellent, thank you for that
[15:15] <cyphermox> mpt: hey
[15:16] <cyphermox> mpt: can I get your opinion of https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/834495 ? better to have icons that are almost invisible in some themes, or no icons at all?
[15:17] <cyphermox> unfortunately special-casing the icons to ship dark when the theme is light and the other way around would be complicated
[15:30] <OwaisL> In some cases especially with the panel at some level of transparency. Mono icons become invisible when opening the dash as the panel changes colour too. Usually happens with light panel+dark icons
[15:46] <mpt> cyphermox, that's a false choice, it works in 11.04
[15:47] <mpt> and I'm pretty sure there was a bug report about it previously
[15:47] <cyphermox> mpt what do you mean?
[15:47] <cyphermox> it "works" in as much as the icons are already there, but afaik they would be just as not very visible
[15:47] <mpt> Basically the menu should be using -symbolic, which mono provides, while the Edit Connections window uses the standard icons that don't
[15:47] <cyphermox> -symbolic?
[15:47] <mpt> "don't" = "mono doesn't provide, I mean
[15:50] <cyphermox> both things use the exact same icons
[15:50] <mpt> cyphermox, exactly, they shouldn't
[15:50] <cyphermox> this is done because normally the icons will match the theme throughout, what nm-connection-editor does is ask what theme is used, that's all
[15:53] <mpt> cyphermox, what does it do with that information?
[15:53] <cyphermox> well, just get the theme used, to know what the icon theme is, then load the icon from that theme
[15:54] <mpt> cyphermox, why does it do that? Why doesn't it just use the icon name?
[15:55] <cyphermox> mpt, it's equivalent. just getting the icon name will also get the one from the current theme
[15:55] <cyphermox> you ask for the icon name, the theme will be used unless the icon is unavailable, then it will start to use fallbacks
[15:55] <cyphermox> however the icon *is* always availa
[15:56] <cyphermox> because it's the same as we use for the indicator icons
[15:56] <cyphermox> (or largely the same, especially for wired)
[16:00] <mpt> cyphermox, what are the names of the icons used?
[16:01] <cyphermox> nm-device-whatever; so -wired, -wireless, -wwan and -unknown, IIRC
[16:01] <cyphermox> -unknown is a possibility but should never be reached, so we can safely forget it
[16:01] <cyphermox> oh, I forgot -vpn
[16:04] <mpt> cyphermox, so, the mono themes should provide, and the network menu should be using, -wired-symbolic, -wireless-symbolic, -wwan-symbolic, etc
[16:04] <mpt> cyphermox, then Humanity or Hicolor should provide, and the Edit Connections window should be using, -wired, -wireless, -wwan, etc.
[16:06] <cyphermox> can you point me to where this symbolic stuff is defined? I know nothing of it and it all sounds a little confusing
[16:06] <cyphermox> e.g. defined as in documented
[16:06] <mpt> Depending on the age of the code it might be using -panel rather than -symbolic
[16:08] <mpt> aha
[16:08] <cyphermox> I can't find anywhere on my system an icon named -symbolic (and -panel has *very few*)
[16:08] <mpt> cyphermox, bug 541882 is where the equivalent bug was fixed for the Sound Preferences.
[16:09] <mpt> Looks like maybe it is supposed to be -panel, to avoid clashing with future -symbolic icons that work differently.
[16:30] <mpt> cyphermox, oh, snap
[16:30] <mpt> we commented at the same time
[16:30] <cyphermox> d oh
[16:30] <cyphermox> :)
[16:30] <cyphermox> well, I understand it better now, though I'm pretty unhappy that this means yet more delta from upstream and debian
[16:30] <cyphermox> but I think with careful work, this can be corrected
[16:31] <mpt> cyphermox, there shouldn't be any delta except in the menu, which is all delta anyway, right?
[16:31] <mpt> And why do you need new icons at all?
[16:31] <cyphermox> mpt: less and less
[16:31] <cyphermox> I'm working on getting the patches upstream
[16:31] <mpt> Well then, even in the menu, exactly the same code would work regardless of theme
[16:32] <mpt> If you're using an icon theme that doesn't have -panel icons, it falls back to the standard ones
[16:32] <cyphermox> well, seems to me like it should be new icons, ubuntu-mono needs to have a dark version of say, nm-device-wired, and a light version. the light one will be used in the panel, the dark one in the UI.
[16:32] <cyphermox> past that I don't really care much how they are done or what the name is, as long as it's implementable in code and doesn't destroy other themes
[16:33] <mpt> cyphermox, are you sure that Humanity or Hicolor or something else in the fallback stack doesn't have them already?
[16:33] <cyphermox> pretty sure
[16:33] <mpt> cyphermox, well if they don't, why doesn't it malfunction upstream?
[16:34] <mpt> Does upstream have versions of Humanity or Hicolor that have more icons than ours?
[16:34] <cyphermox> hicolor just has colored icons, and that works no matter if your panel is dark or light
[16:34] <mpt> cyphermox, right, that's what you want here
[16:35] <mpt> Again comparing to the Sound Preferences, the volume icons there are slightly colored too
[16:35] <cyphermox> but the name of the icon used in the code is always the same here, I use nm-device-wired for both the panel and connection editor, that's how it's done upstream
[16:35] <mpt> cyphermox, exactly!
[16:36] <mpt> cyphermox, so step 1, change the names in the menu code, adding -panel
[16:36] <mpt> Step 2, change the names in the mono theme, again adding -panel
[16:37] <mpt> The Edit Connections window code remains unchanged
[16:37] <cyphermox> mkay, now this makes sense
[16:39] <cyphermox> mpt: finally, you know the icons will look different in ubuntu-mono and humanity at least for wired?
[16:40] <cyphermox> in ubuntu-mono we have arrows, in humanity what I find now is two connectors of some sort, looks a bit like a belt
[16:40] <mpt> cyphermox, if anything, that's a feature ... Mono's wired icon is not very good :-)
[16:40] <cyphermox> alright.
[16:41] <cyphermox> care to update the bug so that it's clear as you described it above?
[19:20] <mamed> hey
[19:20] <smoser> is unity-2d-panel leaking extremely badly for others ?
[19:21] <mamed> guys
[19:21] <mamed> i removed unity it was so slow but i loved global menu . i want it back (i mean global menu) can you help me?
[19:21] <smoser> I'm using 4.6.1-0ubuntu1, its been up for < 8 hours, and sucking 1.1G resident.
[19:22] <smoser> Kaleo, ^ ?
[19:22] <mamed> noone will help i think
[19:23] <smoser> mamed, you could try unity-2d. i dont think that the unity panel was expected to function without the rest.
[19:26] <htorque> smoser: is it unity-2d-panel or the unity-panel-service (bug 835646)?
[19:26] <smoser> unity-2d-panel is what shows in top
[19:26] <htorque> ok, then that's not that
[19:27] <smoser> i run 'system-load-indicator' which might be what differenciates me from stock
[19:28] <smoser> i just killed unity-2d-panel, and quit the system-load-indicator. i'll see if that is less leaky
[19:28] <htorque> smoser: i'm running that here as well, though using normal unity. haven't seen it leaking.
[19:38] <smoser> well, its visably still leaking for me. started off at 32M resident, its alrady up to 46M in 10 minutes.
[19:40] <Kaleo> smoser: hi, let me see
[19:41] <Kaleo> smoser: that's not good, can you file a report with the specifics of your configuration please?
[19:43] <smoser> Kaleo, what sort of specifics ?
[19:43] <smoser> bug 850320 opened
[19:44] <htorque> smoser: that gotta be similar to bug 835646 - you can trigger the memory raise by opening any program
[19:44] <htorque> e.g., check mem usage, run start and quit gimp, check mem usage again
[19:44] <smoser> hm... htorque i dont know. i dont start a lot of GUI problems.
[19:44] <smoser> programs.
[19:45] <smoser> i dont actually think i've *started* an X11 program in the last 15 minutes
[19:45] <smoser> i do use 'gnome-open' fairly extensively though for opening urls in firefox.
[19:46] <htorque> smoser: maybe just coincidence, will monitor it a bit and confirm if it raises on without any action.
[19:46] <smoser> well its hard to do *no* action
[19:46] <smoser> :)
[19:46] <htorque> heh, true
[19:46] <smoser> for one, you just made my launcher panel come out, and the indicator panel light up by saying my name
[19:48] <smoser> i'll let others figure out if its a dupe or not.
[19:50] <htorque> smoser: did you switch between windows a couple of times during that period? seems to raise on every switch here (~500kb each time).
[19:52] <smoser> yeah. switching desktops seems to make it leak
[19:56] <macer1> Hi. What is ayatana doing exactly? I mean...is it managing Ubuntu look and feel and thinks like that?
[20:00] <macer1> ?
[20:02] <Omega> macer1: it tries to improve the user experience of ubuntu and applications on ubuntu
[20:03] <macer1> cool :D
[20:03] <Omega> so yes look and feel are all part of what ayatana does
[20:03] <Omega> https://wiki.ubuntu.com/Ayatana
[20:04] <macer1> I am running oneiric now. Ayatana made very good work on imporiving user experience :)
[20:04] <Omega> :)
[20:06] <macer1> i want to report a bug about some dropped gestures/keys like Ctrl+D in compare to natty. does it affect ayatana or only unity?
[20:07] <macer1> maybe ayatana deleted Ctrl+D to show desktop, to give better user experience :D
[20:13] <Omega> macer1: yes it affects ayatana
[20:14] <Omega> if it is a design change, it affects ayatana
[20:14] <macer1> hmm...is there a list of changes like that?
[21:17] <jderose> tedg: what's the correct, modern way to save and restore an app's window size and position?
[21:17] <tedg> jderose, Great question :-)
[21:17] <tedg> jderose, It seems to be falling on apps to do today, but my personal believe is the WM/session manager should help there.
[21:17] <jderose> hehe
[21:17] <tedg> jderose, But they're not today.
[21:18] <tedg> belief
[21:18] <jderose> yeah, it does seems like a weird thing for the app to manage... so that being the case, how should an app to this?  what's "the tedg way"? :)
[21:24] <tedg> jderose, You can just grab your position from you window and restore it.  Honestly, i think you probably should just have a good default.
[21:24] <jderose> yeah
[21:24] <tedg> It's quick to maximize, which is really what most people want anyway.
[21:24] <tedg> Especially with a video editor.
[21:25] <jderose> yeah :)
[21:28] <jderose> tedg: so just call Window.maximize() before I call Window.show_all()?