[07:00] <mitya57> Is the Debian importer stuck? It still hasn’t imported the workrave upload from two days ago.
[07:00] <mitya57> According to jbicha on #ubuntu-devel, it also did not import gnome-settings-daemon 3.22.2-3.
[07:10] <wgrant> mitya57: Yeah, we discovered a couple of ours ago that debmirror's failing for some reason. We're investigating.
[08:29] <wgrant> mitya57: debmirror is fixed, so imports should be running as normal now. Expect packages to be available in 2-3 hours.
[08:30] <mitya57> wgrant, great, thanks!
[22:36] <nacc> cjwatson: maybe i'm missing it in the web service documentation, but given a branch_merge_proposal object, is the ID itself available? Or is it reasonable to use the last part of the web_link to extract it? Basically am working on `git ubuntu submit` that opens the merge proposal against the imported repository for review, but we might be in a detached head state and I'm trying to come up with a good
[22:36] <nacc> naming scheme for the branch eventually (the resulting MP seems reasonable)


[00:02] <sergiusens> nacc: if you are seeing failures to upload; this has been going on all day (not related to 2.40) and something snapstore related
[00:03] <nacc> sergiusens: no, wasn't that -- and now i'm thinking it is something else (possibly worse, in that some jobs succeeded and some failed). I'm retriggering all 4 so they use 2.40 hopefully and we'll see what happens
[00:04] <nacc> sergiusens: urgh ... unsquashfs failures? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/350/console
[00:04] <nacc> i just had two of the four fail that way
[00:05] <nacc> sergiusens: but the other two got past that point, it seems
[00:05] <sergiusens> nacc: that is a corrupted download of the core snap; this is part of the general store slow down we are all waiting to get fixed
[00:05] <nacc> sergiusens: oh ok, retry should work?
[00:06] <nacc> sergiusens: or is there a better ... solution?
[00:06] <sergiusens> nacc: I am not in the store team, but a retry could work, yes
[00:06] <nacc> sergiusens: thanks!
[00:06] <nacc> we'll see what it does :)
[00:07] <sergiusens> nacc: btw, why aren't you using launchpad buildd and such?
[00:37] <cjwatson> I can understand people not doing so for per-commit CI
[00:38] <cjwatson> Though I hope we'll support that kind of thing at some point
[00:43] <nacc> sergiusens: what cjwatson said
[00:44] <nacc> sergiusens: in any case, some jobs are showing the link error for libgpg-error still
[00:44] <nacc> but not all
[00:44] <nacc> sergiusens: which feels like a worse place to be than we were
[00:44] <nacc> i'll start debugging in the AM
[01:28] <mup> PR snapcraft#2039 closed: Release changelog for 2.40.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2039>
[02:34] <mup> PR snapcraft#2040 opened: lifecycle: always prime dependencies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
[05:19] <mborzecki> morning
[05:20] <mborzecki> something wrong with the store? the download seems to be capped at 50-60kBps
[05:57] <zyga> good morning
[05:57]  * zyga goes to wake the kids
[05:57] <zyga> mborzecki: yes, store is affected by ceph issue
[05:58] <mborzecki> ceph has fallen apart/
[05:58] <mborzecki> ?
[06:18] <zyga> mborzecki: not sure what happened really
[06:18] <zyga> it's online but very slow apparently
[06:19]  * zyga is almost done with the kids
[06:24] <zyga> not if only kids made me breakfast in return :)
[06:41] <zyga> good morning pedronis, is #4931 ready to go? it has 2 "+1"s and it is green but you expressed an idea that there's perhaps more to be done in that area
[06:41] <mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[06:43] <zyga> pstolowski|afk: I'll play with #4946
[06:43] <mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
[07:03] <pstolowski> morning
[07:04] <kalikiana> moin moin
[07:04] <kalikiana> o/ pstolowski
[07:05] <pstolowski> hey kalikiana
[07:19] <pedronis> zyga: yes, it needs to be done differently to be correct
[07:19] <zyga> pedronis: thanks for confirming that
[07:20] <pedronis> that's why I marked it blocked
[07:34] <mup> PR snapd#4920 closed: timeutil: in Human, count days with fingers <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4920>
[07:36] <zyga> pstolowski: hey, I pushed to https://github.com/snapcore/snapd/pull/4946/files
[07:36] <mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
[07:36] <zyga> can you please have a look
[07:38] <pstolowski> zyga: thanks, looking
[07:44] <pstolowski> zyga: looks good, thanks for extra test
[07:54] <pstolowski> zyga: thinking about this stale connections problem.. as i mentioned on the forum, discard-conns is the last task on snap-removal, it may never get executed if a task before it fails; if think we should run this task regardless of any earlier error (use Lanes?)
[08:00] <zyga> pstolowski: can you walk me through an example please
[08:00] <zyga> (sorry for the lag, my daughter is just leaving for school now)
[08:06] <pstolowski> zyga: we run stop-snap-services, remove-aliases, unlink-snap, remove-profiles, remove hook, discard-conns is last; in particular remove-hook can easily pose problems; discard-conns should be executed always I think
[08:07] <pstolowski> zyga: and nb, i wonder if remove hook shouldn't be called earlier in the sequnce, it's probably run too late
[08:07] <zyga> pstolowski: when remove hook fails, what happens then?
[08:08] <pstolowski> zyga: ah, ignore remove-hook failure, no problem there, we set ignoreError:true on it
[08:09] <pstolowski> zyga: so yeah, the only problem is if any other task fails and discard-conns is not reached
[08:10] <pstolowski> I need to run to the dentist, bbl
[08:10] <zyga> pstolowski: sure
[08:10] <zyga> pstolowski|denti: when you are back, do we undo stuff when any of those fail?
[08:10] <pstolowski|denti> zyga: no, we don't have undo on snap removal, afair it's very hard to undo those
[08:11] <pstolowski|denti> (something we discussed on different occasion with pedronis afair)
[08:15] <mup> PR snapcraft#2013 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013>
[08:16] <pedronis> zyga, mborzecki: #4931 is updated
[08:16] <mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[08:17] <zyga> lookinbg
[08:17] <pedronis> zyga: the change is simple, testing it a bit less so
[08:18] <mup> PR snapcraft#1800 closed: grammar: on..to statement <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
[08:18] <mup> PR snapcraft#1900 closed: many: handle copying of symlink permissions gracefully <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>
[08:38] <mborzecki> zyga: do you know what the plan for nvidia is?
[08:38] <zyga> mborzecki: review your branch with gustavo
[08:38] <zyga> mborzecki: and I think we'll do 2.32.2 with this
[08:40] <mborzecki> zyga: oh ok
[08:45] <zyga><EMAIL_ADDRESS>[09:08] <zyga> not a happy store day
[09:09] <sparkiegeek> zyga: we're just helping you improve your error handling ;)
[09:19] <zyga> sparkiegeek: oh yes, we need to get creative on the word "http" :-)
[09:19]  * zyga hugs sparkiegeek
[09:19] <zyga> it's good that we have plenty of reviews to make :)
[09:24] <om26er> popey: kindly register the name 'sublime-text' under snapcrafters as I don't have the permissions to do so.
[09:25]  * zyga would love to see sublime-text with subl alias
[09:26] <popey> om26er: someone else has registered it, back in 2016
[09:26] <popey> but never uploaded anything
[09:26] <popey> I'll ping them a mail to let them know we'd like to take it over
[09:27] <om26er> popey: yeah, that would make sense
[09:27] <om26er> zyga: the app name is already subl in the yaml file, so we only need the alias (that I'll request once we upload it).
[09:28] <zyga> pedronis: I reviewed #4931
[09:28] <mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[09:29] <popey> om26er: mail sent
[09:29] <popey> lets give it a few days for them to respond
[09:29] <zyga> om26er: perfect!
[09:30] <zyga> om26er: I use the deb still but I  use sublime everywehre so I'm super happy to switch
[09:30] <zyga> it would be nice if there was a way for github to add a banner to pull request page saying "we know about XXX issue, tests are red while that happens"
[09:30] <om26er> aha, so you are our first user ;-)
[09:31] <popey> well crap, their email bounces
[09:31] <om26er> zyga: I also contacted upstream, so you got anything to add there: https://forum.sublimetext.com/t/modern-instalation-snap-package/31123
[09:31] <zyga> is wbond the upstream?
[09:31] <om26er> zyga: yes
[09:32] <om26er> popey: bummer, wonder what's next for us.
[09:32] <mup> PR snapd#4921 closed: skip test if no user "daemon" in build jail <Created by rkitover> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4921>
[09:32] <popey> I'm going to take it.
[09:32] <popey> if you registered a snap over a year ago, never uploaded anything and deleted your email address...
[09:33] <zyga> pedronis: can you please look at https://github.com/snapcore/snapd/pull/4911
[09:33] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[09:33] <zyga> I'm inclined to merge it but I wanted to double check
[09:34] <pedronis> do we still know if we need it?
[09:34] <zyga> I don't think we need it but it's actually very useful for other reasons
[09:34] <zyga> snap version is how we ask people to report bugs and give us initial hints
[09:35] <popey> om26er: done, snapcrafters has sublime-text now
[09:35] <om26er> popey: do we need to ask for 'classic' confinement again ?
[09:36] <om26er> also what about remove the name sublime-text-3 completely, is that possible ?
[09:36] <popey> Yes, I would recommend asking for both the alias and classic confinement in one post
[09:36] <popey> we can just unpublish the sublime-text-3 so nobody can see it
[09:38] <om26er> popey: we already have a alias request in forum.snapcraft.io, so only created a new request for classic confinement
[09:38] <popey> Awesome
[09:38] <popey> Nice work om26er :)
[09:39] <pstolowski> back
[09:44] <om26er> popey: have you also enabled auto builds for that new name ?
[09:44] <popey> not yet.
[09:45] <om26er> hmm, I think for classic confinement request to proceed we would need to have something in the build queue.
[09:46] <om26er> ...same goes for alias request
[09:46] <popey> one moment, I have to remve s-t3 first
[09:46] <popey> https://usercontent.irccloud-cdn.com/file/JzviDh1g/
[09:46] <popey> ^
[09:47] <pedronis> zyga: I will re-look in a bit,  I'm in a twisty maze of conflicts and also it getting close to lunch
[09:47] <zyga> pedronis: ack, thank you and enjoy your lunch :)
[09:49] <popey> https://usercontent.irccloud-cdn.com/file/fNwd5Kq9/
[09:49] <popey> ^ om26er
[09:50] <greyback> was there a CI wobble? https://github.com/snapcore/snapd/pull/4932
[09:50] <mup> PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
[09:50] <greyback> log complaining of odd things
[09:50] <mborzecki> zyga: pushed updates to #4942
[09:50] <mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
[09:50] <popey> om26er: all done from here?
[09:51] <greyback> mborzecki: yay, thanks for that, I'm looking forward to using it
[09:51] <om26er> popey: seems so, yes
[09:51] <popey> awesome
[09:51] <popey> o/ thanks again!
[09:52] <om26er> popey: add me as a collaborator ?
[09:55] <zyga> om26er: can you please ping me once the snap is published
[09:55] <om26er> zyga: sure, will do.
[10:01] <mup> PR snapd#4947 opened: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4947>
[10:01] <om26er> popey: whenever you read this: 1. Kindly add me as a collaborator to sublime-text, 2. I can still `snap info sublime-text-3` so its not really gone.
[10:03] <om26er> zyga: the build failed because it requires classic confinement, that I believe will be granted by jdstrand (and also the alias).
[10:05] <zyga> om26er: did it fail or just got flagged on upload?
[10:05] <om26er> zyga: the latter.
[10:25]  * zyga reviews 4772
[10:25] <zyga> that's a biggie
[10:25] <zyga> I'm reading and scrolling and scrolling
[10:25] <zyga> and thinking, gee, how long is this
[10:25] <zyga> then noticed the header :)
[10:42] <pstolowski> E: Unable to locate package linux-image-extra-4.15.0-12-generic on ubuntu 18.04 in spread
[10:54] <zyga> pstolowski: missing update perhaps?
[10:55] <pstolowski> or archive not fully sync? i've restarted the test, let's see if it persists
[10:55] <zyga> nowadays archive cannot be partially synced
[11:27] <pedronis> zyga:  I have a nitpick about #4911
[11:27] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[11:28] <zyga> pedronis: I'll tweak tha
[11:28] <zyga> that
[11:30] <zyga> pedronis: done
[11:45] <zyga> pedronis: review on the big store PR
[11:46]  * zyga breaks for 15 minutes
[11:59]  * zyga debugs current 18.04 issue
[12:01] <mborzecki> off to pick up my daughter from school, bb for standup
[12:07] <zyga> hmm
[12:07] <zyga> I know what's wrong now
[12:07] <zyga> cachio: ping
[12:07] <cachio> zyga, hey
[12:08] <zyga> cachio: two questions
[12:08] <zyga> what is our kernel in google ubuntu bionic image?
[12:08] <zyga> I get Linux mar281357-854414 4.15.0-12-generic #13-Ubuntu SMP Thu Mar 8 06:24:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[12:08] <mup> PR #13: Bugfix/review tools reenable <Created by mvo5> <Merged by elopio> <https://github.com/snapcore/snapd/pull/13>
[12:08] <zyga> which is very odd
[12:08] <zyga> second
[12:08] <zyga> we need to regenerate that image
[12:08] <zyga> and get a more recent kernel
[12:08] <zyga> because modules for this kernel are no longer in the package
[12:08] <zyga> this must be done ASAP or we must disable bionic tests
[12:09] <zyga> we fail because essentially this happens:
[12:09] <zyga> google:ubuntu-18.04-64 ...# apt-cache policy linux-image-extra-4.15.0-12-generic
[12:09] <zyga> N: Unable to locate package linux-image-extra-4.15.0-12-generic
[12:09] <zyga> N: Couldn't find any package by glob 'linux-image-extra-4.15.0-12-generic'
[12:09] <zyga> N: Couldn't find any package by regex 'linux-image-extra-4.15.0-12-generic'
[12:09] <cachio> zyga, the ubuntu bionic image is not generated by us
[12:09] <cachio> zyga, let me try with the last image
[12:09] <zyga> cachio: ah, I see
[12:09] <zyga> yeah, let's try today's image
[12:10] <cachio> yes
[12:10] <zyga> if this works I'll send the PR
[12:11] <mup> PR snapd#4721 closed: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
[12:12] <zyga> cachio: have a look at 4948
[12:12] <mup> PR snapd#4948 opened: spread: use more recent bionic snapshot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4948>
[12:14] <cachio> zyga, aoorived
[12:14] <cachio> zyga, just wait to see the test results
[12:14] <zyga> thanks, let's see if something blows up along the way
[12:14] <zyga> I'm running it locally here and it's past the point where it broke earlier
[12:15] <cachio> zyga, this images are being updated every day with latest changes
[12:15] <zyga> yeah, it's something w may have to repeat until release
[12:15] <cachio> previously I made to detect automatically the last one and use it
[12:15] <zyga> after release I assume our image will be an alias to the latest stable bionic image
[12:15] <cachio> but we had problems too
[12:15] <cachio> yes
[12:31] <pedronis> zyga: I upadted #4931 , let me know if it's clearer
[12:31] <mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[12:31] <zyga> thanks, looking
[12:39] <mup> PR snapd#4877 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4877>
[12:39]  * kalikiana lunch
[12:42]  * zyga considers closing https://github.com/snapcore/snapd/pull/4349
[12:42] <mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
[12:42] <zyga> we have plenty of PRs and this one doesn't seem to move now
[12:42] <zyga> ogra_: ^
[12:42] <ogra_> zyga, what should move there ?
[12:43] <zyga> ogra_: the PR got NACKed, is there ongoing discussion or other reason to keep it open?
[12:43] <zyga> note that we can always reopen things
[12:43] <ogra_> zyga, it ends with a question from alex to gustavo that got never answered
[12:43] <zyga> we're just struggling with the number of open PRs
[12:43] <ogra_> zyga,  we need this feature for a customer ...
[12:43] <ogra_> one way or the other
[12:43] <niemeyer> What's the PR?
[12:44] <ogra_> my suggestion was turned down, a question was asked what a better approach would be and that is where it stands now
[12:44] <zyga> niemeyer: #4349
[12:44] <mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
[12:44] <mup> PR snapd#4948 closed: spread: use more recent bionic snapshot <Critical> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4948>
[12:45] <zyga> thanks Sergio!
[12:45] <zyga> we need to merge master into most important PRs that are ready to land now
[12:46] <ogra_> zyga, niemeyer, the way more important one is #4819 though ... thats slowly getting urgent
[12:46] <mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
[12:46] <zyga> cachio: I made a back port of the google update for 3.32 but it seems we are still using linode there
[12:46] <ogra_> (i think koza adjusted it properly to be mergeable)
[12:46] <zyga> ogra_: I'll look now
[12:46] <ogra_> ... that one also has an open alex question :)
[12:48] <zyga> that one looks mergeable now, with the updates given it adds one specific new pattern and corresponding tests
[12:48] <zyga> hmm
[12:48]  * zyga needs to read the tests in detail though
[12:48] <mup> PR snapd#4349 closed: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4349>
[12:48] <ogra_> right, but we need to do something about the fact that it will bite us again with the next customer
[12:49] <ogra_> so long term a more graceful regex is needed
[12:49] <ogra_> (manufacturers tend to invent their own tty names for serial ports ... thats not uncommon)
[12:49] <zyga> ogra_: what names those serial ports? that's a specific kernel driver picking such name?
[12:50] <ogra_> zyga, the BSP kernel typically
[12:50] <ogra_> or the devicetree
[12:50] <niemeyer> ogra_: Closed, commented, let us know
[12:51] <zyga> ogra_: I believe it will largely fix itself with hotplug
[12:52] <ogra_> zyga,  point is ... vendors tend to make up new ttyXXX names when introducing a new board
[12:53] <ogra_> and customers using the image tend to waste hours and hours trying to find out why the serial interface they defined does not work at all ... there is no actual valid reason to have a whitelist there
[12:54] <zyga> ogra_: there are some reasons, it's not as clear cut as you claim IMO; still I think work on hot plug will change how we do this thing, it may be that for devices that are automatically detected we will trust the path
[12:54] <ogra_> (but i'm preaching that since we started adding this list in #2626 ... )
[12:54] <mup> PR #2626: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>
[12:54] <zyga> koza: hey
[12:54] <zyga> koza: looking at #4819, can you tell me what the various test changes are for
[12:54] <mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
[12:54] <zyga> koza: I was expecting just some new test chunk
[12:55] <mup> PR snapd#4672 closed: tests: adding test for removable-media interface <Go! Go! Go!> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
[12:55] <zyga> koza: not alterations to existing tests
[12:55] <ogra_> zyga, FYI note that the customer is stuck working on their own features due to this since a week before the sprint ... (the devices are needed for some of their BT addo boards that everything else depends on)
[12:55] <ogra_> *addon
[12:56] <ogra_> zyga, it would be good if we didnt run into this again ... if hotplug helps with serial terminals etc then fine ... if we cant get it in time fore the next customer loosening the whitelist would be helpful though
[12:57] <zyga> ogra_: we cannot open it up to arbitrary tty string AFAIR but I understand what you are saying
[12:58] <ogra_> zyga, can you explain why we cannot open it up with a less strict regex ?
[12:59] <ogra_> (nobody explained the reason for this ever... which caused alex' question in that PR)
[12:59] <mborzecki> zyga: fwiw yocto keeps a list of 'known' tty names in the project tree https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/shadow/files/securetty
[13:00] <zyga> mborzecki: that's pretty useful
[13:00] <mborzecki> probably covers most of what you'd see in the wild
[13:00] <ogra_> zyga, i understad that we do not want to open access to tty[0-n] here ... but everything else *is* a serial tty
[13:00] <zyga> ogra_: as chipaca there commented, /dev/tty, /dev/ttyN are off-limits
[13:00] <ogra_> yes
[13:01] <ogra_> so a regex that makes sure you have a letter there would suffice
[13:01] <zyga> oh
[13:01] <zyga> standup
[13:01] <mborzecki> zyga: gogogo
[13:02] <ogra_> zyga,  having to wait one full snapd release cycle fore every customer that has a new serial tty name is costly and not really practical ... and there seems to be n reason for that strictness
[13:02] <ogra_> *no
[13:03] <zyga> ogra_: I'll work on landing this PR and we can discuss with jdstrand if a more open regex is ok
[13:04] <ogra_> zyga, great (i talked to jdstrand in budapest and he said he would support opening it up)
[13:04] <zyga> ok
[13:04] <ogra_> (if you read the old PR he already supported it there ;) )
[13:06] <jdstrand> it's true. we shouldn't do it without niemeyer though since the current approach is based on his decision
[13:07] <ogra_> yes
[13:07] <jdstrand> note the other day I mentioned a middle ground: take ogra_'s list and expand the regex for everything we know about
[13:07] <jdstrand> if we had done that, the latest one would've already been allowed
[13:07] <ogra_> yep :)
[13:07] <jdstrand> so I suspect future boards will tend to just work if we do that
[13:08] <ogra_> unless a vedor adds a new name :)
[13:08] <jdstrand> hence 'tends' :)
[13:08] <ogra_> (which happens more frequent than one would think sadly :) )
[13:10] <ogra_> (i admittedly never understood that ... ttyS* used to be sufficient for like 15 years ... but apparently branding on a device node level became a thing at some point)
[13:11] <alexlarsson> jamesh: hey, did you see https://github.com/flatpak/xdg-desktop-portal/issues/167#issuecomment-376810447
[13:18] <koza> zyga, answered
[13:32] <kalikiana> re
[13:38] <koza> zyga: thanks and sorry for confusing ;-)
[13:38] <zyga> nah, ok
[13:38] <zyga> I'm just dumb today
[13:47] <pedronis> niemeyer:  btw the first PR of the chain is #4771,  the rename to SnapAction etc is there
[13:47] <mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[13:50] <pedronis> niemeyer: I scheduled something with Bret after your lunch break
[13:50] <niemeyer> pedronis: Thank you!
[14:10] <ondra> kyrofa is sergio around or on holidays?
[14:14] <kyrofa> ondra, sergio is on holidays for the rest of this week and next. Can I help?
[14:28] <om26er> popey: Hey! did you add me as a collaborator for sublime-text ?
[14:29] <popey> om26er: no. I don't think we should. The requirements for classic confinement prohibit it.
[14:29] <popey> om26er: sorry, been on and off the keyboard as I'm on holiday
[14:29] <popey> (currently getting my car tyres replaced) :)
[14:31] <om26er> alright ok. I had rights to android studio and sublime previously ;-)
[14:32]  * zyga break
[14:33] <ondra> kyrofa already chatted to ev https://bugs.launchpad.net/snapcraft/+bug/1759592
[14:33] <mup> Bug #1759592: kernel build fails for lack of modprobe <Snapcraft:New> <https://launchpad.net/bugs/1759592>
[14:33] <jdstrand> roadmr: two snaps have a weird runtime error: https://dashboard.snapcraft.io/snaps/tiled/revisions/61/ and https://dashboard.snapcraft.io/snaps/huggle/revisions/651/
[14:33] <roadmr> jdstrand: yes :(
[14:33] <jdstrand> roadmr: what is that about?
[14:33] <roadmr> jdstrand: we've been having wobbly/slow transfers (uploads/downloads) since yesterday.
[14:33] <jdstrand> ok
[14:33] <kyrofa> ondra, and that's a regression from 2.35, sounds like?
[14:33] <ondra> kyrofa just getting frustrated that yet another break for kernel snap build in LP. Close to give up on LP builds
[14:34] <jdstrand> roadmr: so retriggering the review should allow it to continue?
[14:34] <roadmr> jdstrand: what's happening is that, as the store server tries to pull the snap for review, it times out resulting in an incomplete transfer...
[14:34] <roadmr> jdstrand: that constitutes an invalid squashfs causing those errors you see.
[14:34] <ondra> kyrofa this is for deb, so before builds were failing because of wrong initrd location
[14:34]  * jdstrand nods
[14:34] <roadmr> jdstrand: sometimes, yes; if the retry manages to get a full download, it'll work. Worth a try.
[14:34] <roadmr> jdstrand: it'll all normalize once our storage goes back to full speed
[14:34] <roadmr> jdstrand: I'll try to get an ETA on that
[14:34] <jdstrand> roadmr: yep, cool. thanks!
[14:35] <ondra> kyrofa locally this is unlikely to fail, as usually you have modprobe installed
[14:35] <kyrofa> ondra, okay, we need to SRU another quick fix as well, so I'll get this fix in there as well, hang tight
[14:35] <jdstrand> roadmr: with the r1015, I wanted to not assume anything (not that those changes would cause this)
[14:35] <cachio> zyga, which info do you need for #4943
[14:35] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[14:35] <ondra> kyrofa may be add LP build as part of release test
[14:36] <roadmr> jdstrand: yes, makes sense, but I'm certain it's unrelated. We've been seeing this since before 1015 was rolled out
[14:36] <roadmr> jdstrand: (things broke yesterday morning, 1015 rolled out today wee hours)
[14:36] <jdstrand> roadmr: yep. not saying it was related, just wanted to touch base
[14:36] <roadmr> jdstrand: appreciated :) thanks
[14:36] <cachio> zyga, https://paste.ubuntu.com/p/B5QY2GDBkB/
[14:37] <cachio> zyga, I don't see errors on logs
[14:38] <kyrofa> cjwatson, if I set the "source archive" when requesting a snap build in LP to a PPA containing a newer snapcraft, will that use the newer snapcraft?
[14:39] <cachio> zyga, https://paste.ubuntu.com/p/kM7zMJtQHB/
[14:42] <popey> om26er: we should fix that :S
[14:44] <popey> om26er: sublime-text amd64 is in edge
[14:45] <cjwatson> kyrofa: Yes
[14:45] <popey> i need to put an icon in the store om26er
[14:45] <om26er> popey: yeah and a screenshot as well
[14:46] <cjwatson> ondra: One of the purposes of the work in progress to allow LP builds to consume snapcraft as a snap is to make it easier to do LP-build-based QA as part of release tests
[14:46] <cjwatson> Not immediately helpful to you, but it is definitely something we've discussed and have work in progress to improve
[14:46] <kaliy> hi. who could I ping to transfer ownership of a snap in the store?
[14:46] <popey> om26er: i have also closed the sublime-text-3 channels
[14:47] <popey> kaliy: nessita  is who usually processes mine, and requires an email to proove ownership
[14:47] <popey> -typos
[14:48] <zyga> I will be back soon
[14:49] <popey> om26er: tested locally, the snap works fine, subl alias works
[14:51] <popey> om26er: ok, added icon and a screenshot.
[14:51] <ondra> cjwatson yeah using snapcraft snap in LP build will be so much better and predictable
[14:51] <popey> om26er: want me to push to stable?
[14:52] <ondra> cjwatson and if we can specify channel to use, that would be dream :D
[14:55] <nessita> popey, hey there, can I help with anything?
[14:56] <popey> nessita: hi, kaliy was asking about snap re-ownership
[14:57] <nessita> kaliy, hey there. If you own the snap, we'll need an email sent from the same email address owning the snap, including the target owner, and getting some ack'd from the new owner
[14:57] <nessita> kaliy, with that I can proceed with the snap transfer
[15:01] <niemeyer> pedronis: #4771 LGTM with some additional suggestions
[15:01] <mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[15:02] <cjwatson> ondra: That's exactly what we're working on, yes
[15:03] <ondra> cjwatson yeah!
[15:08] <popey> om26er: i need to go afk in a bit, want me to publish this snap? :)
[15:33] <zyga> re
[15:43] <mup> PR snapd#4949 opened: tests: fix quoting issues in econnreset test <Created by zyga> <https://github.com/snapcore/snapd/pull/4949>
[16:02] <pedronis> niemeyer: meeting?
[16:02] <kaliy> nessita: ack! to which email should I send that?
[16:02] <niemeyer> There!
[16:02] <nessita> kaliy, pinging privately to give you the email
[16:45]  * kalikiana out
[17:04] <niemeyer> mborzecki: Where's the nvidia PR?
[17:04] <mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/4908
[17:04] <mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
[17:34] <niemeyer> mborzecki: DO you have a moment for a call?
[17:34] <mborzecki> niemeyer: give me a sec
[17:35] <mborzecki> niemeyer: standup ho?
[17:35] <niemeyer> Okay.. I need to change clothes as well as it's getting unreasonably warm.. will be there in a minute
[18:05] <cachio> zyga, is it ok the change for #4943 ?
[18:05] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[18:06] <mup> PR snapd#4682 closed: tests: new spread test for physical-memory-control interface <Decaying> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
[18:10] <zyga> cachio:  I’m afk shopping for groceries
[18:10] <zyga> Looking now
[18:10] <cachio> hehe, it is ok
[18:13] <zyga> Nice
[18:13] <zyga> Thank you!
[18:18] <mup> PR snapd#4950 opened: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[18:19] <cachio> pedronis, could you plase see this #4950
[18:19] <mup> PR #4950: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[18:19] <cachio> we have the master broken for this issue
[18:19] <cachio> pedronis, I am working in a solution be I moved that to manual to unblock other PRs
[18:22] <pedronis> cachio: if it takes a while we should probably switch not to manual but have an if at the beginning of the sections
[18:23] <pedronis> I mean take a while to fix
[18:27] <cachio> pedronis, you mean to skip just that part?
[18:27] <cachio> for fedora
[18:27] <pedronis> yes
[18:27] <pedronis> mmh
[18:28] <cachio> not sure how long it will take as the snap is failing
[18:28] <cachio> it is not seem to be a test issue
[18:28] <cachio> I can do that change
[18:28] <pedronis> cachio: sorry, now that I think of it
[18:29] <pedronis> should we use the systems filter?
[18:29] <cachio> yes
[18:29] <pedronis> systems: [-fedora-*]  or something like that?
[18:31] <cachio> updated
[18:34] <pedronis> thanks
[18:36] <cachio> pedronis, thanks to you for reviewing
[18:37] <mup> PR snapcraft#2041 opened: kernel plugin: add kmod as build-package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2041>
[18:57] <Caelum> zyga: I update my second PR and now I'm looking at your notes on the package
[19:10] <mup> PR snapd#4950 closed: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[19:18] <niemeyer> Taking a break for exercising.. back for a meeting at the top of the hour
[19:18] <niemeyer> o/
[19:33] <jdstrand> zyga: hi! fyi, on 16.04 system with up to date master:
[19:33] <jdstrand> $ ./run-checks --static
[19:33] <jdstrand> ...
[19:33] <jdstrand> Running vet
[19:33] <jdstrand> interfaces/apparmor/spec.go:129: arg l for printf verb %s of wrong type: *github.com/snapcore/snapd/snap.Layout
[19:33] <jdstrand> exit status 1
[20:19] <zyga> jdstrand: oh, looking
[20:19] <zyga> looks like a bug in vet
[20:19] <zyga> does this fix it for you?
[20:19] <zyga> https://www.irccloud.com/pastebin/90wGfR4u/
[20:32] <cachio> niemeyer, #4943 ready
[20:32] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[20:37] <kyrofa> zyga, are snaps confined on Debian?
[20:41] <mup> PR snapd#4951 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
[20:42] <mup> PR snapd#4896 closed: store: support macaroon refreshes in store.SnapAction <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4896>
[20:43] <mup> PR snapd#4771 closed: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[20:57] <mup> PR snapd#4772 closed: tests/lib/fakestore/store:  teach the fake store to fake the new install/refresh endpoint <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4772>
[21:02] <niemeyer> cachio: \o/
[21:03] <mup> PR snapd#4943 closed: tests: adding debian sid to google backend <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4943>
[21:05] <cachio> niemeyer, just fedora remains in linode
[21:07] <cachio> niemeyer, I could disable selinux for the google image and it should work, while we can work on fix the issues around it
[21:07] <cachio> niemeyer, so we have all the machines in google
[21:13] <niemeyer> cachio: How is it working in Linode
[21:13] <niemeyer> ?
[21:13] <cachio> selinux disabled
[21:14] <niemeyer> cachio: So disabling in Google sounds fine
[21:14] <cachio> niemeyer, it is gonna be temporal
[21:15] <cachio> I'll make the change in that case
[21:15] <niemeyer> cachio: Yeah, we can work on this spearately
[21:15] <niemeyer> separately
[21:15] <niemeyer> cachio: If Linode doesn't have it we won't lose anything and can migrate and work on that later
[21:16] <cachio> niemeyer, yes, that's the idea
[21:16] <cachio> otherwise we will never end with the movement
[21:16] <niemeyer> Yep
[21:42]  * cachio afk
[23:07] <Caelum> this go stuff is weird, I can't even figure out how to build anything out of a git clone


