[06:10] <mborzecki> morning
[06:53] <mup> Bug #1700560 changed: “snap find” returns confusing results <Snappy:Fix Released> <Snap Store:Invalid> <https://launchpad.net/bugs/1700560>
[07:29] <zyga> hello
[07:29] <zyga> sorry for being late
[07:29] <zyga> mborzecki how are you doing? :-)
[07:29] <mborzecki> zyga: hey
[07:30] <mborzecki> it's snowing outside (again)
[07:30] <mborzecki> zyga: have i missed anything interesting on friday?
[07:31] <mvo> hey zyga and mborzecki
[07:31] <zyga> haha, same here :-) snow snow snow
[07:31] <zyga> good morning mvo
[07:31] <mvo> here as well!
[07:31] <mvo> snow!
[07:31] <mborzecki> mvo: morning
[07:31] <zyga> well, I had a great Friday EOD except for one test that made me think all weekend about it
[07:33] <mborzecki> zyga: what was the test?
[07:33] <zyga> https://github.com/snapcore/snapd/pull/4644
[07:33] <mup> PR #4644: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
[07:33] <zyga> look at the diff first
[07:33] <zyga> it passes everywhere but on core
[07:34] <zyga> jamesh hello
[07:36] <mborzecki> btw. this is what mikołajki looks like this time of the year: https://imgur.com/a/1Np8S
[07:36] <zyga> oh, we have a bug report hidden on github: https://github.com/snapcore/snapd/pull/3889#issuecomment-364637980
[07:36] <mup> PR #3889: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3889>
[07:37] <zyga> mborzecki woah, nice!
[07:37] <zyga> warsaw is full of smog because of inefficient combustion heaters and people burning trash :/
[07:38] <mborzecki> sounds like every major city during the winter :P
[07:39] <mborzecki> there's an area in lodz, south-west, towards pabianice, mostly older housing, the air quality meters are usually going all red during the winter
[07:39] <zyga> yeah, it's all around poland
[07:39] <zyga> I miss spain, nobody burned trash, it wasn't that cold, air was clean
[07:39] <mborzecki> it wasn't that cold <-- that's your solution there :)
[07:40] <zyga> yeah but also everything was heated by gas, not coal/wood/garbage
[07:40] <zyga> and also a bit more money on average
[07:43] <mborzecki> zyga: that test failing, `cannot stat /var/lib/snapd/seccomp: No such file or directory` ? another thing, was there no /etc in the snap rootfs?
[07:43] <zyga> there is /etc in the core snap, we also have writable paths that change how that operates
[07:45] <mborzecki> zyga: there's a separate path for all this in snap-confine too?
[07:45] <zyga> nope
[07:45] <zyga> well, not for layouts
[07:45] <zyga> I have a suspicion what the problem might be... stay tuned :)
[07:46] <mborzecki> zyga: right, not for layouts, but for bootstrapping the mount namespace
[07:47] <zyga> yes, we do have different setup there
[07:47]  * zyga looks at http://aqicn.org/city/poland/mazowieckie/warszawa/ursynow/ and at http://aqicn.org/city/spain/catalunya/barcelona-eixample/
[07:55] <jamesh> zyga: hi
[07:55] <zyga> hey!
[07:55] <zyga> I merged master into your PR
[07:56] <zyga> and resolved some conflicts due to a recent big code move
[07:59] <zyga> jamesh I may also work on that branch further this week, mainly by chopping it down and landing parts while the last validation problem gets solved
[07:59] <jamesh> thanks.  I've been thinking a bit more about the checks jdstrand wanted.  If we can't work out a way to reliably reconstruct the mount source from the mountinfo file, I wonder if it would be enough to ensure it is on the right device?
[08:00] <zyga> jamesh I don't know yet, I need to think about that and focus (just barely woke up)
[08:01] <jamesh> i.e. if we expect the mount source to be in the user's /run/user/$UID tmpfs, we should be able to reliably check that it is still from that file system after the mount
[08:02] <jamesh> (e.g. hasn't been replaced by a symlink to /etc on a different device)
[08:02] <zyga> yes, that's doable
[08:02] <zyga> one thing we can do is to check that after the mount op finishes there are no more symlinks than before
[08:02] <zyga> but I need to think about what we might be racing with here
[08:02] <jamesh> of course, for the xdg-document-portal case, the mount point is in a fuse file system under $XDG_RUNTIME_DIR, so we can't just check the one device number
[08:04] <jamesh> I think we could do a simple walk backwards through mountinfo before the mount to find out the expected device for the source, and then check the details of the new mountinfo entry afterwards to confirm
[08:05] <zyga> yeah, that's doable, I think we need to walk both the mount table and the path components and see where we land at each stage (if we follow any symlinks along the way)
[08:06] <zyga> jamesh btw, I was also wondering about one more thing, if we can simplify the problem by 50% by doing "mount -t stuff /dev/stuff ."
[08:06] <jamesh> for user mounts, I think it'd be okay to consider any cross-device symlinks to be an error
[08:06] <zyga> if we mount in the current directory, if that's even doable, we have smaller attack surface
[08:06] <zyga> not sure if we're going to mount more than fuse filesystems now
[08:07] <mborzecki> mvo: could you upload a .vendor.tar.gz release files to github releases page for 2.31?
[08:07] <jamesh> zyga: what do you mean by "mount -t stuff" here?
[08:07] <zyga> jamesh: pushd && cd /tmp && mount -t tmpfs tmpfs . && popd
[08:08] <zyga> jamesh no way to attack mount target directory (mount point)
[08:08] <zyga> and after we cd we can take all our time to investigate where we've landed
[08:08] <zyga> (we can also write a secure chdir)
[08:09] <mvo> mborzecki: sure, let me do this
[08:09] <jamesh> zyga: is that more secure than doing "cd dest; mount --bind /source ." ?
[08:09] <mborzecki> mvo: thanks
[08:09] <zyga> no, that's exactly what I meant
[08:09] <zyga> the idea is to avoid mount /one/path /another/path
[08:10] <zyga> and to reduce that to /one/path
[08:12] <jamesh> just wanted to check what would happen when mounting over a symlink: the command line tool dereferences the symlink itself, so that doesn't help much
[08:12] <zyga> jamesh yeah, that happens at syscall level too, that's why mount(2) sucks so much :/
[08:13] <jamesh> so who wants to propose a mountat() system call? :)
[08:13] <zyga> there were some proposals like that
[08:14] <zyga> but I think it's a bit complex for reasons I don't fully understand
[08:14] <zyga> there is some reason why it's path based more than just FD based
[08:14] <zyga> the last thing I remember was ...
[08:17]  * zyga still searches
[08:18] <zyga> https://lwn.net/Articles/718638/
[08:20]  * zyga breaks for breakfast
[08:23] <alexlarsson> jamesh: hey, did you look at the document portal?
[08:26] <zyga> hey alexlarsson
[08:26] <alexlarsson> hey hey
[08:27] <alexlarsson>  You can't get any simple mount() changes in
[08:27] <alexlarsson> because al viro hates the mount syscall and wants to completely redo it
[08:28] <alexlarsson> Thus blocking minor improvements
[08:28] <alexlarsson> Not that i disagree with him...
[08:32] <zyga> well, a no-follow flag would do wonders
[08:32] <zyga> but yeah
[08:32] <zyga> I'd love to see a new API too
[08:32] <jamesh> alexlarsson: I haven't done a full test of your branch yet.  I'll get that done and add some feedback to the PR.
[08:32] <zyga> (don't really mind if both happen)
[08:33] <jamesh> there is a fantasy linux mount API described here: https://lwn.net/Articles/718638/
[08:33] <alexlarsson> What i would love is a bind mount + make readonly in a single call
[08:34] <alexlarsson> I have some horrendous complicated code for recursive read-only bind mounts :/
[08:35] <alexlarsson> https://github.com/projectatomic/bubblewrap/blob/master/bind-mount.c
[08:35] <alexlarsson> this is total bullshit
[08:35] <alexlarsson> and should just be MS_BIND | MS_REC | MS_RDONLY
[08:37] <zyga> all software evolves till it parses mountinfo ;-)
[08:39] <alexlarsson> I asked al, and he agreed it was bullshit. But...
[08:39] <zyga> but nack to small improvements?
[08:40] <alexlarsson> yeah
[08:40] <zyga> is he working on the new big API or is it just fossilisation stage and nothing happens?
[08:41] <alexlarsson> unclear
[08:43] <jamesh> If you fixed mount() so that flags other than MS_REC were respected when performing a bind mount, how would the app even know?
[08:44] <zyga> jamesh I think it'd require a MOUNT_EXTRA_FLAGS flag or something similar to indicate desire to use a richer interface
[08:44] <zyga> or an entirely new syscall
[08:45] <jamesh> zyga: the syscall is currently documented as ignoring other flags, and the call is likely to succeed on an old kernel anyway
[08:45] <jamesh> so you'd need to check after the fact to see if they were applied
[08:46] <zyga> too messy, the idea is to make userspace easier, not just hard but different
[08:46] <zyga> given what you said a new syscall is really needed
[08:47] <alexlarsson> jamesh: child of MS_MGC_VAL ?
[08:48] <jamesh> If they'd instead made it an error to specify the flags that it currently ignores, there'd be something user space could check for
[08:48] <alexlarsson> yeah
[08:48] <alexlarsson> but that would make sense!
[08:48] <zyga> haha
[08:48] <zyga> all the good choices we never did
[08:50] <zyga> and even once the new interface is here it will be many many cycles before it can be used as a dependency without cutting a significant chunk of users
[09:31] <Chipaca> morning all
[09:36] <mvo> hey Chipaca, good morning
[09:36] <Chipaca> mvo: hiya
[09:38] <Chipaca> I suck at naming things. What would *you* call this Thing, and what would you call the arguments to New after the first? https://gist.github.com/chipaca/21222a4fa23ae5d8629c84cc016f23ea
[09:38] <Chipaca> ^ that's what i've been playing with this weekend
[09:38]  * Chipaca now gets back to work
[09:39] <mvo> Chipaca: hm, maybe Formater?
[09:40] <Chipaca> mvo: it's not strictly work, and it's got bugs still, but if you want to play with it, https://people.canonical.com/~john/snap-find should work on amd64
[09:40] <Chipaca> (needs a running snapd)
[09:41] <mvo> Chipaca: nice
[09:42] <mvo> Chipaca: Columnizer , ColumnFormater, SheetFormater for some more ideas
[09:42] <Chipaca> oooh, Columnizr and be all web 2.0
[09:43] <Chipaca> wrt the bugs, one is go's, in that i need to add code to handle double-wide characters by hand (search for 'hello' and look at hello-bluet)
[09:43] <Chipaca> another is that in long listings it seems to be doing something wrong and leaving too much space for things it's not going to print yet, so there's a cutoff missing its spot
[09:43] <Chipaca> but anyway,lots of fun rune-twiddling to be had
[09:44] <mvo> Chipaca: :) looks/sounds like it indeed!
[10:44]  * Chipaca -> physio break
[10:59]  * Chipaca -> *really* physio break
[11:06] <mup> PR snapd#4648 opened: debian, snap: only static link libseccomp in snap-seccomp on ubuntu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4648>
[11:12] <mup> PR snapd#4645 closed: snapctl: allow `snapctl get` from any uid <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4645>
[12:01] <mup> PR snapd#4649 opened: many: record if snap was installed with --dangerous, snow relevant annotation in `snap info` and `snap list` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4649>
[13:00] <mup> PR snapd#4650 opened: daemon: allow `snapctl get` from any uid <Created by mvo5> <https://github.com/snapcore/snapd/pull/4650>
[13:01] <Chipaca> hmmm, hangouts seems rather dark right now
[13:02]  * Chipaca turns it off and back on again
[13:02] <Chipaca> oh god they're trying to use opengl
[13:50] <mup> PR snapd#4629 closed: ifacestate: only rewrite security profiles if the system-key changes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4629>
[13:53] <Chipaca> man, go-flags is terrible at formatting this stuff
[13:53] <Chipaca> :-(
[13:54] <Chipaca> https://pastebin.ubuntu.com/=dS8vNTVhrM/
[13:54] <Chipaca> like, wtf is going on with the option alignment
[13:54] <Chipaca> --hello
[13:54] <Chipaca> .                                       --yes-im-over-here
[13:54] <Chipaca> .    --WAT
[13:58] <mup> PR snapd#4651 opened: cmd/snap: add help for service commands (oops) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4651>
[13:58]  * Chipaca hugs mup
[14:02] <Son_Goku> today is a day where I curse Go for making it so that build flags are comments in Go files
[14:03] <mborzecki> Son_Goku: CGO_LDFLAGS_ALLOW is your friend
[14:03]  * Son_Goku sighs
[14:04] <mborzecki> Son_Goku: they did forget to add a similar for pkg-config though :)
[14:04]  * Son_Goku mournfully looks over at the nice stuff in Rust with Cargo...
[14:17] <mborzecki> off to pick up the kids
[14:19] <mvo> zyga: 4643 has a trivial suggestion for a comment fix
[14:19] <zyga> ack
[14:20] <mup> PR snapd#4638 closed: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4638>
[14:25] <mup> PR snapd#4651 closed: cmd/snap: add help for service commands (oops) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4651>
[14:25] <Chipaca> wooooo
[14:25] <Chipaca> that's got to be a record
[14:25] <Chipaca> 23 minutes from PR to landed with 2 +1s and green spread
[14:29]  * mvo hugs Chipaca
[14:37] <mup> PR snapd#4646 closed: snap-seccomp: fix cgo pkg-config and LDFLAGS <Created by stapelberg> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4646>
[15:11] <mvo> the classic confinement test segfaults on bionic :( /me wants the `snap run --gdb` branch to be merged to debug this
[15:11] <Chipaca> jdstrand: you around?
[15:12] <mup> PR snapd#4643 closed: snap: disallow layouts in various special directories <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4643>
[15:34] <jdstrand> Chipaca: hey, yes
[15:34] <Chipaca> jdstrand: I was looking through the review tools wondering about version validation
[15:34] <Chipaca> jdstrand: are they still from lp:click-reviewer-tools ?
[15:35] <jdstrand> Chipaca: for the moment
[15:35] <Chipaca> jdstrand: and if so, is it _verify_pkgversion in common.py
[15:35] <Chipaca> jdstrand: and if so, maybe update it so it matches snapcraft's validator?
[15:35] <Chipaca> jdstrand: or, sync with snapcraft about it
[15:36] <Chipaca> there are things that one considers invalid that the other doesn't, in both directions
[15:36] <jdstrand> Chipaca: I can do that. it matched at one point...
[15:36] <jdstrand> Chipaca: is there a particular issue you are looking at?
[15:37] <Chipaca> jdstrand: I'm adding version validation to snapd
[15:37] <Chipaca> and I'd like to write that it matches what the review tools and snapcraft do
[15:37] <Chipaca> but currently i cannot :-)
[15:37] <jdstrand> then, yes, I'll adjust the review tools to match snapcraft
[15:38] <jdstrand> Chipaca: since you've looked at snapcraft, where is the validation happening there?
[15:38] <Chipaca> jdstrand: ^[a-zA-Z0-9.+~-]{1,32}$ is what snapcraft is checking fwiw
[15:39] <jdstrand> so '~' is a valid version?
[15:39] <Chipaca> jdstrand: schema/snapcraft.yaml
[15:39] <Chipaca> jdstrand: yes
[15:39] <Chipaca> jdstrand: also README.~1~
[15:40] <jdstrand> Chipaca: let me rephrase. '~', '.', '+' and '-' are all supposed to be valid versions?
[15:40] <Chipaca> jdstrand: in snapd, _anything_ is a valid version :-)
[15:40] <Chipaca> but yes in snapcraft those things are valid versions
[15:40] <jdstrand> Chipaca: the store has its own checks separate from the review-tools aiui, and the review tools reflect that
[15:40] <jdstrand> Chipaca: I know it is in snapcraft :P is snapcraft *wrong*?
[15:40] <Chipaca> this is turning into a Meeting, isn't it
[15:41] <Chipaca> *gasp*
[15:41] <Chipaca> surely not
[15:41] <Chipaca> sergiusens: you on national holiday today, n'eh?
[15:42] <Chipaca> kyrofa: kalikiana: can we talk about versions for a bit?
[15:42] <Chipaca> or maybe i should open a bug
[15:42] <kyrofa> Chipaca, sure!
[15:42] <jdstrand> Chipaca: honestly, I think we need the store team. iirc there are checks there
[15:42] <Chipaca> kyrofa: am I right in thinking that snapcraft uses the schema/snapcraft.yaml thing to validate versions?
[15:42] <kyrofa> Oh, looks like I have some reading to do
[15:43] <kyrofa> Chipaca, yes, if it's a string it's validated with that regex
[15:43] <Chipaca> jdstrand: ok
[15:43] <jdstrand> I'll change the review tools to whatever is agreed to. the version check was more important when we had the version as part of the security label
[15:43] <Chipaca> noise][: who knows about the version validation the store does?
[15:44] <Chipaca> noise][: that is, validation of the version string in a snap
[15:44] <kyrofa> Chipaca, yeah we have no horse in this race either-- you just tell us what you want it to be and it shall be done
[15:44] <Chipaca> kyrofa: basically the regexp there is suspect, but we have apparently three different ones already :-) so, this
[15:45] <Chipaca> kyrofa: version must match ^fantastic-.*$
[15:45] <Chipaca> \o/
[15:45] <jdstrand> I *think* what I was remembering was that we were doing what the store does, not what snapcraft does, since people can run the review-tools on a snap prior to upload (no one does that now, but when this was written, that was the thinking)
[15:45] <kyrofa> Yeah seems reasonable
[15:45] <kyrofa> :P
[15:46] <Chipaca> jdstrand: right, but I'm not sure the store enforces the "version must be debianish" rule any more
[15:46] <jdstrand> it's possible now that click and snapv1 are gone, the version check in the store was removed
[15:46] <jdstrand> right. me either
[15:46] <jdstrand> hence you asking them :)
[15:46] <pedronis> jdstrand: Chipaca: I don't see a version check in the store
[15:47] <Chipaca> hmmm
[15:47] <pedronis> there's just a max length
[15:47] <jdstrand> it had to do with the upload
[15:47] <pedronis> afaict
[15:47] <jdstrand> I forget what it was called...
[15:47] <Chipaca> maybe I should just try to upload something with a ridiculous version and see what happens
[15:49] <jdstrand> I don't know if the output of the test is: 'Is a valid package' or 'Stated package version matches snap.yaml'
[15:49] <jdstrand> those two tests are not from the review tools
[15:51] <jdstrand> pedronis: does what you looked at have those checks? ^
[15:52] <Chipaca>   - malformed 'version': 'this is some silly potatoes'
[15:53] <diddledan> no spaces?
[15:53] <pedronis> Chipaca: that seems review tools tough
[15:53] <pedronis> not the store itself
[15:53] <pedronis> I don't see a pattern check for version in the store code
[15:54] <Chipaca> jdstrand: note review tool's [A-Za-z0-9.+:~-]+? means those things are also valid versions for this, fwiw
[15:55] <Chipaca> so, it's just snapcraft and review tools, beyond the length limit
[15:56] <jdstrand> Chipaca: yes
[15:57] <pedronis> there's a 32 chars max-length
[15:57] <Chipaca> jdstrand: and i just pushed a thing with a version of ~ just to make sure
[15:57] <pedronis> in the sotre
[15:57] <pedronis> store
[15:57] <jdstrand> alright, well, if there are no checks in the store, I'll just update the review tools to match snapcraft
[15:57] <pedronis> jdstrand: I'm double checking with other people about the store
[15:57] <Chipaca> kyrofa: is there any reason snapcraft explicitly disallows epoch-style versions things?
[15:58] <Chipaca> kyrofa: (there's no ":" in there)
[15:58] <kyrofa> Chipaca, not that I know of. This regex has been there as long as I can remember
[15:58] <jdstrand> pedronis: it was some code that westby wrote. I can't remember the name of it. it might be gone now
[15:59] <kyrofa> Chipaca, we don't use the version for anything other than plopping into the snap.yaml and putting it into the filename of the resulting snap
[15:59] <jdstrand> kyrofa: it probably should include ':'. people like to snapcraft a stage-package and just use the deb version
[16:00] <kyrofa> jdstrand, yeah easy peasy. Sounds like we want some other changes too though, perhaps to not start or end or have multiple [.+~-:]
[16:00] <Chipaca> would ^[a-zA-Z0-9]([a-zA-Z0-9:.+~-]{,30}[a-zA-Z0-9+])?$ be any better?
[16:00] <Chipaca> oh, oh, _ also
[16:00] <pedronis> jdstrand: other store people seems to confirm there's no check (atm)
[16:00] <Chipaca> ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+])?$
[16:00] <pedronis> *seem
[16:00] <kyrofa> Yeah seems fine to me Chipaca. You want it, you got it
[16:01] <Chipaca> mvo: you also know something about versions, could you eyeball it? ^
[16:01] <mvo> Chipaca: in a meeting right now, will look soon
[16:02] <Chipaca> mvo: ack
[16:03] <jdstrand> Chipaca: I would suggest: ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+~])?$
[16:03] <jdstrand> Chipaca: (allow ~ at the end)
[16:05] <Chipaca> jdstrand: i don't mind; what version are you imagining that needs it?
[16:05] <jdstrand> 1.2.3-2~
[16:05] <Chipaca> I left the + in there because I imagined somebody wanting a 3.2+ version
[16:05] <jdstrand> I've seen that before
[16:05] <Chipaca> ok, fair
[16:05] <mvo> yeah, 1.0~ will be common
[16:05] <mvo> (ish)
[16:06] <mvo> its a common pattern for e.g. backports
[16:06] <Chipaca> also if [+~_-] isn't an emoticon it should be
[16:06] <jdstrand> Chipaca: alright, adding to trello ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+~])?$. ping me if changing
[16:06] <Chipaca> jdstrand: will do, thank you!
[16:07] <jdstrand> I'm also surprised that the review tools allow what they do... they didn't always. I remember the discussions. anyway, who cares, it is changing now :)
[16:07] <Chipaca> kyrofa: running with this one ^ will shout if it changes
[16:07] <Chipaca> also may i suggest you python people use (?: instead of plain ( :-P
[16:10] <Chipaca> kyrofa: actually i'm not sure what the schema validation uses for regexps; if {,30} trips it up, you can use a * and the max-length of 32 will catch it
[16:11]  * Chipaca breathes in, lets people deal with their problems, and gets back to his own
[16:15] <kyrofa> Chipaca, sounds good
[16:16] <kyrofa> Sorry, made the mistake of launching chrome. Had to reboot
[16:22] <Chipaca> written forum post ahead of PR, because why not: https://forum.snapcraft.io/t/snapd-enforcinig-snap-versions/3974
[16:22] <Chipaca> (currently not listed so people aren't confused :-) )
[16:23] <kyrofa> Chipaca, waiit.. how do you do unlisted posts?
[16:24] <kyrofa> jdstrand, what kind of timeline do you anticipate for that change? We should coordinate
[16:25] <Chipaca> kyrofa: magic
[16:25]  * kyrofa hears "special permissions you don't have"
[16:25] <Chipaca> kyrofa: (tap the gear, it should be there)
[16:26]  * Chipaca publishes a snap with a version of 'unpredictable-counterrevolutions'
[16:26] <kyrofa> I see hide details and poll
[16:26] <jdstrand> kyrofa: not terribly soon unless someone wants it *right now*
[16:26] <Chipaca> kyrofa: you pleb
[16:26] <kyrofa> jdstrand, no rush from me. I suppose snapcraft could make the change before you folks and it would be okay. It'd be bad the other way around
[16:27]  * kyrofa puts together a PR
[16:27] <mvo> Chipaca: the version of "base-18" is "very-unstable", but that should still validate right?
[16:27] <Chipaca> mvo: unpredictable-counterrevolutions validates :-)
[16:28] <mvo> Chipaca: heh
[16:29] <jdstrand> kyrofa: what is in the review-tools is pretty close to what we agreed to
[16:29] <kyrofa> Good deal
[16:29] <jdstrand> kyrofa: I guess just commit to snapcraft soon and these can just roll in later
[16:30] <kyrofa> jdstrand, sounds good
[16:30] <jdstrand> the only problematic one is '_' in that you'll start allowing '_' but the review tools won't
[16:30] <jdstrand> but, you'd have to know that all of a sudden you could use it
[16:31] <jdstrand> the other bits show the review tools more strict already, and people haven't been complaining
[16:31] <Chipaca> or we haven't heard them :-)
[16:32] <Chipaca> (i think it's the sort of thing that people will hit, complain, tweak the string, and move on
[16:32] <Chipaca> )
[16:32] <Chipaca> s/complain/grumble/ perhaps
[16:32] <jdstrand> point is, status quo if we aren't in perfect sync
[16:32] <jdstrand> when we are in perfect sync, no more grumbling
[16:36] <roadmr> hi jdstrand
[16:37] <roadmr> jdstrand: so nothing will change with the review tools r1000 unless I set that resquashfs env vraiable, right?
[16:38] <jdstrand> roadmr: not wrt resquash, no
[16:39] <roadmr> jdstrand: ok - right. I have r1000 on staging right now and it was happy with my usual, trivial test snap
[16:39]  * jdstrand nods
[16:39] <jdstrand> roadmr: you may have noticed all the snaps in tests/ in the bzr tree
[16:39] <roadmr> jdstrand: oh I did not! awesome!
[16:40] <jdstrand> roadmr: that was part of all the testsuite updates I did
[16:40] <Chipaca> jdstrand: kyrofa: you've probably realised by now that it's {0,30} not {,30} in the regexp
[16:40] <jdstrand> Chipaca: yes
[16:40] <Chipaca> the {,30} might be a perlism, or it might be a bug in my head :-)
[16:40] <roadmr> jdstrand: fantastic! I usually sanity-check locally against some bogus snap I have, to avoid pushing a bogus revno, but this should make all that moot!
[16:40] <roadmr> moot-woot!
[16:41] <jdstrand> roadmr: if you want to send me that snap, I can add it to the tools
[16:41] <jdstrand> or anything else you like to test
[16:41] <roadmr> jdstrand: I don't think it's needed, it's an empty snap with classic confinement and only meant to protect against that case we had once...
[16:41] <roadmr> jdstrand: where you had an undeclared dependency so the thing worked for you but failed when pushed to the store
[16:41] <jdstrand> I may already have that use case in there
[16:42] <roadmr> jdstrand: to be honest I think I'll switch my local testing from my crap snap to the list you have here, though again it's for sanity, if you ran that test suite at merge time that looks quite thorough
[16:42] <jdstrand> roadmr: note I said 'wrt resquash'. that is because there are new and updated checks, but that is all normal stuff
[16:43] <roadmr> jdstrand: so does resquash modify the snap-under-test? or just verifies that when resquashing, the result is identical to what was uploaded?
[16:44] <roadmr> jdstrand: (that's why I zeroed in on that feature - was worried it might somehow alter the uploaded snap)
[16:44] <roadmr> in which case many components would be unhappy
[16:44] <jdstrand> roadmr: there is a big matrix for testing that I use. 14.04 was tested. running 'make functest' will run the tools on tests/, but the output is different on 14.04 and 16.04 on some click stuff due to testsuite mocking
[16:44] <jdstrand> roadmr: that will go away when I drop click/snapv1
[16:45] <roadmr> that'll be awesome
[16:45] <jdstrand> roadmr: the resquash will *not* modify the original squash. it unsquashes then resquashes and makes sure they are the same
[16:45] <jdstrand> s/they are/it is the same as the orig/
[16:45] <roadmr> jdstrand: ah, nice!
[16:46] <jdstrand> yeah, we totally don't want to touch the original
[16:46] <jdstrand> roadmr: also note, that the resquashfs have always run
[16:46] <roadmr> ohh
[16:46] <jdstrand> roadmr: they are even running in r1000. I didn't change that
[16:47] <jdstrand> roadmr: the env vars say whether the check is enforced or not, and whether or not to use fakeroot
[16:47] <jdstrand> they haven't been enforced for a long time, and r1000 doesn't change that
[16:47] <jdstrand> once snapcraft 2.39 is is in -updates on all the releases, I'll turn enforcement back on
[16:48] <roadmr> jdstrand: I see. So if it's enforced it'll actually return an error if they don't match?
[16:48] <jdstrand> roadmr: yes
[16:48] <jdstrand> but the snap needs to be squash with -no-fragments, otherwise false positives
[16:48] <jdstrand> and snapcraft 2.39 does that
[16:48] <roadmr> jdstrand: ok. I was thinking how to set that variable but from this I get we shouldn't, until you ask for a tools update which enforces this, right?
[16:49] <jdstrand> roadmr: yes. you don't need to do anything. I was mentioning it in case you wanted to test it yourself or do something on staging, etc, but prod doesn't need to do anything
[16:50] <roadmr> jdstrand: ok. Sounds like we'll test that once you enable it (at which point it'll make it to staging anyway)
[16:50] <jdstrand> roadmr: when I turn on enforcement, it'll be by default and the tools will honor SNAP_RESQHASHFS_ENFORCE=0 to turn it off
[16:50] <roadmr> jdstrand: much fiddlier for me to add a feature flag to set the env var
[16:50] <jdstrand> yes
[16:50] <roadmr> jdstrand: right, we can totally add the feature flag if we see a lot of false positives and we want to be able to switch that off quickly
[16:50] <jdstrand> the env var was mostly for us in debugging the enforcement feature
[16:51] <jdstrand> I never wanted you to have to do anything
[16:53] <roadmr> thanks :)
[16:53] <roadmr> we're clear on that then. r1000 should land in prod sometime this week
[16:53] <jdstrand> \o/
[16:53] <jdstrand> thanks :)
[16:53] <roadmr> jdstrand: I'll be afk from tomorrow until Feb 21st
[16:54] <jdstrand> roadmr: ack. while I have you, you adjusted the debs to install already?
[16:54] <roadmr> jdstrand: yes, I did that first on staging to ensure none of the deps wrecked the world, then updated the tools, which are running fine too
[16:54] <jdstrand> perfect
[16:54] <jdstrand> thanks again! :)
[16:55] <jdstrand> most of those deps you probably had. a few are if you want to run parts of the testsuite there
[16:56] <roadmr> jdstrand: yes, we did tweak the set of deps a bit (removed python3-all since we already install python3) but there were only 5 new ones
[16:56]  * jdstrand nods
[17:10] <Chipaca> why, oh why, doesn't the go test runner tell me exactly what file it's running? There are eleventyone backend_test.go and at least five have a TestUpdatingSnapToOneWithFewerHooks :-/
[17:32] <mup> PR snapd#4652 opened: tests: fix spread test failures on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4652>
[17:39] <RobertGlick> Hello everyone I am having problems removing a snap
[17:40] <RobertGlick> I keep getting an error I have googled and seems like I must be the only one
[17:40] <RobertGlick> the error is error: cannot remove "chromium": snap "chromium" has changes in progress
[17:41] <RobertGlick> I did a reboot and did not open chromium and I am still getting this message
[17:41] <ogra_> snap changes ?
[17:41] <RobertGlick> no
[17:41] <ogra_> (i mean ... run that command to see the changes in progress)
[17:41] <RobertGlick> ah ok
[17:42] <kyrofa> RobertGlick, then run `snap change <changeid for chromium>` to see what it's doing
[17:42] <RobertGlick> ok got 4 errors installing chromium
[17:43] <RobertGlick> but then it succesfully installed
[17:44] <ogra_> can you just paste the output of the snap changes command to https://paste.ubuntu.com/ ?
[17:44] <ogra_> also "snap version" would be helpful
[17:46] <RobertGlick> hmm I pasted
[17:46] <ogra_> give us the url then :)
[17:46] <RobertGlick> but should there be a link
[17:47] <ogra_> yes, in the url bar in your browser window
[17:47] <RobertGlick> https://paste.ubuntu.com/=cybnndDSsC/
[17:47] <RobertGlick> how to see snap version
[17:48] <ogra_> just run "snap version"
[17:48] <RobertGlick> thanks
[17:48] <ogra_> that will print all relevant version info ybout your system
[17:48] <RobertGlick> 2.30
[17:48] <ogra_> the full output please :)
[17:48] <RobertGlick> snap    2.30
[17:48] <RobertGlick> snapd   2.30
[17:48] <RobertGlick> series  16
[17:48] <RobertGlick> solus   3
[17:48] <RobertGlick> kernel  4.14.18-51.current
[17:48] <ogra_> ah
[17:49] <ogra_> solus ...
[17:49] <RobertGlick> yup
[17:49] <ogra_> ikey, your customer ! ^^^^^
[17:49] <ogra_> :D
[17:49] <RobertGlick> Thanks
[17:49] <RobertGlick> will do
[18:05] <ikey> ogra_, what the who
[18:05] <ikey> oh hey a customer
[18:05] <ogra_> ikey, yeah, you have them !
[18:05] <ogra_> :)
[18:05] <ikey> we need to update our snapd before we look further into bugs me thinks
[18:06] <ikey> so that everyone is on the same baselevel
[18:07] <ogra_> well, 2.30 is the current stable one
[18:08] <ikey> o .31 is unstable?
[18:08] <ogra_> candidate
[18:09] <ikey> o
[18:12] <mup> PR snapd#4642 closed: many: add nfs-home flag to system-key <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4642>
[18:20] <RobertGlick> ogra_ and ikey fixed it  not sure how this worked but i did sudo snap revert chromium then sudo snap remove chromium and it removed
[18:20] <ogra_> great
[18:21] <ogra_> it was probably just still doing some delayed operation while you tried the remove the first time
[18:21] <RobertGlick> hmm strange i did a reboot and did not open the app
[18:21] <RobertGlick> and was still getting that error
[18:22] <RobertGlick> but happy reverting and removing worked
[18:28] <RobertGlick> ogra_ one last question how do I clear the cached version to download a fresh copy?
[18:28] <ogra_> there is no caching
[18:29] <ogra_> it should just download anew if you removed the snap before
[18:29] <RobertGlick> ok
[18:29] <RobertGlick> thanks
[18:32] <mup> PR snapcraft#1923 opened: mypy: update to 0.560 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1923>
[19:47] <mup> PR snapcraft#1914 closed: docker: add Dockerfiles for all risk levels <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1914>
[20:07] <jdstrand> tyhicks: so, that dbus service activation change is proving to be annoying: https://github.com/snapcore/snapd/pull/4652#discussion_r167665241
[20:07] <mup> PR #4652: tests: fix spread test failures on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4652>
[20:08] <jdstrand> tyhicks: I'm not sure why dbus isn't defaulting to 'unconfined' if AssumedAppArmorLabel is not set...
[20:09] <jdstrand> tyhicks: istr you saying you'd look at it, comment in a bug, something... (am I crazy?)
[20:10] <tyhicks> jdstrand: that sounds like something I said but I think I let it fall off my plate once it sounded like there was a usable workaround
[20:11] <jdstrand> tyhicks: I mean, really, it could even be configured via bus configuration
[20:11] <tyhicks> (I think that was mid-sprint, too, so maybe that had something to do with it)
[20:11] <jdstrand> <apparmor mode="(enabled|disabled|required)" assumedlabel="unconfined"/>
[20:15] <jdstrand> tyhicks: ok... how should we proceed now? what are your thoughts on what it should be doing?
[20:16] <tyhicks> jdstrand: I've taken a note to look into it soon
[20:17] <jdstrand> tyhicks: ok, thanks. holler if you want me to do anything. in the PR with mvo, I recommended adjusting systemd's timedate1 dbus service file
[20:17] <tyhicks> jdstrand: I don't have an answer right now but I think we discussed a new permission that may be implied by an existing permission
[20:17] <jdstrand> oh right
[20:18] <jdstrand> tyhicks: well, when you have time to look at it, feel free to ping me to discuss
[20:19] <tyhicks> jdstrand: will do - thanks!
[20:48] <roadmr> jdstrand: hey so the tools already support common-id for apps within a snap, right?
[20:49] <jdstrand> roadmr: as of r1000
[20:49] <roadmr> jdstrand: fantastic :) thanks! (just checking)
[20:51] <jdstrand> roadmr: 980.1.3 to be specific
[20:51] <roadmr> right :) cool!
[20:52] <jdstrand> roadmr: and 980.1.4 has your ctime fix
[20:53] <jdstrand> as it happens, I saw that issue today with r950. looking forward to r1000
[20:53] <roadmr> jdstrand: oh perfect :) yes, I haven't seen it super often but sometimes it happens
[20:53] <roadmr> jdstrand: haah it was fun with wxmaxima which had daily builds and when one got stuck it built a queue of like 100 revisions :/ pushing them through by hand was fun
[20:53]  * roadmr said fun twice, imagine how fun it actually was
[20:56] <jdstrand> hehe, yes :)
[22:45] <mup> PR snapcraft#1564 closed: setup: changes to make installable from PyPI <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1564>
[23:05] <mup> PR snapd#4653 opened: all: snap versions are now validated <Created by chipaca> <https://github.com/snapcore/snapd/pull/4653>
[23:12] <mup> Bug #1749028 opened: snapd and disks <Snappy:New> <https://launchpad.net/bugs/1749028>


