[05:39] <mborzecki> morning
[05:54] <zyga> Hey
[05:54] <zyga> Taking the dog out
[05:54] <mborzecki> zyga: found anything interesting about the lxd issue?
[06:03] <mborzecki> zyga: reading through https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652 nice find!
[06:03] <mup> Bug #1871652: snap run hangs on system-key mismatch due to reexec and shutdown <champagne> <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed for zyga> <https://launchpad.net/bugs/1871652>
[06:14] <mborzecki> mvo: hey
[06:14] <mvo> good morning mborzecki
[06:15] <mborzecki> zyga: hm i was worried that maybe the client gets stuck, but looking at the backtrace the client timeout seems to work
[06:16] <mborzecki> zyga: i think that the unfortunate part is that the client timeout (overall timeout for all retried requests) is 50s, then *12 retries in snap run, we're looking at 10 minutes after which snap run would fail eventually
[06:18] <zyga> mborzecki: it's debugged
[06:18] <zyga> :)
[06:18] <zyga> mborzecki: if you are talking about the lxd issue
[06:18] <zyga> mvo: good morning :)
[06:18]  * zyga woke up in good mood and just returned from dog & bike ride
[06:18] <mvo> zyga: good morning! you seem to be in a good mood :) ?
[06:18] <zyga> indeed
[06:18] <mborzecki> zyga: i know, just looking at the backtrace you posted there, https://github.com/snapcore/snapd/pull/8462 and the client.do() loop
[06:18] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[06:19] <zyga> yesterday surely ended on a high note
[06:19] <zyga> I have some more thoughts about how this problem is annoying
[06:19] <zyga> but I think the fix is valid
[06:19] <mvo> mborzecki: yeah, a timeout of 10min seems a bit excessive
[06:19] <mvo> zyga: yeah, I like hte idea to just check for shutdown
[06:20] <mborzecki> mvo: there's this comment that isn't true anymore https://github.com/snapcore/snapd/pull/8462/files#diff-0ffbc404d8a8e3aaeca8cd9d066c3d71R160
[06:20] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[06:20] <mborzecki> uhh it's `// connect timeout for client is 5s on each try, so 12*5s = 60s`
[06:21] <mvo> mborzecki: uh, so it looks like we try to accomodate thie situation already? is that check buggy?
[06:21] <mvo> mborzecki: also if the retry timeout should be max 60s but in reality is 10min is there a different bug there too :( ?
[06:22] <zyga> I can debug this further
[06:22] <zyga> I wanted to check the solution in practice
[06:22] <zyga> the socket is there
[06:22] <zyga> but will never activate
[06:22] <mborzecki> mvo: probably the client retry bits evolved separately
[06:22] <zyga> maybe we just hang on connect?
[06:22] <zyga> ahhh
[06:22] <zyga> fiun
[06:22] <zyga> hhe
[06:22] <mborzecki> zyga: yeah
[06:22] <zyga> ok, I'll get back to my coffee
[06:23] <mvo> mborzecki: aha, yeah, that makes sense
[06:23] <zyga> but I'm happy :)
[06:23] <mvo> mborzecki: sorry, I see these lines are from an open PR
[06:23] <mborzecki> if the socket wasn't there it would fail much earlier i believe
[06:23] <mvo> zyga: woah, thanks so much for adding this PR so quickly
[06:23] <zyga> :D
[06:23] <zyga> after breakfast I'll verify this
[06:24] <zyga> and write some tests
[06:24] <mvo> zyga: yeah, having a test there would be great
[06:24] <mborzecki> zyga: mvo: so actually a funny scenario, the socket we use to talk to snapd is there, but snapd may be inactive, how do you find out that the other end is inactive if poking th socket isn't reliable?
[06:24] <zyga> any issues with spread?
[06:26] <zyga> mborzecki: we should think about how to prevent the bug for real
[06:26] <zyga> mborzecki: I realized it's much harder because the dependency is dynamic
[06:26] <zyga> mborzecki: we depend on the active reexecution target that may be core or snapd and the revisions may change at runtime any number of times
[06:27] <zyga> mborzecki: which is not great
[06:31] <zyga> mvo: so 2.44... 4?
[06:31] <mvo> zyga: 2.44.3
[06:31] <zyga> perfect
[06:31] <zyga> thank you
[06:31] <mvo> zyga: I hope I can upload that today
[06:31] <mvo> tonight
[06:31] <mvo> something like this :)
[07:00] <mborzecki> hmm preseed reset is failing in an intresting way
[07:01] <mborzecki> saw the same rpoblem twice already
[07:01] <zyga> yeah I noticed
[07:01] <zyga> did you debug it more? I didn't look deeper
[07:01] <mborzecki> the log https://paste.ubuntu.com/p/gTcdq4h8CF/
[07:14] <pstolowski> morning
[07:15] <zyga> good morning pawel
[07:17] <mborzecki> pstolowski: hey
[07:17] <mborzecki> pstolowski: preseed reset hangs on 20.04 https://paste.ubuntu.com/p/gTcdq4h8CF/
[07:17] <mborzecki> pstolowski: but i'm not able to reproduce it manually
[07:17] <mvo> pstolowski: good morning
[07:19] <pstolowski> mborzecki: interesting, i'll take a look
[07:22] <mborzecki> doing 'restart all jobs' in gh actions is actually very confusing
[07:23] <mborzecki> looks like it's first restating the unit tests job, then the canary jobs, and then the stable ones
[07:23] <mborzecki> and E: Failed to fetch http://pkg.jenkins.io/debian-stable/binary/jenkins_2.222.1_all.deb  Could not connect to pkg.jenkins.io:80 (<IP_ADDRESS>), connection timed out
[07:26] <jamesh> presumably it is respecting the job dependencies: the stable jobs can't restart until the restarted canary jobs have completed, which can't restart until the restarted unit tests have completed
[07:27] <zyga> jamesh: exactly
[07:27] <zyga> mborzecki: yeah, they don't invalidate past results until such jobs actually start
[07:27] <zyga> mborzecki: if it's a one off failure like that just ask mvo to override
[07:27] <zyga> no use in burning money on this
[07:31] <zyga> can I get a 2nd review on green https://github.com/snapcore/snapd/pull/8403
[07:31] <mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
[07:31] <zyga> it's not much and I'd like to get it in and have one less
[07:35] <zyga> jdstrand: thank you for the reviews
[07:35] <zyga> I'll break for breakfast and then get back to work
[07:36] <mvo> zyga: which PR is that? I can override if needed
[07:43] <pedronis> pstolowski: I reviewed #8414, thank you
[07:43] <mup> PR #8414: o/configstate: core config handler for persistent journal <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
[07:43] <pedronis> couple small comments
[07:50] <pstolowski> pedronis: ty
[07:52] <pstolowski> mborzecki: yeah, hangs for me too when run on gc. will try to add some debug
[07:53] <mborzecki> pstolowski: oh, you manged to reproduce it?
[07:54] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/8462#pullrequestreview-390565291
[07:54] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[07:54] <pstolowski> mborzecki: it seems so.. it's hanging on < /mnt/cloudimg/var/lib/snapd/desktop/applications, i'm waiting for spread to timeout
[07:55] <mborzecki> pstolowski: ha, interesting, i ran with -shell and executed the test line by line
[07:55] <mborzecki> pstolowski: btw. diff -up is easier to read there
[07:55] <pstolowski> mborzecki: also it's interesting it found a diff
[07:58] <mup> PR snapd#8450 closed: selinux: export MockIsEnforcing; systemd: use in tests <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8450>
[08:00] <zyga> mvo: not sure, it was pawel
[08:00] <zyga> mborzecki: ta
[08:00]  * mborzecki wonders why it's showing `degraded` here
[08:01] <zyga> mborzecki: systemctl --failed
[08:02] <mborzecki> zyga: yeah, that's the mystery, shadow.service apparenty failed :P
[08:02] <zyga> shadow.service?
[08:02] <zyga> what is that
[08:02] <zyga> I don't have it
[08:02] <zyga> is it related to homed?
[08:02] <mborzecki> zyga: idk maybe https://paste.ubuntu.com/p/f7hkWx94vQ/
[08:03] <zyga> which package ships that?
[08:04] <mborzecki> zyga: surprise surprise.. `shadow` :P
[08:05] <mborzecki> zyga: btw it runs the following /bin/sh -c '/usr/bin/pwck -r || r=1; /usr/bin/grpck -r && exit $r'
[08:09] <zyga> pwck?
[08:09] <zyga> wow
[08:09] <zyga> I learned something today already
[08:09] <zyga> YoU HaVe BeEn Hax0rEd
[08:16] <zyga> re
[08:20] <mborzecki> zyga: yeah, from what i managed to find it checks /etc/group against /etc/gshadow
[08:20] <zyga> so is something corrupted on your system?
[08:21] <mborzecki> zyga: nah, i had a `sudo` group at some point that was listed in gshadow, but got removed from /etc/group
[08:23] <mborzecki> zyga: probably something went out of sync during one of my arch 'installs', that's actually rsyncing whole sysroot from another arch system, wouldn't be surprised since the actuall install from scratch was years ago
[08:43] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8462 again please
[08:43] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[08:50] <mvo> zyga: thanks for adding the test to 8462
[09:01] <zyga> mvo: I'll verify this in the machine where it is easy to reproduce now
[09:02] <mvo> zyga: \o/
[09:14] <zyga> I believe I can write a spread test for this as well
[09:29] <mvo> zyga: extra browny points if that is possible and not too much work
[09:29] <zyga> mvo: I think so, just a moment to know
[09:30] <mvo> zyga: \o/
[09:30] <zyga> mvo: gotta justify a push to fix that silly typo :D
[09:45] <zyga> test in progress
[09:51]  * mvo hugs zyga
[10:01] <ijohnson> morning folks
[10:01] <ijohnson> hey zyga I saw this failure for session-tool on one of my PR's that is relatively up to date with master https://pastebin.ubuntu.com/p/tj9qTTN6Wf/
[10:01] <ijohnson> looks like it's a gdm issue with 19.10?
[10:01] <zyga> yeah
[10:01] <zyga> I saw it, I asked sergio to remove gdm
[10:01] <pstolowski> hi ijohnson !
[10:01] <ijohnson> ok
[10:01] <zyga> I'll send a patch to stop the gdm session
[10:01] <ijohnson> o/ pstolowski
[10:01] <zyga> though
[10:01] <zyga> maybe I should remove that part of the test
[10:01] <zyga> it's not like we are leaking our sessions
[10:02] <zyga> it's just a goose chase
[10:02] <zyga> ijohnson: what do you think?
[10:02] <ijohnson> mmm it's a bit annoying, but in this instance also genuinely useful to have it tell us that something is on the image that is leaking state around
[10:02] <ijohnson> I dunno
[10:03] <pstolowski> is it related to the bug sergio raised recently? https://bugs.launchpad.net/snapd/+bug/1868857
[10:03] <mup> Bug #1868857: Installing evolution-data-server on test images pulls in GDM and the desktop <snapd:Triaged> <https://launchpad.net/bugs/1868857>
[10:04] <zyga> pstolowski: yes
[10:04] <zyga> after checking and checking I managed to convince him we have GDM :)
[10:07] <zyga> brb
[10:10] <ijohnson> mmm okay another random failure from overnight about being unable to connect to the systemd user session: https://pastebin.ubuntu.com/p/QdyVGHHDrJ/
[10:11] <pstolowski> mborzecki: this preseed-reset hang issue is misterious; i added debug that should show up right after the last diff line where it hangs , but it's quiet :/
[10:11] <pedronis> pstolowski: core-persistent-journal is failing on core16
[10:12] <pstolowski> pedronis: yeah, i've seen this, didn't happen when run locally, investigating
[10:15] <mborzecki> pedronis: mvo: i'm looking into the mount point rename
[10:27] <mvo> mborzecki: thank you
[10:30] <mborzecki> mvo: pedronis: i'll split the /run/mnt/host bind mount till after we have the directory in the core snap
[10:31] <mborzecki> i mean the /host directory
[10:31] <mvo> +1
[10:32] <zyga> afk for another moment, sorry :/
[10:42] <ijohnson> mvo: could you use your magical powers to merge https://github.com/snapcore/snapd/pull/8451 ? It's been restarted numerous times and all the current failures there have either been reproduced and known by others, or have been reported
[10:42] <mup> PR #8451: osutil: mock proc/self/mountinfo properly everywhere <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8451>
[10:44] <mvo> ijohnson: sure
[10:44] <mup> PR snapd#8451 closed: osutil: mock proc/self/mountinfo properly everywhere <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8451>
[10:44] <ijohnson> thank you \/o
[10:44] <ijohnson> oh whoops I was too excited
[10:45] <ijohnson> \o/
[10:45] <mvo> haha
[10:51] <pedronis> pstolowski: now, it passed, it seems flakey somehow
[10:55] <pstolowski> pedronis: yes, maybe there is something flaky. i'm running it in a loop locally now
[11:03] <zyga> re
[11:05] <mup> PR snapd#8464 opened: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[11:05] <mborzecki> mvo: pedronis: ^^
[11:05] <mborzecki> i did not add the /run/mnt/data -> /run/mnt/ubuntu-data bind mount too, let's see if the tests pass
[11:07] <pedronis> mborzecki: they won't, actually initramfs will need some changes
[11:07] <mborzecki> hmm ah right, there's some hard coded names there too
[11:07] <pedronis> mborzecki: https://paste.ubuntu.com/p/cF4NVBChbG/
[11:08] <mborzecki> looks like the bind mount data -> ubuntu-data could make it work tho
[11:08] <pedronis> yes, but we do want then to change the initrd
[11:09] <pedronis> because otherwise is a bit too many level of mounts
[11:09] <pedronis> mborzecki: also my pastebin has type -d (not sure why I did that), so there's a couple more things actually
[11:10] <pstolowski> pedronis: just run it 10 times without failure. weird. will give it one more spin
[11:10] <ijohnson> pedronis: mborzecki: suspicious that the initrd has things like this:
[11:10] <ijohnson>     echo 'LABEL=ubuntu-boot /run/mnt/ubuntu-boot auto defaults 0 0' >> /run/image.fstab
[11:11] <ijohnson> that seems like it would defeat the purpose of our cross-checking no?
[11:11] <pedronis> ijohnson: it's optimizing some mounts
[11:11] <pedronis> ijohnson: you'll have to discuss what that means
[11:12] <ijohnson> mmm yes
[11:12] <ijohnson> pedronis: is the results of the discussion this morning summarized somewhere ?
[11:13] <pedronis> ijohnson: seems you got the doc
[11:13] <ijohnson> yes mborzecki PM'd it to me
[11:14] <pstolowski> zyga: btw i've re-requested your review of #8414 as it changed substantially
[11:14] <mup> PR #8414: o/configstate: core config handler for persistent journal <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
[11:14] <zyga> ack
[11:14] <zyga> I'll look in 10 minutes
[11:18] <ijohnson> pedronis: I left a comment in the doc, so will we now have /run/mnt/boot instead of (or in addition to) /run/mnt/ubuntu-boot ?
[11:18] <pedronis> ijohnson: no
[11:18] <ijohnson> ok, so the changes are just for ubuntu-data really
[11:19] <ijohnson> (and all alter egos of ubuntu-data)
[11:19] <pedronis> ijohnson: yes, we'll have temporarely both data and ubuntu-data until initramfs is fixed
[11:19] <ijohnson> sure
[11:28] <zyga> pstolowski: looking
[11:33] <diddledan> jdstrand: possibly I'm still broken? https://forum.snapcraft.io/t/snapcraft-and-strict-multipass-call-for-testing/16488/5
[11:33] <Saviq> diddledan: yeah that's not something we're doing
[11:33] <diddledan> strangely at least two snaps have started fine, but those are desktop apps and I spent some time cooking toast
[11:34] <diddledan> ... after reboot, so I was well past apparmor starting when I logged-in
[11:35] <diddledan> Saviq, yeah LXD is also dead
[11:38] <zyga> pstolowski: +1
[11:39] <Saviq> diddledan: have a look at https://github.com/ubuntu/zsys/issues/60#issuecomment-609729305 for what fixed things for me on zfs root - not snapd, but the overall problem may be the same - look in the journal for things refusing to mount due to target not being empty
[11:44] <diddledan> it's not that.. I have a correct set of files in /etc/zfs-list.cache and there are no failed mounts in the journal
[11:46] <zyga> mvo: sorry for the lag, i have a test
[12:04] <zyga> I'm running a few more iterations to recheck if fails without the fix and to remove redundant parts
[12:04] <zyga> I'll push the final version before the standup
[12:05] <zyga> most likely in 20 minutes, after the next run
[12:06] <pstolowski> pedronis: 100 runs and no failure; i wonder if we were seeing a failure from before USR1 commit
[12:06] <pedronis> pstolowski: maybe, let's see if it gets green and can land
[12:07] <pstolowski> pedronis: doh.. it failed on 20.04
[12:08] <pstolowski> pedronis: on preseed-reset, which is the other issue i'm investigating
[12:08] <pedronis> pstolowski: could you recheck quickly my #8436 , I had to change the spread test because I remember it passing on core20 but actually the systemd there now uses a different property name
[12:08] <mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
[12:09] <pedronis> pstolowski: maybe we need an explicit journalctl --flush ? or do some activity that is none to produce logs?
[12:09] <pstolowski> pedronis: looking
[12:09] <pedronis> s/none/known/
[12:10] <pstolowski> pedronis: maybe, but it seems that enabling logging writes a single starting entry, so only question is if flush is needed
[12:11] <pstolowski> pedronis: but the problem is now preseed-reset test which breaks with master
[12:12] <jdstrand> diddledan: can you perform: sudo systemd-analyze plot > ./1871148-vm-no-varlib-mount_diddledan.svg' and attach it to https://bugs.launchpad.net/apparmor/+bug/1871148?
[12:12] <mup> Bug #1871148: services start before apparmor profiles are loaded <AppArmor:Invalid> <apparmor (Ubuntu):Fix Released by jdstrand> <zsys (Ubuntu):Invalid by jibel> <apparmor (Ubuntu Focal):Fix Released by jdstrand> <zsys (Ubuntu Focal):Invalid by jibel> <https://launchpad.net/bugs/1871148>
[12:12] <jdstrand> (without that trailing "'" of course
[12:12] <jdstrand> )
[12:21] <diddledan> jdstranddone :-)
[12:21] <diddledan> jdstrand done :-)
[12:22] <pstolowski> aaha, we started shipping var/lib/snapd/desktop/applications in the pkg, that's the primary reason of preseed-reset test failure
[12:38] <jdstrand> diddledan: https://bugs.launchpad.net/snapd/+bug/1871148/comments/24
[12:38] <mup> Bug #1871148: services start before apparmor profiles are loaded <AppArmor:Invalid> <snapd:New> <apparmor (Ubuntu):Fix Released by jdstrand> <zsys (Ubuntu):Invalid by jibel> <apparmor (Ubuntu Focal):Fix Released by jdstrand> <zsys (Ubuntu Focal):Invalid by jibel> <https://launchpad.net/bugs/1871148>
[12:39] <jdstrand> mvo, zyga: ^ I added a snapd task. please see my comment. it seems that root on zfs is aggravating the condition that apparmor.service might start after snap services
[12:39] <zyga> looking
[12:40] <jdstrand> since we don't see it on non-root-on-zfs systems (even though the possibility is there)
[12:40] <zyga> yeah, I think we need to think about how to handle this
[12:41] <jdstrand> mvo: this is possibly another 2.44 point release. up to you to decide, but with focal making zfs an option in the installer, and that seems to push the system into this bug more than others, ...
[12:42] <mup> PR snapd#8465 opened: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple 😃> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8465>
[12:44] <cachio> pedronis, hey
[12:44] <jdstrand> zyga: I need to step away, but maybe this is the time to align with non-Ubuntu-but-apparmor-enabled systems? I forget the details, but iirc, there is an additional snap-apparmor unit or similar that can be After apparmor, and then snapd can add After snap-apparmor to the units. I defer to you, mvo, etc on the design and am happy to review a PR
[12:44] <cachio> I see this error on uc20 nested tests
[12:44] <cachio> https://paste.ubuntu.com/p/sBWXC4VZyG/
[12:44] <cachio> is it something new?
[12:44] <cachio> first time I see this
[12:44] <zyga> jdstrand: that's a brilliant idea
[12:44] <zyga> jdstrand: we can just no-op if apparmor is of
[12:44] <zyga> *off
[12:44] <jdstrand> yeah
[12:44] <zyga> and we can always put the dependency into the units
[12:44] <jdstrand> yeah
[12:44] <zyga> mvo: ^ that's a solution that's easy
[12:45] <zyga> I can look at this after the current bug
[12:45] <jdstrand> diddledan: thank you for your persistence :)
[12:45]  * jdstrand -> steps away
[12:45] <mvo> zyga, jdstrand works for me
[12:46] <cachio> pstolowski, hey, I see also this error in nested test for uc20 Apr 09 12:08:53 ubuntu snapd[720]: hotplug.go:131: internal error: cannot get global device context: broken assertion storage, looking for model: broken assertion storage, cannot decode assertion: asser
[12:46] <mup> PR #9: Added the travis config file <Created by elopio> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/9>
[12:46] <cachio> pstolowski,  any idea?
[12:48] <pstolowski> cachio: no, maybe core20 requires something new to be done in that area, i'll need to investigate
[12:48] <cachio> pstolowski, thanks
[12:48] <pstolowski> #8465 should unbreak master
[12:48] <mup> PR #8465: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple 😃> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8465>
[12:48] <pedronis> it sounds like some code is running before seeding is done
[12:48] <pstolowski> mborzecki: ^
[12:48] <pedronis> I thought that code waiting on seeding
[12:49] <zyga> today is sponsored by <critical> tag
[12:49] <mborzecki> heh ;)
[12:49] <mvo> zyga: yeah, it totally is
[12:49] <mvo> it's the N-days before the release feeling
[12:50] <pstolowski> pedronis: it doesn't wait
[12:50] <pedronis> pstolowski: it waits for the system snap to be there at least
[12:50] <pstolowski> pedronis: right, that's true
[12:51] <pstolowski> mborzecki: for clarity, i pinged you about 8465
[12:51] <mborzecki> pstolowski: figured ;)
[12:52] <mborzecki> mvo: pedronis: added the compatibility bind mount, i can succesfuly go through the install mode, but it hangs in initramfs in run mode
[12:52] <mvo> zyga: so you are suggesting all our snap unit have "After=apparmor.service", is that what you said earlier? are you on it? should I?
[12:52] <mborzecki> mvo: pedronis: pushed a patch to #8464 anyway
[12:52] <mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[12:52] <mvo> mborzecki: please do, maybe something for dimitri
[12:53] <mvo> pstolowski: do we need 8465 for 2.44 as well as a cherry pick?
[12:53] <pedronis> mvo: we have no way to rewrite atm though
[12:53] <pedronis> to rewrite units
[12:53] <mborzecki> pstolowski: do you know what that blocked the test?
[12:54] <mborzecki> pstolowski: it would actually hit the kill timeout
[12:54] <mvo> pedronis: yeah, but at least all new focal install with zfs will not be affected if we have it now
[12:54] <pedronis> pstolowski: that's really weird because 131 is definitely after we are getting events
[12:56] <pedronis> something is very broken
[12:57] <pstolowski> mborzecki: not yet, as i said in the comment and standup notes i'm investigating; maybe qemu-nbd hangs when we leave execute. if i re-arrange the test to first unmount and clean up and then fail on diffing, it fails as expected and doesn't hang
[12:58] <pstolowski> mvo: probably yes
[13:28] <zyga> mvo: I've verified that the spread test fails without the fix and passes with the fix
[13:29] <zyga> mvo: I'll jump into the apparmor issue in a moment, after the call
[13:30] <diddledan> zyga, I take it from that the fix doesn't work? I'm understanding how CI testing works, right?
[13:31] <zyga> diddledan: ?
[13:31] <diddledan> :-p
[13:31] <zyga> diddledan: hopefully not :)
[13:31] <diddledan> fail test == fix works; passing test == shruggy shoulders no idea
[13:32] <diddledan> maybe it works?
[13:32] <mvo> zyga: \o/ thank you
[13:32] <diddledan> #shipit!
[13:38] <zyga> mvo: I pushed the test now
[13:44] <zyga> that was a nice bug
[13:45] <zyga> jdstrand: I'm looking after apparmor now
[13:54] <zyga> mvo: have a look at 8462 again please
[13:54] <zyga> maybe mborzecki as well
[13:54] <zyga> I'll get rid of my plate, grab coffee and jump into apparmor and zfs
[13:55] <mvo> zyga: sure, will do
[13:56] <ijohnson> pedronis: I merged master into 8424, the only thing missing there are tests for lsblk.go and the reimplementation of lsblk with sysfs + udev, which probably means we need to rename the file or maybe move it to it's own package somewhere
[13:56] <ijohnson> but all the logic in boot and cmd_initramfs_mounts should be there and that is tested and ready to review
[13:59] <pedronis> ijohnson: so I should focus on cmd_initramfs_mounts ?  and a bit on boot , if I understand correctly
[13:59] <ijohnson> pedronis: yes
[14:00] <pedronis> ok, having a break and then I will look
[14:00] <ijohnson> thanks
[14:02] <pedronis> zyga: btw, I didn't says this in the standup but I definitely prefer our snap services' units to be after something we control (or well defined from systemd) than a 3rd package service, we can control the dep on that one in one place at least
[14:02] <zyga> +1
[14:02] <zyga> yeah, I strongly agree
[14:02] <zyga> this is so much cleaner than vague dependency on apparmor in each of the service files we write
[14:06] <pstolowski> mvo: the script ijohnson linked requires greasemonkey which works on pretty much every browser
[14:08] <mborzecki> zyga: hah, so when a workflow is successful, there's no way to restart it
[14:08] <mvo> pedronis: should I cherry pick 8459 (omit many snap-ids) for 2.44.3 too?
[14:08] <mvo> pstolowski: nice!
[14:10] <zyga> mborzecki: yeah :)
[14:10] <zyga> mborzecki: I have some ideas on that though
[14:10] <mborzecki> omg, close/reopen didn't trigger anything
[14:10] <mborzecki> oh w8, it did
[14:11] <zyga> really?
[14:11] <zyga> oh
[14:11] <zyga> odd
[14:11] <zyga> there's a way to trigger on more
[14:11] <zyga> anyway
[14:11] <zyga> ENOTIME
[14:14] <mup> PR snapd#8466 opened: tests: backport partition fixes to 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8466>
[14:23] <pstolowski> oh, preseed-reset fix failed on 19.10
[14:24] <pstolowski> cachio: did you update 20.04 images but not 19.10?
[14:26] <cachio> pstolowski, I updated all of them
[14:27] <cachio> pstolowski, https://travis-ci.org/github/snapcore/spread-cron/builds/672701787
[14:30] <mvo> pstolowski: hm, 8465 failed in 19.10 in preseed-reset it seems, can you please have a look?
[14:30] <mvo> pstolowski: it's strange as it seems like the only place where it fails
[14:30] <pstolowski> mvo: yeah, i just noted this above
[14:30] <mvo> pstolowski: aha, sorry
[14:30] <pstolowski> mvo: i'm confused
[14:30] <pstolowski> mvo: did our deb packaging change made it to all ubuntu versions?
[14:31] <mvo> pstolowski: maybe not, the SRUs are notoriously slow :/
[14:31] <mvo> pstolowski: https://paste.ubuntu.com/p/SzwVMqT9GX/
[14:33] <pstolowski> mvo: yes, plus it needs to be on the image we download. oh well, i need to relax this test check then
[14:33] <mvo> ok
[14:33] <mvo> pstolowski: or just limit it to 20.04 for now?
[14:33] <pstolowski> mvo: good idea
[14:34] <cachio> pstolowski, do you need another update?
[14:35] <pstolowski> cachio: no, not for now, afaiu we need to snapd deb 2.44 to make it through
[14:35] <pstolowski> *to wait
[14:43] <cachio> mvo, I found that the nested machine is locked because it reaches 100% of cpu
[14:43] <cachio> and it has 1 cpu
[14:44] <cachio> most of the cases is when snapd is installing or removing
[14:52] <zyga> re
[14:52] <zyga> am I online?
[14:53] <pstolowski> zyga: no
[14:53] <zyga> haha :)
[14:54] <zyga> I managed to connect from my thinkpad
[14:56] <cachio> mvo, I'll try some qemu configuration to avoide this
[15:03] <jdstrand> zyga: fyi, I answered your question about offline and unknown in https://github.com/snapcore/snapd/pull/8462#discussion_r406269208
[15:03] <zyga> thank you, looking
[15:03] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[15:03] <zyga> jdstrand: I'm wrapping up the fix for apparmor now
[15:04] <jdstrand> zyga: but, then that got me thinking about: https://github.com/snapcore/snapd/pull/8462#discussion_r406270147
[15:04] <zyga> jdstrand: hmmm
[15:04] <jdstrand> zyga: these are not blockers imo
[15:04] <zyga> jdstrand: maybe
[15:04] <jdstrand> I have to step into a meeting
[15:04] <zyga> I need to go AFK for 10 minutes now
[15:06] <jdstrand> zyga: or maybe return nil (I mentioned that in a followup comment)
[15:07]  * jdstrand fully attends meeting
[15:07] <mborzecki> guys, i'm taking a day off tomorrow as well, ping me if there's anything urgent
[15:07] <mvo> cachio: nice, thank you
[15:07] <pedronis> ijohnson: I did a high-level pass on 8424,  let me know if you have questions
[15:07] <pstolowski> mvo: ok, i pushed a fix. tested manually on 19.10 & 20.04, should work. fingers crossed
[15:10] <mvo> pstolowski: cool, thank you
[15:11] <ijohnson> thanks pedronis looking now
[15:40] <zyga> I'm home now
[15:40] <zyga> mvo: testing apparmor fix now
[15:41] <zyga> it's so annoying we build depend on gcc-multilib
[15:41] <zyga> it clashes with cross compiler stack I use
[15:42] <mvo> zyga: thanks, looking forward to the PR
[15:44] <mup> PR snapd#8403 closed: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8403>
[15:45] <zyga> mvo: https://github.com/snapcore/snapd/pull/8462 is green, except for preseed-reset on ubuntu 20.04
[15:45] <mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
[15:45] <zyga> mvo: shall I merge it?
[15:45] <zyga> it's one patch
[15:49] <mvo> zyga: yes, sounds good
[15:49] <zyga> k
[15:49] <mvo> zyga: I will cherry pick then
[15:50] <zyga> mvo: release branch CI overflows 50minutes in travis
[15:50] <zyga> mvo: actually, you must merge it
[15:50] <zyga> required status check
[15:50] <mvo> zyga: just noticed but I think it also hang in the preseed
[15:50] <zyga> aha
[15:50] <zyga> I didn't look deeper
[15:50] <mvo> zyga: so hopefully once the preseed fix lnaded this is good again :)
[15:50] <zyga> focusing on apparmor
[15:50] <mvo> zyga: no worries
[15:50] <zyga> hmm
[15:50] <zyga> but
[15:50] <zyga> ah ok
[15:50] <mvo> zyga: yeah, looking forward to this fix
[15:55] <mup> PR snapd#8462 closed: cmd/snap: don't wait for system key when stopping <Security-High> <⚠ Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8462>
[15:55] <zyga> thanks!
[15:55] <mvo> zyga: I backed the system-key lxd fix to 2.44 (cc stgraber) - I still plan an upload tonight/in the morning
[15:55] <mvo> zyga: *thank you*
[15:55] <zyga> pleasure :)
[16:04] <stgraber> excellent, thanks zyga and mvo
[16:04] <zyga> stgraber: thank you for providing the perfect laboratory environment :)
[16:15] <ijohnson> mborzecki: how did you manage to duplicate the number of tests on 8464 ? o_O
[16:15] <ijohnson> > 37 successful and 3 failing checks
[16:18] <mborzecki> ijohnson: clearly gh wanted to test that PR thoroughly
[16:18] <ijohnson> it wanted to be double extra sure
[16:19] <mborzecki> each +1 doubles the tests
[16:19] <ijohnson> that would be kinda funny if gh just kept adding to the list, so if you have to restart tests like 4 times it would say "89 successful and 4 failing checks"
[16:21] <mup> PR snapd#8467 opened: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
[16:25] <zyga> mvo, jdstrand: ^
[16:26] <zyga> tested locally on my focal install
[16:26] <zyga> with lxd and systemd-analyze
[16:27] <zyga> I'll break for coffee and be back later (mvo: tg to summon me please)
[16:42] <pstolowski> 8465 failed on google:ubuntu-20.04-64:tests/main/interfaces-timeserver-control
[16:46] <alvesadrian> hello, there is something similar for after: on app: , I know after is only for parts but there is something like that in app:
[16:46] <pstolowski> Failed to restart systemd-timesyncd.service: Unit systemd-timesyncd.service is masked.
[16:46] <alvesadrian> I mean apps:
[16:48] <zyga> pstolowski: check what masks that service
[16:49] <alvesadrian> zyga, hello why after: is not accespted by snapcraft in apps: ?
[16:50] <alvesadrian> zyga there is something like after: from parts: in apps:?
[16:50] <zyga> I don't understand
[16:50] <alvesadrian> $ snapcraft
[16:50] <alvesadrian> Issues while validating snapcraft.yaml: The 'apps/ovs-vswitchd' property does not match the required schema: Additional properties are not allowed ('after' was unexpected)
[16:51] <zyga> I still don't understand
[16:51] <zyga> what do you mean after for parts?
[16:51] <alvesadrian> zyga parts: accept after:
[16:51] <alvesadrian> but it looks like u can use after: on apps:
[16:52] <zyga> yes but the meaning is different
[16:52] <zyga> what do you want to do?
[16:53] <alvesadrian> service or command orders after this do this
[16:56] <zyga> alvesadrian: https://snapcraft.io/docs/snap-format documents "after" for apps
[16:56] <zyga> alvesadrian: which version of snapcraft are you using?
[16:56] <alvesadrian> 2.44
[16:56] <ijohnson> alvesadrian: are your apps meant to be services/daemons ?
[16:56] <alvesadrian> ijohnson yes
[16:57] <zyga> alvesadrian: are you building in docker?
[16:57] <zyga> alvesadrian: snapcraft is at 3.11
[16:57] <zyga> alvesadrian: that version surely supports this construct
[16:58] <ijohnson> alvesadrian: you probably need to add `daemon: simple` or something to make sure your apps are daemons and not CLI/GUI "apps"
[16:58] <zyga> alvesadrian: snapcraft or snapd?
[16:58] <zyga> (I mean 2.44)
[16:59] <alvesadrian> snapcraft
[16:59] <ijohnson> alvesadrian: what's `snapcraft version` ?
[16:59] <alvesadrian>  snapcraft version
[16:59] <alvesadrian> snapcraft, version 2.43.1+18.4
[16:59] <ijohnson> alvesadrian: you should install snapcraft via the snap not the debian package
[16:59] <alvesadrian> bionic
[17:00] <ijohnson> alvesadrian: `apt remove snapcraft && snap install snapcraft`
[17:00] <jdstrand> is there a way with the new spread tests to re-run a specific job? it seems like twice now I only have 're-run all jobs'?
[17:00] <jdstrand> I'm talking about the github interface
[17:01] <zyga> jdstrand: not at present, ask mvo to override if this is a well-known failure that is fixed elsewhere
[17:01] <zyga> jdstrand: we discussed github actions vs travis and while there are some shortcomings as compared to travis we decided to keep the experiment alive for now
[17:02] <jdstrand> zyga: ok, so long as I'm not missing something. it seems that fedora is failing a lot.
[17:03] <jdstrand> something about reboot iirc
[17:03] <zyga> jdstrand: it's more that a specific test is failing,
[17:03] <jdstrand> I'll keep an eye on it
[17:03] <zyga> jdstrand: aha
[17:03] <zyga> thanks, maybe it's something new
[17:03] <zyga> there are a few fixes in flight that should get rid of most of those
[17:03] <zyga> jdstrand: on the upside actions lets us really run those tests as soon as possible, much faster than travis offered
[17:03] <jdstrand> zyga: it was a specific spread test related to core reboot *I *think*, don't jump on it now ;)
[17:04] <zyga> I won't, my goal is to focus on your feedback for udev PR
[17:04] <zyga> but I think tomorrow, today I just want to get the fixes ready
[17:04] <jdstrand> zyga: I also commented on the apparmor pr
[17:05] <jdstrand> (but only a comment at this point since you were still testing)
[17:05] <zyga> I noticed, going through that now! :)
[17:08] <Eighth_Doctor> popey: hey, I just noticed that the instructions for rhel are wrong: https://snapcraft.io/install/icq-im/rhel
[17:08] <Eighth_Doctor> snapd has been available in EPEL 8 for a while now
[17:08] <zyga> hey Eighth_Doctor :)
[17:09] <zyga> good to see you again
[17:09] <Eighth_Doctor> The CentOS instructions were updated, but apparently not the RHEL ones
[17:09] <Eighth_Doctor> zyga: hello :D
[17:09] <popey> hello Eighth_Doctor
[17:09] <Eighth_Doctor> how are you surviving?
[17:09] <zyga> Eighth_Doctor: with three kids at home
[17:09] <popey> they're editable on the forum now, which makes life easier
[17:09] <Eighth_Doctor> popey: hey
[17:09] <zyga> Eighth_Doctor: and parents-in-law
[17:09] <Eighth_Doctor> woo
[17:09] <popey> oh, or are they, no they are not
[17:09] <zyga> Eighth_Doctor: and overeager police that fines you for taking your dog out on a bike
[17:09] <popey> not *those* ones
[17:09] <zyga> Eighth_Doctor: splendind :)
[17:10] <zyga> Eighth_Doctor: we are lucky I have a job
[17:10] <jdstrand> zyga: I think I was wrong about suggesting ConditionPathExists: https://github.com/snapcore/snapd/pull/8467#discussion_r406351235
[17:10] <mup> PR #8467: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
[17:10] <Eighth_Doctor> I'm lucky I still have a job
[17:10] <Eighth_Doctor> living alone and not being able to meet people regularly has sucked
[17:10] <zyga> jdstrand: ack
[17:10] <popey> Eighth_Doctor is this correct? https://snapcraft.io/docs/installing-snap-on-red-hat
[17:11] <Eighth_Doctor> popey: yes
[17:11] <popey> oh look https://github.com/canonical-web-and-design/snapcraft.io/issues/2646
[17:11] <popey> :D
[17:11] <Eighth_Doctor> that's why I didn't notice for months :D
[17:11] <popey> thanks for noticing now, anyway :D
[17:12] <Eighth_Doctor> I only noticed today when somebody asked me about adding snapd for EPEL 8, which I distinctly remember doing this last year
[17:12] <Eighth_Doctor> popey: no problem :)
[17:13] <zyga> jdstrand: maybe we should not change the cache for the point release
[17:13] <zyga> jdstrand: I'm happy to do this for +1
[17:13] <zyga> not sure
[17:13] <zyga> mvo: ^
[17:15] <Eighth_Doctor> zyga: the loneliness and the fear of getting sick gets to me
[17:16] <Eighth_Doctor> but I've been doing fine so far for the past month
[17:16] <mvo> zyga: reading
[17:17] <mvo> Eighth_Doctor: hey, great to hear that you are fine (but yeah, the loneliness part is depressing :(
[17:18] <Eighth_Doctor> mvo: and my "community energy" is draining with nothing to refill it these days
[17:18] <Eighth_Doctor> no SUSECON, no CentOS Dojo, no Red Hat Summit, etc.
[17:18]  * mvo nods
[17:19] <Eighth_Doctor> I'm just begging for Flock and oSC to not get canceled in the fall
[17:19] <jdstrand> zyga: it is up to you
[17:20] <jdstrand> zyga: your snapd-apparmor already assumes /var/cache/apparmor, so it is fine to just add /var/cache/apparmor to RequiresMountsFOr
[17:20] <cachio> zyga, #8468
[17:20] <mup> PR snapd#8468 opened: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[17:20] <mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[17:20] <cachio> pleas could you take a quick look?
[17:20] <jdstrand> (ie, today, you aren't worrying about alternate locations and presumably not suffering bugs for it, so there is no need to change in the dot release)
[17:29] <mvo> zyga: just to double check - the unit in 8467 does nothing if both are available? there will be no races or apparmor compiling the same profile in parallel or something (cc jdstrand)
[17:51] <zyga> mvo: no because our service depends on the system service
[17:52] <zyga> mvo: so in practice, if the system service loaded snapd profiles nothing new happens
[17:52] <zyga> mvo: if it didn't we load the profiles
[17:52] <zyga> mvo: *but* the new dependency from snap.foo.bar.service to snapd.apparmor.service means the boot race is over
[17:52] <zyga> mvo: snapd.apparmor.service has After=apparmor.service, so they will be serialized
[17:55] <mup> PR snapd#8469 opened: snap: do not use os.Environ() in 2.44 <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8469>
[17:55] <zyga> mvo: I'll adjust the PR once to get the cache recommendation from jamie and remove the changelog
[17:56] <zyga> mvo: ah, thanks for that
[17:56] <zyga> I wasn't sure
[17:56] <mvo> zyga: nice
[17:56] <zyga> mvo: fix your PR please
[17:56] <mvo> zyga: which one?
[17:56] <zyga> https://github.com/snapcore/snapd/pull/8469#pullrequestreview-391010494
[17:56] <mup> PR #8469: snap: do not use os.Environ() in 2.44 <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8469>
[17:56] <zyga> =
[17:56] <mvo> zyga: fixing now, sorry
[17:57] <ijohnson> wow zyga you beat me to that by 10 seconds
[17:57] <zyga> :D
[17:57]  * zyga refrains from joking about stuff now
[17:58]  * mvo hugs ijohnson and zyga - awesome team!
[17:58] <ijohnson> :-)
[17:59] <mup> PR snapcraft#3023 closed: pluginhandler: move attributes to PluginHandler <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3023>
[18:01]  * mvo vanishes a bit while 2.44 builds are churning along
[18:02] <jdstrand> mvo: today, apparmor is looking at /var/lib/snapd/apparmor/profiles. if you can do a focal upload of snapd that makes you control it, I can do a focal apparmor upload that undoes it. Also, the snap-apparmor service is After=apparmor so there is no race. running one after the other is 'ok' because the speed at which the parser will load the cache into the kernel is essentially as fast as it can read from
[18:02] <jdstrand> the disk, unless it recompiles policy. the 2nd run will never recompile policy since it is After=apparmor
[18:03] <zyga> we are *burning* through spread jobs today!
[18:03] <jdstrand> mvo: we can consider an apparmor SRU to stop looking at /var/lib/snapd/apparmor/profiles at some future point if desired
[18:03] <jdstrand> mvo: we would probably wait for a bigger SRU bug and piggyback on it though
[18:06] <jdstrand> mvo: it would be good if you could ping me on when you are going to do a focal upload so I can do the apparmor one after
[18:06] <ijohnson> zyga: indeed, it is pretty responsive, and I even made the cardinal mistake of pushing an open PR branch 3 times in 5 minutes :-P
[18:13] <zyga> re
[18:13] <zyga> ok, back to branches
[18:15] <mvo> jdstrand: I will do a focal upload tonight or tomorrow with the .3 fixes
[18:16] <zyga> jdstrand, mvo: can we decide on the cache directory
[18:16] <zyga> shall I change it from /var/cache/apparmor?
[18:19] <jdstrand> zyga: I agree to not change in this PR
[18:19] <zyga> OK
[18:19] <zyga> I'll adjust the RequiresMountsFor
[18:19] <zyga> to add /var/cache/apparmor
[18:19] <zyga> and nothing else
[18:19] <jdstrand> yeah, just add /var/cache/apparmor to that
[18:19] <zyga> is that ok? (I want to do only one push)
[18:19] <zyga> OK
[18:20] <jdstrand> zyga: actually
[18:20] <zyga> yes?
[18:20] <zyga> (I won't push for a few more minutes so I'm open to changes :)
[18:21] <jdstrand> zyga: this will hit other releases of Ubuntu eventually. we should verify the cache locations of all of them
[18:21] <jdstrand> zyga: otherwise snapd-apparmor will fail on those where the cache isn't in /var/cache/apparmor
[18:22] <zyga> jdstrand: snapd.apparmor.service is a .deb only feature so we can correct anything we want at the time we choose to dput to the archive
[18:22] <jdstrand> zyga: so, snapd hardcodes /var/cache/apparmor when compiling policy, no?
[18:22] <zyga> jdstrand: having said that, you are right,
[18:22] <zyga> jdstrand: can we use the location?
[18:22]  * zyga checks
[18:23] <zyga> yes
[18:23] <jdstrand> zyga: I think that is accurate (though, yes, please check :). if so, I think the only question would be if a release doesn't have /var/cache/apparmor, then we create it in the deb packaging rather than have snapd create it
[18:23] <zyga> we hard-code /var/cache/apparmor
[18:24] <jdstrand> ok, good
[18:24] <zyga> jdstrand: given that we use this location in 14.04 already I _think_ we are safe
[18:24] <zyga> jdstrand: or are you saying we should mkdir the directory from the service to be safe?
[18:24] <jdstrand> ok, then yes, don't change it cause like you said, deb only item and we can verify the other deb uploads
[18:24] <jdstrand> zyga: no, for focal, that is the location that apparmor creates
[18:25] <zyga> jdstrand: oh, one thing before I forget: "systemd-analyze security"
[18:25] <zyga> I dind't know this before, perhaps it's new
[18:25] <jdstrand> zyga: I can look at the packaging real quick for all the releases
[18:25] <zyga> thank you
[18:27] <zyga> mvo, jdstrand: I pushed the updates to https://github.com/snapcore/snapd/pull/8467
[18:27] <mup> PR #8467: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
[18:27] <jdstrand> zyga: that is interesting. I wonder if it considers AppArmorProfile=.... today, it seems to primarily (understandably) care about its own nspawn/etc directives
[18:28] <zyga> jdstrand: I didn't look at what it checks but it's true that systemd has grown considerable vocabulary of sandboxing features over the years
[18:28] <mvo> zyga: ta
[18:28] <zyga> jdstrand: I would say it rivals snapd in some ways so it's a nice selection
[18:29] <zyga> Lucy has fever, oh buy
[18:29] <zyga> boy*
[18:29] <zyga> :/
[18:29] <jdstrand> zyga: ok, the apparmor package creates /var/cache/apparmor all the way back to trusty
[18:29] <zyga> good
[18:30] <zyga> so we're good
[18:30] <zyga> I think it's safe to keep this as-is for 2.44.3
[18:30] <jdstrand> yeah. just normal QA
[18:30] <zyga> we can do more in 2.45 without a time pressure
[18:30]  * jdstrand nods
[18:30] <zyga> we are at 25/32 workers so the changes should proces quickly
[18:31] <zyga> but I anticipate a small queue for about an hour while we go through the stuff that will spawn stable and unstable tests
[18:31] <zyga> mvo: I think we should aim for tomorrow morning
[18:31] <zyga> mvo: unless you want to dput at ~ 22
[18:31] <zyga> and I'll just get back to work to work on the feedback from jdstrand
[18:31] <zyga> btw, jdstrand are you available tomorrow?
[18:32] <jdstrand> zyga: I am working tomorrow, yes
[18:34] <zyga> ok
[18:34] <zyga> mvo: shall I stick around or are you OK for today?
[18:41] <mvo> zyga: all good for today
[18:41] <zyga> OK, signing off :)
[18:42]  * zyga EODs
[18:43] <mup> PR snapd#8465 closed: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple 😃> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8465>
[18:47] <mup> PR snapd#8470 opened: tests: update snap-preseed --reset logic to acommodate for 2.44 change (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8470>
[18:48] <mup> PR snapd#8466 closed: tests: backport partition fixes to 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8466>
[19:13] <pstolowski> mvo: thanks for merging my test fix!
[19:16] <pstolowski> mvo: and for the herry pick! huh, what are those all failures there
[19:17] <pstolowski> ah, i see another PR
[19:18] <mvo> pstolowski: yeah, some fallout from the divergence of 2.44 and master
[19:19] <mvo> pstolowski: I will wait for the tests and do the release tomorrow, I think its getting a bit too late
[19:23] <mup> PR snapcraft#3024 opened: tests: remove usage of FakeApt fixtures in lifecycle <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3024>
[19:32] <mup> PR snapcraft#3025 opened: tests: move FakeApt fixtures into deb tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3025>
[19:52] <mup> PR snapd#8469 closed: snap: do use os.Environ() in 2.44 <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8469>
[19:55] <mup> PR snapd#8471 opened: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8471>
[20:21] <mup> PR snapd#8470 closed: tests: update snap-preseed --reset logic to acommodate for 2.44 change (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8470>
[20:21] <mup> PR snapd#8472 opened: tests: disable some problematic tests for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8472>
[20:24] <mup> PR snapd#8467 closed: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8467>
[21:05] <mup> PR snapcraft#3024 closed: tests: remove usage of FakeApt fixtures in lifecycle <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3024>


[06:56] <ShapeShifter499> hi
[06:58] <ShapeShifter499> I have a ubuntu 22.04 server install and I am using it to compile some versions of android roms. I have run into an issue where I wanted to build an older rom that requires openssl1.1.1    Is there a recomended way to go about installing it along side the current openssl3.0 ?
[07:00] <ShapeShifter499> I could probably chroot an older ubuntu but I wanted to intergate some of these builds into jenkins builds
[07:14] <pvh_sa> @shapeshifter499 - can you build in a Docker container with the older version of things? Not sure if that would integrate with Jenkins
[07:17] <ShapeShifter499> I guess?  I'm a bit new there, never built projects using a docker container
[07:17] <ShapeShifter499> a few years ago I had been running 20.04 and I know everything worked there
[07:19] <ShapeShifter499> was there a reason why ubuntu didn't ship a legacy package?  also unless I misunderstand stuff it looks like 1.1.1 still gets security updates?
[07:20] <ShapeShifter499> considering they still ship old gcc, seems like maybe they should have also included openssl 1.1.1
[07:20] <lotuspsychje> !jammy
[07:21] <lotuspsychje> check on the releasenotes ShapeShifter499 a lot of usefull info on changes there
[07:27] <pvh_sa> the release notes don't really answer @ShapeShifter499's question for me - I get it, OpenSSL 3 is the new default - but e.g. on my Ubuntu 22.04 (upgraded from 20.04) machine I have libssl.so.1.1
[07:27] <ShapeShifter499> yeah
[07:29] <ShapeShifter499> it looks like I should be able to just manually compile openssl 1.1.1 and point the build to it
[07:29] <ShapeShifter499> I'll try that now
[07:32] <pvh_sa> could do I guess :) a closer look shows that my libssl1.1 comes from a package libssl1.1 that was discontinued in the move to openssl 3 (i.e. its there in focal and not there in jammy). I'd recommend learning to how to use a Docker build environment rather than compiling an old version... the investment it going to pay off
[07:34] <ShapeShifter499> is docker going to cause a lot of overhead though?
[07:34] <lotuspsychje> compile yourself is not supported and prob not the best secure idea
[07:34] <ShapeShifter499> lotuspsychje: how so?
[07:34] <ShapeShifter499> security wise
[07:35] <pvh_sa> nope... its not like a VM, its basically your existing kernel with a different userland. here's an ancient blog post on using such a blog environment - update for the ubuntu 20.04 that you want to use: https://sweetcode.io/using-docker-reproducible-build-environments/
[07:36] <pvh_sa> and another one - https://www.rainerhahnekamp.com/en/docker-build-environment/ - less detailed but more readable
[07:38] <pvh_sa> one of the key advantages of doing things this way is reproducibility - specify exactly the dependencies you want, from a known reliable source (i.e. the packages for ubuntu 20.04) and then you can re-do the builds on a different machine, etc with no worries that you might have forgotten some hand-tuning in your build.
[07:47] <ShapeShifter499> pvh_sa: I should be able to have the dependencies inside of the docker image and all of the compiled bits including source outside of it?
[07:48] <pvh_sa> the stuff that is "constant" is inside the image and the stuff that changes (typically the compiled code) is outside and mounted into the image using a volume.
[08:02] <ShapeShifter499> right okay, I
[08:03] <ShapeShifter499> oops hit enter
[08:03] <ShapeShifter499> I'll try it, meant to add
[08:23] <ShapeShifter499> pvh_sa: someone informed me in another chat that there was this commit https://github.com/lifehackerhansol-android/android_kernel_lge_msm8998/commit/9ca52bf77ff18a19c35b4c4eef29bb23dc2afba6
[08:23] -ubottu:#ubuntu-server- Commit 9ca52bf in lifehackerhansol-android/android_kernel_lge_msm8998 "cert host tools: Stop complaining about deprecated OpenSSL functions"
[08:23] <ShapeShifter499> apparently from Linus himself, which would workaround the openssl issue I have