[07:41] <bullgard4> I found PM1a_STS and PM1b_STS in the ACPI 3.0b Spec but not in Ubuntu kernel 2.6.20-16generic. How does PM1a_STS map to Ubuntu?
[09:24] <mjg59> bullgard4: I don't understand the question
[09:36] <bullgard4> mjg59: In http://advogato.org/article/913.html you have written: ""The user presses the power button. The system switches on, jumps to the BIOS start address, does a certain amount of setup (programming the memory controller and so on) and then looks at the ACPI status register. This tells it that the machine was previously suspended to RAM." I asked: "Where can I find the ACPI status register in Ubuntu 7.04 using the 2.6.20-16gener
[09:37] <mjg59> bullgard4: Yes, and I don't understand the question
[09:37] <mjg59> The register is part of your hardware, not the software
[09:50] <bullgard4> ACPI 3.0b Specification gives an 'Intel Architecture SetSleepingState example' where it clears the wake status by aserting a bit in the PM1a_STS status register. Where is the equivalent code to be found in Ubuntu 7.04?
[09:51] <bullgard4> asserting
[10:11] <mjg59> bullgard4: acpi_hw_clear_acpi_status
[01:01] <bullgard4> Thank you very much. I was able to find it in hwsleep.c, hwregs.c, achware.h and elsewhere.
[02:17] <zul> morning
[02:50] <rtg> amitk: " rtg: Why did you change the -xen config to use MSS stack instead of MMC stack - commit 99b3465fe77281eeb12073e362cb4c7fc332095a?" - blind ignorance. I was satisfying a missing config parameter, but didn't think it through.
[04:40] <iwj> Can I talk to someone about DKMS ?
[04:41] <kousotu> !ask
[04:41] <kousotu> of coursethe damn bot ain't here...
[04:41] <kousotu> iwj: just start your question, someone wil most likely answer you
[04:41] <iwj> I know what you mean but I really don't know anything about DKMS.  I need to know what the kernel guys think of it ...
[04:43] <iwj> In particular, apropos of bug 121676.
[04:45] <rtg> iwj: bug BenC. I'm sure he has some comments.
[04:48] <BenC> iwj: the kernel guys are pushing it :)
[04:48] <iwj> BenC: ^
[04:48] <iwj> Ah, hello.
[04:48] <BenC> iwj: we need it to help support third-party modules
[04:48] <BenC> from OEMs and such
[04:49] <zul> its still sitting the revu right now
[04:49] <iwj> So what's the state of this package ?  Is there a package ?
[04:49] <iwj> Ah.
[04:49] <BenC> it's in universe revu
[04:49] <zul> no one on the motu team has looked afaik i can take a look at it hopefully tonight
[04:50] <zul> or get someone to review it
[04:50] <BenC> yeah, we'd like it to be in universe for gutsy
[04:50] <kousotu> I'm glad the Ubuntu kernal is so forgiving lol
[04:50] <BenC> would be nice if debian would take it so we can just sync it
[04:50] <rtg> BenC: actually we'd like it to be in main for Gutsy (if that is possible)
[04:51] <BenC> rtg: at the very least in universe, so it's installable
[04:51] <BenC> since it wont be in by default, there's not much point in having it in main right now
[04:52] <zul> im getting someone the motu team to do a quick review and ill try to ram it in
[04:55] <kousotu> isthere any wat to have transparency autoset?
[04:55] <zul> iwj: its getting reviewed shortly
[04:56] <iwj> Excellent, thanks.
[04:58] <xhaker> BenC, next ATi driver with AIGLX support, did you know about it already?
[05:01] <rtg> zul: Whom specifically is reviewing the DKMS package? I want to keep track of this issue.
[05:02] <zul> rtg: bddebian
[05:02] <zul> rtg: comments will appear at http://revu.tauware.de/details.py?upid=189
[05:02] <rtg> zul: thanks.
[05:03] <zul> rtg: you can bug him if you want :)
[05:18] <zul> rtg: first review done http://revu.tauware.de/details.py?upid=189
[05:21] <rtg> zul: that was quick. Thanks for the heads up.
[05:22] <zul> no probs
[05:34] <eagles0513875> hey guys what do i have to do to get some wifi drivers added to gutsy
[05:34] <eagles0513875> http://bcm43xx.berlios.de/?go=devices that is the link right now it seems that there r only 2 supported broadcom cards but hopefully they will release more card support
[05:35] <zul> open a bug in launchpad
[05:36] <eagles0513875> ?
[05:36] <eagles0513875> u mean like a wish list kind of thing
[05:36] <zul> yes
[05:36] <eagles0513875> ok am doing it now
[05:38] <eagles0513875> zul: would u like me to link u to the bug then
[05:38] <zul> yes the url in the bug report would be nice
[05:40] <eagles0513875> https://bugs.launchpad.net/ubuntu/+bug/137549
[05:40] <zul> thanks
[05:42] <eagles0513875> no prob
[05:43] <eagles0513875> zul: if those drivers r included in gutsy this distro and pc linux os u will be the only 2 with out of box support
[05:44] <eagles0513875> j/w what is the programming language used by the kernel is it c++ or something else
[05:44] <mjg59> eagles0513875: Erm. We ship bcm43xx.
[05:44] <mjg59> We have done for two years
[05:44] <mjg59> We can't ship the firmware, so you won't get out of the box support
[05:45] <eagles0513875> what u mean
[05:46] <mjg59> I mean, the driver you're asking us to include has been in Ubuntu for two years
[05:47] <eagles0513875> really what repository
[05:47] <mjg59> It's part of our kernel image
[05:47] <eagles0513875> ok for some reason my doesnt work out of the box
[05:47] <eagles0513875> do i download the firmware thats in the repository
[05:48] <mjg59> We can't supply the firmware
[05:48] <eagles0513875> ok
[05:48] <eagles0513875> what do i have to do to get my wifi to work
[05:49] <mjg59> Search for bcm43xx on the wiki
[05:49] <eagles0513875> ok
[05:49] <mjg59> There are instructions there
[05:49] <eagles0513875> ur kernel wiki or general kubuntu one
[05:49] <mjg59> General one
[05:50] <eagles0513875> ok
[05:54] <kousotu> um.. how many workspaces does gutsy-5 have default?
[05:54] <kousotu> and how might I go about changing them?
[05:54] <eagles0513875> u go into system settings not sure bout how many though
[05:55] <eagles0513875> then desktop
[05:55] <kousotu> there wsn't a manager on 4 or 5
[05:55] <kousotu> and for some reason I only have 1 now
[05:56] <kousotu> 2 would be good, 4 would be awesome
[05:56] <kousotu> lol
[05:57] <eagles0513875> lol
[05:58] <eagles0513875> r u on gnome or kubuntu
[05:58] <kousotu> gnome
[05:58] <eagles0513875> then i dont know lol
[05:58] <eagles0513875> im on kde
[05:58] <kousotu> damn..
[05:58] <kousotu> lol
[05:58] <eagles0513875> sry
[05:58] <kousotu> lol
[05:58] <kousotu> np
[05:58] <kousotu> it's a preference
[05:58] <eagles0513875> kousotu: try #ubuntu-kernel
[05:59] <kousotu> lol
[05:59] <eagles0513875> not that channel
[05:59] <eagles0513875> try #ubuntu+1
[05:59] <eagles0513875> that is the gutsy channel
[05:59] <kousotu> I'm in +1
[05:59] <kousotu> I'm also trying to instal beryl, but that isn't in gutsy :(
[05:59] <eagles0513875> lol still no answer in there
[06:00] <eagles0513875> i think its compiz or compizfusion not sure
[06:00] <kousotu> compiz-fusion
[06:00] <kousotu> but I don't want compiz, I want beryl
[06:00] <kousotu> lol
[06:00] <eagles0513875> !compiz-fusion
[06:00] <kousotu> it's installedlol
[06:01] <kousotu> but like I said, I want brryl and not compiz
[06:01] <kousotu> lol
[06:01] <eagles0513875> i think beryl was merged into compiz-fusion
[06:01] <zul> guys this is offtopic here
[06:01] <eagles0513875> kousotu: bring the convo to +1
[07:38] <kousotu> ...
[07:38] <kousotu> brb
[07:38] <kousotu> oops...
[07:45] <zul> hah i dont think kvm-intel is meant to be able to suspend
[08:34] <bdmurray> zul: I ran across bug 135760 and was wondering what happens next with a bug like that
[08:35] <zul> which one is that?
[08:36] <bdmurray> one where you recommend that they boot with "pci=assign-busses" and it fixed their issue
[08:36] <zul> maybe there is a blacklist i have to check
[08:37] <zul> bdmurray: ask for the output of sudo dmidecode and we can black list it
[08:37] <bdmurray> zul: okay, how does that work?
[08:38] <zul> bdmurray: basically the kernel checks a table for a hardware vendor and takes approiate action
[08:39] <bdmurray> some kernel options can have negative side effects though like acpi=off - right?
[08:40] <zul> yep
[08:42] <zul> bdmurray: basically ask the output of dmidecode and I can get it blacklisted for him
[08:45] <bdmurray> zul: Right, I've asked
[08:45] <zul> great dont forget to assign the bug to me ;)
[08:54] <Kano> hi, did you notice that
[08:55] <Kano> rt2500usb            0x0003      0x148f   0x2573
[08:55] <Kano> rt73usb              0x0003      0x148f   0x2671
[08:55] <Kano> are both for the same usb id
[08:55] <Kano> rt73usb              0x0003      0x148f   0x2573
[08:55] <Kano> i mean
[08:55] <Kano> that does not work
[08:56] <Kano> maybe disable it in rt2500usb
[09:11] <BenC> Kano: which one doesn't work?
[09:15] <Kano> well you can not use both the same time
[09:15] <Kano> my tester should come back soon
[09:19] <Kano> how about adding http://sourceforge.net/projects/et131x
[11:20] <Kano> it seems both drivers fail
[11:20] <Kano> only the original ralink rt73 works