[06:21] <sakhi> moonin
[06:42] <Symmetria> morning
[07:21] <inetpro> good morning
[07:31] <superfly> hi inetpro
[07:35] <nuvolari> o/
[10:17] <Symmetria> hrm
[10:18] <Symmetria> can you switch ioschedulers on the fly
[10:18] <Symmetria> or do I need a reboot
[14:19] <Symmetria> sup
[14:21] <superfly> hey Symmetria... getting closer to the end of that sync?
[14:21] <Symmetria> heh yeah, it should go live as soon as the sf dude wakes up and fixes the dns
[14:21] <Symmetria> we're still synching but they will come live with what we have synched
[14:21] <Symmetria> we're up to about 10TB so far
[14:22] <superfly> of the 14? that's good progress
[14:24] <Symmetria> root@mirror:/diskspace4# ps uwxa |grep rsync |grep heanet |grep source |awk '{print $13}' |sort |uniq
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/l
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/m
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/o
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/p
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/s
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/t
[14:24] <Symmetria> heanet.dl.sf.net::sourceforge/v
[14:25] <Symmetria> thats all thats left
[14:25] <Symmetria> and one of those only has like 200 files to go
[14:25] <Symmetria> heh superfly we've been CLOCKING traffic filling that thing up
[14:33] <queery> maaz coffee on
[14:33]  * Maaz starts grinding coffee
[14:37] <Maaz> Coffee's ready for queery!
[14:37] <Symmetria> heh
[14:37] <Symmetria> we saw a 25% increasew in youtube traffic today
[14:38] <Symmetria> because of the quake/tsunami
[14:38] <queery> maaz, thak you
[14:38] <Maaz> queery: Excuse me?
[14:38] <queery> maaz, thank you
[14:38] <Maaz> queery: Okay :-)
[14:49] <nuvolari> geez. mixed emotions though. wow on traffic, not so wow on the disaster.
[17:57] <Morganvd> evening all
[18:04] <nlsthzn> Hey Morganvd :)
[18:19] <superfly> evening Morganvd and nlsthzn
[18:19] <nlsthzn> Hey superfly :)
[18:22] <superfly> hmmm, looks like TENET's SourceForge mirror is still not in rotation
[18:23] <superfly> at least DNS is resolving properly
[18:26] <Symmetria> aha
[18:27] <Symmetria> they fixed the dns
[18:27] <Symmetria> and I've just seen the first hit off it
[18:27] <Symmetria> will probably go into full rotation in the next few minutes
[18:27] <Symmetria> could still take an hour or two though
[18:28] <Symmetria> the last of the syncs are still happening, still running at 800mbit/second synching, but I recon it has less than a terabyte to go
[18:29] <Symmetria> heh still synching mo, my, op, os, ou, ov, po, pr, so, sp, st, su, sy and tu
[18:29] <superfly> Symmetria: I tried to download something a few minutes ago
[18:29] <superfly> didn't work
[18:29] <superfly> or didn't seem to
[18:29] <Symmetria> yeah they still conducting tests etc
[18:30] <Symmetria> <IP_ADDRESS> - - [11/Mar/2011:20:22:13 +0200] "GET /project/openlp/openlp/1.9.4/OpenLP-1.9.4-setup.exe HTTP/1.1" 302 299 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110218 Firefox/4.0b12pre" tenet.dl.sourceforge.net
[18:30] <superfly> ah, that would be why... "still syncing .. op ..
[18:30] <Symmetria> was that you?
[18:30] <superfly> Symmetria: yeah, that was me :-)
[18:30] <Symmetria> :P try something else please
[18:30] <Symmetria> lol
[18:30] <superfly> hrm, ok
[18:32] <superfly> Symmetria: cool, it's working (I'm downloading Audacity)
[18:33] <Symmetria> I'm just giving the DNS fix for tenet.dl.sourceforge.net a little time to propagate (so it has the right CNAME), and I'll turn public access to the mirror on.
[18:33] <Symmetria> ^^^ just got that from them
[18:33] <superfly> cool beans
[18:33] <Symmetria> heh here come the hits already
[18:34] <superfly> nice :-D
[18:41] <Symmetria> ok, sp done
[18:42] <Symmetria> and po about to finish
[18:44]  * Symmetria goes to eat while he waits for this to finish
[18:48] <Symmetria> su also done
[18:49] <superfly> op will take the longest
[19:00] <Symmetria> are you seeing tenet in the list of mirrors yet?
[19:00] <Symmetria> as an option?
[19:02] <superfly> Symmetria: not the last time I looked, which was about 10 minutes ago
[19:02] <Symmetria> k, they still testing
[19:03] <Symmetria> seeing test traffic still
[19:07] <Symmetria> BANG
[19:07] <Symmetria> its live
[19:07] <Symmetria> http://sourceforge.net/projects/fuel/files/fuel/fuel-0.1/fuel.msi/download
[19:07] <Symmetria> that should say TENET on it
[19:08] <Symmetria> might nto be fully there yet, but the one I just tested definately went there
[19:09] <superfly> Symmetria: indeed it does!
[19:09] <superfly> woohoo! :-D
[19:09] <Symmetria> try some other random download
[19:09] <Symmetria> and see if it goes to the right place
[19:10] <Symmetria> don't think they've redirected everything yet, it might just be random test things
[19:10] <superfly> Symmetria: is "op" finished yet?
[19:11] <Symmetria> root@mirror:~# ps uwxa |grep rsync |grep heanet |grep source |awk '{print $13}' |sort |uniq
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/m/project/mo
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/m/project/my
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/o/project/op
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/o/project/os
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/o/project/ou
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/o/project/ov
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/p/project/po
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/p/project/pr
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/s/project/so
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/s/project/st
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/s/project/sy
[19:11] <Symmetria> heanet.dl.sf.net::sourceforge/t/project/tu
[19:11] <Symmetria> negative
[19:11] <Symmetria>   30 second output rate 840753000 bits/sec, 72442 packets/sec <[19:12] <Symmetria> yeah we're not in the official list of mirrors yet on their page
[19:12] <Symmetria> so don't think they've gone fully public yet
[19:18] <superfly> Symmetria: I think they've switched on their geolocation though
[19:22] <|3o|3> I've forgotten, which is better on linux, Nvidia or ATI?
[19:28] <linuxboy> i fine nvidia to be better
[19:28] <linuxboy> *find
[19:28] <linuxboy> but I haven't really tried ATi much
[19:28] <linuxboy> so i could be wrong
[19:32] <Symmetria> superfly they've definately turned something on
[19:32] <Symmetria> I've just seen my first hit from mweb
[19:32] <linuxboy> was that me?
[19:33] <Symmetria> did you try and download fuel?
[19:33] <linuxboy> possibly
[19:33] <linuxboy> I clicked that link up there ^^^
[19:33] <Symmetria> if so then probably :P
[19:33] <linuxboy> TENET wasn't in the selection list though
[19:34] <Symmetria> yeah think they are still working on stuff
[19:34] <linuxboy> ah, it tries to autodownload from tenet
[19:34] <linuxboy> but in teh list I get "(Cape Town, South Africa, ZA) " with no link to click
[19:35] <Symmetria> hrm, it should be johannesburg not capetown :P
[19:35] <Symmetria> but I recon they still doing work on their side
[19:35] <linuxboy> it should also have a link to click
[19:36] <Symmetria> we still havent finished synching everything and they still running data checks I think
[19:36] <Symmetria> but I couple more just finished
[19:36] <Symmetria> st seems to be the one thats gonna finish last
[19:36] <Symmetria> its still on sta
[19:36] <Symmetria> mo is on mor
[19:37] <Symmetria> and os is about to finish
[19:39] <Symmetria> you is also on tur so that will finish soon as well
[19:39] <Symmetria> tu I mean
[19:39] <Symmetria> its amazing how many apps start with the word star :P
[19:41] <Morganvd> i preffer nvidia too
[20:01] <Symmetria> god damn
[20:01] <Symmetria> the developers of the world are a really uninspired bunch
[20:02] <Symmetria> :P why the hell does every developer have to call his project open* osx* star*
[20:02] <Symmetria> :P
[20:02] <Symmetria> like, lets get some originality people :P
[20:02] <Morganvd> lol
[20:02] <Morganvd> i have been looking at jave and the naming is just not working for me
[20:03] <Symmetria> hehe Im watching the rsync mirror scroll
[20:03] <Symmetria> and realizing it would be a real interesting social experiment
[20:03] <Symmetria> to analyze opensource project names
[20:03] <Symmetria> because people all seem kinda obsessed with the same names :P
[20:05] <Morganvd> and the same project
[20:05] <Morganvd> but diffrent
[20:05] <Morganvd> its the same thing why not help better the first one
[20:05] <Symmetria> heh all I want right now is this damn sync to finish :)
[20:07] <Symmetria> hrm, what other words can you think of that could start with mot
[20:07] <Symmetria> :p its on motogt
[20:07] <Symmetria> oh, motor* doh :)
[20:09] <Symmetria> lol, this is something for very bored people to do :P star at the rsync list coming through and try and guess the next name thats gonna show up
[22:35] <nuvolari> fp
[22:35] <nuvolari> sheesh, the tsunami is really bad :/


