[00:05] <mwhudson> kyrofa: is there a snapcraft policy on rebasing / squashing commits?
[00:08] <mwhudson> kalikiana: is there a snapcraft policy on rebasing / squashing commits?
[00:23] <elopio> mwhudson: we try to keep one commit per pull request. But for external contributors, we can always click the squash button.
[00:24] <mwhudson> elopio: oh ok
[00:24]  * mwhudson squashes away then
[00:24] <elopio> thanks.
[05:54] <mborzecki> morning guys
[06:32] <mborzecki> pushed 2 extra patches to #4153, think it's good to go
[06:32] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[07:03] <zyga-ubuntu> o/
[07:03] <mborzecki> zyga-ubuntu: hi there
[07:03] <zyga-ubuntu> hi
[07:03] <mvo> hey zyga-ubuntu  and mborzecki
[07:04] <mborzecki> another cold and rainy day, damn i hate atumn
[07:05] <zyga-ubuntu> mborzecki: I was thinking "man, what a gloomy morning"
[07:07] <mborzecki> at least it's not below 0 yet :/
[07:09] <zyga-ubuntu> mborzecki: did you see what's in zakopane this week?
[07:09] <mborzecki> nope, is it 2-3m of snow?
[07:10] <zyga-ubuntu> mborzecki: looks like sub-zero temps during daytime
[07:10] <zyga-ubuntu> so, some good progress on tests yesterday
[07:11] <zyga-ubuntu> I have some more to go but I think I can carve out a chunk now and send a PR
[07:15] <zyga-ubuntu> mborzecki: interesting failure in https://github.com/snapcore/snapd/pull/4153 - there's a missing break in a switch statement
[07:15] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[07:16] <mborzecki> yup
[07:17] <mborzecki> is that intentional?
[07:18] <zyga-ubuntu> no, except for the one that is explicitly commented as such
[07:19] <mborzecki> ok
[07:22] <zyga-ubuntu> school run
[07:27] <mborzecki> any idea where I can get debian-9-64 image that was used in this test?
[07:37] <mborzecki> yeah, no wonder the error wasn't picked up on my arch laptop, I don't have apparmor, but it's weird that gcc test passed on debian-9 image that I pulled from zyga-ubuntu's site :/
[07:45] <zyga-ubuntu> re
[07:45] <zyga-ubuntu> mborzecki: debian-9 is confusing
[07:45] <zyga-ubuntu> mborzecki: we have a "bug" so that debian refers to either sid or stretch in spread, depending on the backend linode vs qemu
[07:46] <zyga-ubuntu> mborzecki: images can be made with adt-buildvm-.. family of scripts but not sure if those would work on arch
[07:46] <zyga-ubuntu> mborzecki: I can build a pair of fresh images and upload
[07:47] <mborzecki> that'd be great, thanks
[07:49] <mborzecki> btw. and what do you use for builiding fedora/opensuse images? packer?
[07:49] <zyga-ubuntu> I don't
[07:50] <zyga-ubuntu> I don't have opensuse images and fedora image was made by someone who's no longer here
[07:50] <zyga-ubuntu> note that debian image is a tweaked cloud image
[07:50] <zyga-ubuntu> same with ubuntu
[07:50] <zyga-ubuntu> so it's "just" a matter of scripting something around a given distribution's cloud image
[07:51] <mborzecki> afaik arch has none :)
[07:53] <zyga-ubuntu> builds are in progress
[07:53] <mborzecki> great
[07:53] <zyga-ubuntu> note that they are not quite reliable and sometimes the "magic" hangs and needs to be retried
[07:53] <zyga-ubuntu> I haven't investigated that, it's a can of worms
[07:54] <zyga-ubuntu> but I should be able to upload some soon
[07:56] <mborzecki> i pushed a patch that should fix that failure, the 'case EPERM:' is in theory covered by a comment, there's some magic in both gcc and clang that will happily accept a fallthrough case if there's a comment that matches a predefined regex
[07:58] <zyga-ubuntu> oh, wow
[08:22] <mborzecki> yay, travis passing now
[08:26] <zyga-ubuntu> refreshed ubuntu images are uploading, I'll make debian images now
[08:26] <zyga-ubuntu> I also fixed the SSL cert
[08:28] <zyga-ubuntu> man, I should have paid for more than 10GB of disk
[08:50] <mborzecki> thanks
[09:12] <pedronis> mvo: I just noticed that becaused configstate.Manager was strange when you turned into a manger Overlord code wasn't completely adjusted
[09:12] <pedronis> and hi
[09:14] <pedronis> mvo: I added a comment about that to #4122
[09:15] <mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
[09:18] <mborzecki> any idea how to convince go that file tagged with `+build !cgo` should not be built when building with cgo enabled?
[09:19] <zyga-ubuntu> hmm, nope
[09:19] <zyga-ubuntu> we have some custom tags
[09:20] <zyga-ubuntu> maybe we could use that as a way to solve the issue?
[09:20] <zyga-ubuntu> like we can build the store with either production or test keys
[09:21] <mborzecki> Chipaca suggested adding stubs for group calls when doing a static build, that's what I'm trying to do, but the no-cgo is picked up when building with cgo anyway :/
[09:22] <mvo> pedronis: good morning! thank you, I have a look
[09:22] <mborzecki> and i'd really like to avoid using function pointers and registering those in init()
[09:22] <pedronis> mvo: let me know if it's not clear
[09:23] <mvo> pedronis: makes sense so far, I get right to it. thanks again!
[09:26] <pedronis> mborzecki: are you disabling it with CGO_ENABLED=0
[09:27] <pedronis> ?
[09:27] <mborzecki> yes, so I have 3 files, group.go (no build tags), group_stubs.go (+build !go) and cgo_group.go (+build cgo)
[09:28] <mborzecki> CGO_ENABLED=0 builds group.go and group_stubs.go (as expected)
[09:28] <mborzecki> CGO_ENABLED=1 builds group.go, cgo_group.go and group_stubs.go (and this is where i get symbol redeclaration)
[09:29] <mborzecki> s/!go/!cgo/
[09:29] <pedronis> that seems odd?  are you sure +build is put in the correct in that file?
[09:29] <pedronis> *correct place
[09:30] <pedronis> go is failry picky where +build should go or it will ignore it
[09:30] <mborzecki> yup, it's right below the license header
[09:31] <pedronis> I never put it there
[09:31] <pedronis> it's eay to get it wrong
[09:32] <pedronis> mborzecki: see for example  asserts/sysdb/testkeys.go  for where we tend to put it
[09:32] <mborzecki> pedronis: damn it, you're right
[09:33] <mborzecki> it was right below /* ... */ license header, apparently go doesn't like that
[09:34] <mborzecki> pedronis: thanks, fixed now, works like charm
[09:34] <pedronis> they need a empty line after (and only blank lines/comments before)
[09:34] <mborzecki> i really really hate go tooling sometimes
[09:35] <pedronis> in general though it's better to put far from keywords, otherwise it's easy for somebody later to break that rule
[09:36]  * kalikiana coffee
[09:40] <pedronis> mvo: thanks
[09:44] <Chipaca> pedronis: good morning
[09:45] <Chipaca> pedronis: you know how alan a little while ago had an issue where a snap somehow got corrupted over a reboot? and that made people think maybe snapd should check the signature of installed snaps on startup as well as on install?
[09:45] <pedronis> Chipaca: yes
[09:46] <pedronis> bit unclear what to do with that until we have warnings though
[09:46] <Chipaca> yes, but
[09:46] <Chipaca> pedronis: on armhf that would be rather prohibitive
[09:46] <pedronis> also expensive
[09:47] <Chipaca> pedronis: the io is bad enough, but our signature makes things worse
[09:47] <Chipaca> pedronis: we're also still doing the double signature check on download+install, which is also not optimal
[09:48] <pedronis> Chipaca: is there a part of this that gets to something we *should* do soon?
[09:48] <Chipaca> pedronis: so this had me revisiting the idea of using two signatures, a cheaper "is the file sane" and a more expensive "is this what we signed"
[09:48] <Chipaca> pedronis: we used to have two signatures (sha256 was the other i think), and i wanted to check with you before chasing people to see if we still had that
[09:48] <Chipaca> to not lose it
[09:48] <Chipaca> before we want it again
[09:49] <pedronis> we still have sha256 from the store afaik
[09:49] <pedronis> don't think it was killed
[09:49] <Chipaca> it seems it might be sha512
[09:49] <Chipaca> still, ok
[09:50] <pedronis> Chipaca: yes, is sha512
[09:50] <pedronis> not sha256
[09:50] <Chipaca> pedronis: if the above sounds sane to you, could you (or can i) mention it to store people lest we forget it?
[09:50] <Chipaca> the other alternative would be to calculate a cheaper checksum on install and use that
[09:53] <Chipaca> anyway, that's enough future-pondering for me. back to the trench!
[09:57] <mvo> Chipaca: I was also wondering about this recently. I'm kind of afraid about the io overhead if we do this but maybe we can make it an optional feature, for some systems we really need it. one really cool alternative would be to use something like a hash-tree so instead of having one global hash for the entire file, have a hash for each block (size to be determined) and on each read we could verify the block only - we would need a trusted hash of
[09:57] <mvo> this block/hash thing but that should be ok. but tradeoffs of course, i.e. each snap would grow or the store would have to send the data oob. anyway just idle thoughts for now
[09:57] <mvo> (huii, that was long)
[09:58] <Chipaca> mvo: does squashfs have anything like this?
[09:58] <mvo> (not a hash-tree more like a hash-flatmap)
[09:59] <mvo> Chipaca: I don't think so, its major work
[09:59] <Chipaca> yeah
[09:59] <mvo> Chipaca: also because it involves the kernel which will have to know about this and do the checking :/
[09:59] <Chipaca> yep
[09:59] <mvo> Chipaca: I think its cool but not short term
[09:59] <Chipaca> ah, no
[10:00] <Chipaca> mvo: short term i just wanted to check we weren't going to throw away the second signature, if we then were going to want to use it :-)
[10:01] <mvo> Chipaca: :) yes
[10:04] <mvo> zyga-ubuntu: a second review for 4150 would be great, hopefully easy
[10:05] <zyga-ubuntu> ak
[10:07] <zyga-ubuntu> done :)
[10:11] <pedronis> Chipaca: I haven't heard discussions about dropping it (sha512) tbh
[10:14] <mup> PR snapd#4158 opened: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
[10:15] <mup> PR snapd#4150 closed: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4150>
[10:16] <pedronis> mvo: got again one of those  /var/lib/snapd changes while tar-ing in 14.04: https://travis-ci.org/snapcore/snapd/builds/298088866?utm_source=github_status&utm_medium=notification
[10:20] <Chipaca> ackk: reviewed (made it all the way through!). This is so close!
[10:21] <mvo> pedronis: interessting. always 14.04, right?
[10:21] <pedronis> possibly yes, not 100% sure
[10:22] <mvo> pstolowski: hm, what happend to PlugInfo.Connections ? iirc we had that some days ago and in master it appears to be gone. what is the replacement to see if a plug is connected?
[10:23] <pstolowski> mvo, you mean Plug.Connections?
[10:25] <mvo> pstolowski: maybe, that, did that change?
[10:25] <mvo> pstolowski: I used to have code like "repo.Plug(snapName, plugName).Connection > 0" to figure out if the plug is connected
[10:28] <pedronis> mvo: well repo is quite in flux
[10:28] <mvo> pstolowski: aha, I see, repo is now handing out PlugInfo instead of Plug, hmm
[10:28] <pstolowski> mvo, indeed
[10:29] <mvo> pstolowski: ok, what I need is to answer the question: "is this (snapName, plugName) pair connected"? I am happy to dig into this myself, was mostly wondering if you have suggestions/plans
[10:29] <pstolowski> mvo, let me see
[10:29] <Chipaca> mborzecki: your pr is very close to a +1; normally i would've +1'ed it leaving you to tidy up the things i point out
[10:30] <mborzecki> Chipaca: thanks for reviewing
[10:30] <Chipaca> mborzecki: give me a shout when you have it, so that i can give it a last once-over
[10:30] <mvo> pstolowski: aha! I think I found it
[10:30] <mborzecki> ack
[10:30] <Chipaca> mborzecki: github hate a comment i made on an commit, i think -- i made the same point in the pr itself just in case
[10:31]  * zyga-ubuntu feels so so
[10:31] <pstolowski> mvo, are you thinking about repo.Connected(..)?
[10:31] <mvo> pstolowski: yes
[10:31] <pstolowski> mvo, i
[10:31] <mvo> pstolowski: or is this misleading?
[10:32] <pstolowski> mvo, i'm wondering if it's good, it takes plugOrSlot
[10:32] <pstolowski> mvo, we could have a "precise" helpe
[10:32] <pstolowski> r
[10:33] <mvo> pstolowski: thanks, its ok for now, I will dig a bit more but this unblocks me. thanks for your help
[10:36] <pstolowski> mvo, I think Connected(..) is not very effective, a simpler helper could just look at slotPlugs or plugSlots maps and return true without all that logic
[10:40] <pstolowski> s/true/bool/
[10:45] <Chipaca> mvo: in your review of #4153, did you forget to +1?
[10:45] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[10:45] <Chipaca> mvo: i see a lot of \o/'s and no /o\ and no +1
[11:05] <mvo> Chipaca: I'm slightly unhappy about the need to write f(void) instead of f() - I understand the reason but I could not bring myself over it yesterday, if I'm the only one who does not like it I'm +1
[11:06] <Chipaca> mvo: I don't like it, but C is C -- if i liked it i'd write more of the stuff
[11:06] <mvo> pstolowski: thanks, I think its fine for now, but if I need something more targeted I will keep it in mind
[11:06] <mvo> Chipaca: heh, fair point
[11:06] <cjwatson> oh I could tell you stories about weird stuff caused by omitting void there
[11:06] <Chipaca> cjwatson: part of me wants you to
[11:06] <Chipaca> cjwatson: the other part is already a block away, screaming
[11:08] <mvo> cjwatson, Chipaca: heh :)
[11:08] <cjwatson> actually thinking about it my best such story was from generated code that said (void) when it actually wasn't, coupled with varargs
[11:09] <mvo> mborzecki: silly question, I am looking at 4135 again and there is a new "break" in apparmor-support.c. I wonder why this is added here, it looks correct but how was it discovered?
[11:10] <mborzecki> mvo: c-unit-tests-gcc failed on debian unstable
[11:11] <mborzecki> as a result of enabling -Wextra warnings
[11:11] <mvo> mborzecki: aha, nice. so it noticed that this was probably unintentional? thats smart
[11:11] <mborzecki> and the CI builds will fail on warnings now :)
[11:12] <mvo> mborzecki: and if there is a "fall-though" comment that is the magic to make it pass?
[11:12] <mvo> mborzecki: (i.e. the line below)?
[11:13] <mborzecki> yes, gcc/clang will match that agains some built-in regexes that cover different variations of 'fall through'
[11:13] <mvo> mborzecki: neat
[11:13] <mup> PR snapd#4141 closed: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4141>
[11:13] <mup> PR snapd#4153 closed: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4153>
[11:22]  * zyga-ubuntu takes a longer break to check if he can work today,
[11:22] <zyga-ubuntu> I don't feel good
[11:23]  * sergiusens is going to be on and off today; off according to the records
[11:49] <mborzecki> i'm looking at packaging, and it's a bit weird, debian/ubuntu has just one 'snapd' package, fedora has it split into snapd and snap-confine, opensuse has a single package again, arch, depending on which files you look at, is either one package (packaging/arch) or 2 packages (one in the repos) or one pacake again (when using PKGBUILD from releases page)
[11:50] <mborzecki> i would assume the idea is to converge all distros to having a single package?
[11:56] <zyga-ubuntu> yes
[11:59] <cjwatson> hmm, what changed recently that would have caused the core snap to be uninstallable in launchpad-buildd's containers?  did we start doing more security setup on the core snap maybe?
[11:59] <zyga-ubuntu> cjwatson: no, I don't think we did
[12:00] <zyga-ubuntu> cjwatson: unless it's udev tagging, we use device cgroups more than before
[12:00] <cjwatson> I can get apparmor working by granting the mac_admin and mac_override capabilities (but I think I remember there being some reason we didn't do that before - will need to dig), and then I run into it wanting udevadm to exist.  I'm sure I managed to avoid all this before
[12:00] <cjwatson> it seems like a surprising category of problems to be new, though
[12:02] <zyga-ubuntu> cjwatson: since we use udev tagging more than before now it is possible that the core snap's configure hook is trying to set something up that was not happening before
[12:03] <cjwatson> if udev is now mandatory then I think snapd is missing a dependency on it
[12:03] <cjwatson> yeah, that's believeable
[12:03] <cjwatson> where does that configure hook live?
[12:06]  * cjwatson installs udev and tries again
[12:07] <zyga-ubuntu> cjwatson: for core it's a bit special, I honestly don't know
[12:09] <ogra_> zyga-ubuntu, cjwatson the source is at https://github.com/snapcore/core/blob/master/hooks/configure ... though mvo is just re-working the world, not sure it stays like that
[12:09] <cjwatson> ta
[12:11] <niemeyer> Hellos
[12:11] <niemeyer> mborzecki: Just sent the invite into the GH org
[12:12] <ogra_> Hellos like greece ? :)
[12:12] <mborzecki> niemeyer: thx
[12:13] <cjwatson> OK, grant mac_admin and mac_override caps and install udev, and all seems to be well again.  Will need to test all the things though ...
[12:18] <niemeyer> mborzecki: There was a third thing I promised you yesterday during our meeting but my notes on it were unfortunate to say the least
[12:19] <niemeyer> mborzecki: I wrote down "forum key", but I'm thinking that this is about the monthly scheduling.. that's what I get for writing down while speaking :)
[12:19] <niemeyer> mborzecki: Are you missing anything else infra-wise?
[12:51]  * zyga-ubuntu -> school, I need to help my daughter
[12:52] <zyga-ubuntu> I'm not much of help today anyway
[12:52] <Chipaca> i just threw my back out doing physio :-(
[12:53] <Chipaca> on the upside, we now know a bit more about what makes it go out
[12:53] <Chipaca> on the downside, FUCKIN' OUCH
[12:53] <mvo> niemeyer: maybe your wrote down linode key?
[12:53] <mvo> Chipaca: /o\ get well!
[12:54] <Chipaca> mvo: that's what i go to phisio for!
[12:54] <Chipaca> physio*
[12:54] <niemeyer> mvo: I had both in the notes.. I think it was really about the monthly scheduling, and I mixed up my writing as we spoke over the linode keys
[12:55] <niemeyer> Chipaca: What was it?
[12:57] <Chipaca> niemeyer: a when my hips go to about 90 degrees pushing, something twangs
[12:57] <Chipaca> but only with my knees at a particular angle
[12:58] <niemeyer> Chipaca: Wow, that must have been pretty hard to "debug", so to speak
[12:59] <Chipaca> niemeyer: some days i wish i had a debugger
[13:00] <Chipaca> of preference one more like smalltalk's
[13:00] <Chipaca> ie that i didn't need to die for it to work
[13:00] <niemeyer> LOL
[13:01] <niemeyer> Chipaca: corpse would be a much better name for those core dumps
[13:28] <cachio> cwayne, hey, any news?
[13:32] <cwayne> cachio: havent heard from QA yet, waiting on Alex to start so I can get you access to that bug
[13:57] <mup> PR snapd#4156 closed: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4156>
[13:58] <pedronis> I need 2nd reviews for #4121 and #4125
[13:58] <mup> PR #4121: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>
[13:58] <mup> PR #4125: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>
[14:03] <popey> jdstrand: do you know of any snap which successfully uses the mpris plug?
[14:05] <popey> jdstrand: specifically an audio player which can be controlled via the buttons in the sound menu on ubuntu
[14:05] <diddledan> I think gradio hooks it, whether successful or not I'm unaware
[14:06] <popey> not successful, i have it playing here and see no reference in the sound menu
[14:07] <diddledan> :-(
[14:07] <diddledan> booo
[14:08] <popey> i made a snap of auryo (a soundcloud client) and it doesn't work here either. But I don't know if I got the config in the yaml right or not
[14:08] <zyga-ubuntu> pedronis: done
[14:08] <popey> I guess I should post on the forum. The problem is the documentation doesn't really cover it from a developer pov
[14:08] <davidcalle> popey gradio
[14:09] <popey> does it work for you davidcalle ?
[14:09] <davidcalle> popey: I did a fresh install last week, so I can't re-check right away, but it worked fine afair
[14:10] <popey> on 17.10?
[14:10] <davidcalle> popey: that's what I'm giving a try now
[14:11] <popey> ok, works on 17.10
[14:12] <davidcalle> popey: works fine on 17.10
[14:12] <popey> not on 16.04 unity
[14:20] <mborzecki> i'm done for today, till tomorrow
[14:22] <mup> PR snapd#4159 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4159>
[14:26] <mup> PR snapd#4160 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4160>
[14:30] <jdstrand> mvo: hi! fyi, those are for a similar udev tagging issue. this wasn't reported by a customer but from the field via the forum. I suggest that it be included in 2.29 so I created a branch, but that is up to you
[14:30] <jdstrand> s/those/those ^/
[14:31] <mvo> thank you jdstrand
[14:32] <mvo> jdstrand: i have a look and see what we can do, probably 2.29.3 as 2.30 is still some time away
[14:32] <jdstrand> mvo: cool (that is what i was thinking)
[14:32] <jdstrand> mvo: for that framebuffer issue, I think I'll try to use a different interface that will be available in more places (eg, time-control, for /dev/rtc)
[14:33] <jdstrand> mvo: I think it is fine to commit the PR you did if you haven't already. I'll just send a followup
[14:33] <mvo> jdstrand: it got only a single +1 so far, but I think its useful becaue it validates the code on devices with a framebuffer
[14:34] <jdstrand> mvo: I also wanted you to be aware of https://github.com/snapcore/snapd/pull/4157
[14:34] <mup> PR #4157: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
[14:34] <jdstrand> mvo: it isn't ready to commit yet (it found a bug in firewall-control :)
[14:34] <Chipaca> popey: I don't know about successful, but: google-play-music-desktop-player, vlc, gradio (from a quick search)
[14:35] <mvo> jdstrand: yeah, thats really nice, I looked at it this morning briefly
[14:35] <popey> i tried copying the gradio mpris config but it barfs when i install the snap
[14:35] <mvo> jdstrand: thanks for that!
[14:35] <popey> https://www.irccloud.com/pastebin/vhbIilEC/
[14:35] <jdstrand> mvo: but the idea is to have a spread test that connects every interface. this will catch things like apparmor syntax issues, the udev_enumerate issue, seccomp policy issues, modules not loading, etc. just a high level test that connects the interface like a user would
[14:35] <jdstrand> mvo: ah cool
[14:35] <mvo> yes
[14:36] <jdstrand> mvo: this technique is what helped me find the uhid issue and the kmod back issues (where the interface fails to connect if the module can't be loaded-- I'll be sending a pr for that)
[14:37] <jdstrand> not uhid. the network-control one
[14:37] <jdstrand> anyway, it is finding things :)
[14:37] <jdstrand> s/back/backend/
[14:38] <jdstrand> mvo: fyi, there may be one more cgroup fixup PR (something I need to investigate for ondra)
[14:42] <mvo> jdstrand: ok, so I will wait a bit before jumping to any 2.29.3
[14:43] <jdstrand> mvo: fyi I was just passing through 4040 and it may be ready
[14:44] <jdstrand> (I didn't look at it, just saw the comments from the submitter)
[14:46] <mvo> jdstrand: looking at it now
[14:46] <popey> \o/ mpris success
[14:46] <jdstrand> popey: oh, I missed your comment, but glad you got it working :)
[14:47] <popey> works on 17.10 but not on 16.04 :(
[14:47] <popey> (is that expected?)
[14:47] <mup> PR snapd#4040 closed: interfaces: add USB interface number attribute in udev rule for serial-port interface <Created by musicguitar> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4040>
[14:53] <popey> jdstrand: do i have to request mpris access on the forum? I have just uploaded auryo. https://dashboard.snapcraft.io/dev/snaps/8645/rev/1/
[14:56] <jdstrand> popey: no. dbus and mpris access I can just handle, unless it is weird and I'd request discussion in the forum
[14:56] <popey> ok
[14:57] <jdstrand> popey: actually, why are you using both?
[14:58] <jdstrand> popey: cause there are two names it is known by?
[15:09] <popey> hm
[15:10] <popey> good question!
[15:10] <popey> lemme fix it
[15:10] <Odd_Bloke> I want to dump the top-level of my repo in to a snap, but using "source: ." means that my .tox and .git directories are included; how can I stop that from happening?
[15:11] <popey> source: ./*  ?
[15:15] <jdstrand> mvo: I am seeing this:
[15:15] <jdstrand> Running vet
[15:15] <jdstrand> overlord/ifacestate/helpers.go:358: arg plug for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Plug
[15:15] <jdstrand> overlord/ifacestate/helpers.go:398: arg slot for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Slot
[15:15] <jdstrand> mvo: I'm up to date on master and looked at upcoming PRs, but don't see fixes
[15:15] <Odd_Bloke> popey: "ValueError: local source (./*) is not a directory"
[15:16] <popey> :(
[15:17] <Odd_Bloke> .tox in particular is a problem because something breaks when snapcraft tries to copy from it.
[15:17] <zyga-ubuntu> jdstrand: I saw that too, I think it's a vet bug honestly
[15:17] <zyga-ubuntu> jdstrand: unless not the same thing
[15:17] <Chipaca> jdstrand: it's a pluginfo, so it has a String(), so %s works
[15:17] <jdstrand> that's all fine. what I'm hearing is everyone is currently just ignoring the vet error?
[15:18] <jdstrand> or do I need to redo godeps or something?
[15:18] <zyga-ubuntu> jdstrand: I just ignore it
[15:19] <mvo> jdstrand: let me check
[15:19] <mvo> jdstrand: I have not seen it, it seems like the go vet on linode is less strict
[15:19] <jdstrand> huh
[15:20] <mup> PR snapd#4113 closed: tests: test for desktop interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4113>
[15:20] <Chipaca> why does it think it's a Plug and not a PlugInfo?
[15:20] <popey> jdstrand: looks like it needs both, yes
[15:21] <jdstrand> popey: do you have snappy-debug output I can see?
[15:21] <popey> sure, one moment
[15:21] <popey> oh, when it fails, or when it succeeds?
[15:21] <mvo> Chipaca, jdstrand might be a recent merge that broke it, I'm looking now
[15:22] <jdstrand> popey: because the dbus one is doing what the mpris interface is supposed to do, but with a different name
[15:22] <jdstrand> popey: does mpris with 'name: auryo' and another mpris with 'name: auryo-player' work?
[15:23] <popey> the one that's in the store works on 17.10
[15:23] <jdstrand> popey: (ie, you create two slots and slots both)
[15:23] <popey> sorry, can you gimmie a pastebin? I don't fully understand
[15:23] <ogra_> jdstrand, quick question ... if i added a content interface bit to my wine snap, could i start snapping random windows exe's that use that content interface as backend to run them via wine (or is execution of binaries blocked ?)
[15:23] <popey> http://paste.ubuntu.com/25911480/ is what it looks like currently
[15:24] <ogra_> jdstrand, (yes/no is enough as answer)
[15:24] <popey> (I had to play around a lot to get this working, only got that working by copy/pasting and fiddling the gradio one)
[15:24] <popey> so mine is based on the gradio snap which is in the store
[15:24] <jdstrand> popey: http://paste.ubuntu.com/25911484/
[15:24] <popey> lemme try that
[15:24] <mvo> jdstrand: hm, could you please check if the go vet thing is something local? I just checked out upstream/master and my 17.10 go vet seems to be happy. or are you on bionic already?
[15:25] <jdstrand> ogra_: execution of binaries is allowed. the trick is getting all the libs to work, etc
[15:25] <ogra_> jdstrand, ok, thanks ...
[15:25] <jdstrand> ogra_: but the security policy allows it
[15:26] <Chipaca> mvo: my 16.04 vet on master throws that error
[15:26] <jdstrand> ogra_: (mrwklix used for write and mrkix for read)
[15:26] <ogra_> ok
[15:27] <mvo> Chipaca: how strange, let me look harder
[15:27] <ogra_> Mr. Kix and Mr. Wklix :)
[15:27] <jdstrand> mvo: fyi, I'm seeing this with run-checks in a 16.04 lxd container
[15:27] <jdstrand> ogra_: hehe :)
[15:28] <jdstrand> mvo: (host is 17.10, logged into 16.04 container, running go vet)
[15:29] <jdstrand> mvo: do you need more info than that?
[15:30] <mvo> jdstrand: no, must be something on my side then, checking
[15:30] <mvo> checking why I don't see the error
[15:31] <Chipaca> waait
[15:31] <Chipaca> jdstrand: can you remove pkg and try again?
[15:33] <jdstrand> Chipaca: remove pkg? (sorry if I'm dense)
[15:33] <jdstrand> oh in gopath
[15:33] <Chipaca> jdstrand: rm "${GOPATH%%:*}/pkg"
[15:33] <Chipaca> -r
[15:34] <jdstrand> that worked
[15:34] <jdstrand> mvo: ^
[15:34] <mvo> aha!
[15:34] <mvo> thanks Chipaca
[15:34] <Chipaca> np
[15:34] <popey> jdstrand: that worked, thanks. uploaded a new auryo
[15:34] <jdstrand> popey: cool :)
[15:35] <jdstrand> Chipaca, mvo: I need to keep a list of things to try. removing pkg, govendor, ...
[15:35] <diddledan> what should I try snapping next?
[15:36] <popey> diddledan: want suggestions? :)
[15:36] <diddledan> please :-)
[15:36] <popey> was gonna suggest nba-go but you already fixed it ;)
[15:36] <diddledan> lol
[15:37] <diddledan> I've got supertuxkart working. I need to get it in the store
[15:37] <popey> diddledan: how about https://forum.snapcraft.io/t/audacity-2-2-0-snap-issues/2719 ? :)
[15:37]  * diddledan goes looksee
[15:41] <Chipaca> diddledan: simcity :-)
[15:43] <jdstrand> popey: ok, done. please snap install it from the store and verify it does what you want
[15:43] <popey> doing now
[15:46] <kyrofa> kalikiana, did you hear about the BlockingIOError discoveries?
[15:46] <kyrofa> I know you were hitting those as well
[15:46] <popey> jdstrand: works as expected (on 17.10), thank you!
[15:46] <popey> will start a thread about 16.04 on the forum
[15:47] <jdstrand> popey (cc flexiondotorg): also, not sure if you saw, but I recommend snappy-debug be used now instead of raw logs. I fixed a bunch of issues with it based on sprint feedback
[15:47] <popey> awesome, will do that
[15:48] <jdstrand> most notably, it doesn't skip dbus any more
[15:48] <popey> i noticed it gave some (more) helpful output when I ran it earlier, good job, thanks!
[15:48] <jdstrand> awesome :)
[15:48] <jdstrand> yw
[15:50] <jdstrand> popey: note that auryo has an executable stack:
[15:50] <jdstrand>  - functional-snap-v2:execstack
[15:50] <jdstrand> 	Found files with executable stack. This adds PROT_EXEC to mmap(2) during mediation which may cause security denials. Either adjust your program to not require an executable stack, strip it with 'execstack --clear-execstack ...' or remove the affected file from your snap. Affected files: opt/Auryo/auryo
[15:51] <jdstrand> 	https://forum.snapcraft.io/t/snap-and-executable-stacks/1812
[15:51] <jdstrand> ./auryo_2.snap: FAIL
[15:51] <jdstrand> why didn't the store notice that...
[15:51]  * jdstrand will look into it
[15:52]  * popey shrugs
[15:52] <popey> it's an electron app
[15:52] <popey> I imagine this is not the only app which has this issue - maybe look at discord and yakyak as other examples
[15:52] <popey> (they're snapped identically)
[15:52] <jdstrand> popey: I mentioned it to the discord guys
[15:53] <jdstrand> popey: I haven't to yakyak (didn't know about it)
[15:53] <jdstrand> popey: is this using electron builder? if so, perhaps it can be made to clear the execstack
[15:53] <popey> no
[15:54] <popey> all three are just dumping their pre-built stuff into a snap
[15:54] <popey> two are proprietary, so we don't have visibility of the source to build
[15:55] <jdstrand> ok, then them clearing it as part of their process is the way to go
[15:55] <jdstrand> I'll see why the store isn't detecting it. it might be a 16.04 vs 17.10 thing
[15:56]  * zyga-ubuntu feels better and starts coding again
[15:59] <zyga-ubuntu> feeling better is still better than feeling worse
[16:00] <mup> PR snapd#4161 opened: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
[16:02] <kyrofa> elopio, the autopkgtest I spun up yesterday morning still hasn't run :(
[16:04] <elopio> kyrofa: no, I'm waiting since saturday :(
[16:04] <kyrofa> elopio, no way
[16:04] <kyrofa> Really?
[16:04] <kyrofa> Gosh
[16:04] <popey> there was a big queue last week but it cleared
[16:05] <popey> (I saw leo complain about the builders queue previously I think) ?
[16:05] <nacc> a bunch of things are going through today, it seems like
[16:05] <nacc> (from uploads i did last week, as well)
[16:05] <popey> still only 40 min queue
[16:05] <nacc> one of my snap LP builds took 48 hours to run :)
[16:06] <kalikiana> kyrofa: discoveries?
[16:07] <kyrofa> kalikiana, still don't know why Travis is tossing the BlockingIOError, but it's masking actual test failures-- run the test that's failing locally, and you'll see them
[16:07] <mup> PR snapd#4162 opened: interfaces/kmod: treat failure to load module as non-fatal <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4162>
[16:07] <elopio> cachio: most of the queue is snapd. Do you really need to run autopkgtests on every pr?
[16:08] <popey> diddledan: how about calibre? They rev frequently. Something which builds a calibre snap which updates frequently would be nice. Popular app too
[16:09] <kalikiana> kyrofa: last time I double checked one of those locally it was passing - are you talking about a particular one?
[16:09] <diddledan> ok, so on my todo then: audacity, simcity/lincity, and calibre
[16:09] <kyrofa> kalikiana, all the ones where it has happened to me :)
[16:10] <diddledan> hah someone said the word calibre in the ubuntu podcast telegram. jinx!
[16:11] <ogra_> calibre totally doesnt fit in that list ! ... the the others are cities !
[16:11] <kalikiana> kyrofa: right. Just wondering if it's the same from your description
[16:11] <diddledan> lol
[16:11] <diddledan> calibrecity?
[16:11] <Odd_Bloke> Hey folks, just posted about a problem with creating a snap I'm having: https://forum.snapcraft.io/t/creating-a-snap-with-a-bunch-of-python-scripts/2735
[16:11] <ogra_> approved !
[16:11] <Odd_Bloke> Input appreciated. :)
[16:12] <nacc> Odd_Bloke: for classic snaps (at least), you're goign to want to build python in your snnap
[16:13] <nacc> Odd_Bloke: fyi, otherwise you'll almost certainly get segfaults
[16:13] <nacc> (well, ont almost certainly, but you might :)
[16:13] <Odd_Bloke> nacc: The scripts don't even end up pointing at the Python in the snap.
[16:13] <nacc> Odd_Bloke: even with the shebang rewriting?
[16:14] <Odd_Bloke> nacc: Well, I think the problem is that I can't get snapcraft to get the scripts in there using the python plugin.
[16:14] <kyrofa> shebang rewrites don't happen with the dump plugin
[16:14] <Odd_Bloke> So I'm not getting the shebang rewrites.
[16:14] <kyrofa> Odd_Bloke, your shebangs wouldn't need to be rewritten if they used /usr/bin/env
[16:14] <nacc> Odd_Bloke: i thinkn you'd need to either use env, or have wrappers
[16:15] <Odd_Bloke> Uh, they are using /usr/bin/env.
[16:15] <Odd_Bloke> Let me double-check what's going on.
[16:16] <Odd_Bloke> Oh, this may be a Python 2 vs 3 issue.
[16:17] <elopio> kyrofa: do you know of a snaps that builds python? I need python3.6.
[16:18] <nacc> elopio: https://git.launchpad.net/usd-importer/tree/snap/snapcraft.yaml
[16:18] <nacc> elopio: we build python2 and 3
[16:23] <elopio> thanks nacc. I had something similar but was getting  "libpython3.6m.so.1.0: cannot open shared object file: No such file or directory"
[16:24] <elopio> I'll try copying some parts from yours
[16:25] <nacc> elopio: that is a classic snap, but i don't thinkn it should matter for building
[16:25] <elopio> nacc: no, I think my problem was the missing --prefix.
[16:26] <nacc> elopio: ah sure
[16:28] <diddledan> popey: regarding audacity, I've sent a tempdir patch upstream: https://github.com/audacity/audacity/pull/211
[16:28] <mup> PR audacity/audacity#211: Update defaultTempDir path in AudacityApp.cpp <Created by diddledan> <https://github.com/audacity/audacity/pull/211>
[16:29] <diddledan> still getting problems with it beyond those issues tho
[16:29] <popey> nice
[16:31] <diddledan> in jailmode audacity gets nuked by seccomp: Log: auid=1000 uid=1000 gid=1000 ses=5 pid=24254 comm="audacity" exe="/snap/audacity/x3/usr/bin/audacity" sig=31 arch=c000003e 50(listen) compat=0 ip=0x7f2d2ad911d7 code=0x0
[16:31] <diddledan> I'm wondering what it's listening on
[16:33] <diddledan> in devmode we're getting a different segfault: audacity: src/hostapi/alsa/pa_linux_alsa.c:1454: BuildDeviceList: Assertion `devIdx < numDeviceNames' failed.
[16:33] <kalikiana> lool: You mentioned in you had a snap that snapcore/snapcraft#1654 was making work, that didn't build before?
[16:33] <mup> PR snapcraft#1654: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>
[16:34] <lool> kalikiana: Yes
[16:34] <lool> kalikiana: just do a simple autotools snap with e.g. gnu hello
[16:34] <lool> when trying to cross-build for e.g. armhf, it will pass --host=armhf instead of --host=arm-linux-gnueabihf and it will fail to find compilers and bail out at configure
[16:35] <elopio> nacc: it works! Thank you :)
[16:35] <popey> diddledan: yeah, i had same, dunno what it's doing.
[16:36] <popey> diddledan: used snappy-debug.security scanlog?
[16:36] <diddledan> yup
[16:36] <diddledan> in devmode the only denials are for xdg-user-dirs
[16:36] <diddledan> Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/xdg/user-dirs.conf" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16:37] <diddledan> and Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/default/nss" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16:37] <diddledan> those are the only two messages in devmode with my tmpdir patch
[16:38] <kalikiana> lool: Okay, will try that. I noticed it made no difference in our autotools hello world so I'm looking to fix that
[16:38] <kalikiana> Thanks
[16:39] <jdstrand> diddledan: the first should be fixed in 2.29
[16:39] <kalikiana> ha, doesn't even configure, nice
[16:43] <nacc> elopio: yw
[16:43] <popey> jdstrand: diddledan i don't believe it is fixed in 2.29 - I'm on 2.29 here and I still see it
[16:44] <kalikiana> kyrofa: seems like our autotools-hello sucks as a test case, if you agree I'll replace it in your --host PR so it actually passes only with your fix
[16:49] <kyrofa> kalikiana, agreed
[16:50] <kyrofa> Sorry, lost power here, didn't realize my modem was plugged into one of the "surge only" outlets of the UPS
[16:50] <kyrofa> Hopefully that lasts for a while
[16:50] <kyrofa> Coding by Candlelight baby
[16:50] <ogra_> romantic !
[16:53] <kalikiana> kyrofa: ouch. hope nothing got lost
[16:53] <kyrofa> Nah
[16:53] <cjwatson> popey: builders and autopkgtests are very separate queues FWIW, even though they share clouds
[16:53] <popey> ah okay :)
[16:54] <jdstrand> popey: https://github.com/snapcore/snapd/commit/acc3eadfb5fb1e6c7553104646cb128646ac2d50 (2.29.2)
[16:55] <popey> k
[17:09] <kalikiana> kyrofa: Hrmmm how do your strange "subfolders" in git work? `git push kyrofa autotools_cross_host` doesn't work... I don't know how to specify the "bugfix" component
[17:10] <kalikiana> need to change location, getting kicked out of the coffee shop, back in a bit
[17:20] <kyrofa> kalikiana, it's part of the branch name. bugfix/<bugref>/description
[17:21] <mup> PR snapd#4163 opened: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
[17:27] <zyga-ubuntu> jdstrand: hey
[17:28] <zyga-ubuntu> jdstrand: not sure if you have energy for reviews today
[17:28] <zyga-ubuntu> Pharaoh_Atem: hey
[17:28] <zyga-ubuntu> guess which OS I'm running?
[17:29] <jdstrand> zyga-ubuntu: I need to look into an issue for ondra first, but feel free to give me the list on irc
[17:30] <zyga-ubuntu> jdstrand: I'm chopping new features into PRs, adding tests as needed, I just one have 4163
[17:30] <zyga-ubuntu> jdstrand: I'm not well today
[17:33] <jdstrand> zyga-ubuntu: sorry to hear that. hope you feel better
[17:34] <zyga-ubuntu> jdstrand: thank you, I'm slightly better now
[17:36] <popey> jdstrand: just noticed a minor typo in snappy-debug... "If have dropped messages, use:"
[17:37]  * diddledan have dropped message
[17:39] <Pharaoh_Atem> zyga-ubuntu: Ubuntu?
[17:40] <zyga-ubuntu> Pharaoh_Atem: MINIX 3 :D
[17:40]  * zyga-ubuntu has some humor back
[17:52] <kalikiana> kyrofa: Whatever I try I get doesn't exist or permission denied... how is it supposed to work?
[17:52] <kyrofa> kalikiana, well, what exactly are you trying?
[17:54] <kalikiana> kyrofa: Trying to push, like I said, doesn't work...
[17:54] <kalikiana> `git push kyrofa bugfix/autotools_cross_host` gives me "src refspec [...] does not match any.."
[17:55] <kyrofa> kalikiana, what is the `kyrofa` remote?
[17:56] <kalikiana> kyrofa: »   url = https://github.com/kyrofa/snapcraft.git
[17:56] <kalikiana> »   pushurl = git@github.com:kyrofa/snapcraft.git
[17:56] <kalikiana> »   fetch = +refs/heads/*:refs/remotes/kyrofa/*
[17:57] <kalikiana> This pattern normally works for any branch from another user or project
[17:57] <kyrofa> kalikiana, and the branch is checked out locally as `bugfix/autotools_cross_host` ?
[17:58] <kalikiana> kyrofa: it's called autotools_cross_host - so bugfix should be part of the name?
[17:58] <kyrofa> kalikiana, it means you're trying to push a branch you don't have
[17:58] <kyrofa> kalikiana, try `git push kyrofa autotools_cross_host:bugfix/autotools_cross_host`
[18:00] <kalikiana> oh
[18:00] <kalikiana> that worked
[18:00] <kalikiana> kyrofa: Thanks!
[18:02] <kalikiana> clearly a dwim version without twice redundant arguments would be boring
[18:02]  * kalikiana wipes a tear for bzr
[18:03] <mup> PR snapd#4164 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4164>
[18:05] <mup> PR snapd#4165 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4165>
[18:06] <jdstrand> mvo: those are the last of the known udev tagging fallout fixes ^. That is the fix for ondra I mentioned. I milestoned the second for 2.29
[18:13] <zyga-ubuntu> jdstrand: do you think we should parse udev rules?
[18:14] <zyga-ubuntu> jdstrand: and have you seen https://github.com/snapcore/snapd/pull/4144
[18:14] <mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
[18:14] <jdstrand> zyga-ubuntu: I have a spread test up for review that would catch stuff like this
[18:15] <jdstrand> jeez, no I did not see that
[18:17] <kalikiana> kyrofa: btw mind having another look at snapcraft#1412 which you reviewed before?
[18:17] <mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
[18:18] <zyga-ubuntu> jdstrand: I'll merge master to fix the conflicts
[18:18] <zyga-ubuntu> jdstrand: but review is very much welcome
[18:20] <mup> PR snapd#4166 opened: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/4166>
[18:21] <cachio> elopio, there is a plan to remove that to nightly
[18:21] <cachio> elopio, it is comming soon
[18:21] <cachio> I need some confirmation before removing this
[18:21] <cachio> jdstrand, https://paste.ubuntu.com/25912364/
[18:22] <cachio> jdstrand, any idea what I need to plug to avoid this error
[18:23] <jdstrand> cachio: the security policy does't like that you are connecting from unconfined. if you have a snap that plugs network-status, I think it would work
[18:23] <jdstrand> that said, that would be a bug in network-status
[18:24] <jdstrand> I'll take a look at that (added to todo for next batch of policy updates, but not for today)
[18:25] <cachio> jdstrand, sure, thanks
[18:27] <elopio> thanks cachio
[18:27] <elopio> cachio: also, you could run the tests for amd64 in travis with adt-lxd. We are close to get that working.
[18:31] <cachio> elopio, well, we are using linode to do that, do you how much you pay for test machines in travis? does it provide any 32 bits machines?
[18:38] <zyga-ubuntu> jdstrand: I merged master into https://github.com/snapcore/snapd/pull/4144
[18:38] <mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
[18:38] <zyga-ubuntu> if you have udev energy in you left please have a look
[18:38] <zyga-ubuntu> I can polish that based on your and pawel's feedback
[18:38] <zyga-ubuntu> and it can go into .3 (I suspect we have to)
[18:41] <jdstrand> ack
[18:41] <zyga-ubuntu> jdstrand: thank you, I guess you can ignore the non-udev PRs for now
[18:41] <zyga-ubuntu> (bigger fire)
[19:15] <mup> PR snapd#4167 opened: cmd/snap-update-ns: fix golint and some stale comments <Created by zyga> <https://github.com/snapcore/snapd/pull/4167>
[19:27] <mup> PR snapd#4168 opened: cmd/snap-update-ns: add new helpers for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4168>
[19:40] <ikey> zyga-ubuntu, i saw you on here as zyga-solus a few times, were you doing anythings there that i could be tripping over?
[19:40] <ikey> wanna get solus snapd rebased and integrated
[19:46]  * elopio goes to the bank before the rain
[19:47] <elopio> cachio: we are using the travis free account, and it doesn't provide 32 machines.
[19:47] <zyga-ubuntu> ikey: no, I didn't do anything more I'm afraid
[19:47] <zyga-ubuntu> ikey: go ahead and rebase, note that we'll have 2.29.3 soon
[19:47] <zyga-ubuntu> (with more fixes)
[19:47] <ikey> is 29 stable or unstable?
[19:47] <zyga-ubuntu> but those should be clean for solus
[19:47] <zyga-ubuntu> unstable still with udev fixes incoming
[19:48] <zyga-ubuntu> but if you rebase for .2 you should be ready for .3 soon
[19:48] <ikey> right
[19:48] <ikey> so it makes sense to get us on the unstable branch
[19:48] <ikey> gonna be a massive pita working out the pending status of existing fixes otherwise
[19:48] <ikey> ok ill make a tarball of snapd 2.29.2
[19:48]  * ikey has a magic script somewhere
[19:50] <ikey> snapd-2.29.2.tar.xz ready, heh
[19:50] <ikey> https://dev.solus-project.com/source/common/browse/master/Scripts/goget.sh <- abomination
[19:50] <mup> PR snapd#4169 opened: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
[19:50] <ikey> but "works"
[19:53]  * zyga-ubuntu pushed a few PRs for upcoming layouts
[19:55] <zyga-ubuntu> I _guess_ I'm done for today
[19:55] <zyga-ubuntu> painkillers and other "meds" made 2nd half of my day useful but I'm far from being good
[19:56] <ikey> :/
[19:56] <ikey> "get well soon" ?
[19:56] <zyga-ubuntu> thanks :)
[19:56] <zyga-ubuntu> just bad luck with my back and the weather sucks :/
[19:56] <zyga-ubuntu> I want back to Spain :(
[19:56] <ikey> ah
[19:57] <zyga-ubuntu> I have a few more bits of code I could share but I think this is more than enough for now
[19:57] <zyga-ubuntu> well...
[19:57] <zyga-ubuntu> well
[19:57] <zyga-ubuntu> I could share one more function
[19:57] <ikey> lol
[19:57] <zyga-ubuntu> but we have 43 PRs already
[19:57] <zyga-ubuntu> damn it... :D
[19:57] <ikey> damn
[19:58] <zyga-ubuntu> and I have steam open just now
[19:58]  * ikey too
[19:58] <zyga-ubuntu> btw, does steam work on solus with amd GPus?
[19:58] <ikey> yeah
[19:58] <zyga-ubuntu> I have a pair of ...
[19:58]  * zyga-ubuntu checks
[19:58] <ikey> testing a regression with hitman here
[19:58]  * ikey also has steam open lol
[19:58] <ikey> just put out LSI 0.6
[19:58] <ikey> im hoping the next major will be the snap
[19:58] <ikey> and we can start ripping steam out of solus itself
[19:58] <zyga-ubuntu> AMD R9 280X (AFAIK)
[19:59] <ikey> should be good after full updates
[19:59] <ikey> so that amdgpu kicks in properly
[19:59] <ikey> (on 4.13)
[19:59] <zyga-ubuntu> I'll install solus on a 2nd HDD and see what works
[19:59] <zyga-ubuntu> I'm kind of curious
[19:59] <ikey> we're a few weeks out yet from a release and im getting my headline features together
[19:59] <ikey> can't just do refreshed ISOs anymore
[19:59] <zyga-ubuntu> it's a budget gaming box, with amd x4 845 and a pair of old used GPus
[20:00] <ikey> LSI will make sure the open source drivers at the very least
[20:00] <ikey> and the steam package depends on LSI and a buttload of libs
[20:00] <ikey> to make sure all the games work
[20:00] <zyga-ubuntu> yeah, I was curious about how that works
[20:00] <zyga-ubuntu> that's why I want to try
[20:00] <ikey> *open source drivers work
[20:00] <ikey> so for that we blacklist libstdc++ vendoring in LSI
[20:00] <ikey> which is how it magically works
[20:01] <ikey> https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/main.c#L108
[20:01] <ikey> ^^
[20:02] <ikey> can't have our users doing obscure `find | xargs rm -rf` commands..
[20:02] <zyga-ubuntu> :D
[20:02] <ikey> todays change was slightly terrifying
[20:02] <ikey> new games are shipping with vendored libressl..
[20:03] <ikey> very, very old libressl
[20:03] <ikey> so i had to teach the intercept module to redirect versioned libssl/libcrypto to a lib{ssl,crypto}-libressl.so on the fly..
[20:03] <ikey> cuz security. -_-
[20:03] <ikey> (some of them are shipping 5+ year old openssls, old curls, etc.)
[20:04] <zyga-ubuntu> that's pretty interesting
[20:04] <zyga-ubuntu> we have one problem with libc and shm_open
[20:04] <ikey> o?
[20:04] <zyga-ubuntu> I wonder if we coudl capture and redirect that function to something snap-aware (but context aware too)
[20:04] <zyga-ubuntu> some calls need to be left as-is
[20:04] <ikey> you could but only for non-setuid binaries
[20:05] <ikey> lsi is using LD_AUDIT for this
[20:05] <ikey> and LD_PRELOAD for the other portion
[20:05] <zyga-ubuntu> some should be tweaked so that the created /dev/shm thing is scoped to the snap
[20:05] <ikey> basically we hijack c lib
[20:05] <zyga-ubuntu> yeah,
[20:05] <ikey> and linker..
[20:05] <zyga-ubuntu> I think we may need to as well
[20:05] <zyga-ubuntu> I'll need to read your code :)
[20:05] <ikey> please do - i tried to keep it simple enough and functional
[20:05] <zyga-ubuntu> but first...
[20:05] <ikey> lol ya
[20:05] <zyga-ubuntu> some gameing :)
[20:05] <ikey> enjoy!
[20:05] <zyga-ubuntu> I'm re-playing wolf games before looking at new colossus
[20:06] <ikey> :D
[20:07] <ikey> "/home/ufee1dead/.local/share/Steam/steamapps/common/Hitman™/bin/libffmpegsumo.so"
[20:07]  * ikey dies inside
[20:07] <ikey> TM in a path
[20:09] <zyga-ubuntu> oh wow
[20:09] <zyga-ubuntu> someone was NACKed by legal :D
[20:13] <kalikiana> clobrano: hey
[20:13] <kalikiana> clemensv:  can you respond to my comment here snapcraft#1648 ?
[20:13] <mup> PR snapcraft#1648: sources: get svn revision with --show-item flag <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1648>
[20:15]  * kalikiana going to wrap up in a bit... long day
[20:17] <c-lobrano> kalikiana: hey, sure, just give me a minute
[20:17] <kalikiana> no rush
[20:23] <cachio> elopio, and how many machines does it provide within the free account?
[20:24] <cachio> elopio, I'll take a look to travis infra
[20:24] <cachio> that could be a good alternative
[20:27] <kyrofa> cachio, Travis? 5, I think
[20:28] <Pharaoh_Atem> ikey: I'm impressed something didn't explode over that
[20:29] <ikey> lol
[20:30] <cachio> kyrofa, good, thanks
[20:30] <zyga-ubuntu> darn
[20:31] <zyga-ubuntu> drat
[20:32] <zyga-ubuntu> I was supposed not to do this
[20:32] <zyga-ubuntu> jdstrand: one PR to look at
[20:33] <mup> PR snapd#4170 opened: cmd/snap-update-ns: add designWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4170>
[20:33] <zyga-ubuntu> this is the tmpfs designer
[20:33] <zyga-ubuntu> I have a good number of prerequisite branches
[20:34] <zyga-ubuntu> but this PR just adds one function for conceptually doing things and contains the most important logic
[20:34] <zyga-ubuntu> I requested you as a reviewer
[20:34]  * zyga-ubuntu really EODs now
[20:36] <cachio> zyga-ubuntu, hey
[20:36] <cachio> enjoy your EOD :)
[20:36] <zyga-ubuntu> o/
[21:36] <mwhudson> github reviews still suck for stacked PRs right
[21:37] <mup> PR snapd#4171 opened: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
[22:42] <dwbrite> Hello, just wanted to pop in and mention that GogLand has been renamed to GoLand, so should be updated in the Featured Snaps section of snapcraft.io
[22:45] <kyrofa> jdstrand, am I correct that a snap using the kernel-module-control plug will not be denied installation?
[22:45] <kyrofa> *sigh* WILL be denied installation
[22:49] <jdstrand> kyrofa: without a snap decl, yes
[22:49] <kyrofa> jdstrand, how do we expect people to experiment with such interfaces?
[22:49] <kyrofa> jdstrand, I've suggested people look into it instead of rolling their own kernel, but then they can't
[22:49] <jdstrand> kyrofa: if you install with --dangerous it works fine
[22:49] <kyrofa> Oh, really? Did that change recently?
[22:50] <jdstrand> no. long time ago for the reason you mentioned
[22:50] <kyrofa> Oh, whew, excellent
[22:50] <kyrofa> It's been a while then
[22:50] <jdstrand> kyrofa: if it doesn'
[22:50] <jdstrand> t work the way I described, it's a bug
[22:50] <jdstrand> but it should. people do this all the time :)


[01:28] <davef> Sweet, I just liberated a Raspberry Pi. Now I got one to play with.
[01:35] <zxmpi_> 1, 2, 3, 4, zero(not a lot of pi in that), pico?
[01:48] <davef> 4
[01:48] <davef> I'll probably get Raspbian on it, then hook it up to the 3d printer at the bench.
[01:49] <davef> I think Cura runs on Linux 🤔
[01:50] <davef> Or I run OctoPi
[02:50] <ball> Alright, let's download this Ubuntu thing and see what it's all about...
[13:22] <zxmpi_> it's sunny outside... must be a trap
[14:51] <davef> # free -m
[14:51] <davef>               total        used        free      shared  buff/cache   available
[14:51] <davef> Mem:         772422        8827      763303          13         291      761887
[14:51]  * davef drools
[14:52] <davef> 768GB RAM :D
[14:52]  * zxmpi_ remembers getting 760k free in dos :-P
[14:52] <davef> and that's only one of the servers
[14:53] <zxmpi_> wooo you can run _2_ electron apps!!
[14:53] <diddledani> wait, that's GB?!
[14:53] <davef> Oh, you want the numbers in GB?
[14:53] <davef> # free -g
[14:53] <davef>               total        used        free      shared  buff/cache   available
[14:53] <davef> Mem:            754           8         745           0           0         744
[14:54] <zxmpi_> 1tb of ram is enough for anyone :-P
[14:54] <diddledani> your servers are too big ;-p
[14:54] <davef> The newer servers start at 1TB
[14:55] <davef> Most of that will be used as cache
[14:55]  * zxmpi_ pats my 2mb psion. ignore the silly people :-)
[15:03]  * davef pokes the firewall


[18:31] <HeadAche> Hello, I have a lot of upstart "Start" commands going off on bootup, and some finish in miliseconds others can take like 4 seconds -- What could be causing this?


[01:18] <Keybuk> *yawns*
[01:19] <Keybuk> thankfully, it is Friday today
[01:19] <AlexExtreme> yup
[01:20] <AlexExtreme> is anyone free to add specs for upstart on launchpad?
[01:20] <Keybuk> yeah
[01:20] <Keybuk> that's why I've moved the specs to the upstart product, and got our own wiki
[01:20] <Keybuk> so brain storming doesn't get in the way of ubuntu releases
[01:20] <AlexExtreme> ok
[01:21] <AlexExtreme> i'll write a spec about profiles later if i get time
[02:13] <AlexExtreme> Keybuk: does this look ok to you? http://upstart.ubuntu.com/wiki/Profiles
[02:13] <AlexExtreme> if so i'll add it on launchpad
[02:28] <Keybuk> AlexExtreme: you should probably indicate where the profiles are actually defined
[02:28] <Keybuk> and how they're chosen
[02:28] <Keybuk> also you need to register the LP entry for it :)
[02:28] <AlexExtreme> ok
[02:29] <AlexExtreme> i've got a pretty good idea about that
[02:33] <AlexExtreme> eww
[02:34] <AlexExtreme> "Sorry, something just went wrong in Launchpad"
[02:34] <AlexExtreme> hmm.
[02:34] <AlexExtreme> works now
[02:36] <Keybuk> cool
[02:36] <Keybuk> (note: we're not using the "release goal" feature)
[02:38] <AlexExtreme> oh
[02:38] <Keybuk> it's not really useful LP thing at the moment, milestones work better
[02:39] <AlexExtreme> ok
[02:40] <AlexExtreme> ok, i've added more stuff to the design section
[03:14] <Keybuk> http://upstart.ubuntu.com/wiki/JobsAsStates
[03:18] <AlexExtreme> looks good
[03:19] <AlexExtreme> btw, could you set a priority for the profiles spec? lp won't let me
[03:20] <Keybuk> I'd like someone to write the competing "Flags" spec as well
[03:20] <Keybuk> as there needs to be a decision about which route to follow
[03:21] <AlexExtreme> k
[03:30] <AlexExtreme> damn, the weather in this country sucks. there's nothing like a good old rain shower to make you feel even better when doing boring coursework.
[03:32] <wasabi_> Jobs as states doesn't appear to differ in anyway from how it works currently: implicite start/stop events for a job
[03:32] <wasabi_> also: good morning
[03:33] <AlexExtreme> morning wasabi_
[03:33] <AlexExtreme> wasabi_: jobs as states means that you can have a job without a exec/respawn/script
[03:33] <wasabi_> Keybuk: Are you going to be writing down our thai conversation? If not I might be able to get some time this afternoon to put it down.
[03:34] <wasabi_> AlexExtreme: Oh, missed that one little word "without"
[03:34] <AlexExtreme> :)
[03:34] <wasabi_> still need the basic state machine syntax put down in writing then
[03:35] <Keybuk> yeah, plan to do that in a bit
[03:53] <Keybuk> http://upstart.ubuntu.com/wiki/JobStates
[03:54] <Keybuk> ^ does that read about right?
[03:55] <Keybuk> (the unwritten intent being, obviously, that post-start is run in the "starting" state and pre-stop run in the "stop" state
[03:57] <AlexExtreme> it sounds ok to me
[03:58] <yankees26> that was odd (i couldn't reconnect)
[03:58] <AlexExtreme> just one comment on this: http://upstart.ubuntu.com/wiki/JobsAsStates - shouldn't it say "A job without either an exec, script or respawn" rather than "A job without either an exec or script" ? (yes, i'm being picky :P)
[03:59] <yankees26> was my question answered while i was gone?
[03:59] <AlexExtreme> yankees26: which question?
[03:59] <Keybuk> AlexExtreme: respawn is syntatic sugar.  I tend to ignore it
[03:59] <AlexExtreme> ah ok
[03:59] <yankees26> the return N_("stop") over return "stop"
[04:00] <Keybuk> respawn ... just means respawn\nexec ...
[04:00] <yankees26> 'cause N_ would just return "stop"
[04:00] <AlexExtreme> yankees26: you lagged out so we probably didn't get it
[04:00] <yankees26> ah
[04:01] <yankees26> well in job.c in const char* functions, it returns N_("the string");
[04:02] <yankees26> and N_ is just a macro that returns "the string" so why not just do return "the string";
[04:02] <AlexExtreme> weno
[04:02] <AlexExtreme> *no
[04:02] <AlexExtreme> N_ performs localization
[04:02] <yankees26> really?
[04:02] <AlexExtreme> afaik, yes
[04:03] <yankees26> 'cause i just see #define N_(_str) (_str)
[04:03] <Keybuk> N marks it for localisation
[04:03] <Keybuk> e.g.
[04:03] <Keybuk> foo () {
[04:03] <Keybuk>    return N_("the string");
[04:03] <Keybuk> }
[04:03] <Keybuk> char *a = foo():
[04:03] <Keybuk> printf ("%s\n", _(a));
[04:03] <Keybuk> it marks the string as likely to be translated
[04:03] <Keybuk> where the _(a) actually translates it
[04:04] <yankees26> oh, is this a natural compiler thing?
[04:04] <Keybuk> it's a gettext thing
[04:04] <yankees26> or is it 'cause libintl.h and locale.h are included?
[04:04] <yankees26> ah ok
[04:10] <yankees26> upstart can completely replace sysvinit right? (like sysvinit doesnt even need to be installed)
[04:10] <Md> right
[04:10] <Md> that's the point
[04:10] <AlexExtreme> well, you need some utilities from sysvinit if you wish to use the sysvinit compat stuff, but to run a fully upstartized system, you don't need it
[04:11] <yankees26> ah
[04:11] <yankees26> what would be missed from using fully upstartized system? (arent shutdown and reboot apps from the sysvinit compat)
[04:12] <AlexExtreme> no, upstart provides it's own
[04:12] <yankees26> ah
[04:13] <Keybuk> pidof, killall5, sulogin, last, mesg
[04:13] <Keybuk> those are the binaries we still use from sysvinit atm
[04:14] <yankees26> ah
[04:14] <yankees26> well pidof i can mimic easily
[04:14] <yankees26> ps -e | grep app | awk {'print $1'}
[04:14] <yankees26> ( i think thats how)
[04:15] <yankees26> (of course it isnt as safe)
[04:15] <yankees26> cause of grep
[04:15] <Md> it would be nice if util-linux were actually maintained, so we could ask the maintainer to accept them there...
[04:16] <yankees26> is efty fully upstartized"?
[04:16] <AlexExtreme> no
[04:16] <AlexExtreme> feisty will be
[04:17] <yankees26> ah
[04:17] <yankees26> well hopefully i
[04:17] <yankees26> 'll have nirvana done sometime in december and i can actually get to doing LFS with upstart
[04:40] <Keybuk> https://wiki.ubuntu.com/DaemontoolsUpstartConfig
[04:40] <Keybuk> ^ and the award for the most pointless thing in the universe to do goes to ...
[04:40] <thom> *giggle*
[04:40] <AlexExtreme> ahahaha
[04:40] <Keybuk> the last two commands in his "Validate" section kinda prove why you really don't need daemon tools if you have upstart
[04:41] <Keybuk> upstart supervising the supervisor
[04:41] <AlexExtreme> yeah
[04:41] <Keybuk> . o O { upstart-compat-daemontools }
[04:41] <yankees26> me being a dumb idiot has no idea what daemontools does and chooses to ignore it :P
[04:41] <thom> well, you'll need some compat bits for daemontools, yeah
[04:42] <thom> the way stdout and stderr and proctitling and stuff are handled
[04:42] <thom> and logging
[04:42] <Keybuk> how does it handled stdout/stderr ?
[04:43] <thom> can't remember, i just remember it being funky
[04:43] <thom> it's been ~4 years since i last went near daemontools
[05:31] <Keybuk> http://upstart.ubuntu.com/wiki/ComplexEventConfig
[05:31] <Keybuk> ^ wasabi_, et al
[05:32] <yankees26> JobAsState link doesnt work
[05:32] <yankees26> says the page doesnt exist
[05:34] <Keybuk> ah, should be JobsAsStates
[05:35] <yankees26> ya
[05:48] !alindeman:*! Hi all!  Wikipedia, the free content encyclopedia project we've all come to depend on, is approaching 1.5 million English articles.  If you wish to track the countdown, join #wikimedia-milestones  Of course, please don't go creating useless articles to "help" :-)


[12:22] <imbrandon> Tonio_, !!! , how was the flight
[12:22] <Tonio_> imbrandon: long....... :)
[12:23] <Tonio_> I have hard time due to the timezone difference
[12:23] <imbrandon> ahh
[12:23] <Tonio_> I woke up at 5 pm today......
[12:23] <imbrandon> heh, thats normal for me :)
[12:23] <Tonio_> I have to force me to bed early and woke up early today
[12:23] <imbrandon> its only 530 pm here now
[12:23] <imbrandon> hehe
[12:23] <Tonio_> hehe
[12:26] <Tonio_> I'm having hard time trying to find where to buy the thinkpad I want......
[12:26] <Tonio_> why on earth isn't that possible to buy on ibm website directly ?
[12:28] <imbrandon> i think you have to get it on the leveeno site
[12:28] <imbrandon> they make the laptops for ibm now
[12:28] <imbrandon> like the new one seele had in MTV
[12:35] <Tonio_> imbrandon: they are not available on lenovo website too, that's my issue :)
[12:36] <imbrandon> hrm
[12:37] <imbrandon> Tonio_, http://www-131.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?storeId=10000001&catalogId=-840&langId=-1&categoryId=2035724
[12:40] <Tonio_> imbrandon: french website doesn't have that chance :)
[12:40] <imbrandon> ahh
[12:49] <jdong> imbrandon: hey, welcome back!
[12:49] <jdong> :)
[12:50] <imbrandon> heya jdong
[01:03] <jdong> imbrandon: any blessings on ktorrent patches yet?
[01:03] <imbrandon> jdong, i'll get to them today
[01:03] <crimsun> hey, can I pester core-dev, too? ;-)
[01:04] <imbrandon> i'm just now getting back in my normal reoutine
[01:04] <jdong> imbrandon: sorry, sorry, sorry :)
[01:04] <jdong> crimsun: sure, it's fun, you should try it ;-)
[01:04] <imbrandon> crimsun, lol
[01:04] <crimsun> zsh: Segmentation fault
[01:04] <crimsun> looks like no pestering for me tonight
[01:05] <imbrandon> heh'
[01:05] <jdong> crimsun: try "bash" ;-)
[02:12] <DaSkreech> How was google campus?
[02:30] <Riddell> DaSkreech: smooth
[02:30] <DaSkreech> What are our objectives for Feisty ?
[02:30] <DaSkreech> Something other than artwork :(
[02:31] <Riddell> port ubiquity to qt 4
[02:31] <Riddell> dist upgrader!
[02:31] <Riddell> port language selector to qt 4
[02:31] <Riddell> bunch of adept changes
[02:31] <Riddell> KDE 4 packages!
[02:32] <DaSkreech> Woah :)
[02:33] <DaSkreech> Lots of groundwork for the big hop?
[02:33] <Riddell> everyone hug Bosonator!
[02:33] <Riddell> DaSkreech: yes, we want it so that when kde 4 is released we can just flip the switch and it's in
[02:33] <DaSkreech> What's Dist upgrader?
[02:33] <Riddell> DaSkreech: to upgrade between releases
[02:34] <DaSkreech> We don't have that now?
[02:34] <Riddell> Bosonator: our docs team are jjesse, nixternal and robotgeek
[02:34] <DaSkreech> I'm pretty certain I used Adept to do that at some point
[02:34] <Riddell> DaSkreech: no graphical tool
[02:34] <DaSkreech> Or you mean with pretty dialogs?
[02:34] <Bosonator> Are those teams, or team leaders?
[02:34] <Riddell> DaSkreech: adept worked for breezy->dapper but hardly at all for going to edgy
[02:35] <Riddell> Bosonator: that's the team (at least the kubuntu side)
[02:35] <DaSkreech> Helo Bosonator
[02:35] <Riddell> Bosonator: they will be able to tell you where you can help most for docs
[02:35] <Bosonator> Hi DaSkreech!
[02:35] <DaSkreech> You are here to help! Welcome!
[02:35] <Bosonator> Riddell: Alright
[02:36] <Riddell> Bosonator: or if you want to try your hand at packaging, you should find a programme that needs it and package folloowing the guide.  hobbsee and others might be good to ask there
[02:36] <DaSkreech> mornfall is off adept right?
[02:36] <Riddell> DaSkreech: he's not doing it at the moment
[02:36] <Bosonator> Ridell: And I can learn how to package from the wiki, correct?
[02:36] <DaSkreech> Right.
[02:36] <DaSkreech> and forums. http://www.ubuntuforums.org/showthread.php?t=51003
[02:37] <Riddell> Bosonator: there's an ubuntu packaging guide somewhere on help.ubuntu.com
[02:37] <Bosonator> Ok, I think I glaced at it earlier. I'll take a closer look.
[02:39] <imbrandon> !package guide
[02:39] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
[02:40] <Bosonator> thanks ubotu
[02:40] <Jucato> moin Riddell, imbrandon, DaSkreech
[02:40] <DaSkreech> Jucato: Hello
[02:40] <imbrandon> ello Jucato
[02:40] <DaSkreech> Is nixternal comatose?
[02:41] <DaSkreech> I haven't heard anything for like 4 days from him
[02:41] <imbrandon> he was arround yesterday
[02:41] <Jucato> would any of you happen to know what file contains changes I make to KControl when I use KControlEdit?
[02:41] <crimsun> he's around today.
[02:41] <DaSkreech> Ok Cool as long as he's alright
[02:41] <crimsun> he made dinner for his S.O. (some type of roast), so don't expect him to be lively for a bit.
[02:44] <robotgeek> Bosonator: you were asking for docs?
[02:44] <Bosonator> Yes, I just joined, and documentation interests me.
[02:45] <robotgeek> Bosonator: great!
[02:45] <Bosonator> robotgeek: How should I get myself oriented to what you guys do?
[02:47] <Riddell> Bosonator: you are joshmbray?
[02:47] <Bosonator> yep
[02:47] <robotgeek> Bosonator: https://wiki.ubuntu.com/DocumentationTeam/GettingStarted
[02:48] <DaSkreech> ktorrent has no docs :)
[02:48] <Bosonator> robotgeek: perfect. thanks.
[02:48] <Jucato> oh, I thought he was asking about packaging, not documentation.hehehe
[02:48] <DaSkreech> is there any plans for krita 1.6 to get into edgy?
[02:48] <Jucato> DaSkreech: special KOffice 1.6 repos
[02:48] <Bosonator> Jucato: I'm new, so I was inquiring about both.
[02:48] <Jucato> from Kubuntu.org
[02:48] <Riddell> DaSkreech: we released edgy teo weeks ago
[02:49] <robotgeek> Jucato: don't you steal doc members :)
[02:49] <Jucato> lol :P
[02:49] <Bosonator> :)
[02:50] <robotgeek> Bosonator: we are currently in discussion on the documentation for feisty fawn
[02:50] <robotgeek> Bosonator: also join #ubuntu-doc
[02:50] <Bosonator> Ok.
[02:50] <Bosonator> Done.
[02:56] <Jucato> does simply editing /etc/xdg/system-settings.menu affect System Settings?
[02:57] <Jucato> nvm, found out :)
[05:20] <Jucato> is there an option in LP to automatically subscribe to bugs that you commented on or changed the status of?
[05:22] <Hobbsee> well, you can hit "email me of responses" each time
[05:22] <Hobbsee> i dont knwo if there's a global optoin for it
[05:22] <jjesse> hello Hobbsee
[05:22] <Hobbsee> hey jjesse!
[05:22] <jjesse> Hobbsee: i'm closer to you then i've ever been
[05:22] <jjesse> i'm in Los Angeles all week :)
[05:22] <Hobbsee> jjesse: oh?  where are you?
[05:23] <Hobbsee> nice!
[05:23] <Jucato> ah, because I remember commenting on more than 5 bugs in LP, yet, only 5 are listed...
[05:23] <Hobbsee> Jucato: it hides fix released ones
[05:23] <Hobbsee> and rejected ones
[05:23] <jjesse> Hobbsee: i'm in training all week, so all of LA i'm seeing is my hotel and the airport :(
[05:23] <Hobbsee> :(
[05:23] <Jucato> yeah, 3 non fix released, 2 fix released... = 5...
[05:23] <Hobbsee> weird
[07:10] <Jucato> !ops
[07:10] <ubotu> Help! Riddell, fdoving, Mez, jpatrick, seth_k, apokryphos, nalioth, Hobbsee, robotgeek, imbrandon, gnomefreak, Hawkwind or trappist
[07:11] <Riddell> ?
[07:11] <Jucato> sorry... was supposed to be in #kubuntu :P
[07:12] <Riddell> Hobbsee: that's a bit unfair
[07:12] <Jucato> hm.. I just realized I don't have auto rejoin...
[07:12] <Hobbsee> oh way cool, more bans to give out;
[07:12] <Jucato> heheh
[07:12] <Jucato> sorry for the !ops in here... :)
[07:13] <Hobbsee> Jucato: it's fine :)
[07:14] <Hobbsee> Jucato: i've not found it
[07:14] <Hobbsee> Jucato: what's the command to search for a subset of an IP?  i've forgottne it
[07:14] <Jucato> ah... oh well. :)
[07:15] <Jucato> in IRC? I don't know... :(*
[07:15] <Hobbsee> hmmm
[07:43] <Riddell> sebas: did you catch what the secure distro was? http://jasmine.19inch.net/~jr/away/2006-11-11-uds/100_0750.JPG
[07:58] <Lathiat> http://jasmine.19inch.net/~jr/away/2006-11-11-uds/100_0752.JPG <- some fine hacking work there
[07:59] <imbrandon> yea jono , community lead recruting some community cheerleaders :)
[07:59] <Hobbsee> hehe
[07:59] <Hobbsee> bet they'd be interesting, if pictures of them were put on the desktop or something
[08:00] <imbrandon> lol
[08:00] <Riddell> we should make that photo the feisty wallpaper
[08:00] <Hobbsee> haha
[08:00] <imbrandon> hahaha
[08:00] <Jucato> lol
[08:00] <Hobbsee> thought there might be some approval there
[08:00] <Hobbsee> and all the girls will just laugh at jono
[08:00] <Hobbsee> sounds good to me :)
[08:00] <imbrandon> i'm just wondering if suzan has seen it yet :)
[08:01] <imbrandon> or how he will explain
[08:01] <imbrandon> :)
[08:01] <Hobbsee> who's suzan?
[08:01] <imbrandon> his wife
[08:02] <Hobbsee> oh right, yes
[09:47] <Hobbsee> was there anyone working on the new basket for feisty?
[10:08] <fabo> Hobbsee: interested to sponsor strigi 0.3.9 ?
[10:09] <Jucato> heheh looks like Riddell really posted that pic... :P
[10:09] <Hobbsee> fabo: sure :)
[10:10] <Hobbsee> hmmm.  basket ftbfs at the moment
[10:32] <ttoine> Tonio_: ?
[10:44] <Jucato> Hobbsee: I've edited system-settings.menu (and put it in ~/.config/menus) to put back some of the stuff that should have been (or should be) in System Settings. is that a proper way to do it? (or must some source file be tampered with?)
[10:44] <Jucato> oh.... bye then :)
[10:44] <Hobbsee> i'll figure it out over dinner, hopefully
[10:44] <Hobbsee> actually, i've got no idea
[10:45] <Hobbsee> you'd have to check another source package
[10:45] <Jucato> it's ok. I'll ask el when she comes back
[10:45] <Jucato> aw... seele's gone... :(
[11:52] <Tonio_> yo ttoine
[11:59] <ttoine> salut, Ton
[11:59] <ttoine> Tonio_:
[11:59] <ttoine> bien rentr ?
[12:07] <Tonio_> waip ca va
[12:29] <Tonio_> grmpf..... ibm sucks really
[12:29] <Tonio_> the same laptop, 1800$ in the us, 3200 in france........
[12:30] <Tonio_> twice the price........
[12:31] <Hobbsee> ouch
[12:32] <Tonio_> I need to find someone in the US that can receive it and ship it to france :)
[12:32] <Tonio_> I'll probably buy in the US then
[12:32] <Tonio_> someone living in the us here ?
[12:32] <Hobbsee> Tonio_: imbrandon is
[12:33] <Hobbsee> Tonio_: werent you just in the US?
[12:33] <Tonio_> Hobbsee: yes
[12:33] <Tonio_> ah yes I didn't thought about imbrandon
[12:33] <Tonio_> good point :)
[12:33] <Tonio_> I'll ask him
[12:34] <Tonio_> they really consider french as stupid
[12:36] <hunger> Tonio_: How so? Are they advertizing "stupid french keylayout"? Or are they more subtile.
[12:38] <_Sime_> Jucato: you might have to run kbuildsyscoa.
[01:41] <ttoine> Tonio_: yeah...
[01:41] <ttoine> i chat of that with my father at lunch
[01:42] <ttoine> he said to me that it is the policy of the french distributor
[01:42] <ttoine> they earn the same with less job
[01:57] <Tonio_> that sucks
[03:07] <Tonio_> imbrandon: ping ?
[03:11] <seele> happy world usability day everyone!
[03:12] <Jucato> hi seele! happy usability day to you, too. :)
[03:12] <Jucato> does that mean you get loads of chocolates today? :)
[03:16] <seele> haha, i wish
[03:16] <seele> i think my boss it taking me out to dinner before we go to the DC event, so its not too bad
[03:17] <Jucato> oooh :)
[03:20] <nixternal> moins everyone
[03:20] <Jucato> moin nixternal!
[03:20] <Jucato> DaSkreech was asking if you were still alive :)
[03:21] <nixternal> i miss Wisconsin and S by GTown, and the lil coffee shop and the smoothie shop, I miss working for FNMA, and most of all, I miss my daughter who lives out there :)
[03:45] <bddebian> Heya
[03:46] <Jucato> hi bddebian!
[03:46] <bddebian> Heya Jucato
[04:41] <Tonio_> imbrandon: ping when you wake up ;)
[04:42] <Lure> Tonio_: hi - still with jet lag?
[04:42] <Tonio_> jet lag ? ;)
[04:42] <Tonio_> Lure: what do you mean ?
[04:43] <Lure> Tonio_: http://en.wikipedia.org/wiki/Jet_lag
[04:43] <Tonio_> Lure: readong
[04:43] <Tonio_> ing
[04:43] <Tonio_> rah !
[04:44] <Lure> Tonio_: this is what I am talking about ;-)
[04:44] <Tonio_> okay so yes, still a bit :)
[04:44] <Lure> Tonio_: being tired for no reason
[04:44] <Tonio_> much harder than in the other way I must say
[04:44] <Lure> Tonio_: did you manage to return laptop and get new one?
[04:46] <Tonio_> Lure: I get it remboursed yes
[04:46] <Tonio_> but I'm trying to buy a thinkpad........; the price in france is completly stupid
[04:46] <Tonio_> price in the US -> 1700$
[04:47] <Tonio_> the same machine in france, with 1GB of ram instead of 2, with 5400 rpm HDD instead or 7200, and 4 cell battery instead of 7
[04:47] <Tonio_> price in france -> 3300
[04:47] <Tonio_> get lower quality and pay twice the price........
[04:47] <Lure> wow, but it has french keyboard, you know ;-)
[04:48] <Tonio_> Lure: bah I'll probably buy in the US, get in shiped in france, pay the taxes and change the keyboard
[04:48] <Tonio_> it'll still be far cheaper
[04:49] <Tonio_> 2300$ for everything, including taxes and shipping so about 1600
[04:49] <Lure> Tonio_: maybe lenove site can ship to EU...
[04:51] <Tonio_> Lure: of course not :)
[04:51] <Tonio_> hehe
[04:51] <Tonio_> Lure: I'll try to get that done with brandon eventually
[04:51] <Tonio_> or I'll buy a dell.....
[04:55] <DaSkreech> What's that thing that edgy does to hide the file system?
[04:59] <Tm_T> DaSkreech: .hidden thing.
[04:59] <DaSkreech> .hidden thing Right Ok :)
[06:59] <DaSkreech> Who has ubotu rights?
[07:04] <jdong> ubotu: who's your daddy?
[07:04] <ubotu> Sorry, I don't know anything about who's your daddy? - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[07:04] <jdong> heh that's what my mom said
[07:04] <jdong> ;-)
[07:04] <DaSkreech> Ubotu is out of date
[07:04] <ubotu> Sorry, I don't know anything about is out of date - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[07:05] <DaSkreech> Lying bot. You are out of date you just don't want your on/off switch flipped to off
[07:05] <jdong> DaSkreech: in all seriousness, Seveas ....
[07:05] <DaSkreech> Yeah I know he hosts them I just want someone to update a factoid
[07:07] <jdong> DaSkreech: can't anyone teach ubotu new tricks?
[07:10] <DaSkreech> Hi Mez
[07:10] <DaSkreech> Well !eol needs to be updated
[07:19] <Mez> !eol > Mez
[07:19] <Mez> y?
[07:21] <DaSkreech> Read it
[07:21] <DaSkreech> Will be?
[07:41] <Seveas> DaSkreech, just try to update it yourself -- any edit attempt will be relayed to #ubuntu-ops so others can see it
[07:41] <DaSkreech> ok
[07:41] <DaSkreech> Umm
[07:42] <DaSkreech> !factoid
[07:42] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://bots.ubuntulinux.nl - Usage info: http://wiki.ubuntu.com/UbuntuBots
[07:42] <DaSkreech> Though I recall the last time I did that with compression someone kept changing it back
[07:42] <DaSkreech> !compression
[07:42] <ubotu> Files with extensions .tar, .gz, .tgz, .zip, .bz2, .7z, .ace and other archive file formats can be opened with file-roller (gnome) or ark (kde) - also see https://help.ubuntu.com/community/FileCompression
[07:42] <DaSkreech> Ok It's fixed now :)
[07:43] <DaSkreech> !no, eol is eol is End-of-life, the point where security updates stop. Hoary went EOL in october 2006, Breezy in april 2007 and Dapper in june 2011
[07:44] <Mez> DaSkreech, you dont have access
[07:44] <DaSkreech> ubotu works like Postfix :)
[07:44] <ubotu> Sorry, I don't know anything about works like Postfix :) - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[07:44] <Seveas> Mez, he knows ;)
[07:45] <Seveas> I always encourage people to still try to edit: that way we all know what needs to be changed
 I'll remember that, Mez
[08:58] <Riddell> testers needed
[08:59] <Riddell> http://kubuntu.org/~jriddell/tmp/wlassistant_0.5.5-0ubuntu3.1_i386.deb
[08:59] <Riddell> please try to connect with edgy wlassistant and that one
[09:03] <Tm_T> Riddell: I'll ping that around if you don't mind.
[09:04] <Riddell> please
[09:06] <Tm_T> Riddell: Any bugreport related to that?
[09:07] <Tonio_> Riddell: didn't that work with edgy ?
[09:07] <Tonio_> it worked correctly with dapper and I didn't touch the package....
[09:07] <Tonio_> Riddell: sorry wpa here I can't test
[09:08] <Riddell> it doesn't work for me
[09:09] <Riddell> according to the bug report 64841 it's because dhclient now outputs something on stderr
[09:10] <Riddell> Tonio_: this patch searches for "There is already a pid file /var/run/dhclient.pid with pid 23486"
[09:10] <Riddell> but I'm worried that string might be translated
[09:10] <Riddell> Tonio_: can you run dhclient eth1 on your french box?
[09:14] <Tonio_> Riddell: sure
[09:14] <Tonio_> Riddell: without sudo ?
[09:14] <Riddell> it needcs sudo
[09:14] <Tonio_> I know :) this is why I asked
[09:15] <Tonio_> Riddell: okay it worked and then ?
[09:15] <Riddell> does it output that error message
[09:17] <Tonio_> Riddell: no error message here
[09:17] <Riddell> ok, run it again
[09:17] <Tonio_> Riddell: just run 3 times and no issue
[09:23] <Riddell> right, source says it's not translated
[09:32] <Tonio_> Riddell: ah okay
[09:34] <Tm_T> Hmm, what was that package building wiki entry?
[09:35] <Riddell> doc.ubuntu.com?
[09:36] <Tm_T> Riddell: Ooh, thank you sir! :)
[09:40] <Tm_T> Riddell: Ok, wep seems to work, haven't got any report about wpa yet.
[09:40] <Riddell> it doeswn't support wpa
[09:42] <Tm_T> Roger.
[09:42] <Tm_T> That explains why noone tried it yet. =)
[09:49] <Tm_T> Riddell: With tested version: http://paste.ubuntu-nl.org/31742/
[09:57] <Riddell> that looks like a separate problem
[10:14] <DaSkreech> btw does nayone else have Konqueror crashes on right clikc?
[10:14] <DaSkreech> Click?
[10:16] <Tm_T> Riddell: I thought so.
[10:19] <Riddell> DaSkreech: not I
[10:19] <DaSkreech> Hmm Ok
[10:19] <DaSkreech> Can KDE not automount an inserted USB stick?
[10:19] <DaSkreech>  that's Hal's job right?
[10:20] <Riddell> KDE tells HAl to dit yes
[10:20] <Riddell> to do
[10:21] <DaSkreech> Is there a button to get KDE to not do that?
[10:23] <Riddell> Cancel
[10:23] <DaSkreech> :-) Something slightly before that button :)
[10:27] <kmon_> hi
[10:28] <Riddell> DaSkreech: unload the kded module
[10:28] <Riddell> hmm, ethereal seems to have disappeared from its package
[10:28] <DaSkreech> ok
[10:34] <kmon_> errr... I know this is not really the place to ask, but I've read in sebas blog about uds-mtv that ati/amd is thinking on HOW to release specs for their graphics cards. Is that a rumour or is it real?