[02:25] <bugman28> sorry to bother. single network device on ubuntu server, want to setup a bridge so VMs can access the local network. I use the libvirt example, the bridge is up, VMs use dhcp don't get an address. What am I doing wrong?
[02:33] <bugman28> ok, set ethernet dhcp : false, removed vlan, set bridge addresses: and now everything works. I don't think the example to correct.
[02:38] <bugman28> thanks for the help. This does not work: To get libvirtd to use a specific bridge with a tagged VLAN, while continuing to provide an untagged interface as well would involve:
[02:39] <bugman28> well, doesn't work on ubuntu server....


[00:01] <silverarrow> what are the latest marvels in the world of ultrabooks?
[00:03] <phillw> silverarrow: from my very poor memory, kubuntu have been playing with them
[00:04] <silverarrow> they are nice though
[00:04] <silverarrow> live CD is usually all fine with destop image?
[00:04] <silverarrow> latest build is very coars pixeled still
[00:04] <silverarrow> might be a bit difficul to fix
[00:05] <phillw> silverarrow: you'd need to have to chat with the kubuntu team. They are the only team I know specialising in net books.
[00:06] <phillw> skaet: do you know if ubuntu net book remix is still progressing?
[00:06] <skaet> phillw - ??  not one on my manifest for keeping an eye on.  details?
[00:07] <phillw> skaet: I did see once upon a time that ubuntu were doing a net-book remix. If it is not on tracker, I guess it died?
[00:08] <phillw> silverarrow: seems like kubuntu is your best bet.
[00:08] <silverarrow> installer still doesn't work in the lastest build
[00:09] <silverarrow> it's like everything works, the wizard window just doesn't show properly
[00:09] <silverarrow> does it make sense?
[00:09] <phillw> silverarrow: https://wiki.kubuntu.org/Kubuntu/Netbook
[00:10] <phillw> silverarrow: I only know of it via snippets of chats on QA etc. I know no more than the ability to find the link for you, sorry.
[00:11] <silverarrow> my mom just bought a netbook with a screen like that
[00:11] <silverarrow> she has better hardware than me these days
[00:12] <silverarrow> I still hold the samsung 9 series high
[00:12] <silverarrow> thanks though
[00:13] <phillw> silverarrow: they ask on that page that you contact on #kubuntu
[00:14] <silverarrow> I might just do that
[00:14] <silverarrow> for now, I have not even bought it yet
[00:14] <phillw> the kubuntu people are really nice guys, as are all our flavours. It is only when I send people away from the family do I hear of 'bad tempered people'.
[00:15] <silverarrow> the lightweight ones are getting really good these days
[00:15] <silverarrow> well, I got a sort of yelling over at debian
[00:15] <silverarrow> they hate the mentioning of ubuntu
[00:15] <silverarrow> not sure why
[00:15] <phillw> lubuntu were looking into one, but we do not have resources in terms of devs to do it.
[00:15] <silverarrow> Is ee
[00:16] <silverarrow> it doesn't matter much right now
[00:16] <silverarrow> in two months time it probably will
[00:16] <phillw> silverarrow: have a look at how many archs we're running with :)
[00:17] <silverarrow> it is impressive
[00:17] <phillw> What we would like to do is not possible,
[00:17] <silverarrow> and laods of feedback on the forum too
[00:18] <phillw> our QA testers are available to any team. We are all one family and help each other out.
[00:18] <silverarrow> which is a very good thing
[00:19] <phillw> it really helps when we only have a couple of hours to go for a milestone release :D
[00:19] <silverarrow> for the moment, I shall focus on ppc testing
[00:19] <silverarrow> i can imagine
[00:20] <silverarrow> i reall didn't like the ubiqity bug though
[00:20] <silverarrow> stops installing completely
[00:20] <silverarrow> ...on to the alternate iso
[00:21] <phillw> silverarrow: that will be appreciated. Whilst PPC is concentrated within lubuntu, the guys will jump in to help any of the teams that support ppc
[00:22] <silverarrow> how do I make screen shots in windows?
[00:22] <silverarrow> the print screen button does not work
[00:22] <phillw> I use Scrot which is Fn+PrcScr
[00:24] <silverarrow> oh thanks
[00:24] <silverarrow> scrot works in terminal lubuntu at least
[00:26] <phillw> silverarrow: if in doubt, head over to #ubuntu-beginners Those folk are pretty good at anything. do not mistake beginners for being newbies.... They are the experienced people from IRC and the main forum area. It's a lot more peaceful than asking on #ubuntu :P
[00:27] <silverarrow> thanks
[00:56] <skaet> smartboyhw,  chinese images that have been tested are now available from: http://localized-iso.qa.ubuntu.com/qatracker/milestones/233/builds  known issues so far are: http://goo.gl/8QNDe
[00:58] <skaet> There is a more recent set at: http://china-images.ubuntu.com/quantal/daily-live/20120905.2/
[00:58] <skaet> but they are likely to have same flaws as the one on the iso tracker.
[01:14] <silverarrow> i think I did it correctly
[01:14] <silverarrow> bug number 1046619
[01:16] <silverarrow> launchpad #1046619
[09:05] <zyga> hey everyone, I need help with community testing of various removable devices in 12.10
[09:05] <zyga> I wrote instructions about this here: https://plus.google.com/116315264177593873442/posts/aQq8vV7gUnE
[09:06] <zyga> it takes just a short moment to try this out and I could really use the help
[09:06] <zyga> the more hardware we see the better
[09:55] <smartboyhw> skaet: Thanks for the info:)
[09:56] <smartboyhw> Thanks for setting it up actually:)
[09:56] <smartboyhw> But I do wonder: Who actually compile the Chinese builds???
[11:10] <smartboyhw> jibel: Are you also responsible for the Ubuntu QA localized ISO tracker?
[11:19] <davmor2> bdmurray: when you get on webcam still seems to be fixed for me
[11:19] <davmor2> marking it so
[11:48] <jibel> smartboyhw, I am not.
[11:48] <smartboyhw> Oh allright
[11:49] <jibel> smartboyhw, actually I am not responsible of any tracker, just helping with iso testing.
[11:49] <smartboyhw> Who then? I can't see testcases there, and the Testcase Admins team members can't add one...
[12:19] <kanliot> why do we have to report on the testing tracker website and not just launchpad?
[12:19] <kanliot> also how bad is it, if i don't report against a specific package in launchpad?
[12:24] <xnox> kanliot: (1) so we know if we need to fix that bug urgently, because it affects the CD; so that we know if the CDs are good and we can release them.
[12:24] <kanliot> ok
[12:25] <xnox> kanliot: (2) reporting without specifying package, wastes everyone's time. Somebody will have to read the bug report, triage decide which package to allocate, then the people who are responsible for that package need to triage the bug again and see if they can fix it.
[12:25] <kanliot> k
[12:25] <kanliot> good answer
[12:25] <kanliot> x2
[12:25] <smartboyhw> +1 xnox
[12:25] <xnox> kanliot: if you don't do neither (1) or (2) then a critical bug can be lost for a very long time.....
[12:26] <xnox> even if the fix is very simple & quick
[12:27] <smartboyhw> kanliot: And if you don't do BOTH there will be serious trouble for us to fix the bug and make Ubuntu bette
[12:27] <smartboyhw> r
[13:55] <kanliot> that iso website what's it called
[13:55] <kanliot> qa tracker or testing tracker
[13:55] <kanliot> or qa testing
[13:55] <kanliot> or smoo smoo
[13:55] <kanliot> ;)
[13:55] <smartboyhw> QA Tracker
[13:55] <kanliot> called testing tracker on the the actual site
[13:56] <smartboyhw> ISO QA Tracker and Packages QA Tracker that is
[14:01] <kanliot> would you mark every important bug on the milestone release tracker?
[14:01] <kanliot> or just bugs that prevent install and use
[14:02] <smartboyhw> kanliot: Second one is better I think
[14:05] <elfy> I mark others kanliot - they need to be flagged somewhere
[14:06] <kanliot> elfy, i don't understand
[14:07] <elfy> I don't just put critical bugs there
[14:10] <kanliot> so you don't put critical bugs on the milestone release tracker?
[14:10] <kanliot> what do you do with the crit bugs?
[14:11] <elfy> kanliot: sorry - not being specific enough - I don't JUST put critical bugs - I put others as well  :)
[14:11] <kanliot> ty elfy
[14:11] <smartboyhw> kanliot: I think that if that the critical bugs affects installation or use, put the bug there. If it does not affect the installation, just a single package, no need
[14:30] <bdmurray> davmor2: great, thanks for testing
[14:33] <kanliot> i just wrote a page for new users that want to contribute to milestone testing.  please reveiew it, it's a short page https://wiki.ubuntu.com/QATeam/Overview/NewTesters?action=recall&rev=16
[14:33] <davmor2> bdmurray: no worries
[14:33] <smartboyhw> Good job kanliot
[14:34] <kanliot> :)
[15:33] <kanliot> so right now we're testing beta 1, to make sure it's ok to release?
[15:33] <kanliot> and second question, what are the dailies for?  the devs?
[15:34] <Riddell> for netboot can mini.iso be put on a USB drive?
[15:35] <Riddell> kanliot: yes, and anyone who wants them
[15:39] <patdk-wk> riddell, sure
[15:40] <Riddell> patdk-wk: how? usb-creator doesn't enable the buttons when I try
[15:40] <patdk-wk> oh wait, you mean the netboot test?
[15:40] <patdk-wk> oh, I dunno about using usb-creator to do it
[15:40] <patdk-wk> probably just no one made a profile for it to know how
[15:42] <patdk-wk> give unetbootin a try?
[15:47] <Riddell> hmm mini.iso doesn't work in virtualbox for me, gets to Installer boot menu but freezes on pressing enter
[15:48] <jibel> Riddell, dd mini.iso to a usb stick and boot from it
[15:48] <jibel> dd if=mini.iso of=/dev/sdX bs=1M
[15:48] <jibel> be careful to dd to the usb device
[15:49] <jibel> not a partition and certainly not your disk drive :)
[15:57] <Riddell> oh amd64 image on a 32bit machine, not likely to be happy
[16:12] <xnox> Riddell: it works if you tap it on the side lightly every 72 seconds
[16:13] <Riddell> or use a 64bit computer
[16:18] <xnox> Riddell: really?! =))))
[16:18]  * xnox giggles
[16:18] <Riddell> yeah yeah, it didn't have a friendly error message like I remember from the normal images last time I did that
[16:19] <xnox> Riddell: is that netboot?
[16:19] <xnox> Riddell: pics or it won't be fixed
[16:19] <xnox> =)
[16:23] <Riddell> xnox: yes
[16:46] <wxl> what is "run once" on the iso tracker?
[16:47] <xnox> wxl: the test is executed at least onces to be acceptable, instead of requiring multiple reports against the test case
[16:49] <wxl> xnox: by that logic, shouldn't the lubuntu arm preinstall (as an example) be run once, too?
[16:50] <wxl> …since the test passed with no bugs?
[16:50] <xnox> wxl: why? 'run once' is a compromise if the test case is (a) hard to do due to time & hardware availability / constraints (b) or covered by other cases, and that particular test cases does not depend on particular hardware.
[16:51] <xnox> wxl: preinstall are very flaky. Are other arm preinstall marked as run once in other products?
[16:52] <wxl> xnox: i misunderstood you. you mean that the testcase will have already been marked as run once, not that some condition causes it to be marked as such.
[16:52] <wxl> rigt?
[16:53] <xnox> wxl: it's a property of a test-case by itself, same as testcase ID & steps.
[16:54] <xnox> wxl: there are no conditions that change that label.
[16:54] <wxl> xnox: ok, nevermind that then. for beta1 do we need anything beyond the mandatory tests?
[16:55] <xnox> wxl: ask skaet. I don't know.
[16:55]  * xnox is just a coder....
[16:55] <xnox> wxl: an image needs to be marked as ready, otherwise it will not be released. Join #ubuntu-release and talk to skaet.
[17:02] <silverarrow> I got a tip on the forum on how to install
[17:02] <silverarrow> wxl?
[17:03] <silverarrow> should I burn a new Beta CD now?
[17:03] <wxl> silverarrow: i'd be curious to hear what it is.
[17:03] <silverarrow> something with unmode
[17:03] <wxl> yeah unless you have a cd-rw (which, again, i recommend)
[17:03] <silverarrow> wait
[17:03] <silverarrow> rw?
[17:04] <wxl> read/write -- you can reburn them
[17:06] <kanliot> installed the new beta
[17:06] <kanliot> but it's turning off my monitor and displaying an error message
[17:06] <kanliot> no idea where to file the bug
[17:06] <silverarrow> I might look for those
[17:07] <silverarrow> though I am afraid this late I shall have to do with a stack of what ever they have at a local store
[17:09] <silverarrow> this is the suggestion when booting; add this in the terminal like boot stage "live video=ofonly"
[17:09] <silverarrow> kanliot, there are new betas all the time? or just updates?
[17:09] <wxl> kanliot: i betcha your bug is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/1041625
[17:10] <wxl> also i should add that beta1 testing is wrapping up
[17:10] <kanliot> is wrapped up
[17:10] <wxl> so now we're ging to move back to daily testing
[17:10] <kanliot> pre beta testing is done
[17:10] <kanliot> i bet it's whatever video drivers i'm using
[17:11] <kanliot> silverarrow what was the question?
[17:11] <kanliot> and i'm bothered enough by the black screen to make it critical
[17:11] <silverarrow> I`thinking of the beta download, is it the same for a few days, or new all the time?
[17:11] <kanliot> but i bet i'm the only one on this planet who thinks a black screen is critical
[17:11] <silverarrow> or am I thinking wrong ?
[17:12] <wxl> sounds like the bugs were too big with ppc that we're probably not going to see an "official" beta release
[17:12] <kanliot> sounds like a good question
[17:12] <kanliot> i'll ask it on the mailing list
[17:12] <wxl> so look for the dailies and keep testing there
[17:12] <wxl> kanliot: yes it's pretty huge— and should eb described in that aforementioned bug report
[17:13] <wxl> kanliot: i should mention there's a fix described there
[17:13] <kanliot> wxl, i'm already a little upset, but i assure you it's a differnt bug.
[17:13] <wxl> oh, and word is there may be a beta2 ppc.
[17:14] <silverarrow> oh
[17:14] <wxl> kanliot: i can understand your feelings, but i would give it a shot. i have seen a lot of symptoms that seem to be pointing at that one issue. worst case scenario it does nothing.
[17:14] <silverarrow> I have been reading up and down on those pages, but they say nothing about the frequencies of updates or new stuff
[17:15] <silverarrow> and I think I have figured out what is wrong with my fujitxu pc, inverter is gone
[17:15] <wxl> silverarrow: mostly, we're testing dailies. these get interrupted by alphas and betas. and the release of course. usually then they sort of turn off testing of the dailies.
[17:15] <kanliot> wxl did the fix include turning the monitor off and on?
[17:15] <wxl> kanliot: nope, updating openchrome. but that's a thought, too.
[17:16] <silverarrow> wxl, thanks, I  have to get the terminology right too
[17:16] <silverarrow> beta, alpha, proto...
[17:16] <wxl> silverarrow: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[17:17] <silverarrow> and I assume a freeze is new hot out of the oven and has been in the freezer for a while?
[17:18] <wxl> freeze means no new features will bad added
[17:18] <silverarrow> ...to cool down
[17:18] <silverarrow> I see
[17:18] <silverarrow> closer to the final setup on the release then
[17:18] <silverarrow> of* perhaps
[17:19] <wxl> once it's frozen, it gets tested basically, and then released
[17:19] <wxl> up until then daily testing is leading to the release
[17:19] <silverarrow> but for the beta 2 rumor?
[17:19] <silverarrow> what do you recommend I go for?
[17:19] <wxl> that will depend on daily testing in the meanwhile and whether or not we can squash critical bugs
[17:20] <wxl> beta1 as you can see is being released today
[17:20] <wxl> it hasn't been fully released yet but it's coming
[17:20] <silverarrow> I will keep my eyes open
[17:20] <wxl> then we await re-spins so that we get fresh dailies
[17:20] <wxl> but it sounds like they're manually copying over the ppc builds to speed things up a bit
[17:20] <wxl> an email will go out to the lubuntu-qa list when that happens
[17:21] <wxl> you MAY want to play with what you already have and see if that thing you figured out might help you get the ball rolling
[17:21] <wxl> that way if that bug is still around, you'll be prepared for it
[17:22] <wxl> and actually taht's a fairly easy fix
[17:23] <silverarrow> I know where to look for bugs though
[17:23] <silverarrow> wonder if gnash mozilla plugin has been tested
[17:24] <silverarrow> all the regular workarounds for ppc
[17:24] <wxl> confirmed that openchrome has nothing to do with the problems in ppc
[17:24] <wxl> getting Lars (another ppc tester) to check out what you were using
[17:27] <silverarrow> lars? where is he?
[17:27] <silverarrow> I am in norway
[17:27] <wxl> dunno
[17:27] <phillw> good, the faster the progress the sooner we can wait for them to go break something else :P
[17:27] <wxl> probably in the dark alley behind your house
[17:27] <silverarrow> lol
[17:27] <silverarrow> you never know
[17:28] <phillw> Allegedly, there should be no more major breakages. Beta 1 --> Beta 2 is bug fixing time.
[17:28] <silverarrow> with a name like that, I would guess some kind of scandinavian connections
[17:28] <wxl> um
[17:28] <wxl> "connections," yes
[17:28] <wxl> in scandinavia, no
[17:28] <silverarrow> a few americans have that name
[17:29] <wxl> an example: https://en.wikipedia.org/wiki/Lars_Ulrich
[17:29] <silverarrow> yes, germans
[17:29] <wxl> here's another good one https://en.wikipedia.org/wiki/Lars_Larson
[17:29] <silverarrow> not common in germany though
[17:29] <silverarrow> very sweedish lol
[17:30] <silverarrow> it`s either danish, swedish or norwegian
[17:31] <wxl> he is in europe according to time zone https://launchpad.net/~larsnooden
[17:31] <silverarrow> but on with the install then
[17:31] <silverarrow> finnland
[17:31] <silverarrow> hmm
[17:32] <phillw> oh, and whilst you're both here. Just to remind you that there is quite a queue of stuff for ppc once the archives are unfrozen ready for the next daily build.
[17:32] <silverarrow> a daily build is something I download and install?
[17:33] <silverarrow> or burn on cd and install?
[17:33] <phillw> silverarrow: yeah, the dailies appear on the iso tracker.
[17:33] <silverarrow> thanks
[17:33] <wxl> it's the same as the beta, silverarrow
[17:33] <phillw> silverarrow: its a lot qwuicker to use zsync for this
[17:33] <wxl> except
[17:33] <wxl> you get a new one every day
[17:33] <wxl> XD
[17:33] <silverarrow> lol
[17:34] <kanliot> if the splash screen is killing my monitor what do i file a bug gainst
[17:34] <phillw> A CD-RW is worth paying for if you play with the dailies.
[17:34] <kanliot> it's the screen saying "an error was encountered checking your disks"
[17:35] <wxl> ↑ told you you want cd-rw!
[17:35] <phillw> kanliot: have a check on https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs
[17:35] <silverarrow> ok ok
[17:36] <wxl> yeah, you know it's getting serious when i whip out the unicode ☻
[17:46] <wxl> silverarrow: you should go confirm bug 1046951
[17:46] <wxl> that's specifically for ppc
[17:46] <silverarrow> thanks
[17:47] <silverarrow> brb, getting cds
[17:47] <wxl> i'd suggest testing video=ofonly and reporting there
[17:47] <wxl> which lars is doing too i think
[17:49] <phillw> wxl: did you get added to the mailing list for all lubuntu type bugs?
[17:49] <wxl> phillw: yeah, so i've been checking on expired packages and all other sorts of things. it's been really useful. thx for the suggestion
[17:49] <wxl> silverarrow: what's your launchpad id out of curiousity?
[17:51] <phillw> it is invaluable for me to have an over view of what is going on. I can also do a search on my gmail account quickly to find a bug that I dimly recall :)
[17:53] <wxl> hahahha yeah no kidding
[17:54] <phillw> balloons: hiyas, how's life treating you?
[17:54] <balloons> phillw, howdy
[17:55] <balloons> I'm working on testcases again today
[17:55] <phillw> hope you don't mind me kidnapping the room for a quick ppc discussion :)
[17:55] <balloons> lol
[17:55] <balloons> ppc is still alive
[17:55] <balloons> as such, talk away
[17:55] <phillw> it is, looks like it is a different bug to that thought.
[17:56] <wxl> where was that number
[17:56] <wxl> bug 1046951
[17:56] <phillw> wxl: which one?
[17:57] <wxl> ↑ aka the "ppc's problem ain't openchrome" bug
[17:58] <wxl> 😂
[18:31] <silverarrow> back, I could not get the CD-rw type until tomorrow
[18:32] <wxl> no rush
[18:32] <wxl> as i said, it will take a while for beta1 to get released and then the proper dailies to come out
[18:32] <silverarrow> I still got a bunch of regular CD-r
[18:32] <wxl> i'd wait
[18:32] <wxl> instead what i'd suggest is to see if you can get the cd you have already burned working
[18:32] <wxl> with video=ofonly
[18:33] <wxl> report to that bug that i mentioned above
[18:33] <wxl> and then if it does work, see if you can get the install going
[18:33] <wxl> and then file more bugs for anything else you find
[18:33] <wxl> and come back and see if we can work through those
[18:33] <silverarrow> I am just home again, and are on the ibook now
[18:33] <wxl> etc etc etc ♻
[18:34] <silverarrow> that is me on the windows computer
[18:34] <wxl> ew
[18:34] <wxl> i mean,
[18:34] <wxl> no, i mean ew
[18:34] <silverarrow> lol
[18:35] <silverarrow> video=ofonly
[18:35] <wxl> 😨
[18:35] <silverarrow> I am writing just ot have to have it on the other screen
[18:36] <silverarrow> and bug bug 1046951
[18:36] <wxl> yp
[18:36] <silverarrow> ok for live cd,
[18:39] <silverarrow> I cannot identify ?
[18:39] <wxl> what do you mean?
[18:39] <silverarrow>    / msg nickserv identifly password?
[18:40] <silverarrow> never mind,
[18:40] <silverarrow> I get asked to identify all the time
[18:40] <silverarrow> fly lol
[18:40] <wxl> well if you're registered you should be able to identify :)
[18:41] <silverarrow> there
[18:41] <wxl> but that's a #freenode question not a #lubuntu or #ubuntu-testing question!
[18:41] <silverarrow> sorry
[18:41] <wxl> np
[18:43] <silverarrow> live video=ofonly
[18:43] <silverarrow> offonly?
[18:43] <wxl> of
[18:43] <silverarrow> indvalid device
[18:43] <silverarrow> unable to open file
[18:44] <silverarrow> I might have to ask on the forum about that
[18:44] <silverarrow> quadruple checked spelling
[18:45] <silverarrow> ??
[18:45] <wxl> i'm sure the spelling is right
[18:45] <wxl> it might be something else
[18:45] <wxl> one sec
[18:49] <silverarrow> no working
[18:49] <silverarrow> I must have fiddled with something
[18:49] <wxl> PATIENCE
[18:49] <wxl> :)
[18:49] <silverarrow> now*
[18:49] <silverarrow> strange lubuntu wait screen
[18:50] <silverarrow> a bit psychedelic
[18:50] <silverarrow> lsd influenced logo
[18:50] <wxl> hm
[18:50] <wxl> the problem may be the "live" part
[18:50] <wxl> that may not be what the image is called
[18:50] <wxl> i don't remember teh command to see all the images
[18:50] <wxl> i think it may be just hitting tab
[18:50] <silverarrow> however, easily readable
[18:51] <wxl> when you get to the boot prompt it should either give you instructions
[18:51] <wxl> or try ?
[18:51] <wxl> or help
[18:51] <wxl> and find the command to list images
[18:51] <wxl> find all the images
[18:51] <wxl> pick an appropriate one
[18:51] <silverarrow> I am as far as loading cd, the lubuntu .... logo
[18:51] <wxl> and enter "image video=ofonly"
[18:51] <wxl> where image is the name of the image
[18:51]  * silverarrow noting down on postit
[18:51] <silverarrow> noteing
[18:52] <wxl> why it is ofonly and not offonly<EMAIL_ADDRESS>[18:53] <wxl> keep reading those threads and you may find other video configs to try
[18:53] <silverarrow> boot up image is much the same
[18:54] <silverarrow> like stripes across the desktop image
[18:54] <silverarrow> actually a bit better
[18:54] <silverarrow> installer works!!
[18:55] <silverarrow> wxl, full install or live stuff first?
[18:56] <silverarrow> i would prefer install right away
[18:57] <wxl> do it!
[18:58] <phillw> silverarrow: you missed wxl he said do the install!
[18:58] <silverarrow> thanks
[19:00] <silverarrow> use LVM with new install?
[19:01] <phillw> silverarrow: if you wish
[19:04] <silverarrow> is it all right to install alongside 12.04 to be able to choose between 12.04 and 12.10?
[19:05] <silverarrow> it would feel safe
[19:05] <silverarrow> if there is an advantage to deleteing 12.04 I can
[19:05] <phillw> if the installer offers side by side you should be ok. There is a gremlin using luks and lvm that has been mentioned. Jusy pay attention to what the installer says.
[19:06] <silverarrow> ok
[19:06] <silverarrow> a gremlin
[19:06]  * silverarrow was hoping to encounter a mogwai
[19:07] <phillw> lol, it's not a fully fledged bug, just something that happens which is thought could be better warned about.
[19:13] <wxl> just dont' get it wet
[19:17] <silverarrow> installer freezes on me
[19:17] <wxl> file a bug
[19:17] <wxl> against ubuity
[19:17] <wxl> err
[19:17] <wxl> ubuiquity
[19:17] <wxl> ubiquity
[19:17] <wxl> sheesh
[19:17] <silverarrow> i have reboot live cd three times and it freezes
[19:18] <silverarrow> i filed a bug last night, could I just keep posting in thesame section?
[19:18] <wxl> no
[19:20] <silverarrow> ok new bug
[19:20] <wxl> no
[19:20] <wxl> not unless it's different
[19:24] <silverarrow> how do you mean wxl?
[19:24] <wxl> if it's the same bug as you reported, no need to report it again
[19:24] <wxl> and if it's not a different bug, no reason to report a new bug
[19:24] <silverarrow> I mean, live video=ofonly makes insaller windows appear
[19:25] <silverarrow> then as I thought, just adding to the same bug
[19:26] <wxl> well if you couldn't get installer windows before, then i would report there that video=ofonly fixes it
[19:26] <wxl> and change the package to yaboot, really
[19:26] <wxl> and then report a new bug for the ubiquity crash
[19:28] <balloons> phillw, ping
[19:29] <phillw> balloons: pong
[19:29] <balloons> do you remember the checkbox testcases?
[19:29] <balloons> from the manual application testing last cycle?
[19:30] <phillw> balloons: I recall looking at them, but did not much woork with them.
[19:31] <balloons> ahh.
[19:33] <silverarrow> I hope launchpad reports are read and checked now and then thoguh
[19:33] <phillw> silverarrow: which bug number is it now under?
[19:33] <wxl> they are, silverarrow, but pointing them out doesn't hurt.
[19:34] <silverarrow> #1046619
[19:34] <phillw> bug 1046619
[19:35] <silverarrow> the issue might be more easily identified if I keep posting in one area
[19:35] <silverarrow> it does feel like the same thing really
[19:36] <silverarrow> I just sorted out the additional live video=ofonly issue
[19:37] <phillw> as the latest x does not solve the issue, it does point to a different issue.
[19:37] <silverarrow> separate issues, but I filed it as ubiquiti in the first place
[19:37] <silverarrow> phillw: you suggest filing a new bug+
[19:37] <wxl> i personally think video=ofonly should be a default for ppc
[19:38] <phillw> silverarrow: no, that bug looks to be correct
[19:38] <wxl> it should ALWAYS work
[19:38] <wxl> whereas the alternative does not
[19:38] <wxl> the con: less support of all of the features of hardware
[19:38] <wxl> but we can have release notes or edit the wiki to help people
[19:39] <silverarrow> it works with the live video=ofonly, as long as it is pointed out, easily done when you are aware
[19:40] <wxl> tho if it was default then people who don't knwo wouldn't get confused
[19:40] <phillw> wxl: silverarrow you guys can have a double check with Lars and then ask gilir to alter the seed file for it.
[19:41] <silverarrow> I actually read it upon first boot, but didn't think much more of it, when cd booted further by its' self
[19:41] <wxl> seed file?
[19:41] <wxl> exactly the problem, silverarrow
[19:41] <wxl> i think there are those that wouldn't even read that
[19:41] <phillw> wxl: the list of files a nd instructions that make an iso
[19:41] <silverarrow> where is lars and gilir then?
[19:42] <phillw> silverarrow: catch them both via the lubuntu-qa mailing list.
[19:42] <wxl> silverarrow: go to bug 1046951 and confirm it, report that video=ofonly fixes it, change to yaboot package and we'll go from there
[19:43] <wxl> go from there = post to lubuntu-qa while cc'ing gilir and larsnooden (look them up on launchpad and you can find their emails)
[19:44] <silverarrow> you are talking above my head
[19:44] <silverarrow> changing to yaboot package?
[19:44] <silverarrow> that is the video off mode thing?
[19:44] <wxl> ok let's start with step one
[19:44] <wxl> 1. confirm that it affects you
[19:45] <wxl> 2. leave a reply saying that video=ofonly fixes the problem
[19:45] <silverarrow> thanks for the patience
[19:47] <wxl> phillw: how do i change the affected package to https://launchpad.net/ubuntu/+source/yaboot?
[19:47] <wxl> furthermore, does that make sense? maybe it is true that the problem lies in an Xorg.conf (or whatever) that is inappropriate for ppc?
[19:48] <phillw> I can yaboot to it.
[19:48] <phillw> *can add*
[19:48] <silverarrow> oh, I do get a desktop environment thoguh
[19:48] <wxl> phillw: but do you get what i mean? like maybe that's a "band aid" not a fix?
[19:49] <silverarrow> wxl, lars reports a more sever outcome of the same issue I suppose?
[19:51] <phillw> wxl: as video=ofonly sorts out the initial X problem and the updated X has no affect, I'm minded to leave it as yaboot. It can always be reverted back to X if warranted.
[19:51] <silverarrow> wxl, lars seems to use the alpha something, I am in beta
[19:51] <silverarrow> I see
[19:51] <silverarrow> X is what?
[19:52] <phillw> silverarrow: the release on 4th Sept was still an alpha
[19:52] <silverarrow> unknows problem?
[19:52] <wxl> phillw: i like it. i'd also like to know how to change packages for future reference. when i did the search it only came up with yaboot-installer
[19:52] <wxl> X = the "desktop"
[19:52] <wxl> kind of
[19:52] <wxl> the graphics overall
[19:52] <silverarrow> i see
[19:52] <wxl> silverarrow: here's lars' experience https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/1041625/comments/34
[19:52] <phillw> if you click the arrow next to package you will get a search window up. Type in yaboot gave me 3 options.
[19:53] <phillw> the new open chrome did not solve it.
[19:53] <wxl> yeah because openchrome isn't even valid for any apple product afaik
[19:53] <wxl> wrong hipsets
[19:53] <wxl> hahah hipsets
[19:54] <wxl> those are from nyc
[19:54] <wxl> i meant chipsets
[19:54] <phillw> I knew what you meant :P
[19:56] <wxl> among other problems i see in lars' log:
[19:56] <wxl> [    72.053] (EE) Failed to load module "fglrx" (module does not exist, 0)
[19:58] <wxl> phillw: how can i get a total package list of a particular iso? like versions and everything. possible?
[19:59] <phillw> erm, they are there... Let me see if I can find the link.
[19:59] <wxl> doesn't seem that there's a current fglrx for ppc
[19:59] <wxl> so therein may lie the problem
[20:04] <phillw> wxl: http://people.canonical.com/~ubuntu-archive/seeds/lubuntu.quantal/
[20:04] <phillw> but that area is well out of my knowledge. catch gilir for a better discussion on such things.
[20:06] <silverarrow> wxl, I posted my experience on the issue
[20:08] <silverarrow> are you familiar with alternate CDs? do i get the black  terminal only?
[20:08] <silverarrow> it can be a nightmare to maneuvuer sometimes
[20:08] <silverarrow> some times easier though
[20:13] <wxl> thx phillw i grok it
[20:13] <wxl> silverarrow: it has been asked on your bug for a X.org.0.log
[20:14] <silverarrow> oh already?
[20:15] <phillw> silverarrow: bugs that bork an install do tend to get moved up the queue of things to be sorted @)
[20:15] <phillw> :)
[20:15] <wxl> yep and i just left a comment
[20:16] <wxl> unfortunately there's no easy way to include the log by command line
[20:17] <wxl> especially now that the package has changed to yaboot
[20:19] <wxl> silverarrow: when you DON'T use video=ofonly can you still use the browseR?
[20:19] <silverarrow> let me reboot
[20:19] <wxl> if not, i'd suggest filing the bug in a text browser like w3m or elinks or lynx
[20:19] <wxl> um
[20:19] <wxl> not filing the bug
[20:19] <wxl> filing the log
[20:20] <silverarrow> oh....no
[20:20] <wxl> ?
[20:20] <silverarrow> I am not web connected on the ibook
[20:20] <silverarrow> major typing
[20:20] <wxl> that's sucky
[20:20] <wxl> so what i'd do is get out a usb key or something
[20:20] <silverarrow> maybe copy and send to usb storage
[20:21] <silverarrow> yeah, I have a usb connected satadrive
[20:21] <silverarrow> almost new
[20:22] <wxl> but make sure you're in the non-ofonly boot
[20:22] <silverarrow> it boots
[20:22] <wxl> get to terminal
[20:23] <wxl> your Xorg.0.log is in /var/log
[20:23] <wxl> (in case you didnt' know that)
[20:23] <silverarrow> i didn't
[20:23] <wxl> that's where all your log files should be
[20:23] <wxl> or at least symlinked to
[20:24] <silverarrow> launching browser from termnal?
[20:25] <wxl> wellll
[20:25] <wxl> don't worry about that
[20:25] <wxl> not web connected, remember?
[20:25] <wxl> just copy /var/log/Xorg.0.log to your usb
[20:25] <silverarrow> fontconfic warnins
[20:26] <silverarrow> but firefox launches
[20:26] <silverarrow> and I get the regular "cannot find server at..."
 XD
[20:27] <silverarrow> well, at least it launched with graphis withing frames
[20:27] <silverarrow> which is more than installer does
[20:27] <wxl> and you didn't use video=ofonly?
[20:27] <silverarrow> no
[20:27] <wxl> hm
[20:27] <wxl> curious
[20:27] <silverarrow> just auto boot up
[20:27] <wxl> hate not repeatable bugs
[20:27] <wxl> anyways
[20:28] <wxl> try rebooting until you get the original problem
[20:28] <silverarrow> everything is more coarse pixelled
[20:29] <silverarrow> abi word lunches a bit weird
[20:29] <silverarrow> see through window
[20:29] <wxl> ok
[20:29] <wxl> so there are problem
[20:29] <wxl> s
[20:29] <wxl> good
[20:29] <wxl> now:
[20:29] <wxl> 1. insert usb key
[20:29] <wxl> 2. load up pcmanfm
[20:30] <wxl> 3. navigate to /var/log
[20:30] <wxl> 4. open up another pcmanfm
[20:30] <wxl> 5. navigate to your usb key
[20:30] <silverarrow> I cannot open usb disk
[20:30] <wxl> 6. drag /var/log/Xorg.0.log to your usb key
[20:30] <silverarrow> which I can it 12.04
[20:30] <wxl> why not?
[20:30] <wxl> what error?
[20:31] <silverarrow> or maybe I can, but with error warning
[20:31] <silverarrow> pcmanfm is a terminal thing?
[20:31] <wxl> no
[20:31] <wxl> it's your file manager
[20:31] <wxl> you could do this in terminal but my guess is you're not very terminal friendly XD
[20:31] <silverarrow> lol sorry
[20:32] <silverarrow> well, terminal takes a lot of thinking and more time
[20:32] <silverarrow> oh yes, it acaully says pcmanfm in quantal
[20:33] <silverarrow> it is open now
[20:33] <silverarrow> for the log?
[20:33] <wxl> can you get to your usb key?
[20:33] <silverarrow> yes
[20:33] <silverarrow> but there are some error messages
[20:34] <silverarrow> but seem to work at least
[20:34] <wxl> ok so if you follow my instructions, just drag from one window to the other
[20:34] <silverarrow> yes, fairly regular procedure
[20:35] <wxl> or (to prove how long it takes in terminal) you could do something like "cp /var/log/Xorg.0.log /media/USB"
[20:35]  * wxl notes that's sarcasm
[20:36] <silverarrow> ...fixes keyboard...
[20:38] <silverarrow>    /media USB is not a directory
[20:38] <silverarrow> !"#¤¤%
[20:38] <wxl> oh don't take me literally
[20:38] <wxl> i was offering an example
[20:38] <wxl> nevermind! just drag and drop! :)
[20:39] <silverarrow> just a reminder, what am I actually doing ?
[20:39] <wxl> or copy and paste from http://www.fileformat.info/info/unicode/char/2203/index.htm
[20:39] <wxl> oops wrong channel sorry
[20:39] <wxl> you're copying Xorg.0.log to your usb
[20:40] <wxl> so you can hook it up to whatever computer is connected to the web
[20:40] <silverarrow> oh, yes, how to get to teh xorg log?
[20:40] <wxl> so that you can post it to the bug report
[20:40] <wxl> it's in /var/log
[20:40] <silverarrow> terminal or file manager?
[20:41] <wxl> you can get to it either way
[20:41] <wxl> whatever you feel more comfortable with
[20:42] <silverarrow> yes I have var log with loads of folders
[20:42] <silverarrow> or /var/log
[20:43] <wxl> is root directory and inside it is var/ directory and inside it is log/ directory and inside it is Xorg.0.log file
[20:43] <wxl> oops
[20:43] <wxl>  / is root directory and inside it is var/ directory and inside it is log/ directory and inside it is Xorg.0.log file
[20:45] <silverarrow> drag and drop resists
[20:45] <silverarrow> permission denied
[20:46] <wxl> that's interesting
[20:46] <wxl> in yoru pcmanfm window for your usb key what's it say in the address bar?
[20:46] <silverarrow> annoying
[20:46] <silverarrow> media/lubuntu/new volume
[20:47] <silverarrow> it is a usb connected sata drive
[20:47] <silverarrow> 320 gb or something
[20:47] <wxl> so go to terminal and do:
[20:47] <silverarrow> I can't close windows, tehy are sort of empty
[20:47] <wxl> are you sure that's what ti is?
[20:47] <silverarrow> or seethrough
[20:48] <wxl> and not Lubuntu
[20:48] <wxl> or New Volume
[20:48] <wxl> or New_Volume
[20:48] <wxl> ?
[20:48] <wxl> you need to know what it is EXACTLY
[20:50] <silverarrow> error opening /media/lubuntu new volume
[20:50] <silverarrow> permission denied
[20:50] <wxl> then there's your problem for some reason
[20:50] <wxl> you need to get that thing web connected and it will solve this whole silliness
[20:50] <wxl> just plug the ethernet in
[20:52] <silverarrow> ok burn cd?
[20:52] <silverarrow> no, I cannot eject live cd
[20:53] <wxl> nope gets kind of locked in there
[20:53] <wxl> remember you're running the whole system off that cd
[20:53] <wxl> it can only keep so much of it in memory so it constantly has to re-read
[20:54] <wxl> removing the cd would be analogous to removing your hard drive on an installed system
[20:54] <phillw> can you do    ls /media
[20:55] <silverarrow> it is a nightmare to type that out
[20:55] <phillw> ls /media
[20:56] <silverarrow> cdrom lubuntu
[20:56] <wxl> hahahhaah
[20:56] <phillw> in the entries, do you see something that starts lbuntu
[20:56] <phillw> ls /media/lubuntu
[20:58] <phillw> do you see various files?
[21:00] <silverarrow> found a usb flash
[21:01] <silverarrow> worked
[21:01] <phillw> :D
[21:01] <silverarrow> apparently usb connected disk drives don't work?
[21:02] <phillw> silverarrow: I don't have a problem, but I'm not using a ppc.
[21:03] <silverarrow> http://paste.ubuntu.com/1189685/
[21:04] <silverarrow> is this worth posting?
[21:04] <wxl> yes
[21:04] <phillw> silverarrow: that's the file being awaited on :)
[21:06] <wxl> ok i'm taking a break, afk
[21:06] <phillw> okies wxl I'm kicking about now.
[21:11] <silverarrow> i hope I pasted it where they wanted it
[21:12] <silverarrow> when will I get as far as installing ?
[21:22] <phillw> as soon as we get the bug squished
[21:23] <phillw> silverarrow: if you are desperate to get an 12.10 in, you can grab the Alpha 3 Milestone via http://iso.qa.ubuntu.com/qatracker/milestones/226/builds
[21:24] <phillw> But to help with sorting out the issue that prevented a beta 1, I do ask that you still keep close eye on the tracker and your bug report.
[21:25] <silverarrow> I will, and I am not desperate
[21:25] <phillw> silverarrow: we hate to lose a milestone release. I assure you that work is being carried out to squish the bugs.
[21:26] <silverarrow> I see
[21:27] <silverarrow> I would make an effort to check out issues
[21:27] <silverarrow> and install beta when it is adviceable
[21:27] <silverarrow> or helpful
[21:30] <silverarrow> daily is not found
[21:31] <silverarrow> not found on this server
[21:31] <silverarrow> maybe down for update?
[21:32] <silverarrow> is it my fault that xubutu no longer have ppc version?
[21:32] <silverarrow> i  have talked way to much about lubuntu and ppc
[21:32] <silverarrow> not even testing xubuntu
[21:33] <silverarrow> however, I like the lubuntu setup
[21:34] <phillw> silverarrow: the dailies are not yet fully re-installed. I made a request that the latest QA-Beta1 be manually covered over, as the others are a few days old.
[21:35] <silverarrow> oooh, inside info
[21:36] <phillw> silverarrow: not really, we tried our darn best to get at least one of the ppc lubuntu out, we ran out of time... But, that is a part of testing.
[21:36] <silverarrow> I am earger to test gecko and mplayer, and that kind of stuff though lol
[21:37] <phillw> We have until the end of the month to sort them both out before Beta 2 lands
[21:37] <silverarrow> so some intense work ahead
[21:38] <phillw> silverarrow: it is a roller coaster ride, but extremely rewarding.
[21:38] <silverarrow> i will make an effort too, and spend time and energy on the testing
[21:39] <silverarrow> as soon as someone has fixed installer I will go ahead
[21:41] <phillw> silverarrow: we are still, during the madness, updating the wiki area. Do keep popping on and keep upto date with what is added. Never fear pinging me or balloons if you have a query about information on the Wiki https://wiki.ubuntu.com/QATeam/Overview/
[23:26] <silverarrow> hi smartboyhw
[23:27] <smartboyhw> Good morning
[23:27] <silverarrow> and good morning to you
[23:28] <silverarrow> ;-)
[23:32] <smartboyhw> Good morning phillw
[23:32] <phillw> hi smartboyhw
[23:33] <phillw> balloons: are you still about?
[23:33] <smartboyhw> HA, i still saw the Lubuntu upgrade testcases not carried out LOL
[23:33] <phillw> smartboyhw: there is little point until the Beta 2?
[23:34] <smartboyhw> HAHAHA, well you are the only one:(
[23:34] <phillw> Same as Wubi is not worth really testing until betas.
[23:34] <smartboyhw> phillw: Wubi IS tested as I saw it now
[23:34] <phillw> smartboyhw: it's only Beta 1.
[23:34] <phillw> smartboyhw: I know, i have tested it in the past for them.
[23:34] <smartboyhw> :)
[23:35] <smartboyhw> Only Beta 1.....Hmm
[23:36] <phillw> smartboyhw: yes, from now on it gets serious
[23:36] <smartboyhw> Oh is it starting? I thought it is ALWAYS serious:)
[23:39] <phillw> smartboyhw: https://wiki.ubuntu.com/Lubuntu/Testing/TheStages
[23:40] <phillw> It has been copied over the main QA site, just that is my most frequently used link.
[23:40] <smartboyhw> Oh alright
[23:41] <smartboyhw> Sadly the Ubuntu Studio images are always marked ready too early for others to test...
[23:41] <phillw> smartboyhw: the bug team were kind enough to overview and edit https://wiki.ubuntu.com/QATeam/Overview#Bugs
[23:42] <phillw> We are still doing a lot of 'behind the scenes' work.
[23:42] <smartboyhw> I have to add the cadence section back:)
[23:42] <smartboyhw> Anyway, going now to school!
[23:42] <phillw> have a good day!
[23:48] <silverarrow> so what testcases are in stall for lubuntu?@