[00:00] <JanC> eh, why hide it from the owner?
[00:00] <oerheks> so, no, if he owns the account, he can become root and also have access.. any encryption without his knowledge smells bad to me.
[00:01] <geosmile> Because its my source code on the machine
[00:01] <Ussat> So, that sounds..um...fishy
[00:01] <geosmile> that is contractually not allowed for him to clone/copy
[00:01] <Ussat> very fishy
[00:01] <geosmile> but I have no way of restricting that technically
[00:01] <JanC> if you don't trust them, don't put your source code on their machine?
[00:01] <oerheks> then don't store it there.
[00:01] <geosmile> JanC, I've to run software that solves a problem for the client
[00:01] <geosmile> oerheks, I have to - to run it
[00:02] <geosmile> I was thinking of encrypting the file system using encryptfs
[00:02] <Ussat> You need ther source...to run it
[00:02] <geosmile> but that does not solve the problem
[00:02] <Ussat> the
[00:02] <geosmile> Ussat, yes, I do need source to run it
[00:03] <Ussat> So, you are going to make part of your clients system, unuseable.....OK I will put it bluntly.....I would find somewhere else REAL fast, because thats a shitty thing to do
[00:03] <geosmile> I could keep keys outside the machine, and encrypt the machine - so that everytime I booted the machine, it would ask for keys from outside the system.
[00:03] <Ussat>  ut, thats just me
[00:03] <teward> encryption without the knowledge or permission of the persons you're working with is a very very grey area legally
[00:03] <geosmile> Ussat, unusable ? I just dont want the client to have the ability to copy my source?
[00:03] <teward> that could get you in trouble
[00:04] <teward> geosmile: then use a compiled language that you only provide binary files for
[00:04] <Ussat> and if you need the source, to run something, then thats an a bigger problem
[00:04] <geosmile> teward, It is a machine on which I am root, and I own the machine. What are you talking about?
[00:04] <teward> > So, you are going to make part of your clients system, unuseable.....OK I will put it bluntly.....I would find somewhere else REAL fast, because thats a shitty thing to do
[00:04] <geosmile> teward, I cant do that - its not cost effective
[00:04] <teward> geosmile: then you're in the catch-22 of software
[00:04] <teward> either you provide your source so your stuff works
[00:04] <teward> or you don't put it on the **client**'s machine
[00:04] <geosmile> teward, if you dont have a solution - why speak?
[00:04] <Ussat> I propose you have bigger issues
[00:04] <teward> what Ussat said
[00:05] <teward> i'm proposing the same
[00:05] <teward> you have larger issues to tackle
[00:05] <geosmile> I agree
[00:05] <teward> (this also sounds a lot like an XY problem)
[00:05] <sarnold> why is a more traditional SaaS approach not possible?
[00:05] <geosmile> Its not a trivial issue
[00:05] <JanC> who does contractually own the code?
[00:05] <teward> ^^ that
[00:05] <geosmile> JanC, I do
[00:05] <JanC> so then make sure that's stated very clearly in your contract, and if they steal it, sue them
[00:05] <geosmile> sarnold, because there is client's data on the machine.
[00:06] <geosmile> JanC, I won't last while I sue them - I've thought about that
[00:06] <geosmile> So - apart from encryptfs - is there something else I can do - that secures the data on the machine?
[00:06] <Ussat> I propose if you dont trust yuour clients, you choose better clients then
[00:06] <Ussat> vet your clients better
[00:07] <oerheks> build a vm with the code, and store it and its output in an archive?
[00:07] <geosmile> Ussat, really? you want to trust your clients with your source code ? Vetting helps?
[00:07] <teward> geosmile: your business premise is the problem here.  The only way to secure the data **on your clients machine** is to provide non-source-code versions.  If you can't do that, then you need to provide SaaS that **does not** have the requisite of being on your clients' controlled machine to begin with.  If you can't do **that** then you need to rethink your approach to this entire project
[00:07] <oerheks> your usercase might be compromised either way
[00:07] <Ussat> THAT ^^^^
[00:07] <teward> because **contractually binding** it so that if they copy or keep your code as a lawsuit is the only way to punish the company
[00:07] <JanC> even non-source could be stolen...
[00:07] <teward> your use case is compromised simply by what your goal is
[00:08] <Ussat> I am REALLY cureious, what kind of business is this /
[00:08] <teward> and your user base will not employ you if you require special encryption and such that is under client's controlled machines
[00:08] <teward> and not your own (even managed service providers provide their own machines for them to manage if it ABSOLUTELY requires clients to put it into their environment and not allow the Client to have access to that infrastructure)
[00:09] <JanC> also, they seem to trust _you_ with their secret data, why can't you trust them?
[00:09] <teward> ^^ that - the double edged sword.
[00:09] <geosmile> JanC, They have checks if i steal their data, since I am on their network
[00:09] <geosmile> JanC, I dont have a way to secure my code
[00:10] <teward> if you don't have a way to secure your code, you shouldn't be putting it on client machines because **You yourself do not trust the client**
[00:11] <Ussat> There is something thats...fishy here
[00:11] <teward> heck, even as a consultant myself **all code I put onto a client's machine** is done under contracts and all Open Source anyways, if you are using something that is Closed Source you shouldn't risk it being put on the client machines.
[00:11] <teward> agreed with Ussat
[00:12] <JanC> it's not like binaries are really more safe than code...
[00:12] <geosmile> Ussat, if you dont understand something - of course it's fishy. Instead perhaps think about a solution - instead of a fish?
[00:13] <geosmile> JanC, It's more painful to decompile for sure
[00:13] <JanC> if it's really all that valuable...
[00:13] <teward> i don't see what your original 'problem' is here, you are just asking about your **solution** not the core problem you're trying to protect against
[00:14] <teward> if your problem is "I have no controls to prevent others copying my code" then you shouldn't share your code
[00:14] <teward> https://xyproblem.info/ <-- this is what your issue sounds like
[00:14] <teward> the XY Problem
[00:14] <JanC> the real solution is a good contract combined with trust
[00:14] <teward> ^^ that
[00:14] <geosmile> teward, the problem is very simple - if you want to understand it.
[00:14] <Ussat> So, youre saying youre slource must REMAIN there to solve a problem
[00:15] <geosmile> I want to work on an AWS EC2 instance - without giving access to Amazon - Prove its impossible - or disprove with a solution.
[00:15] <teward> and you don't want to enforce your contracts with legal methods
[00:15] <Ussat> I propose your "solution" is not a good solution
[00:15] <Ussat>  without giving access to Amazon
[00:15] <Ussat> Ya...ok sure
[00:15] <teward> geosmile: whenever ${SYSTEM} is not in your own physical possession you can't control anything
[00:15] <Ussat> thats not happening
[00:15] <geosmile> teward, but you can, when it is in your posession
[00:15] <geosmile> teward, that doesnt prove a thing!
[00:15] <teward> anyone with physical or console access to the machine directly (Amazon) can access your system
[00:16] <teward> geosmile: Rule #1 of System Security is: If anyone else has access to the machine, it's a risk
[00:16] <geosmile> teward, sure - but when they do - they might get random bits
[00:16] <teward> so if anyone OTHER than you has access to the system, you either (1) accept the risk that ANYONE with admin on the machine you're deploying to can access your code (and your CONTRACT will enforce rules about copying, etc.)
[00:16] <Ussat> dude there FREEKING AMAZON....
[00:16] <teward> or (2) don't deploy your software
[00:16] <teward> you don't have other options
[00:17] <teward> you have no solution to *block* access to your *source* which **you say you must have there**
[00:17] <teward> and rule 0 applies
[00:17] <Ussat> You are trying to solve a personel issue technically, not gonna happen
[00:17] <teward> the only other solution is, in your contract, forbid the copying or use of your code and audit all access attempts.  and then when that's breached, sue the client
[00:18] <teward> but as you said that'd not be "doable" for your AMBIGUOUS business case
[00:18] <teward> in which case you have no way to protect against the issue you're trying to prevent - no legal repercussions, no reason for anyone to obey the contract.
[00:18] <teward> this is a personnel / business operations problem, and not one you'll solve technically.
[00:19] <geosmile> Thanks. Will try to solve it contractually.
[00:19] <teward> to put this into another perspective let's take an active Consulting contract I have with the Lubuntu Team for adminning their infra for them.
[00:20] <teward> that contract specifically states: "All materials present on the Lubuntu Team's infrastructure is the property of the Lubuntu Team.  Unauthorized copying of the data to any environment is a violation of this contract and subject to legal ramifications."
[00:20] <teward> so even though I have full root access to their systems to admin their stuff, and run *hosted* infra for them as well, everything on those servers is *their property* and they have contractually written in that I am not going to steal their stuff
[00:21] <JanC> teward: well, except for all the open source software they don't own, I'm sure?  :)
[00:21] <teward> JanC: well, that's in the Exceptions in that section of the contract.
[00:22] <JanC> I assume it's about content & maybe configurations (although it might be hard to claim copyright on those)
[00:22] <teward> "Exceptions to the ownership of property are existent for any open source software provided under other licenses and not direct property of the Lubuntu Project and Team, including but not limited to: Phabricator, Discourse, Jenkins, Matterbridge"
[00:22] <teward> JanC: basically, yes.
[00:22] <teward> but the point was any code they wrote and uploaded for example is going to be their property
[00:22] <teward> vs. the software they already deploy
[00:23] <teward> i'm not at liberty to share the entire contract ;)
[00:23] <JanC> and I suppose all scripts you write for admin purpose are owned by them
[00:23] <teward> unless the scripts are deployed open source.
[00:23] <teward> and just reused by me :P
[00:23] <teward> but basically, yes.  Except where the scripts are already present in the Ubuntu repos, etc.
[00:24] <teward> there's a LOT of exceptions written in as well, but that's the benefit of 2+ years of the contract existing ;)
[00:25] <JanC> best to be as clear as possible in the contract, and then trust the other side means well  :)
[00:25] <teward> yep :)
[00:25] <teward> it's not like Lubuntu's infra is running anything proprietary either
[00:26] <teward> all the core stuff they use is Ubuntu driven and Open Source
[00:26] <teward> except for the VMware Tools that's installed on the hosted infra in my cluster under the contract :P
[00:26] <teward> but that's not mine either ;)
[00:26] <teward> the contract's pretty airtight protecting IP on both sides
[00:27] <teward> and again, it's under contract - breach means legal repercussions
[00:27] <teward> for either side depending where the breach happens. :P
[00:27] <teward> but again, that's a business operations thing, not a technical enforcement
[00:28] <teward> audit: yes.  control via contract: yes.  control via technical means: restricted ACL to access the machines, no other technical enforcements.
[00:28] <teward> (again, per contract) ANYWAYS i digress.
[00:28] <teward> *goes back to stabbing SQL code*
[00:29] <geosmile> Thanks teward - I just need to replace that Lubuntu by "me".
[00:29] <teward> no, you need a much more verbose contract
[00:29] <geosmile> if its my property - and copying/snapshotting/...
[00:30] <teward> AND given this quote from you: "I won't last while I sue them - I've thought about that"
[00:30] <teward> you **need to enforce the contract with legal repercussions**
[00:30] <teward> the wording in my contract won't help you
[00:31] <teward> it's a consulting contract, not a SaaS or "I'm Providing Softare" contract
[00:31] <teward> YOUR contract will have its own needs
[00:32] <geosmile> teward,  you are right - time to talk to a lawyer for that problem
[00:32] <teward> yup
[00:32] <teward> (and I keep a lawyer on retainer for this purpose LOL - all contracts NOT issued by my LLC need heavily reviewed first before I do any signatures)
[00:36] <teward> that, and the Lubuntu one has some bias, I've worked with the Lubuntu team for a few years on a few things so there's a larger web of trust there :p
[00:36] <teward> ANYWAYS
[00:36] <teward> i need to go stab the postfix channel i need some... custom things and opinions...
[00:36] <geosmile> thank you!
[00:39] <teward> JanC: there's only like three cases where I have an SaaS or "Software provided under contract" situation, and all of those cases are 'protected' by deployment of a managed device which I own and lease to the customer under the contract, or a dedicated VM template/image/deployment that I've already built and Customer doesn't have any access to directly other than through the deployment wizard which preconfigures the deployed system
[00:39] <pizzaiolo> nothing to contribute here, just would like to say this has been an enjoyable backlog to read. :)
[00:39] <teward> which in turn block the 'client' from direct access to the system, but again they physically have access so it *could* be someone bruteforcing but yeah.
[00:39] <teward> pizzaiolo: heh it's fun to read the chaos yes?
[00:40] <pizzaiolo> lol yes, but more interesting to hear about your contract and contracts in general. i've personally been burned by ambiguity and lack of a contract early in my career so i learned that lesson
[00:42] <teward> heheh well I'm not a lawyer
[00:42] <teward> but when you have to run a business you learn stuff ;)
[00:42] <teward> it's the lawyers that do most of that work for me :P
[00:43] <JanC> it's probably not that hard to do a good contract yourself either
[00:53] <geosmile> JanC, if you give them a dedicated VM template - once they have the template - its still the same problem, no?
[00:57] <JanC> I think you want to ask teward that
[00:57] <JanC> but I guess there are ways to do that when there is a trusted 3rd party
[00:59] <teward> geosmile: the VM is limitedAccess to the template, but again we audit the crap out of the access so anyone accessing it without it being me triggers a huge warning email and CC'd the lawyers the corresponding contract data (self-written audit code!) but that's a different set of circumstances because I don't hesitate to sue clients who break the contract.  And such contracts are amended contractually for "Managed VM Appliances"
[01:00] <teward> but again, everything is contract driven for controls
[01:00] <teward> and USUALLY have major repercussions for clients heh
[01:23] <cliluw> Is there a difference between `chmod 0400` and `chmod 400`?
[01:24] <sarnold> at bash, no; in programming languages, maybe
[02:09] <qman__> 0400 would override suid/guid bits
[02:11] <sarnold> $ touch test ; chmod 7777 test ; ls -l test
[02:11] <sarnold> -rwsrwsrwt 1 sarnold sarnold 0 Jan 16 02:10 test
[02:11] <sarnold> $ chmod 400 test ; ls -l test
[02:11] <sarnold> -r-------- 1 sarnold sarnold 0 Jan 16 02:10 test
[08:14] <Seveas> sarnold: in other languages a definite yes :) (400 == 0620)