[07:25] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3789 Generating diffs
[07:25] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3789 Needs rebuild due to higher version at destination
[08:29] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3789 Pending binary packages
[09:30] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3789 Successfully built
[21:14] <rbalint> hi, do i need extra permissions to trigger autopkgtests with bileto? https://bileto.ubuntu.com/excuses/3789/eoan.html does not seem to be progressing


[08:39] <davmor2> Morning All
[14:00] <jtatum> jcollado, sorry to email and then just submit merge proposals :) The time I have to work on things is kind of limited by work so I wanted to get something in sooner
[14:31] <jcollado> jtatum: No problem.
[16:20] <dholbach> plars, davmor2: jcastro and I were wondering if we could add some documentation for https://wiki.ubuntu.com/Jams/Testing to get people involved for testing during https://wiki.ubuntu.com/UbuntuGlobalJam
[16:21] <dholbach> (2nd to 4th October 2009)
[16:21] <davmor2> dholbach:  I can in a bit but not right now :)
[16:21] <jcastro> cr3: so basically, do you have a page that's the easy "how to run a bunch o tests on a live cd" type page?
[16:21] <dholbach> davmor2: saving the world again?
[16:22] <jcastro> cr3: I was thinking at the minimum we could get a bunch of people running tests. And this is the weekend after beta, so good opportunity.
[16:22] <plars> dholbach: neat, will try to take a look at it , but might be next week before I can get to it
[16:23] <dholbach> plars: if everybody just adds a few bits to it we should be good
[16:23] <dholbach> https://wiki.ubuntu.com/Jams has a lot of general information already
[16:23] <cr3> jcastro: it should be as easy as: Applications -> Administration -> System Testing
[16:23] <dholbach> and Jams/Bugs or Jams/Packaging can probably be used as a template :)
[16:24] <cr3> jcastro: how would you suggest I promote that? I'd be weary to have a wiki page that just contains so little information
[16:24] <jcastro> screenshots?
[16:24] <jcastro> and maybe explain right away how hard we worked to make it easy, etc
[16:25] <cr3> jcastro: sure, where would you suggest we host this page so that it's apparent?
[16:25] <davmor2> cr3: leave it to me dude I'll throw it in free of charge ;)
[16:26]  * cr3 hugs davmor2
[16:26] <jcastro> wow, and that all worked out. :D
[16:26] <cr3> jcastro: you have that effect on people :)
[16:26]  * dholbach can see the love in testing land :)
[16:26] <jcastro> cr3: the jam is right after beta so if you can think of anything to take advantage of a bunch o people getting together with a bunch of hardware ...
[16:27] <cr3> jcastro: I'll be presenting in Montreal during the jam, I'm quite psyched
[16:27] <jcastro> oh excellent
[16:27] <davmor2> jcastro, dholbach: might be useful if you can have a word with slangasek to get a set of images posted to the tracker for that too.
[16:27] <cr3> jcastro: all thanks to komputes though, he's doing an awesome job of annoying me about it :)
[16:27] <davmor2> then people can sign up and log results there :)
[16:28] <jcastro> davmor2: good idea.
[16:28] <slangasek> set of what images?
[16:28] <dholbach> it should be the beta images, I guess
[16:28] <dholbach> 2nd to 4th october, right?
[16:30] <davmor2> slangasek: on friday before the gbj just throw up a clean sheet for gbj for people interest to log bug against basically
[16:30] <slangasek> well if it's the beta images, the beta images will already be on the tracker at that point
[16:32] <davmor2> slangasek: true.
[17:54] <davmor2> cr3: the issue with AAO is that on ubuntu or unr?
[17:55] <cr3> davmor2: I think it's on all
[17:55] <fader_> davmor2: He went to lunch... IIRC it was with both
[17:55] <fader_> cr3: Heh, make a liar out of me
[17:55] <cr3> fader_: I installed the telepathy package, so I can now irc while at lunch
[17:56] <davmor2> telepathy-idle :)
[17:56] <fader_> Hehe
[17:57] <davmor2> I'm running an install in 1 second
[17:58] <davmor2> currently looking at the really weird ubuntu-moblin-remix to track a bug for gruemaster :)
[18:10] <davmor2> cr3, fader_: did you check http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-netbook-remix/20090911/livecd-20090911-i386.out when it failed ;)
[18:11] <davmor2> have a word with slangasek I'm sure he will oblige with a respin to fix it if you ask really, really nicely :)
[19:15] <davmor2> fader_, cr3: just to let you know I just went to do an install of UNR and it's horrifically broken so that is probably why the fail :)
[19:58] <davmor2> fader_: do me a quick favour please just have a quick read of https://wiki.ubuntu.com/Jams/Testing and  ensure it makes sense before I add some images please
[19:58] <davmor2> cr3: ditto ^
[19:59] <fader_> davmor2: For the step "Check if your computer has a cpu with added virtualization: " you might want to include expected output
[19:59] <fader_> i.e. "if it outputs $foo you have it.  If it doesn't output anything, you don't"
[20:00] <davmor2> good point
[20:00] <fader_> davmor2: Looks pretty good... I'm sure it will be even better with screenshots :)
[20:01] <davmor2> fader_: so everything else makes sense?
[20:02] <fader_> davmor2: Yeah, seems to.  But then I have gone through the process myself, so I might have the same blind spots that you do
[20:02] <fader_> I'm sure we'll find out what's missing when people try to use it :)
[20:02] <davmor2> hahahahahahaha
[20:21] <davmor2> fader_: Okay quickly imaged up I need to change the one though
[20:28] <davmor2> jcastro: ping
[20:30] <jcastro> davmor2: pong
[20:30] <davmor2> jcastro: Hopefully https://wiki.ubuntu.com/Jams/Testing is the kinda thing you and dholbach are after
[20:30] <jcastro> looking
[20:31] <jcastro> davmor2: that's perfect
[20:31] <jcastro> basically the "bunch of guys in a pub" use-case
[20:32] <jcastro> davmor2: since beta comes out like the day before is it useful to do ISO testing during the Global Jam?
[20:32] <davmor2> jcastro: yes the release will be out by then but it will be useful to get the extra eyes on it too
[20:33]  * jcastro nods
[20:34] <davmor2> jcastro: plus if people do test on hardware and a particular gfx card for example is playing up it can get logged before and hopefully fixed before final
[20:34] <jcastro> right
[20:34] <davmor2> jcastro: so win win :)
[20:35] <jcastro> what I was wondering is for the global jam to just tell people to use the beta .iso, and then after the jam is completed then give them "homework" to test subsequent CDs if they want to keep going
[20:35] <jcastro> davmor2: I've asked teams to submit their calls-for-test and TODOs for the jam
[20:36] <jcastro> so for example if bryce needs a certain kind of card to test on or something we can hopefully use the jam participation to find it
[20:38] <davmor2> jcastro: Sounds like a plan :)  Test ati cards and gnome they suck at the moment ;)