[05:20] <Chazzle> hello?
[05:21] <Chazzle> hope I am in the right place...
[05:21] <Chazzle> I am looking for help with installation of Ubuntu...


[10:27] -SwissBot:#xubuntu-devel- ::xubuntu-default-settings:: Release xubuntu-default-settings 21.04.2 @ https://github.com/Xubuntu/xubuntu-default-settings/commit/99de9a1c460f967f32dc7cb1fbd2ee888458ef11 (by bluesabre)
[17:15] <krytarik> Just to avoid accidental duplicate effort, I've staged the Planet Ubuntu update for our feed URL at 'lp:~krytarik/config/xubuntu', and since I've noticed one merely needs to be an Ubuntu Member to be able to just push to the original repo, I've already asked Unit193 for it but anybody else is of course free to relay it to there too - I figure this is more straightforward than doing it via  ...
[17:15] <krytarik> ... an MP which I was originally planning on filing.
[22:42] <krytarik> And the above is done now!
[23:47] <bluesabre> Oh nice!
[23:47] <Unit193> I am, sometimes.
[23:47] <bluesabre> :)
[23:48] <Unit193> I just did a sync. :3
[23:56] <bluesabre> Nice


[06:55] <ara> good morning all
[08:38] <davmor2> Morning
[08:43] <ara> morning davmor2
[12:42]  * ara -> lunch
[14:04] <davmor2> fader|away: where are you?
[15:09] <ara> davmor2, today is a bank holiday in the US
[15:09] <davmor2> ah
[15:09] <davmor2> thanks
[15:10] <davmor2> just thought he'd forgotten to change his nick again you know what he's like :D
[16:23]  * ara takes a break before the QA meeting
[16:59] <ara> QA meeting now in #ubuntu-meeting