[00:18] <ppp> hggdn Ive make a mistake. The last install.tar I had was when I had two disks and it worked, I accidently attached it to the bug
[00:19] <ppp> I no longer have the install logs for my old four hdd system
[00:23] <ppp> Ive added a comment to the bug explaining. Hopefully someone who does have the hardware to test this will be able to produce logs. Another user commented to being effected by it as well, it certaintly does occur
[00:31] <ppp> hggdh - Im going to appeal for testing assistance on the Intrepid section of the Ubuntu forums
[00:41] <hggdh> ppp, OK
[01:05] <kgoetz> can pbuilder be used to build source packages (as though i ran 'debuild -S'). I just managed to get pbuilder installed and running, and i'd rather not create a hardy chroot now as well
[01:06] <greg-g> kgoetz: I haven't messed with pbuilder much, but the people in #ubuntu-motu probably have :)
[01:09] <kgoetz> greg-g: i'll go and ask them my question there, thanks :)
[01:12] <greg-g> kgoetz: good luck!
[01:13] <kgoetz> greg-g: hehe. thanks
[01:26] <hggdh> kgoetz, you use pbuilder to verify your package
[01:26] <hggdh> you would use debuild to create the source package
[01:26] <hggdh> and pbuilder will create a special chroot
[01:28] <kgoetz> hggdh: guess i'll havve to build a hardy chroot then. cheers.
[01:29] <kgoetz> hm. pdebuild. *investigates*
[01:33] <hggdh> well, I guess you could also use a ppa to test the package
[01:44] <charlie-tca> Could I have someone set the status of Bug #212028 to wishlist please?
[01:59] <hggdh> charlie-tca, I wonder if the NTFS drivers are packaged in the livecd
[02:01] <hggdh> I dimly remember something about them not being provided on standard installs (and perhaps on the livecd as well?), but this was some releases ago...
[02:02] <hggdh> I would like to hold on setting as wishlist until we can find about that, if you do not mind
[02:02] <Hobbsee> it has from hardy onwards
[02:02] <Hobbsee> actually, ntfs has been mounted, read only, for ages.
[02:02] <Hobbsee> since, breezy or something
[02:02] <hggdh> hey cheers Hobbsee long time
[02:02] <Hobbsee> heya :)
[02:03] <hggdh> Hobbsee, what do you think -- if the bug above a wish or a real one then?
[02:04] <hggdh> s/if/is/
[02:04] <Hobbsee> kgoetz: you can build the source package on any release, more or less.  it's where you build the binaries that's the big difference
[02:04]  * Hobbsee looks
[02:05] <Hobbsee> whoever wrote that last comment is wrong - it's a bug.
[02:05] <Hobbsee> at least, i'm fairly sure it is.
[02:06] <Hobbsee> mounting partitions should be desktop-agnostic, although what it does with them aftewards might not be.
[02:06] <Hobbsee> hggdh: probably try asking in #xubuntu about if, if other people have it.
[02:07] <Hobbsee> maybe ask for the output of 'mount' to see if they've been mounted somewhere, and the user just hasn't found them / has been looking in the wrong place / etc
[02:07] <Hobbsee> although, come to think of it...
[02:07] <Hobbsee> is that ntfs, or vista-filesystem partitions?
[02:08] <Hobbsee> i thought they had new filesystem types for vista, and 7.10 would be too old to support them
[02:10] <hggdh> hum, might be... I forgot about vista
[02:10] <hggdh> charlie-tca, ping?
[02:11] <charlie-tca> hggdh: I'm here
[02:11] <hggdh> see above, for Hobbsee's input
[02:12] <Hobbsee> and i'd highly doubt it's something that would need a spec.
[02:12] <Hobbsee> particularly when it got later advertised in the ubuntu release notes, and many of the reviews.
[02:12] <charlie-tca> since the bug was against Xubuntu, and in Ubuntu the drives are auto mounted, it seems like a wish list item
[02:12] <charlie-tca> for Xubuntu.
[02:14] <charlie-tca> I thought the bug was against all drives, regardless of filesystem
[02:15] <Hobbsee> depends - it's likely intentional that it gets mounted everywhere
[02:15] <Hobbsee> rather than the feature not being implemented in xubuntu
[02:16] <charlie-tca> I can check in #xubuntu and the Xubuntu mailing list, if need be. Thanks for the advice.
[02:22] <charlie-tca> Hobbsee, the answer I got in #xubuntu is that they won't automount using Xubuntu Live CD, nor should they
[02:23] <Hobbsee> was teh answer from a reputable source?
[02:24] <charlie-tca> I think so, let me check for sure, though
[02:25] <Hew> Hey guys, haven't got a reply from #ubuntu-devel so I'll ask here. Is there a page somewhere that defines the usage of depends/recommends/suggests for a package? I have an idea of what they are for, but figured there should be a guideline/policy for it somewhere to define the grey areas.
[02:26] <pwnguin> heh
[02:26] <pwnguin> there is a small one
[02:26] <pwnguin> lemme find the link
[02:26] <pwnguin> apt-get install debian-policy
[02:26] <Hobbsee> Hew: yes, it's in debian policy
[02:28] <Hew> wow, there's actually a package for this stuff. Thanks, I'll take a look.
[02:29] <charlie-tca> Hobbsee: I'm going to put this through the mailing-list, then I can decide.
[02:29] <charlie-tca> Thanks for helping
[02:29] <Hobbsee> y/w
[02:31] <pwnguin> Hew: yea, debian takes that stuff srsly
[02:33] <Hew> pwnguin: yea, it's good to have it written down somewhere. Trying to work out depends/recommends atm in bug #231811
[02:34] <hggdh> sorry, had my son on the phone (just moved to Belgium, first night there, and he is WIDE awake...)
[02:36] <pwnguin> Hew: i think there's some discussion about pulling recommends by default
[02:37] <Hew> pwnguin: yes, recommends gets pulled by default in synaptic / apt-get / others afaik
[02:46] <kgoetz> Hobbsee: it does require i install the build-deps for the package for teh debuild to succeed though (i thought)
[02:52] <Hobbsee> kgoetz: indeed.
[03:38] <WilDec> Hi. New to Ubuntu.  Trying to install 8.04.1 on RAID partitions.  Failing. due to mangled superblocks.  Found two directly-relevant bugs (https://bugs.launchpad.net/~justin-traer).
[03:38] <WilDec> They're long-lived (~3 years), still present in Hardy, and not-resolved (one's 'Triaged').   I'm completely unfamiliar with Bug Process 'here' ...
[03:38] <WilDec> What's the right next step for getting them looked at?
[11:28] <qense> hello
[11:29] <thekorn> hello qense!
[11:58] <aleboco> hi guys, some time ago i reported this bug #237815... i turned to be completely wrong! how can i adjust it or close it?
[12:07] <bdmurray> aleboco: you can set the status to Invalid yourself
[12:09] <aleboco> bdmurray,ah, i didn't know
[12:09] <aleboco> bdmurray, but can i actually modify it so that it is right? or is it better to open another one?
[12:10] <aleboco> bdmurray, it is because i think i now know what it was about
[12:14] <askand> bug  128585 can be closed
[13:41] <kleop2> hi
[13:41] <kleop2> I installed ubunu 7.10
[13:42] <kleop2> and it fails to detect the modes allowed by my LCD
[13:42] <kleop2> defult info in xorg.conf is wrong
[13:47] <charlie-tca> kleop2: This is actually the area where we work to triage and correct bug-reports. For support you might try #ubuntu
[13:47] <kleop2> well this is the bug, I would expect it to just work
[13:50] <Fallen[oqp]> here is a bug sorting channel, for support go to #ubuntu
[13:50] <Fallen[oqp]> or submit a bug report if your bug isn't a duplicate
[13:53] <takdir> kleop2: report bug at https://bugs.launchpad.net/ubuntu/+filebug
[13:54] <kleop2> ok
[14:38] <bahadunn> hi
[14:39] <bahadunn> there is a bug for kqemu-source
[14:39] <bahadunn> Bug 249493
[14:39] <bahadunn> if installed with aptitude libc6-dev is installed so there is no problem
[14:39] <bahadunn> but with apt-get libc6-dev is not installed so the module cannot build
[14:40] <bahadunn> I have tested this on i386 and amd64 so I was wondering if it is okay to assign the status of this bug as confirmed
[14:40] <bahadunn> I also made a patch for the package with build depends for libc6-dev
[14:41] <bahadunn> I want to make sure I am following correct procedure is why I am asking
[14:50] <norsetto> bahadunn: libc6-dev is a recommended package, it won't be installed by default in hardy
[15:01] <bahadunn> norsetto: right but if one apt-get install kqemu-source libc6-dev which is required to build kqemu would not be installed
[15:01] <bahadunn> norsetto: shouldn't kqemu-source depend on libc6-dev instead of recommending it?
[15:02] <norsetto> bahadunn: its ok in intrepid and its not worth fixing in hardy, just confirm the bug so that people are aware they have to install it manually
[15:02] <bahadunn> okay
[15:03] <bahadunn> so I can comment that this issue is fixed in intrepid?
[15:03] <norsetto> bahadunn: yes, by default we install recommends
[15:04] <bahadunn> okay
[15:21] <thekorn> bdmurray, hi, when you have some time, it would be nice if you could review and test lp:~thekorn/python-launchpad-bugs/new.httpconnection
[15:22] <thekorn> it fixes the one-shot session bug, and merges the config files
[15:22] <thekorn> (the one for the testcases and the username file for the http-header)
[15:22] <bdmurray> thekorn: I'm still in London so it probably won't be until early next week
[15:23] <thekorn> there are also some improvements to the testsuite
[15:23] <thekorn> bdmurray, no problem, take your time, it's not urgent
[15:23] <bdmurray> thekorn: actually, it might be a great thing to test now as I could get someone to check the logs easily
[20:25] <mouz> hi. i linked a bug with a fixed debian bug. it is the first time i linked a bug. as it is fixed i'd like to set the status to 'fixed released', but i'm not allow to do so. also i wonder what should be done with the status of the ubuntu task. can someone help me with these? thanks :) it is bug 249076
[20:29] <charlie-tca> mouz, I think you have to change the status of the line you added, right? I can't even figure out how to do that link yet.
[20:34] <joumetal> mouz: I think it will update status automatically if you wait for while.
[20:35] <hggdh> mouz, launchpad will update the linked upstream bugs by itself
[20:35] <mouz> hggdh: thanks. should i leave the ubuntu task to status 'confirmed'?
[20:37] <hggdh> now varies...
[20:37] <hggdh> let me look atthe bug
[20:39] <hggdh> I do not think so. It can be set to triaged, but -- until the new version is packaged, it should not go to fix commited/fix released.
[20:39] <mouz> hggdh: ok so i should file a merge request?
[20:40] <mouz> (i checked that it must not be a sync)
[20:41] <hggdh> usually the maintainers are pretty up to speed; if the fix is a critical one (which seems not to be the case), then a merge would be warranted
[20:41] <hggdh> so we leave it as it is until a mantainer gets to it.
[20:41] <hggdh> (I updated to triaged)
[20:41] <mouz> ok thanks a lot for your help :)
[20:42] <hggdh> you are welcome. Thank YOU for helping ;-)
[20:53] <Fallenou> hi , can someone tell me what's incomplete in this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/136836 ?
[20:53] <Fallenou> maybe i can add some details
[20:55] <charlie-tca> Needs a dmesg log for the non-working case, any other reports/logs with information about it.
[20:55] <charlie-tca> Just add them as attachments when you make comment
[20:55] <Fallenou> ok
[21:29] <stpere> somebody found what was wrong with my update notifier? :)
[21:30] <hggdh> stpere, what bug?
[21:30] <stpere> it's not filled actually
[21:30] <stpere> I think I should fill it tho
[21:30] <hggdh> well, then it gets much more difficult to deal with it ;-)
[21:30] <stpere> well, my update notifier tray icon in hardy tells me I have 1 update ready
[21:30] <hggdh> yes, please fill it
[21:30] <stpere> ok
[21:31] <stpere> but I don't know how to duplicate it
[21:31] <stpere> is that really important?
[21:31] <hggdh> is it still going on?
[21:31] <stpere> err.. well, it happens 100% of the time now here :)
[21:31] <stpere> so, I guess I "duplicate it"
[21:32] <hggdh> it is an issue you are having
[21:32] <hggdh> so it warrants a bug
[21:32] <hggdh> and I *think* I remember something about it some days (?) ago, from the log -- your u-n says you have 1 update, bu there are many
[21:33] <stpere> yes, exactly
[21:34] <stpere> I'm filling it now
[21:34] <hggdh> OK, thanks
[21:37] <thekorn> stpere, when I remember correctly mvo asked you to run some testscripts, right?
[21:38] <thekorn> if you still have them somewhere, or a link to them, it would be nice to add this scripts to your bugreport
[21:38] <thekorn> and of course the results
[21:38] <stpere> yes
[21:44] <thekorn> super, thanks
[21:58] <stpere> here it is : bug 249957
[21:58] <stpere> thx ubottu.. good bot :)
[21:59] <Awsoonn> I am wanting to clean up the wiki a bit; https://wiki.ubuntu.com/UbuntuBugDay
[21:59] <Awsoonn> are the MOTU tasts really needed here?
[22:00] <Awsoonn> they don't have anything to do with a HugDay from my perspective, and should be put anywhere else
[22:03] <Awsoonn> such as here: https://wiki.ubuntu.com/MOTU/GettingStarted
[22:03] <Awsoonn> what say you?
[22:09] <thekorn> Awsoonn, I don't have a strict opinion on this, I think this MOTU related bits are there traditionally,
[22:10] <thekorn> IMHO, removing them or moving them to another place should be done after talking to leading members of the MOTU and Bug teams,
[22:10] <bdmurray> those are wiki includes that dholbach asked for please don't remove them
[22:11] <Awsoonn> that's just what I needed to know, thanks!
[22:12] <bdmurray> he is on vacation at the moment but we can check with him when he gets back
[22:12] <Awsoonn> I'll write him a note about it, see what he thinks
[22:30] <nickellery> what are people's thoughts on a Ubiquity bug day?
[22:38] <mrooney> nickellery: that could be good, though I seem to remember one in the past already
[22:44] <nickellery> mrooney, Ah, I see there was one last December
[22:50] <mrooney> nickellery: though that was over a release ago so, it may not be overkill?
[22:51] <joumetal> nickellery: please don't confirm needs packaging bugs for things already packaged.
[22:51] <nickellery> joumetal, apologies if this was done
[22:53] <joumetal> like bug 249664. reporter has made about 40 needs packaging bugs in last days.
[22:54] <nickellery> mrooney, do you think it would be a good idea to have one now, then?
[22:54] <nickellery> or would it be too much
[22:54] <joumetal> some of them are already packaged.
[22:57] <mrooney> nickellery: I don't know, I haven't really looked at how many open/important bugs there are in it
[23:22] <calc> is mail broken for anyone else?
[23:22] <calc> er wrt lp bugs?
[23:29] <mrooney> calc: it seems like it might be
[23:29] <mrooney> I didn't receive email for some bug changes in one of my projects
[23:39] <nickellery> mrooney, calc, I can confirm that as well