 :P
[07:09] <immu> jink meaning
[07:09] <immu> i don't think you have any idea of how good Unity7 is
[07:11] <immu> i am going to run unity7 on17.10 and report bugs for eventual support in 18.04
[07:12] <lordievader> Good morning
[07:13] <EriC^^> hey immu
[07:13] <immu> hey how do u doing
[07:13] <immu> u prayed your friday prayers
[07:13] <EriC^^> i'm christian (technically) and agnostic in reality
[07:15] <lotuspsychje> not unity on artful here
[07:15] <EriC^^> i recently learned how to make tortillas
[07:15] <EriC^^> it's so easy
[07:15] <lotuspsychje> how are you lordievader
[07:15] <EriC^^> i think i dreamt at night about making some
[07:15] <lotuspsychje> lol
[07:16] <lordievader> lotuspsychje (IRC): Doing good here, how are you?
[07:16] <lotuspsychje> mycroft make tortilla
[07:16] <EriC^^> haha
[07:16] <lotuspsychje> great here
[07:16] <EriC^^> when will it happen!
[07:16] <lotuspsychje> soon :p
[07:16] <EriC^^> lol
[07:16] <lotuspsychje> IOT is comming to us
[07:16] <ducasse> EriC^^: oh - can you give me the link to that pizza video you were talking about? i've been having homemade pizza urges lately :)
[07:17] <EriC^^> ducasse: https://www.youtube.com/watch?v=HCAPjIVOdJw
[07:17] <EriC^^> about the tortilla's i found 2 insanely easily and quick to make recipes
[07:17] <ducasse> EriC^^: brilliant, thank you kind sir!
[07:18] <EriC^^> get tortilla bread, put hot dog in it, wrap it, put a tooth pick, fry it in oil on both sides, put some ketchup and mustard in a bowl and dip in it and eat
[07:18] <jink> immu: I just don't care for GUIs.  I don't usually run Ubuntu Desktop (Server only).  And it's easy flamebait. :>
[07:19] <EriC^^> it's delicious, then for desert, get a tortilla bread, put nutella on it, put a banana in it and wrap it and eat
[07:19] <EriC^^> takes like 5mins to make them both, and it's very good
[07:19] <EriC^^> ducasse: no problem!
[07:19] <immu> your choice jink as you like it
[07:19] <ducasse> jink: no x server at all, just tty?
[07:20] <jink> ducasse: I run Windows, mostly.  Company policy.  And on a VPS, it makes no sense to run X.
[07:21] <EriC^^> even at home you're not allowed to run linux?
[07:21] <lordievader> Auch, Windows.
[07:21] <EriC^^> (that might sound stupider than i think it sounded)
[07:21] <jink> lordievader: Ssssst.
[07:21] <jink> EriC^^: I don't own a computer.  Just my work laptop.
[07:21] <immu> https://community.ubuntu.com/t/unity-7-continuation-call-for-developers-and-supporters/736/5
[07:21] <EriC^^> jink: oh
[07:22] <jink> EriC^^: No offence taken, btw. :)
[07:22] <ducasse> jink: oh, no - that's pretty obvious, i'd say. so you _do_ use a gooey - windows.
[07:22] <jink> ducasse: :P
[07:22] <immu> we need windows for certain things
[07:22] <ducasse> jink: all you need is a tty and tmux :-P
[07:22] <immu> and its better to have a backup
[07:22] <immu> brb
[07:22] <immu> after an hour mate
[07:22] <jink> Last time I used X was some 15-20 years ago, fvwm 1 on FreeBSD. :P
[07:23] <jink> immu: Take your time.  I'll be here for at least another 8 hours.
[07:23] <lordievader> ducasse (IRC): You mean ssh and tmux ;)
[07:23] <immu> sure all
[07:23] <ducasse> lordievader: not necessarily, no :)
[07:23] <jink> ducasse: It's screen, since I haven't made the move to tmux, yet, but sure.  That'll work.
[07:24] <ducasse> jink: i loved fvwm, kept using 1.24r for years and years
[07:24] <jink> :D
[07:24] <jink> Light, fast, awesome.
[07:25] <jink> On Windows I use Cygwin, and I bound a terminal to a hotkey.  Then ssh from there to wherever, and command-line perl awk shell, the works.
[07:28] <lordievader> No Bash on Windows (or however it is called).
[07:28] <lordievader> ?
[07:38] <ducasse> is that wsl (windows subsystem for linux), or is that a different beast?
[07:42] <lordievader> Oh, yeah. That's the one.
[08:14] <jink> lordievader: Windows 7, so, not yet.  Well, Cygwin bash, but not "native".
[08:16] <lordievader> Ah, I see.
[08:32] <jink> https://i.imgur.com/iAuvvCY.jpg
[10:52] <Sveta> https://askubuntu.com/questions/559060/fast-pdf-reader-that-remembers-the-last-viewed-page
[10:52] <Sveta> someone nom it for a bounty or something?
[10:53] <Sveta> i'm personally looking for a pdf viewer with continuous scrolling that remembers the last page that i opened, and is not okular or evince.  mupdf does not have continuous scrolling.
[10:53] <Sveta> so it's similar to that question, but i also need continuous scrolling..
[11:15] <immu> yo amigos
[11:28] <jink> 'sup immu? :)
[11:48] <immu> back
[11:53] <immu> jink, how u doing
[11:53] <immu> hi ducasse EriC^^ have your seen bluecasse
[11:56] <jink> Fine, at work. :)
[11:58] <BluesKaj> Hey folks
[12:00] <lordievader> Hey BluesKaj
[12:00] <jink> Hi BluesKaj.
[12:00] <BluesKaj> Hey lordievader, jink
[12:00] <lordievader> How are you doing?
[12:00] <jink> . · o ( is het al weekend? )
[12:01] <ducasse> g'morning BluesKaj \o
[12:01] <BluesKaj> fine here, some snow and cold , wintery , how about you, lordievader
[12:01] <BluesKaj> Hey ducasse
[12:01] <lordievader> Rain.... further more, doing good.
[12:10] <EriC^^> hi immu
[13:07] <pauljw> Hi everyone
[13:08] <BluesKaj> 'Morning pauljw
[13:09] <pauljw> hey BluesKaj :)
[13:10] <BluesKaj> got an arctic blast here last night
[13:10] <pauljw> :) same here, was 53F last evening and woke up to 27F this morning... brrr...
[13:20] <BluesKaj> bright sunshine and clear cold air
[13:22] <BluesKaj> the cold to a certain point doen't bother me much
[17:28] <EriC^^> !ping
[17:45] <oerheks> Hi EriC^^
[17:45] <oerheks> please be save, S.A. is crazy
[17:49] <EriC^^> hi oerheks
[17:51] <oerheks> i am looking at a special bike, silly pricing, bicycle for a wheelchair .. https://www.marktplaats.nl/a/fietsen-en-brommers/fietsen-bakfietsen/m1223114177-bakfiets-rolstoelfiets-van-raam.html
[17:57] <BluesKaj> where are the bike's control/handlebars to steer it
[17:58] <nacc> BluesKaj: first pciture is disassembled, it seems
[17:58] <nacc> BluesKaj: it's a nnormal fiet
[17:58] <nacc> BluesKaj: so directly abovd behind the platform/ramp
[17:58] <nacc> *above and behind
[17:59] <nacc> relative to the front of the bike
[17:59] <nacc> 3/9 is a better view
[17:59] <BluesKaj> yeah, but that's out of kilter to my eye
[17:59] <nacc> only in the first photo
[17:59] <nacc> (at least, to me)
[18:00] <nacc> oerheks: pretty impressive :)
[18:09] <oerheks> Yes, the steering bar needs some work
[18:09] <oerheks> but the rest is sound, he says
[18:09] <oerheks> i don' t need it, but i think i can make someone happy, else i buy it myself.
[18:13] <oerheks> this one is 6 years old or so, new ones look like this.. https://www.vanraam.com/nl-nl/onze-fietsen/rolstoelfietsen
[18:14] <BluesKaj> yeah, that's more practical for the driver
[19:03] <TJ-> Recall I reported at the beginning of the Linux v4.14 development cycle that AMD adding sme_me_mask (for Secure Encrypted Memory) into the memory-manager sub-system brokke many modules because it caused any module using PAGE_TABLE to pull in the EXPORT_SYMBOL_GPL symbol - this broke nvidia and many other out-of-tree non-GPL drivers. I reported this upstream but Thomas Gleixner, the sub-system
[19:03] <TJ-> maintiainer, refused to change it. Well, at the last minute (after v4.14rc8 and before final, it's been fixed in commit 87df26175e67c26ccdd3a002fbbb8cde78e28a19 ... but I noticed in the commit sign-offs: "Despised-by: Thomas Gleixner<EMAIL_ADDRESS>:D
[19:03] <TJ-> So disaster averted at the 11th hour
[19:03] <nacc> heh that sounds like tglx to me
[19:04] <daftykins> why'd that fool want to intentionally maintain something causing so much breakage?
[19:06] <TJ-> It was the EXPORT_SYMBOL_GPL being pulled in via (a very common) use of PAGE_TABLE macros. Inadvertently, but painfully. Linus comments in the commit message that the symbol ought to be in lower layers to prevent it propogating into drivers from the memory-manager, but for now the symbol has been made EXPORT_SYMBOL.
[19:06] <nacc> daftykins: tglx, ime, does not care about out of tree stuff
[19:07] <nacc> most kernel devs don't
[19:07] <nacc> (speaking as a former kernel dev)
[19:07] <TJ-> indeed, and to a great extent I agree with him. What I don't agree on is creating a new GPL symbol that is relied on by lots of existing core code, causing regressions.
[19:07] <nacc> yeah
[19:08] <nacc> also that may or may not be entirely legit
[19:08] <nacc> depends on your interp. of the GPL and whether you get some entanglement there
[19:08] <nacc> while not changing the exposed licensure of an existing symbol, it in effect does :)
[19:08] <TJ-> As far as nvidia goes the legal analysis is identical to the ZFS issue
[19:08] <nacc> yeah
[19:09] <TJ-> you've got a body of existing code with it's own existing stable API. Then you create a shim that translates that API to the kernel's API, and the shim is GPL licensed
[19:11] <TJ-> The argument that the existing stable (non Linux, non GPL) code behind the external API is a derivative of Linux is obviously not true. Where the arguments arise is that the shim is a derivative (and correctly licensed as GPL) but is called from non GPL code which, the argument goes, is also a derivative.
[19:11] <nacc> yeah its' about the limits of the virality
[19:13] <TJ-> I don't agree with Canonical very often (or they don't agree with me!) but from a long time back my legal advice, and my own analysis, says the derivation does not carry into pre-existing separate body of code - -especially in cases like Nvidia and ZFS where that code is cross-platform and not derived from Linux.
[19:13] <nacc> yeah
[19:13] <nacc> that's my understanding as well
[19:41] <TJ-> on another topic, some fab hackers have got full JTAG debuf access to the Intel CSME at last. So visibility into the southbridge MINIX OS and I wouldn't be surprised if it leads to a way to completely replace the OS on the southbridge at some point
[19:41] <daftykins> :)
[19:45] <TJ-> Hopefully that plus a reduced EFI (like Google's NERF) will finally allow users/owners to control Rings -2 and -3
[19:46] <daftykins> technically PCHs not southbridges anymore ;D
[19:46] <TJ-> It's quite scary realising there's a full network and device stack running and it ain't running on the CPU the user knows about, but on the CPU in the southbridge on the motherboard
[19:46] <TJ-> true, but the distinction is more helpful :)
[19:47] <daftykins> :>
[19:47] <TJ-> north vs south, I think, makes it easier to visualise the separation of concerns
[19:48] <TJ-> why is there ever a web-server in the MCE anyhow?
[19:48] <daftykins> bit cringe for the remote control features mmm
[19:52] <TJ-> For anyone interested (it's an easy read): https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf
[21:28]  * Bashing-om ready to have fun now :)
[21:37] <pauljw> hey Bashing-om :)
[21:40] <Bashing-om> pauljw: \o . Good day ?
[21:42] <pauljw> mostly Bashing-om, my primary system had a keyboard failure today, using my standby now...
[21:43] <Bashing-om> pauljw: Backups are good :)
[21:43] <daftykins> :D
[21:45] <pauljw> yep
[21:47] <pauljw> waiting on a quote from sys76 for a replacement...  already have a used one coming from ebay, but it may or may not be in good shape.
[21:49] <Bashing-om> I use an Old Old commadore mechanical keyboard. would really be a pain to adapt to another .
[21:51] <pauljw> seems since i switched to laptops only they're all different.  really don't like the sys76 one, chic-let style.
[21:56] <Bashing-om> pauljw: Being on different keyboards has ruined my typing skills :( getting back out of the habit of watching my fingers - yuk !
[21:56] <daftykins> still itching to get my hands on that clients kids Lenovo to have a go at repairing
[21:59] <Bashing-om> sadly, daftykins - I am all caught up .. not even an old box to linux-install and pass along .
[22:00] <daftykins> d'aww
[22:02] <Bashing-om> The bright side is that I have the time to devote to the fall chores in readiness for Winter .
[22:02] <daftykins> that's a bright side!?
[22:02] <daftykins> :D
[22:04] <Bashing-om> daftykins: When it comes to repairing a roof, or repairing a computer - the computer time wins every time :)
[22:05] <daftykins> :D
[22:05] <daftykins> oooh yes
[22:06] <daftykins> hopefully the case part turns up from aliexpress soon
[22:08] <Bashing-om> daftykins: Living on an island, at the mercy of the "shipping" .
[22:08] <daftykins> even worse from ali, that's China via the slow boat :D
[22:08] <daftykins> the option read "15 to 60 days"
[22:11] <Bashing-om> daftykins: How long does it take you to get to the London aorport ?
[22:11] <daftykins> ah it's a 45 minute flight typically
[22:11] <daftykins> depends if you get the jet (fast) or the twin prop
[22:12] <Bashing-om> daftykins: Oh you have air servicve on the island ! Wonderful :)
[22:12] <daftykins> yep, costs a good £120 both ways usually though
[22:13] <daftykins> er as in £60 each direction minimum
[22:14] <Bashing-om> daftykins: Well, even so - sure beats walking :P
[22:14] <daftykins> :D
[22:14] <daftykins> tad soggy and cold this time of year yep :>
[22:16] <Bashing-om> LOL
[22:16] <daftykins> the ferry goes to the south coast too, usually £40 each way as a passenger only
[22:26] <Bashing-om> daftykins: Ouch ! They got you by the short hairs :)
[22:27] <daftykins> XD
[22:27] <daftykins> i like to think it's a way of keeping the locals at bay


[02:48] <mup> PR snapd#6217 opened: tests: reset snapd state on tests restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6217>
[04:18] <mup> Bug #1753760 changed: Adding public RSA Key doesn't make login on device possible <Snappy:Expired> <https://launchpad.net/bugs/1753760>
[06:46] <zyga> o/
[07:34] <geodb27> People : hi !
[07:34] <zyga> hello
[07:48] <zyga> brb, need to take the dog out
[07:57] <pstolowski> mornings
[07:58] <pstolowski> back to yesterday's test panic issue, the debug log from zyga shed some light on it
[07:59] <mvo> pstolowski: good morning and good luck wit hthat
[08:00] <zyga> Hey Paweł, Michael
[08:00] <zyga> mvo: I’m off the 2.36 bug
[08:00] <zyga> No progress made
[08:00] <zyga> Need to finish my stuff now
[08:04] <mvo> zyga: ok
[08:06] <pstolowski> zyga: may i ask you to try one more patch>
[08:06] <pstolowski> ?
[08:18] <zyga> Sure
[08:19] <pstolowski> zyga: https://pastebin.ubuntu.com/p/Kgs7tXTfRH/
[08:26] <mvo> pedronis: re 6195 - shall we (after this got a second review) merge and do 2.36.2 and then look for a better place for this than link_snap.go? or would you rather like to look for this place now before it goes to master?
[08:31] <mup> PR snapd#6218 opened:  snapstate: update fontconfig caches on install (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6218>
[08:59] <pstolowski> zyga: actually that patch won't help; i'll have another one soon
[09:00] <pstolowski> i wish i understand what the delta is between our setups and why it doesn't fail for me on travis, pretty weird
[09:17] <zyga> pstolowski: re, sorry, had a delay and network woes
[09:18] <zyga> pstolowski: yeah
[09:18] <zyga> pstolowski: if you want I can give you ssh access
[09:18] <zyga> not sure if that would help
[09:18] <zyga> to my box
[09:18] <zyga> where this happens
[09:18] <zyga> I can work on another
[09:23] <pstolowski> zyga: yeah, that could help, thanks. also question, did we change anything related to finding if apparmor should be enabled or not recenlty? it looks like setup-profiles in this test now wants to read vanilla snap-confine profile of core; this happens if we find that release.AppApparmorLevel != NoApparmor. we're not mocking vanilla profile in the mock core snap obviously
[09:24] <pstolowski> mvo: you might know as well^
[09:24] <zyga> pstolowski: not sure when is recently
[09:24] <zyga> when apparmor is not entirely disabled we operate
[09:24] <zyga> including making a special profile for snap-confine itself
[09:24] <zyga> if you think mocking is missing by all means, add some
[09:25] <pstolowski> yep. it's just curious it's not happening consistently
[09:26] <Chipaca> moin moin
[09:26] <zyga> hey Chipaca
[09:26] <Chipaca> have you seen https://forum.snapcraft.io/t/disable-enable-not-longer-working-when-snap-have-gpio-pins-as-connect/6473 ?
[09:26] <zyga> oh noes
[09:26] <zyga> well
[09:26] <zyga> this is a bug we fixed
[09:27] <Chipaca> zyga: "withthe edge channel" of core presumably?
[09:27] <zyga> yes
[09:27] <pstolowski> morning Chipaca
[09:28] <zyga> Chipaca: your questions got me curious
[09:28] <zyga> so I did some more experiments on https://github.com/snapcore/snapd/pull/6147
[09:28] <mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[09:29] <zyga> and I believe we understand why additional permissions are required
[09:29] <zyga> my only question now
[09:29] <zyga> should I split the permissions so that snap-update-ns is called with the existing profile transition
[09:29] <zyga> and the only permission we have remains "r"
[09:29] <zyga> adding a new block for snap-discard-ns which runs with the same profile
[09:29] <zyga> or is the patch as-is good enough?
[09:30] <Chipaca> zyga: WWJ(S)D?
[09:30] <zyga> split it
[09:30] <Chipaca> :-)
[09:30] <zyga> for maximum confinement
[09:30] <zyga> I'll do that
[09:30] <zyga> btw, love the acronym :D
[09:39] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/6147 is ready now
[09:39] <mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[09:40] <zyga> eh
[09:40] <zyga> https://gitlab.gnome.org/GNOME/gnome-control-center/issues/230#note_373259
[09:50] <mup> PR snapd#6219 opened: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
[10:00] <zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6147
[10:00] <mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[10:01] <zyga> Chipaca: thank you!
[10:21] <zyga> I also need a 2nd review on https://github.com/snapcore/snapd/pull/6159
[10:21] <mup> PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
[10:31] <pstolowski> zyga: +1 with one question
[10:33] <mup> PR snapd#6159 closed: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6159>
[10:33] <zyga> answered
[10:33] <zyga> thanks! :)
[10:33] <zyga> mvo: what's the 2.36 weather like?
[10:37] <mvo> zyga: medium, still see failures but can't reproduce them
[10:38] <zyga> mvo: magic
[10:38] <zyga> mvo: pstolowski is working on a fix for the panic I can reproduce trivially
[10:38] <zyga> I'll just run tests for his incremental patches
[10:38] <pstolowski> zyga:you can try https://github.com/snapcore/snapd/pull/6219
[10:38] <mup> PR #6219: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
[10:38] <zyga> sure thing
[10:39] <pstolowski> zyga: btw, it's green, does it mean anything?
[10:39] <zyga> test in progress
[10:39] <pstolowski> cause i can't repro here, pretty annoying
[10:40] <mvo> pstolowski: I can try to run this after my current run, I had some luck reproducing the panic
[10:45] <pstolowski> mvo: thanks. i tried running it with spread -debug -repeat 10 google:ubuntu-16.04-64:tests/unit/go
[10:51] <pedronis> mvo: I hopefully answered in the PR
[11:02] <mvo> pedronis: ta
[11:03] <pedronis> np
[11:03]  * pedronis goes back to swap daying
[11:04] <mvo> pstolowski: I am running it now again, lets see
[11:13] <zyga> Brb, coffee or something warm
[11:26] <mvo> pstolowski: https://paste.ubuntu.com/p/9rj8ydFg5p/ <- I cherry picked  1c5b166643a5623b0a534fd1a8acb7d03d50d856 from 6219 earlier
[11:29] <pstolowski> mvo: aha, interesting, let me mock core rev 1 as well
[11:30] <mvo> pstolowski: shall I run it again?
[11:30] <mvo> pstolowski: I mean, after you upated the pr?
[11:35] <pstolowski> mvo: i've just pushed a change
[11:35] <pstolowski> mvo: thanks!
[11:35] <cachio> pedronis, I am working again with the #5714
[11:36] <mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[11:50] <mvo> 6195 needs a second review
[11:55] <zyga> mvo: I reproduced 2.36 bug again
[11:55] <zyga> pstolowski: no panic yet
[11:56] <pstolowski> zyga: are you running with the update i pushed  a few minutes ago ^ ?
[11:56] <zyga> pstolowski: no, the one from earlier today
[11:56] <zyga> mock vanilla profile for snap-confine
[11:57] <zyga> mvo: same thing, apparmor parser killed by signal
[11:57] <pstolowski> zyga: ok; yeah, i think one more revision of core in the tests needs it too, i added it
[11:57] <zyga> ok
[11:59] <mvo> zyga: anything interessting why its killed?
[11:59] <zyga> mvo: I cannot find any information about why
[11:59] <mvo> zyga: or what signal? sigter
[11:59] <zyga> hits appreciated
[11:59] <mvo> zyga: meh :(
[12:00] <zyga> I suspect sigterm because it says "terminated"
[12:01] <zyga> ah
[12:01] <zyga> something interesting
[12:01] <zyga> mvo: look at this
[12:01] <zyga> lots of terminated errors https://www.irccloud.com/pastebin/FVHUi8t8/
[12:01] <zyga> I thought it is just one time
[12:02] <zyga> mvo: it's not just once
[12:02] <zyga> it seems to happen all the time
[12:02] <zyga> snap changes https://www.irccloud.com/pastebin/2UoYFGwX/
[12:04] <zyga> *hmm*
[12:04] <zyga> mvo: note that this branch doesn't have the tweak I used before
[12:04] <zyga> so the error was not fatal
[12:04] <zyga> I was testing pawel's patches
[12:04] <zyga> I will record the seed and continue unless anyone has some better idea
[12:07] <zyga> ok, seed is -seed=1543315161
[12:07] <zyga> I will pull more of pawel's patches
[12:08] <zyga> as well as my stashed error handling
[12:08] <zyga> and let's see
[12:08] <mvo> zyga: thank you
[12:08] <mvo> zyga: I run it also with your diff to make the error fatal
[12:09] <mvo> zyga: but so far no luck in reproducing
[12:09] <zyga> restarted
[12:09] <zyga> back to working on feature
[12:13] <Chipaca> what's holding back snapd on debian?
[12:14] <zyga> Chipaca: AFAIK there's a test failure that happens there
[12:14] <zyga> but no investigated
[12:14] <Chipaca> I mean packaging-wise
[12:14] <Chipaca> it's on 2.30
[12:14] <Chipaca> and no reexec
[12:15] <zyga> I believe you are wrong, there is reexec
[12:15] <Chipaca> hmm
[12:15] <zyga> as for the package, nobody released updates
[12:17] <Chipaca> I wonder if deepin mangles os-release or sth, then
[12:17]  * Chipaca installs deepin
[12:17] <zyga> note that we have a blacklist, not a whitelist
[12:17] <Chipaca> no we don't
[12:17] <Chipaca> I mean
[12:17] <Chipaca> 	if !release.DistroLike("debian", "ubuntu") {
[12:18] <Chipaca> that's a whitelist, even if it has a "not" in front of it
[12:19] <zyga> oh
[12:19] <zyga> indeed
[12:19] <zyga> that's new to me
[12:19] <Chipaca> zyga: reading a bit of above, "terminated" is the %s of signal 15
[12:19] <zyga> aha
[12:19] <zyga> sigkill
[12:19] <zyga> that's odd
[12:19] <zyga> wonder why we do that
[12:19] <Chipaca> zyga: /usr/share/go-1.6/src/syscall/zerrors_linux_amd64.go
[12:19] <zyga> (not really us probably)
[12:19] <zyga> ze errorz zey keep koming!
[12:20] <Chipaca> I think it's just shorthand for "zee autogeneraed files"
[12:20] <Chipaca> zyga: 15 is TERM, so what else would you call it?
[12:21] <zyga> ah, sorry
[12:21] <zyga> 9 is kill
[12:21] <Chipaca> :-)
[12:21] <zyga> I did make tea, not coffee
[12:21] <zyga> so terminated
[12:21] <Chipaca> and 9 would say "killed"
[12:21] <zyga> maybe test setup?
[12:22] <zyga> there is one silly way to fix it :)
[12:22] <zyga> we could wrap aa-parser with an apparmor profile
[12:22] <zyga> that rejects SIGTERM :D
[12:22] <zyga> (I'm half serious)
[12:22] <zyga> might help us to pinpoint the sender
[12:22] <zyga> because we would get a denial
[12:25]  * pstolowski lunch
[12:33] <zyga> is maciej around today?
[12:33] <zyga> ah, he called in sick
[12:33] <zyga> ok
[12:43] <Chipaca> https://forum.snapcraft.io/t/cannot-run-any-program-trace-breakpoint-triggered-errors/8707?u=chipaca if anybody has clues about apparently x11 being broken on deepin
[12:44]  * zyga thinks
[12:45] <zyga> I know
[12:45] <Chipaca> zyga: i'm going to get lunch, but i'll read when i return
[12:45] <zyga> ls /tmp/.X11-unix
[12:45] <zyga> on ubuntu we use abstract socket to talk to x
[12:45] <zyga> on some systems we don't
[12:46] <zyga> without special support we won't have x socket
[12:51] <Wimpress> If snap A connects to snap B via a content interface, can snap A execute binaries within snap B?
[12:51] <zyga> Wimpress: yes, but must use the internal interface, not via "snap run ..." or /snap/bin/..."
[12:51] <zyga> and said binaries run with confinement of snap A
[12:52] <Wimpress> snap A is confined.
[12:52] <Wimpress> snap B might be classic ;-)
[12:52] <zyga> by internal interface I mean by knowing how to execute the binary directly from where the content sharing is establieshed
[12:52] <zyga> Wimpress: content sharing shares bits and bytes
[12:52] <zyga> not changing anything else
[12:52] <zyga> does't grant more permissions to run
[12:52] <zyga> or not run
[12:53] <Wimpress> OK, so by virtue of having the snaps connected, snap A can not execute binaries from snap B. Correct?
[12:53] <zyga> no, that's not correct
[12:53] <zyga> if I have a snap that contains a shell script
[12:53] <zyga> and I expose that via a content interface
[12:53] <zyga> and that interface is connected to some other sna
[12:54] <zyga> that other snap can invoke that shell script
[12:54] <Wimpress> Excellent.
[12:54] <zyga> that shell script may not be an exposed application
[12:54] <zyga> and in fact if it is an exposed application
[12:54] <zyga> I cannot use that exposed application from any snap
[12:54] <zyga> note that this doesn't imply any more permissions
[12:55] <zyga> if you content-connect to LXD, for example, you don't get to run LXD with all the powers attached
[12:55] <Wimpress> So snap A would have to invoke the binary in snap B via a full path?
[12:55] <zyga> it's just a way to share bytes
[12:55] <zyga> Wimpress: with path, environment and any other quirks required
[12:55] <zyga> it's as easy or hard as the associated binary implementation details are
[12:57] <Wimpress> Would binaries snap A want to execute from snap B be referenced via /snap/snapA/current/bin/foo or via /snap/snapB/current/bin/foo? Or will $SNAP be fine?
[12:57] <zyga> neither, you need to use the real path where they are shared
[12:57] <zyga> so if you share them to, say
[12:57] <zyga> $SNAP/plugins/
[12:57] <zyga> and find them there
[12:58] <zyga> you need to know to call $SNAP/plugins/foo/bin/plugin.bin
[12:58] <zyga> $SNAP or any other variables are not aware of that
[12:58] <zyga> they will not know anything about any connected content interfaces (perhaps many)
[12:58] <zyga> they will always point to the snap for which the main process was started
[12:58] <zyga> (snap A in this case)
[12:58] <Wimpress> OK. Sounds promising.
[12:59] <Wimpress> So, if snap A (confined) is connecting to snap B (classic), snap A can execute binaries exposed from snap B but within the confinement defined by snap A. Correct?
[12:59] <zyga> yes
[13:00] <Wimpress> Cool.
[13:00] <zyga> it's really just the same
[13:00] <zyga> as if they were copied into snap A
[13:00] <zyga> it's just a way to share bytes
[13:00] <Wimpress> Just wanted to be clear.
[13:00] <zyga> sure
[13:00] <Chipaca> zyga: am back. Indeed /tmp/.X11-unix/X0 is where it's at
[13:01] <zyga> yay
[13:01] <Chipaca> zyga: so what do I do?
[13:01] <zyga> we can easily fix that too
[13:02] <zyga> hold on
[13:03] <zyga> looking for something
[13:05] <zyga> Chipaca: in cmd_run.go we handle XAUTHORITY
[13:05] <zyga> we could handle X11 socket
[13:06] <Chipaca> zyga: handle it how?
[13:06] <zyga> ha, that's tricky
[13:07] <zyga> we can see the socket
[13:07] <zyga> but not access it
[13:07] <zyga> perhaps we should preserve /tmp/.X11* in snap-conifne
[13:07] <zyga> which is not terribly hard but not super easy either
[13:07] <zyga> Chipaca: can you please file a bug
[13:07] <zyga> or find one
[13:07] <zyga> I bet people reported it
[13:07] <zyga> there are also mentions of this on the forum
[13:07] <cachio> zyga, hey
[13:08] <Chipaca> zyga: I mean, this is from the forum :-)
[13:08] <zyga> Chipaca: let's cross reference them then
[13:08] <zyga> cachio: hello
[13:08] <cachio> zyga, I could make the cifs test work but ...
[13:08] <cachio> zyga, just adding this to the interface "/run/mount/utab rw,"
[13:08] <Chipaca> zyga: I wonder if there's a way to tell X to use abstract sockets
[13:08] <zyga> I think we discussed that
[13:09] <zyga> cachio: we should not do that
[13:09] <zyga> Chipaca: some systems don't have one
[13:09] <cachio> zyga, based on the comment we shouldn't
[13:09] <zyga> cachio: we cannot add that permission because that would allow snaps to confuse the host's libmount about what certain attributes are
[13:11] <Chipaca> zyga: it seems to also have an abstract socket, @/tmp/.X11-unix/X0
[13:11] <zyga> Chipaca: is there anything in the environment
[13:11] <zyga> any X... variable set?
[13:11] <zyga> maybe we can do a low cost fix
[13:12] <zyga> "unset XSTH"
[13:13] <Chipaca> nothing that I can see
[13:14] <zyga> dunno then
[13:18] <Chipaca> zyga: and if I install with devmode it workss
[13:18] <zyga> oh
[13:18] <zyga> that's odd
[13:18] <Chipaca> zyga: so it's not the /tmp/.X11 socket
[13:18] <zyga> what's the denial?
[13:18] <Chipaca> zyga: it's access to the socket itself
[13:18] <pstolowski> mvo: any news on the 2nd run of https://github.com/snapcore/snapd/pull/6219 ?
[13:18] <Chipaca> 1 sec because I accidentally killed the vm :-)
[13:18] <mup> PR #6219: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
[13:19] <zyga> pstolowski: I ran it again, 0 failures
[13:19] <zyga> restarted (thanks for reminidng me)
[13:19] <pstolowski> nice, thanks
[13:19] <pstolowski> fwtw travis pass was green again
[13:22] <Chipaca> [  157.486384] audit: type=1400 audit(1543324906.843:348): apparmor="DENIED" operation="create" profile="snap.xbill-xaw.xbill-xaw" pid=3187 comm="xbill" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
[13:22] <Chipaca> had to purge the charon thing to get to see that
[13:22] <zyga> hold on
[13:22]  * Chipaca goes to check on the soup
[13:22] <zyga> weird
[13:23] <Chipaca> soup for lunch isn't that weird
[13:23] <Chipaca> i've got a bad cold
[13:23] <Chipaca> ¯\_(ツ)_/¯
[13:23] <Son_Goku> niemeyer, zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
[13:23] <Son_Goku> this might make you guys happy :)
[13:23] <zyga> indeed
[13:23] <zyga> Son_Goku: mborzecki is sick, he's off today
[13:23] <zyga> but I'll make sure he knows
[13:23] <Son_Goku> ah, that's too bad
[13:23] <Son_Goku> hope he feels better soon :)
[13:24] <zyga> Chipaca: which interfaces do you have connected
[13:24] <zyga> Chipaca: x11 plug grants socket AF_NETLINK, not unix
[13:24] <zyga> also allows some x abstractions, reading on those now
[13:25] <zyga> Chipaca: but nothing grants access to that socket
[13:25] <zyga> Chipaca: could it be the case that apparmor simply doesn't handle abstract sockets
[13:25] <zyga> and we never noticed?
[13:26] <Chipaca> sounds like a jdstrand question :-)
[13:26] <Chipaca> or, maybe a jjohansen ? if i remember people right
[13:26]  * Chipaca often doesn't
[13:30] <Chipaca> mmm, tasty tasty schadenfreude http://forum.asrock.com/forum_posts.asp?TID=10174
[13:32] <zyga> Chipaca: both would know
[13:32] <Chipaca> ok, i'm off to have actual lunch now
[13:32] <Chipaca> ttfn
[13:32] <zyga> good idea
[13:33] <zyga> I'll wait till after standup
[13:33] <zyga> I'd love to land https://github.com/snapcore/snapd/pull/6147
[13:33] <mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[13:33] <zyga> mvo: can you do a quick review, in mborzecki's absence
[14:22] <Chipaca> zyga: https://pastebin.ubuntu.com/p/B5d5n36p2h/ might this be relevant to the x11 thing?
[14:22] <zyga> maybe
[14:27] <zyga> mvo: the bug is https://bugs.launchpad.net/snapd/+bug/1805182
[14:27] <mup> Bug #1805182: /tmp is sometime cleaned up after snaps are launched <snapd:Triaged> <https://launchpad.net/bugs/1805182>
[14:39] <Chipaca> socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) vs socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0)
[14:53] <mup> PR snapd#6220 opened: cmd: drop cruft from snap-discard-ns build rules <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6220>
[14:53] <zyga> mvo: can you do a quick review of https://github.com/snapcore/snapd/pull/6147 please
[14:53] <mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[14:53] <zyga> it's green and if it lands I can continue
[14:53] <zyga> and has one and a half review
[14:54] <mvo> zyga: I try, have a lot of meeting now :/
[14:54] <zyga> ok
[14:54] <zyga> pstolowski: perhaps you ^
[14:54] <pstolowski> 6147?
[14:54] <pstolowski> zyga: ^
[14:55] <zyga> yes
[14:55] <pstolowski> ok
[14:58] <zyga> meanwhile, 2.36 branch for those errors
[15:02] <zyga> mvo: I just realized something
[15:02] <zyga> the terminated error is not new
[15:02] <zyga> we probably had it since forever
[15:02] <zyga> but we would not notice it until the special situation in 2.36 branch
[15:02] <zyga> this doesn't change why it is broken
[15:03] <zyga> but may help us form new perspective
[15:03] <zyga> because we had ignored those errors all the time
[15:03] <zyga> we would just happily carry on
[15:03] <mup> PR snapcraft#2417 opened: Revert "lifecycle: make snapcraft init template use > not | (#2393)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2417>
[15:09] <mup> PR snapd#6221 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
[15:10] <zyga> mvo: this one is for you https://github.com/snapcore/snapd/pull/6221
[15:10] <mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
[15:29] <mup> PR snapd#6222 opened: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[15:33] <zyga> pstolowski: nice
[15:33] <zyga> pstolowski: 0 errors
[15:34] <pstolowski> zyga: very nice, thanks, i'm cleaning that PR atm, will push an update
[15:34] <zyga> pstolowski: I woudn't mind a follow up
[15:34] <zyga> this looks sane as-is
[15:38] <pstolowski> well it outputs debug
[15:38] <pstolowski> pushed
[15:38] <pstolowski> i'll cherry pick into master
[15:38]  * cachio lunch
[15:40] <zyga> cachio: offtopic, can we start instances not in us-east
[15:40] <zyga> it would be awesome if we could do europe too
[15:40] <zyga> cachio: latency to us-east sucks :/
[15:41] <zyga> not sure if this is something you or gustavo needs to handle
[15:41] <zyga> spread on travis is ok
[15:41] <zyga> but interactive spread for debugging is not
[15:41] <zyga> I'm fine with editing my spread.yaml if I can achieve that
[15:49] <mup> PR snapd#6147 closed: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  🐎> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6147>
[15:49] <zyga> thank you mvo!
[15:51] <zyga> mvo: https://github.com/snapcore/snapd/pull/6221 no errors yet!
[15:51] <mvo> zyga: meeting ended early :)
[15:51] <mvo> zyga: oh no
[15:51] <mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
[15:51] <zyga> well, there are unit test panics that pstolowski is fixing
[15:51] <mvo> zyga: its so annoying
[15:51] <zyga> but none of the other errors
[15:52] <zyga> so while I don't get it, it's interesting output
[15:53] <mvo> zyga: it seems to be happening all the time in the 6128 PR
[15:55] <zyga> mvo: 6128 is merged, I assume you mean a 2.36 backport of that
[15:55] <zyga> well, let's see
[15:55] <zyga> I need to break for dinner now
[15:55] <zyga> I will be back
[15:55] <zyga> mvo: https://github.com/snapcore/snapd/pull/6220 looks like an easy win
[15:55] <mup> PR #6220: cmd: drop cruft from snap-discard-ns build rules <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6220>
[15:56] <zyga> and helps me move forward too
[15:56] <mvo> zyga: 6218 - sorry
[15:57] <mvo> zyga: as a general rule I always approve PRs that have only reds
[16:14] <zyga> re
[16:14] <zyga> looking
[16:17] <zyga> mvo: https://github.com/snapcore/snapd/pull/6221 didn't fail on that apparmor issue
[16:17] <mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
[16:17] <zyga> mvo: do you have any theory as to why the patch may make it better?
[16:19] <mvo> zyga: in a meeting, can you just retrigger?
[16:21] <cachio> zyga, I think we can
[16:21] <zyga> yep
[16:21] <zyga> did
[16:21] <cachio> nice
[16:21] <cachio> there is a problem
[16:21] <zyga> cachio: if you tell me how I'd love to try
[16:21] <zyga> but I need to take the dog out first :)
[16:22] <cachio> the spread cleaner is configured to clean machines just on us-east1-b
[16:22] <zyga> oh
[16:22] <cachio> it is basically because you query instances by zone
[16:30] <kenvandine> mvo: were you saying desktop-launch in brave was taking ~2s on the 2nd launch on 18.10?
[16:30] <zyga> kenvandine: AFAIK it was update-mime-cache or something like that
[16:30] <kenvandine> that should only be on the first run
[16:32] <zyga> pstolowski: I just got a notification that ISS is rising
[16:32] <zyga> coool
[16:32] <zyga> the app is not even open
[16:33] <pstolowski> zyga: :)
[16:34] <zyga> kenvandine: yeah but from what mvo researched it seemed to be a constant cost
[16:34] <kenvandine> interesting
[16:34] <zyga> I didn't examine that, I think it's best to wait for mvo to leave the meeting frenzy
[16:35] <kenvandine> i just tried it on my 18.10 laptop and i'm getting good results
[16:35] <kenvandine> desktop-launch elapsed time:  0.116752997
[16:35] <zyga> mmm
[16:36] <mvo> kenvandine: interessting - here is my second run:http://paste.ubuntu.com/p/hFbMF8CQKT/
[16:36] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6222#issuecomment-442126406
[16:36] <mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
[16:36] <mvo> kenvandine: maybe specific to my machine, its a pretty beaten setup :)
[16:37] <kenvandine> mvo update-mime-database and update-icon-cache should only run on the 1st run
[16:37] <mvo> kenvandine: ok, should I set -x the script to see what is going on?
[16:37] <mvo> kenvandine: let me do that
[16:37] <kenvandine> yes
[16:38] <kenvandine> mvo:  that would be useful
[16:39] <kenvandine> mvo: that should only run if needs_update is true
[16:39] <pstolowski> zyga: damn, i think it's not deteministtic... saw that error once but then stopped getting it as the test was tweaked
[16:40] <kenvandine> mvo: https://pastebin.ubuntu.com/p/C2M7Y6XQpf/
[16:41] <mvo> kenvandine: it looks like the user-dirs.dirs check is setting needs_update=true
[16:41] <mvo> kenvandine: I'm trying to figure out now why
[16:41] <kenvandine> oh
[16:42] <kenvandine> mvo: that's not setting it for me
[16:42] <kenvandine> so maybe that's the trigger
[16:42] <kenvandine> perhaps we shouldn't overload needs_update there
[16:43] <mvo> kenvandine: I have no .md5sum file in my dir it seems
[16:45] <kenvandine> mvo: what's your actual $HOME/.config/user-dirs.{dirs,locale} look like
[16:46] <mvo> kenvandine: I don't have a user-dirs.locale
[16:46] <kenvandine> sigh...
[16:46] <kenvandine> i wonder why not
[16:46] <mvo> kenvandine: I have no idea :/
[16:46] <mvo> kenvandine: but its there on my other box - what creates it?
[16:47] <kenvandine> not sure
[16:47] <kenvandine> mvo: so for you it's doing a bunch of things on every run that it shouldn't
[16:47] <mvo> kenvandine: indeed
[16:47] <kenvandine> seb128: ^^ what creates user-dirs.locale?
[16:48] <roadmr> hey folks, a question! two old revisions of each snap are kept for rollback purposes. But these are squashfs-mounted. Why are they mounted if they're not really in use?
[16:49] <zyga> roadmr: two reasons
[16:49] <zyga> roadmr: we didn't do it better
[16:49] <zyga> roadmr: we don't cache meta/snap.yaml
[16:49] <zyga> so we really go and look each time you ask
[16:49] <zyga> we also rely on the filesystem being there to discover things like hooks
[16:49] <roadmr> ok :)
[16:51] <mup> PR snapd#6220 closed: cmd: drop cruft from snap-discard-ns build rules <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6220>
[16:51] <zyga> roadmr: given that they consume memory it would be nice to not have to mount those
[16:52] <zyga> roadmr: we might get to a point where snapd caches enough stuff about them to stop needing that
[16:52] <roadmr> zyga: indeed, it did seem weird and wasteful but doesn't seem to be the end of the world :)
[16:52] <zyga> pstolowski: I keep getting panics
[16:52] <zyga> those that your PR fixes
[16:53] <zyga> cannot wait for 6219
[16:53] <pstolowski> zyga: noooo..
[16:53] <pstolowski> zyga: uh oh, you getting them without my PR?
[16:53] <zyga> yes
[16:53] <zyga> btw
[16:53] <pstolowski> ufff
[16:53] <zyga> inside your pr
[16:53] <zyga> what were the calls to the "snap" command like?
[16:54] <zyga> can you check that in the test quickly
[16:54] <zyga> even locally
[16:55] <pstolowski> zyga: probably none, i added just in case run-hook is exectued, as this was a case in many other tests before. i can probably remove it here, but there is no harm in leving it
[16:55] <zyga> can you just double check before this goes in
[16:56] <pstolowski> ok
[17:01] <cachio>  zyga already tried mounting on /run/mount but still get the same denial
[17:01] <cachio> apparmor="DENIED" operation="open" profile="snap.test-snapd-sh.with-cifs-mount" name="/run/mount/utab" pid=24510 comm="mount" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0
[17:01] <zyga> cachio: you'd have to change the interface
[17:01] <zyga> cachio: to do two more things:
[17:01] <zyga> allow that path to be written
[17:01] <zyga> and create a symlink in /run/mount/utab
[17:01] <zyga> the problem is that it's not easy to do 2)
[17:01] <zyga> for the moment I have no solution
[17:02] <pstolowski> zyga: no calls to snap cmd, verified with fmt.Printf("%q\n", ms.snapCmd.Calls()) in teardown
[17:02] <zyga> cool
[17:04] <cachio> zyga, ok, I'll try that
[17:04] <zyga> cachio: no, please don't
[17:05] <zyga> cachio: there is no fix now
[17:05] <cachio> zyga, ah, ok
[17:05] <cachio> :(
[17:05] <zyga> sorry, no easy win
[17:05] <zyga> mvo: one more trivial https://github.com/snapcore/snapd/pull/6223
[17:05] <mup> PR #6223: cmd/libsnap: move apparmor-support to libsnap <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
[17:06] <zyga> this all setting the stage for the big tool cleanup that mborzecki requested
[17:06] <mup> PR snapd#6223 opened: cmd/libsnap: move apparmor-support to libsnap <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
[17:22] <pstolowski> #6219 failed on unrelated stuff, for the 2nd time
[17:22] <pstolowski> google:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable
[17:22] <mup> PR #6219: overlord/tests: fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
[17:23] <pstolowski> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
[17:23] <pstolowski> (previously it failed on the .mnt unit bug)
[17:24] <zyga> cachio: some quick comments on 6217
[17:25] <zyga> pstolowski: eh
[17:25] <zyga> 2.36 of doom
[17:25] <zyga> pstolowski: perhaps we should merge the two 2.36 fixes into one branch
[17:26] <zyga> WOAH
[17:26] <zyga> we foudn some useful stuff
[17:26] <cachio> zyga, tx
[17:26] <zyga> error from apparmor-parser https://www.irccloud.com/pastebin/4APIpXG2/
[17:28] <zyga> jdstrand: hey, I recall there were some parser incompatiblity with older LEAP releases
[17:28] <zyga> this looks similar ^
[17:28] <zyga> do I recall if you had a PR that fixed this in master
[17:29] <zyga> this comes from a PR that makes errors actually reported: https://github.com/snapcore/snapd/pull/6221
[17:29] <mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
[17:29] <zyga> it is against 2.36, not master
[17:30] <pstolowski> zyga: !
[17:31] <mup> PR snapd#6224 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6224>
[17:31] <zyga> I opened one against master
[17:31] <zyga> let's see what happens
[17:31] <zyga> I need to take Bit out for that walk!
[17:31] <zyga> I'm terrible at tracking time sometimes
[17:31] <zyga> ttyl
[18:03] <zyga> mvo: I'll break to get some groceries with wife
[19:05]  * cachio afk
[19:14] <mvo> zyga|afk: hm - so "AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap-confine.core.6016 in /var/lib/snapd/apparmor/profiles/snap-confine.core.6016 at line 103: Exec condition must begin with '/'." - in my profile line 103 is: "    change_profile unsafe /** -> [^u/]**,
[19:14] <mvo> "
[19:53] <zyga|afk> Hey
[19:53] <zyga|afk> mvo: I know what that is but I m afk now
[20:28] <zyga|afk> mvo: still here?
[20:36] <mvo> zyga|afk: back now
[20:36] <zyga> hey
[20:36] <zyga> so long story, we use a incompatible format in master
[20:36] <mvo> zyga: you know what it is?
[20:36] <mvo> zyga: meh
[20:36] <zyga> yes, we knew about it
[20:36] <zyga> I think jdstrand assumed that leap is not needed anymore
[20:36] <zyga> and because we didn't return the error all the way
[20:36] <zyga> it was non-fatal
[20:37] <zyga> I actually think there's some correlation between this and the unit test failure
[20:37] <zyga> see
[20:37] <zyga> if some things weren't mocked
[20:37] <zyga> and really ran
[20:37] <zyga> they may really fail
[20:37] <zyga> and then we'd start undoing
[20:37] <zyga> look at master version of the PR that uncovers this
[20:37] <mvo> zyga: hm, so why is it flaky then and does not fail all the time?
[20:37] <zyga> the error in master is exactly the panic that pawel was chasing
[20:37] <mvo> zyga: and its incompatible with 16.04?
[20:37] <zyga> it depends on what ran before
[20:37] <zyga> I don't think it is incompatible with xenial
[20:38] <zyga> but I don't know yet
[20:38] <zyga> I just realised what it was while outside
[20:38] <zyga> I will see for myself on leap 42.3 - i have all those VMs around
[20:38] <mvo> zyga: ok, thats great that we finally have a lead
[20:38] <zyga> I didn't check
[20:38] <zyga> or I don't remember
[20:38] <zyga> if the unit test failure was specific to one system
[20:38] <mvo> zyga: I'm still puzzled that we see these failures on ubuntu
[20:38] <zyga> or was it all over
[20:39] <zyga> yeah
[20:39] <zyga> what's curious is that here (now) we got a message from apparmor parser
[20:39] <zyga> we got the output saying "stuff is bad here and here"
[20:39] <zyga> previously it was just "terminated"
[20:39] <zyga> that's still hinting at another problem
[20:39] <zyga> that's all the insight I have so far
[20:39] <mvo> 2018-11-27 17:11:14 Error executing google:ubuntu-16.04-64:tests/main/parallel-install-interfaces-content:common :
[20:39] <mvo> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
[20:39] <zyga> yeah
[20:39] <zyga> that means you run with edge profile
[20:39] <mvo> zyga: aha, ok
[20:39] <zyga> because you were not able to load the real profile
[20:40] <zyga> maybe 16.04 _is_ incompatible
[20:40] <mvo> zyga: yeah, indeed
[20:40] <zyga> I'll check
[20:40] <zyga> fun stuff
[20:40] <zyga> well
[20:40] <mvo> zyga: that would be nice, thanks a lot, again, great to hear the progress
[20:40] <zyga> "fun"
[20:40] <zyga> logging a problem vs returning it
[20:40] <zyga> because reliability
[20:41] <zyga> while I have you
[20:41] <zyga> https://github.com/snapcore/snapd/pull/6223
[20:41] <mup> PR #6223: cmd/libsnap: move apparmor-support to libsnap <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
[20:41] <zyga> :D
[20:41] <zyga> pretty plesae
[20:41] <zyga> *please
[20:42] <mvo> zyga: heh, ok
[20:42] <zyga> \o/
[20:42] <zyga> thanks!
[20:43] <zyga> I'm moving this because the next PR will add a tool.c tool.h combo that is all about "I want to run snapd tool from another snapd tool written in C"
[20:43] <zyga> this is the cleanup that maciej requested
[20:43] <zyga> so I'm shaving some yak there
[20:43] <zyga> mvo: https://github.com/snapcore/snapd/pull/6149 this is the next critical in the pipe, but that's for tomorrow
[20:43] <zyga> mvo: I'll get to that apparmor issue now
[20:43] <mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[20:43] <zyga> and let's see what we get
[20:44] <mvo> zyga: ok, my critical pipe is 2.36, can we somehow test the theory that its incompatible apparmor? and if incompatible, what exactly is incompatible and is there something we could revert back to?
[20:44] <zyga> yes
[20:44] <zyga> one part of the syntax is
[20:44] <zyga> I have it on screen now
[20:44] <zyga> I don't think we can revert it easily
[20:44] <zyga> it was intertwined with other work jdstrand did for docker and some other snaps
[20:45] <zyga> what we have now is rich enough to know we have old apparmor parser
[20:45] <zyga> so we might be able to offer alternative syntax
[20:45] <zyga> stay tuned
[20:45] <zyga> or
[20:45] <zyga> go get some rest
[20:45] <zyga> go get github.com/mvo5/rest
[20:46] <zyga> leap 42.3 has apparmor parser 2.10.3
[20:46] <zyga> checking 14.04
[20:47] <zyga> 14.04 has 2.10.95
[20:47] <zyga> feels like the .95 is a "backport of lots of stuff"
[20:47] <zyga> I'll check compatibility now
[20:48] <zyga> TW has 2.13
[20:49] <mvo> zyga: thank you
[20:52] <pedronis> mvo: zyga: do we have issues in 2.36 that affects only SUSE ?
[20:52] <pedronis> do we turn on apparmor by default there?
[20:53] <zyga> pedronis: it affects one suse release but it seems that there's some overlap with other distributions because the error was ignored
[20:53] <zyga> no
[20:53] <zyga> but we don't special case that in apparmor backend when  setting up core/snapd
[20:53] <zyga> we could also fix it there somewhat
[20:53] <pedronis> is this specific to snap-confine own profile?
[20:54] <zyga> yes
[20:54] <pedronis> zyga: so we did something there that breaks on some distros != ubuntu where we do use apparmor?
[20:54] <pedronis> but didn't notice because we were ignoring apparmor parsing errors?
[20:54] <zyga> yes
[20:54] <pedronis> mmh
[20:54] <pedronis> fun, not
[20:55] <zyga> not really parsing errors, we ignored all setup errors
[20:55] <zyga> with a comment saying "better to carry on"
[20:55] <zyga> I guess this goes back to the age when we had mysterious errors when snap revision was not in the state
[20:55] <zyga> and we just ignored it
[20:55] <zyga> without knowing what that ultimate cause was
[20:55] <zyga> but as I told mvo, I think that's not the full story
[20:55] <zyga> and that we are missing something
[20:56] <pedronis> zyga: in which sense?
[20:57] <zyga> I think there are two issues related to apparmor parser
[20:57] <zyga> one has a clear message that says we use unknown syntax and happens on leap 42.3
[20:57] <zyga> another has no message at all
[20:57] <zyga> and happens all over the place
[20:57] <pedronis> mmh
[20:57] <zyga> (certainly on xenial)
[20:57] <pedronis> this is related to recent changes to the snap-confine profile?
[20:57] <zyga> no
[20:58] <pedronis> since when is this broken?
[20:58] <zyga> I think ~2 months
[20:58] <pedronis> then
[20:58] <zyga> let me check
[20:58] <pedronis> also on xenial?
[20:58] <pedronis> you are saying 2.35 ... ?
[20:58] <pedronis> or just that 2.36 has been around so long?
[20:58] <zyga> I don't believe xenial parser has issues with this
[20:58] <zyga> one sec, git blame'ing
[20:59] <zyga> hmmm, no that's not right
[20:59] <zyga> it must be something else
[20:59] <zyga> the patch introducing this syntax is from 2016
[20:59] <pedronis> well you said we have two problems
[20:59] <zyga> back to the idea board
[21:00] <pedronis> zyga: anyway this sounds more and more a needs fresh brain issue, that solve it now
[21:00] <zyga> I will check the backend code now
[21:00] <zyga> yeah
[21:00] <zyga> I'm just happy we have something to look at now
[21:00] <pedronis> I would recommend to sleep on it and we talk in the morning
[21:00] <zyga> all yesterday was chasing ghosts
[21:00] <zyga> good idea
[21:00] <zyga> let's EOD
[21:00] <mvo> ok
[21:01] <zyga> see you tomorrow
[21:01] <pedronis> mvo: if it's not a regression we can decide to do 2.36 anyway
[21:01] <pedronis> mvo: sounds like too many moving parts atm
[21:01] <pedronis> mvo: we should discuss in the morning
[21:01] <zyga> pedronis: he's left now
[21:01] <pedronis> ok
[21:01] <pedronis> good either way
[21:02] <pedronis> as stand by my "needs fresh brain" "proclamation"
[21:02] <pedronis> let's chat in the morning again
[21:02] <zyga> yep
[21:02] <pedronis> s/as/I/
[21:02] <roadmr> 🧠
[21:04] <pedronis> roadmr: brain emoji?
[21:04] <roadmr> pedronis: you wanted fresh brain :)
[21:05] <pedronis> now you make me sound like a zombie, "brains" "brains"  :)
[21:05] <roadmr> there's unsurprisingly also an emoji for that :P
[21:06]  * pedronis is unsurprisingly unsurprised :)
[21:07] <roadmr> hehe
[21:10] <kyrofa> It's so tiny here, I thought it was ice cream
[21:11] <roadmr> kyrofa: oh, you mean, like: https://bit.ly/2AsL6KS ?
[21:11] <kyrofa> Haha
[21:34] <mup> PR snapd#6225 opened: tests: fix for failover test on how logs are checked <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6225>


[12:27] <Unfrgiven> \sh: hey dude
[12:31] <Unfrgiven> good morning all
[12:31] <tseng> hi
[12:33] <Unfrgiven> how are you tseng?
[12:34] <Unfrgiven> tseng: expect a intro developer doc for review sometime next week
[12:34] <tseng> Unfrgiven: yay!
[12:35] <Unfrgiven> tseng: :)
[12:35] <Unfrgiven> tseng: how are things in the mono world?
[12:36] <tseng> good
[12:36] <tseng> dajobe just sent me candy
[12:36] <Unfrgiven> ?!?
[12:37] <tseng> new muine plugins packages
[12:39] <Nafallo> dang. I thought it _was_ candy :-P
[12:40] <tseng> it is!
[12:40] <Nafallo> sounds more like bling ;-)
[12:54] <Unfrgiven> tseng: does muine have media library support like rhythmbox?
[12:54] <Unfrgiven> i find rhythmboxes library support quite sucky
[12:55] <seth_k> siretart: are you the one to talk to about universe games?
[12:58] <tseng> Unfrgiven: sortof
[12:58] <tseng> you need to see it to understand
[12:59] <Burgundavia> seth_k, I am the cheerleader for MOTUGames (but I haven't done any of the grunt work)
[01:00] <seth_k> Burgundavia, can you cheerlead for me? I've patched zSNES 1.42 and it now builds on Breezy (current version is 1.36 in Breezy and 1.40 in upstream)
[01:01] <seth_k> Burgundavia, and was wondering about getting it pushed to universe, so that jdong doesn't eat me for making a backport without the package being in breezy
[01:02] <Burgundavia> list it here
[01:02] <Burgundavia> http://www.ubuntulinux.org/wiki/MOTUNewPackages
[01:02] <Burgundavia> and then bug siretart about it
[01:03] <seth_k> that's for updated packages as well as new?
[01:03] <tseng> no
[01:03] <Burgundavia> hmm, got by our wiki again
[01:05] <seth_k> so, ermm
[01:05] <seth_k> try again :P
[01:05] <Nafallo> tseng: feel free to review to patch against etherape ;-)
[01:06] <Nafallo> tseng: only 561kB ;-)
[01:06] <tseng> etherape?
[01:06] <Nafallo> s/ape/eal/
[01:06] <tseng> yes
[01:06] <Nafallo> I'm tired ... :-P
[01:07] <Nafallo> I tried to build the damn thing against breezy multiple times *sigh*
[01:07] <Nafallo> FTBFS as a result :-P
[01:10] <seth_k> Burgundavia, do you have another idea?
[01:10] <seth_k> bug siretart directly and bypass wikipage?
[01:10] <Burgundavia> I guess so
[01:11] <seth_k> okay, I guess I'll just wait for him to come back
[01:11] <Burgundavia> the world will not end if it takes a few days
[01:12] <Burgundavia> and I am glad that jdong is cracking down
[01:12] <seth_k> oh, I'm not in any hurry
[01:29] <tseng> yay, death to zwiki
[01:38] <Burgundavia> hey tseng, I think beagle might have a small memory leak issue
[01:40] <tseng> yes?
[01:41] <Burgundavia> I actually had another program complain about lack of memory
[01:41] <Burgundavia> beagle had been running for about 1 hours
[01:41] <Burgundavia> and I walked the dog just beofre I started it
[01:42] <Burgundavia> hm, no actually, I didn't
[01:42] <tseng> well im not an elite coder type
[01:42] <tseng> i fix packaging bugs
[01:42] <tseng> that sounds like one valid to discuss with upstream
[01:42] <tseng> ill be happy to do what i can to assist you in that
[01:43] <Burgundavia> it also corrupted my terminal;
[01:43] <tseng> ok again not a packaging issue
[01:43] <Burgundavia> yes
[01:43] <tseng> so are you comfortable reporting bugs upstream?
[01:44] <tseng> i have very good sucess with this
[01:44] <Burgundavia> sure, where?
[01:44] <Burgundavia> gnome or novell?
[01:44] <tseng> gnome
[01:44] <Burgundavia> can do
[01:44] <tseng> http://beaglewiki.org/Main_Page
[01:44] <tseng> all info here
[01:45] <tseng> also #dashboard on gimpnet is available
[01:45] <tseng> thanks.
[01:51] <Burgundavia> tseng, can I start bugging you now?
[01:51] <Burgundavia>  trow has changed the topic to: www.beagle-project.org | Beagle 0.0.11 has been released!
[01:51] <tseng> damn
[01:51] <tseng> ok
[01:51] <Burgundavia> btw, nice work with all the mono stuff
[01:52] <tseng> thanks.
[01:54] <tseng> trow and joe fixed all my bugs for this release too
[02:24] <tseng> wb schweeb
[02:32] <tseng> Burgundavia: did that make any sense, before i blow him off? in #db
[02:32] <tseng> mp3 tagging + graphing + "the brain"
[02:48] <Burgundavia> the tagging tool should be part of tying beagle deeper into the desktop
[02:48] <Burgundavia> and the brain thing is just odd
[02:48] <Burgundavia> but I could see drag and drop mindmapping
[02:48] <Burgundavia> that might be cool
[02:49] <Burgundavia> no, you didn't blow him off
[02:49] <tseng> yes, im ignoring him :P
[02:49] <Burgundavia> the motus have made good progress with NewPackages recently
[02:49] <tseng> great
[02:49] <Burgundavia> so I figured I would celebrate by adding another
[02:49] <tseng> im the worst motu ever
[02:49] <Burgundavia> the man who makes Mono rock is not the worst MOTU ever
[02:50] <tseng> heh i dont contribute to group projects
[02:50] <tritium> tseng, no, I'm an awful motu right now
[02:50] <tseng> i contribute only to mono things all over the place.
[02:50] <tseng> i wonder how many packages i own now
[02:51] <tseng> mono, gtk-sharp, gtk-sharp2, gecko sharp 1, 2, gtksourceviewsharp 1,2, beagle, muine, tomboy, f-spot, evo-sharp
[02:51] <tseng> gmime-sharp
[02:51] <tseng> more im sure
[02:54] <tseng> yeah i dont see any of you on breezy-changes
[02:54] <tseng> to make an argument
[02:54] <tritium> you're right
[02:54] <tseng> i give up on koke
[02:54] <tseng> im uploading this
[02:55] <tritium> I'll get back in gear after I defend.
[02:55] <plugwash> still no freepascal binaries in universe though :(
[02:57] <|QuaD-> whooaa... just saw breezy changes, that was fast!
[02:58] <tseng> a new record?
[02:58] <|QuaD-> heh, i dunno, i just came back to my comp and saw new beagle, and then i check breezy changes, not updated
[02:58] <|QuaD-> then it is!
[02:58] <tseng> indeed
[02:58] <Burgundavia> can the Mono people promote Ubuntu, due to our speed in getting their apps into U?
[02:59] <Burgundavia> being Novell employees and all
[03:05] <|QuaD-> Burgundavia: ubuntu devs are novell employees?
[03:05] <|QuaD-> eh?
[03:05] <Burgundavia> the mono devs
[03:05] <|QuaD-> ohh, why would they awant to promote the competition?
[03:23] <tseng> |QuaD-: we arent really competition at all atm
[03:23] <tseng> we are free and dont (yet) offer commercial support
[03:23] <tseng> actually at GUADEC, someone asked miguel "when will fedora have mono"
[03:23] <tseng> he says, probably never.. just use novell. actually, dont use novell, use ubuntu
[03:24] <tseng> you can download the ogg
[03:26] <|QuaD-> haha i believe you :)
[03:27] <tseng> he sent me a stuffed monkey and a mono tshirt
[03:28] <tseng> :)
[03:28] <tseng> i <3 novell guys, they just have a crappy distro
[03:29] <|QuaD-> haha
[03:29] <|QuaD-> yeah
[03:31] <|QuaD-> i tried suse between my debian->ubuntu switch
[03:32] <|QuaD-> i lasted 2 days with suse
[03:34] <ogra> tseng, i wonder when he offers you a job ;)
[03:34] <tseng> hah
[03:34] <tseng> i doubt they woudl pay someone to do deb and not rpm
[03:34] <tseng> BenM already does all the rpms
[03:35] <ogra> tseng, but they look for people :)
[03:35] <tseng> sure.
[03:36] <ogra> and miguel knows your skills ;)
[03:54] <|QuaD-> tseng: started beagle, crashed right away
[03:55] <tseng> can you come up with something a bit more useful?
[03:55] <tseng> beagled --fg --debug
[03:55] <|QuaD-> tseng: hehe, yeah, trying to figure it out first
[03:55] <tseng> give me the exception
[03:55] <|QuaD-> address already in use.... seems can't bind to a socket
[03:55] <|QuaD-> thats my comp
[03:55] <tseng> i see
[03:55] <tseng> do you have another beagle still running
[03:55] <|QuaD-> tseng: nope
[03:56] <|QuaD-> tseng: actually, seems i have an old process
[03:56] <tseng> yes :)
[03:56] <|QuaD-> from when it crashed a while back
[03:57] <tseng> kill that off and try again
[03:57] <|QuaD-> tseng: i did, its goin
[03:58] <tseng> rock on
[03:58] <|QuaD-> how do we use the config?
[03:58] <tseng> beagle-config --help
[03:59] <tseng> its not very useful atm
[03:59] <|QuaD-> tseng: ok, thats why i don't really understand it
[03:59] <|QuaD-> couldn't figure out what it does
[03:59] <tseng> it adjusts one setting
[03:59] <|QuaD-> yeah
[04:01] <|QuaD-> tseng: you are running hula right?
[04:01] <|QuaD-> on ubuntu?
[04:01] <tseng> hrm i ran it once
[04:01] <tseng> to try it
[04:01] <|QuaD-> ahh, i wanted to know the stability
[04:01] <tseng> its stable
[04:01] <|QuaD-> it works well?
[04:01] <tseng> just lacking features/polish
[04:01] <|QuaD-> do you knwo anyone using it?
[04:01] <tseng> well my peeve is the deb i used
[04:01] <tseng> doesnt send mail to an A record
[04:02] <tseng> it dies if there is no MX
[04:02] <|QuaD-> does it do it now?
[04:02] <tseng> no idea
[04:02] <tseng> id hope they fixed it
[04:02] <|QuaD-> ohh
[04:02] <|QuaD-> i am waiting for a new hula package, ours is kinda old
[04:02] <tseng> yes
[04:05] <tseng> goodnight
[04:07] <|QuaD-> night
[05:51] <whiprush> |QuaD-: I use hula.
[05:51] <whiprush> tseng: your beagle-fu is _awesome_.
[06:09] <schweeb> tseng: hai
[08:11] <siretart> morning
[08:33] <Burgundavia> morning
[08:34] <jsgotangco> salut
[08:39] <DanielN_PD> moin
[08:41] <wm_eddie_> ohayoo gozaimasu
[08:44] <siretart> huh? what language is that? ;)
[08:44] <jsgotangco> japanese
[08:45] <siretart> ah. :)
[08:45] <wm_eddie_> I'm one of those crazy people who take Japanese.
[08:46] <wm_eddie_> It's great for making sure my GPA doesn't get too high ><
[08:47] <siretart> gpa?
[08:47] <wm_eddie_> Grade Point Average.
[08:48] <siretart> aha
[08:48] <schweeb> wm_eddie_: high school or college?
[08:48] <wm_eddie_> College.
[08:49] <schweeb> college is kind of important, hs is worthless
[08:49] <schweeb> (gpa that is)
[09:11] <ivoks> :)
[09:15] <jsgotangco> rock and roll high school :)
[09:49] <koke> hi all!
[10:07] <ivoks> hi
[10:13] <Mithrandir> tseng: about two hours and fifteen minutes?  Impressive.
[10:15] <DanielN_PD> haihai :)
[11:05] <jsgotangco> ogra, edubuntu summit?
[11:06] <ogra> jsgotangco,
[11:07] <ogra> yep
[11:07] <jsgotangco> ogra, frankly i am very much interested in edubuntu but it has escaped me for some reason, probably because i have no idea what is happening about it
[11:09] <ogra> jsgotangco, i was in bergen at the skolelinux gathering with sabdfl and JaneW last weekend and we sorted what we need and what is doable in the short timeframe we have
[11:09] <jsgotangco> ahhh now at least it has been structured a bit
[11:10] <ogra> long term target is to have something like the debian-edu packages but with less crack....
[11:10] <ogra> short term target is to have a "one classrom solution" for now....
[11:10] <jsgotangco> ok ill look on the wiki on what is in there and start writing crack for it on our svn
[11:11] <jsgotangco> ogra, the wiki, url, and list just came in as a surprise for me
[11:11] <jsgotangco> i thought it was either half-alive or half-dead
[11:11] <ogra> jsgotangco, half-alive would match it ;)
[11:11] <ogra> jsgotangco, we just didnt have a clear picture before last weekend
[11:12] <ogra> but now it comes to life more and more
[11:14] <jsgotangco> ok that's great at least its back on track i'll look in the wiki first
[11:15] <ogra> jsgotangco, feel free to add cool stuff
[11:17] <jsgotangco> ogra, i'm only good at writing crack xml so i'll add an edubuntu tree into svn
[11:17] <jsgotangco> and just post in the wiki
[11:18] <ogra> jsgotangco, i thenk we'll need a lot of docs.... and it wolud be cool to have everything in the same format (the apps are very mixed and every single one brings its documentation in its own format
[11:18] <ogra> )
[11:18] <ogra> s/thenk/think
[11:19] <jsgotangco> ogra, it actually needs a very thorough manual
[11:19] <jsgotangco> teacher/student
[11:19] <jsgotangco> hrmm
[11:19] <jsgotangco> i should start investigating
[11:19] <ogra> jsgotangco, yes :)
[11:20] <jsgotangco> ogra, count me in, i just transferred ownership of kubuntu manuals to a prospective committer and edubuntu just got in at the right time
[11:20] <ogra> yay
[11:25] <DanielN_PD> mhmh
[11:25] <DanielN_PD> some wiki stuff about edubuntu?
[11:25] <jsgotangco> www.edubuntu.org
[11:25] <DanielN_PD> thx
[11:26] <jsgotangco> its very much in flux at the moment though
[11:27] <Riddell> ogra: would you be able to review my ivman package?  http://dev.kubuntu.org.uk/~jr/kubuntu/ivman/
[11:27] <ogra> Riddell, during the day....
[11:27] <jsgotangco> Riddell, hi would you be able to review kubuntu docs when they're already up for review?
[11:27] <Riddell> jsgotangco: sure, how do I find them?
[11:28] <jsgotangco> Riddell, i'll publish them as html when they're done and send a link to you
[11:28] <Riddell> cool
[11:28] <jsgotangco> Riddell, so far kubuntu quick guide is almost done
[11:35] <jsgotangco> ogra, wee its now in our svn i'll just hack up basic doc structure tonight
[11:35] <jsgotangco> (its just folders for now but its a start)
[11:36] <ogra> yeah
[11:38] <DanielN_PD> does someone now, when the @ubuntu.com adresses are open for the common members?
[11:38] <DanielN_PD> :)
[11:38] <jsgotangco> hmmm
[11:38] <jsgotangco> i think its a forwarder for now
[11:39] <DanielN_PD> ?
[11:40] <DanielN_PD> ah it's not a whole pop3 account?
[11:40] <jsgotangco> im not so sure..ogra?
[11:42] <DanielN_PD> well, i'ts not such important, just interested me, cause it would be cool to get such an adress
[11:42] <DanielN_PD> :)
[11:43] <jsgotangco> well sabdfl has continously abused elmo on that :-) im sure it'll come soon
[11:44] <ogra> DanielN_PD, its a forwarder, yes
[11:46] <DanielN_PD> ogra: ok, and do you know something about when it's open for the normal members?
[11:46] <ogra> nope
[11:46] <DanielN_PD> oki :)
[11:46] <jsgotangco> normal members?
[11:46] <jsgotangco> you mean there are special members? hehehe
[11:47] <DanielN_PD> should talk more clean
[11:47] <DanielN_PD> :)
[11:47] <DanielN_PD> there was a thread on the list a fiew months ago. topic was, that every member recieves such an adress
[11:48] <ogra> yep, thats planned
[11:49] <ogra> but depends on the launchpad structure i guess....
[11:49] <ogra> thats why sabdfl told everyone to subscribe to the launchpad members group in the last CC meeting
[11:51] <jsgotangco> yeah i remember that right
[11:55] <jsgotangco> DanielN_PD, https://launchpad.ubuntu.com/people/ubuntumembers
[12:03] <tseng> good morning motus
[12:03] <jsgotangco> hi
[12:04] <wm_eddie_> It's about that time to go to bed.
[12:09] <mon> hi, i was wondering if there's any news about packaging the games Corey Burger mentioned in his blog. they seem pretty cool
[12:15] <tseng> Mithrandir: btw beagle has a networked mode now
[12:16] <tseng> Mithrandir: i think the security is the same as the web service.. off-by-default and then only searchs folders you allow
[12:23] <jsgotangco> bye bye
[12:27] <HostingGeek> AHHHHHHHHHHH
[12:27] <HostingGeek> this chilli is burning
[12:27] <HostingGeek> and water makes it burn more
[12:27] <HostingGeek> helopppp
[12:37] <jamessan> eat some salt
[12:44] <jbailey> I like that burning feeling.  It reminds me that I'm alive. =)
[12:53] <DanielN_PD> launchpad seems to be a very interesting project
[01:06] <koke> tseng: BTW, I'm still alive ;P
[01:06] <koke> but madly busy
[02:12] <tseng> koke: :D
[02:12] <tseng> koke: hi!
[02:25] <tseng> wow the wiki is much better
[02:44] <tseng> whiprush: ping?
[03:10] <bddebian> Good morning
[05:30] <lesliev> I have been looking at the missing .desktop file problem: to write these files, do we need to redo the package or just submit a .desktop file?
[05:30] <lesliev> https://wiki.ubuntu.com/UniversePackageWithoutDesktopFile
[05:33] <lesliev> If helping would be making a new package, what is CDBS?
[05:33] <ivoks> hm, new wiki
[05:33] <ivoks> cdbs is way of defining rules in debian/rules :)
[05:33] <ivoks> faster wiki :) better wiki :)
[05:34] <tseng> and its not ugly as hell
[05:34] <ivoks> yeah..
[05:35] <ivoks> works great
[05:35] <ivoks> one remark, tough..
[05:35] <ivoks> it doesn't return you to the page you requested
[05:35] <ivoks> after login
[05:40] <lesliev> How do you know if cdbs is used by looking at debian/control?
[05:41] <ivoks> debian/rules
[05:41] <tseng> debian/control will tell you
[05:42] <tseng> it has cdbs as a build-dep
[05:42] <ivoks> jesus... does anyone uses ISDN with linux?
[05:43] <lesliev> ok, I am looking at making a .desktop file for sopwith
[05:43] <lesliev> I see that cdbs is not being used but debhelper is in build-depends, so thats ok
[05:45] <lesliev> Now in rules, I have to make rules to install .desktop and the png icon...
[05:46] <lesliev> and put in a call to dh_desktop
[05:46] <lesliev> Do I just put dh_desktop under binary-arch?
[05:47] <lesliev> What lines do I put in to install the .desktop and the png, and where?
[05:49] <ivoks> lesliev: i did cp blabla.desktop $(curdir)/debian/blabla/usr/share/applications/
[05:49] <Mez> https://wiki.ubuntu.com/MOTUNewPackages
[05:49] <Mez> the 2REviews" section ...
[05:49] <Mez> is that for thing that ahve been done but need fixing, or for things that just need doing#
[05:51] <lesliev> ivoks: under which build target? Does it matter? I suppose 'install' is logical.
[05:51] <tseng> https://wiki.ubuntu.com/MOTUTodo is for things that need doing
[05:51] <Lathiat> yay breezy works and it didnt remove any packages:)
[05:54] <ivoks> lesliev: under build
[05:55] <ivoks> lesliev: ah, pardon, install
[05:55] <lesliev> ok, and I put the dh_desktop at the end of binary_arch
[06:48] <Lathiat> tseng: hrm, monodevelop failsto start becauseit cant find gnome-sharp in the GAC, known issue?
[06:52] <thesaltydog> is there any german mate who can help me in translating a message?
[06:58] <siretart> hi
[06:59] <littlepaul> hi siretart
[06:59] <siretart> hm, thesaltydog left a minute too early..
[07:00] <littlepaul> siretart, a wrote my statement to help him - but he left already
[07:01] <siretart> perhaps he already found someone
[07:04] <littlepaul> siretart, O.T. but i'm interested in your opinion about something that i wrote for a while
[07:04] <siretart> littlepaul: what is it?
[07:05] <ivoks> hi all
[07:05] <littlepaul> it is a text (thoughts about ubuntu) not a script ;-)
[07:05] <siretart> hi ivoks
[07:08] <siretart> littlepaul: ok, url?
[07:13] <littlepaul> siretart, i hope you got it
[07:14] <siretart> jupp
[07:21] <tseng> Lathiat: i guess its missing a dep
[07:22] <Lathiat> tseng: any idea which one so i canfind out?
[07:22] <Lathiat> libgnome-cil isinstalled
[07:22] <tseng> libgnome2.0-cil?
[07:22] <Lathiat> ah
[07:22] <Lathiat> right, no thats not installed
[07:22] <tseng> mail me about it
[08:08] <mitsuhiko> hi folks
[08:08] <ivoks> hi
[08:09] <mitsuhiko> i've found ab bug in the wiki, who do I have to contact?
[08:11] <bddebian> Hello mitsuhiko
[08:11] <mitsuhiko> hi
[08:13] <bddebian> It's a wiki, fix it.. ;-)
[08:15] <mitsuhiko> it's not a wiki page, it's the wiki itself ;)
[08:15] <mitsuhiko> http://www.ubuntulinux.org/search_form
[08:16] <mitsuhiko> when you search you can't goto an wiki page cause all links has a "/view" appended
[08:18] <bddebian> Oooohhhhhh
[08:18] <bddebian> :-)
[08:22] <binbrain> i have some newbie questions...pbuilder is used for maintaining the chroot env right
[08:23] <binbrain> you build your pacakage against the base.tar.gz
[08:23] <binbrain> why not just chroot and then build your package in there?
[08:25] <jamessan|work> because pdebuild is easier
[08:25] <jamessan|work> and it cleans up after you
[08:26] <seth_k> with pdebuild it's just one command, boom you're done and have signed packages. why not use it and save the trouble?
[08:26] <jamessan|work> ooh, you can have pdebuild sign the pacakges, too?
[08:27] <binbrain> so in practice, do you usually chroot and test the built package
[08:28] <jamessan|work> ah, so you can.  I'll have to remember that option
[08:28] <mitsuhiko> hi DanielN
[08:29] <seth_k> jamessan|work, --auto-debsign :)
[08:30] <binbrain> anyhow, I'm running hoary, I can pbuild a breezy base, build against that, and chroot to test it
[08:30] <DanielN> hi mitsuhiko
[08:30] <binbrain> is my logic correct here
[08:30] <seth_k> absolutely, i'm running breezy and have both hoary and breezy bases
[08:31] <binbrain> excellent
[08:31] <binbrain> thanks for the help
[08:32] <seth_k> so I use a line like pdebuild --auto-debsign --buildresult ../ -- --basetgz /var/cache/pbuilder/hoary.tgz
[08:32] <jamessan|work> :)
[08:33] <seth_k> :D
[08:33] <seth_k> I was told, though, that you should build a hoary chroot, then update it to breezy, rather than building a direct breezy chroot
[08:33] <seth_k> http://wiki.ubuntu.com/PBuilderHowto
[08:34] <jamessan|work> lowercase b
[08:36] <seth_k> oops, sorry
[08:37] <jamessan|work> that's ok.  there was a link from that page
[08:37] <jamessan|work> :)
[08:37] <seth_k> hmm, binbrain, guess you missed that link: http://wiki.ubuntu.com/PbuilderHowto
[08:38] <seth_k> meh, I'm really good at *just* missing siretart :)
[08:38] <seth_k> he was idle for something like 29 minutes when I arrived
[08:50] <siretart> huh? i'm here :)
[08:51] <seth_k> :O
[08:51] <seth_k> :D
[08:52] <seth_k> I have a patched zSNES package, 1.4.2 (1.3.6 is in Breezy, 1.4.0 is upstream)
[08:52] <seth_k> and I hear you're the one to talk to about Universe games
[08:52] <seth_k> and was wondering if you could look at it for me sometime
[08:52] <tseng> hm how do you mean you have 1.4.2 while 1.4.0 is upstream
[08:53] <siretart> seth_k: great :) - yes, where is your package?
[08:53] <seth_k> sorry, 1.4.0 is in Debian. 1.4.2 is the latest release, from source
[08:53] <binbrain> breezy.buildd not present, DLing from and placing into debootstrap/scripts folder
[08:54] <seth_k> siretart, http://sethkinast.com/ubuntu/breezy/zsnes/
[08:54] <seth_k> siretart, thank you much :)
[08:54] <siretart> seth_k: do you happen to know if it is c++?
[08:55] <seth_k> most of it is x86 assembly, i'm not sure if the supporting code is c++
[08:56] <siretart> ok.
[08:56] <seth_k> but it does build cleanly on a fresh chroot'd breezy, and on fresh hoary as well
[08:56] <seth_k> any quick way for me to peek and tell?
[08:57] <siretart> seth_k: your dsc is strange, it is referring to a zsnes_1.420-1ubuntu1.tar.gz
[08:58] <seth_k> o_0
[09:00] <seth_k> yes, I see that. hm, but the file I uploaded was 1.420.orig.tar.gz
[09:01] <seth_k> I took 1.400 from debian, uupdate -u on the source of 1.420, then patched the source to build. i'm not extremely familiar with that process yet so I probably mismatched something
[09:01] <siretart> seth_k: no problem. I'm just looking at it
[09:02] <siretart> seth_k: did you test your package? does it work?
[09:02] <seth_k> siretart: indeed. 2 up-to-date breezy systems
[09:02] <siretart> great! :)
[09:02] <seth_k> siretart, I also used the same source and backported it to hoary, and tested successfully on 3 hoary systems
[09:02] <seth_k> so source is surely good
[09:03] <siretart> did you happen to check your version agains the bugs listed at http://bugs.debian.org/zsnes
[09:03] <siretart> ok
[09:04] <seth_k> siretart, i did not. Shall I compare changelog to buglist?
[09:04] <siretart> seth_k: if you want to do the debian maintainer a favor, yes ;)
[09:05] <siretart> seth_k: I see that parts of zsnes are written in c++
[09:05] <seth_k> ah, and C++ is restricted right now
[09:05] <seth_k> ok
[09:05] <siretart> uploads of c++ applications are restricted for breezy
[09:05] <siretart> yepp
[09:06] <siretart> I'm checking it anyway right now, just a moment
[09:07] <herve> hello
[09:07] <bddebian> Heya herve
[09:08] <seth_k> siretart, this package closes debian bugs 293061, 309347, 301611
[09:09] <siretart> :)
[09:09] <seth_k> siretart, I believe the other three bugs are debian-specific because they are not reproducible on my system after following the steps specified
[09:09] <siretart> seth_k: ok, so, please update the changelog, stating that this package closes the given bugs, and give the it the version number 1.420-0ubuntu1
[09:10] <siretart> that way, we can adopt the debian version more easily if necessary
[09:10] <seth_k> got it
[09:10] <herve> seth_k, I haven't followed, but I hope you reported your patches to debian?
[09:10] <seth_k> while I have a smart person here, when I run "dch" my e-mail address is filled out as<EMAIL_ADDRESS>do you know offhand where to change that? ;)
[09:10] <siretart> references in the changelog of 'our' (the ubuntu package) should make it more easy for Aaron to adopt the changes
[09:11] <tseng> set DEBEMAIL
[09:11] <tseng> in bashrc
[09:11] <seth_k> ah ha, thank you sir
[09:11] <siretart> yepp, tseng is faster ;)
[09:11] <siretart> I think $EMAIL would be a fallback
[09:12] <abelli> ciao
[09:12] <siretart> hi abelli
[09:12] <abelli> siretart .. are you aware of any problem with hp pavilion's?
[09:12] <abelli> siretart: ciaaoooooo ..
[09:13] <siretart> seth_k: btw, it is zsnes_1.420.orig.tar.gz, not zsnes-1.420.orig.tar.gz ;)
[09:14] <seth_k> ;) I'll learn, if slowly
[09:14] <siretart> abelli: sorry, I'm not at linuxtag
[09:14] <seth_k> i've repackaged quite a bit of stuff, but this was my first patched app
[09:14] <siretart> seth_k: we all were beginners ;)
[09:14] <seth_k> siretart, ubuntu has the best community i've ever found
[09:14] <abelli> siretart: thx anyway.
[09:14] <seth_k> siretart, the amount of support to help people get started contributing is amazing
[09:15] <seth_k> and I thank you for that. I've been having a lot of fun
[09:15] <siretart> seth_k: are you interested in joining Motu (or espc the MOTUGames Team)? ;)
[09:15] <tseng> siretart: does he have a choice?
[09:15] <seth_k> siretart, I do not think I'm knowledgable enough yet
[09:15] <seth_k> but I would love to get deeper into helping maintain Ubuntu
[09:16] <seth_k> I've been packaging backports recently, since that's not too difficult and I know how
[09:16] <siretart> there are a lot of tasks to be done, which are not that hard to learn
[09:17] <siretart> seth_k: If you think you have something which is worth uploading, just ping me or some other MOTU in this channel to get your package reviewed. If good, we will upload it to universe
[09:18] <seth_k> siretart, I would be excited to help in whatever way I can
[09:18] <siretart> :)
[09:18] <seth_k> uploading the changed files here in a sec
[09:19] <seth_k> thank you for helping me out so readily, I was a bit nervous :P
[09:20] <herve> do you know how to unblock a stuck cursor?
[09:20] <herve> (sounds strange, I know)
[09:20] <jamessan|work> ctrl-q  ?
[09:20] <siretart> herve: random guess: CTRL-q
[09:20] <jamessan|work> heh
[09:21] <jamessan|work> maybe he didn't mean in a terminal
[09:23] <herve> silly X
[09:24] <seth_k> siretart, everything is uploaded
[09:25] <seth_k> siretart, http://sethkinast.com/ubuntu/breezy/zsnes/
[09:25] <siretart> seth_k: the diff.gz is missing
[09:26] <seth_k> heh, sorry
[09:26] <seth_k> one more second
[09:26] <siretart> oh, I see now, you accidentally turned your package to a native one
[09:26] <seth_k> >_<
[09:27] <herve> ouch!
[09:27] <jamessan|work> make sure the orig tar.gz is named as package_version.orig.tar.gz
[09:27] <jamessan|work> that's bitten me a few times
[09:28] <seth_k> okay, I think this is biting me because I both updated to new upstream, and patched. I'll symlink zsnes_1.420-0ubuntu1.orig.tar.gz to zsnes_1.420.orig.tar.gz?
[09:28] <seth_k> or is there a better way
[09:29] <siretart> no. thats not a good idea, i think
[09:29] <jamessan|work> yeah, that's what uscan usually does
[09:29] <jamessan|work> wait, you don't need the -0ubuntu1, do you?
[09:30] <seth_k> well, I made changes beyond just merging upstream source
[09:30] <siretart> dpkg-buildpackage should recognize ../zsnes_1.420.orig.tar.gz and build a non native package
[09:30] <seth_k> even though my version is -0ubuntu1?
[09:30] <siretart> seth_k: that doesn't matter. your changes will appear in the diff.gz
[09:30] <jamessan|work> seth_k: yeah, but it's the *orig* tarball, so that's not going to change
[09:30] <siretart> that doesn't matter at all
[09:30] <jamessan|work> its version is 1.420
[09:31] <jamessan|work> and will stay that no matter what rev the Ubuntu/Debian package is
[09:31] <seth_k> okay, I think I've got it now
[09:33] <seth_k> yes, this looks much better! here it comes
[09:33] <herve> DanielN, ready to sign when?
[09:33] <seth_k> apologies for the runaround
[09:33] <siretart> ah, I see a .diff.gz :)
[09:34] <seth_k> and the .dsc file is right this time around too :)
[09:34] <siretart> :)
[09:34] <seth_k> okay, upload complete
[09:36] <siretart> gnarf.. /me updates pbuilder ;)
[09:42] <siretart> seth_k: your package looks fine, I would upload it, it it wasn't the C++ freeze now
[09:43] <seth_k> i understand
[09:43] <seth_k> how long does the freeze last?
[09:43] <seth_k> since the g++ transition is done iirc
[09:43] <siretart> seth_k: as soon as every package from here is transitioned: https://wiki.ubuntu.com/UniverseCxxTransition
[09:43] <siretart> ;)
[09:44] <siretart> err https://wiki.ubuntu.com/CxxLibraryList thats the right one
[09:44] <seth_k> haha
[09:44] <seth_k> ok :) thank you for taking so much time to help me out
[09:44] <siretart> sorry, I can't give you a better date. but its our priority atm
[09:45] <siretart> you're welcome
[09:45] <siretart> thank you for your contribution!
[09:46] <seth_k> where in your opinion is the place to try to get involved right now? I'm a good repackage-monkey, at least :P
[09:46] <seth_k> or is it better to hold off right now
[09:48] <siretart> I think the best way to help us ATM would be to help with the CXX Transition
[09:48] <siretart> often it's not that hard as it sounds
[09:49] <thesaltydog> tseng, ??
[09:49] <seth_k> is that just rebuilding the stuff listed there? (if you need to get back to work, I can find somewhere else to get my questions answered)
[09:49] <tseng> thesaltydog, ??
[09:49] <thesaltydog> tseng, do you have a minute?
[09:49] <tseng> yes
[09:50] <thesaltydog> I have updated my source code, so I made a new bum_1.3.0.orig.tar.gz file
[09:50] <thesaltydog> cleaned the directory, and changed the source
[09:50] <siretart> seth_k: in principle, its just rebuilding. but you have to look at the build dependencies, rename the binary package and check the shlibs file
[09:50] <thesaltydog> why do I have such entries in diff.gz file:
[09:50] <siretart> seth_k: sometime it also involves adapting the debian/rules, but usually its not that hard
[09:51] <thesaltydog> --- bum-1.3.0.orig/debian/compat
[09:51] <thesaltydog> +++ bum-1.3.0/debian/compat
[09:51] <thesaltydog> I don't have the 7debian dir in orig file
[09:51] <siretart> seth_k: look at the descriptions above, and at some bugzilla bugs, espc the debdiffs included there
[09:51] <tseng> you arent supposed to have debian in the orig
[09:51] <tseng> its part of the diff
[09:51] <thesaltydog> in fact I don't
[09:52] <thesaltydog> so you mean that that's no problem having /debian dir entries in diff.gz?
[09:52] <tseng> thats how its supposed to be
[09:52] <siretart> thesaltydog: you needed a german before?
[09:52] <tseng> .orig.tar.gz is the source code exactly as you got it from the upstream
[09:52] <thesaltydog> oh, I believe it makes the diff quite unreadable
[09:52] <tseng> same md5 and everything
[09:52] <thesaltydog> siretart, I found him, thanks!
[09:52] <tseng> eh if you cant read the diff unpack the source and read debian/
[09:53] <siretart> ok :)
[09:53] <herve> thesaltydog, your diff.gz is telling right
[09:53] <ivoks> 'evening
[09:53] <herve> yo ivoks
[09:53] <tseng> dpkg-source -x foo.dsc
[09:53] <seth_k> siretart, I will do research then :)
[09:53] <thesaltydog> herve, thanks
[09:53] <tseng> will unpack the orig and apply the diff
[09:53] <seth_k> siretart, last question and then I will leave you alone :P
[09:53] <ivoks> with this new networkmanager, wifi-radar is obsolete
[09:53] <tseng> ivoks: it actually works?
[09:53] <seth_k> siretart, should I keep that zsnes stuff uploaded, or will you handle it from here?
[09:53] <ivoks> tseng: yeah
[09:54] <tseng> ivoks: GIMME
[09:54] <ivoks> tseng: this on i have is very very buggy
[09:54] <herve> I remember some diffs telling "--- /dev/null" for new files
[09:54] <herve> this looks more readable for me
[09:54] <tseng> ivoks: the package, or the software
[09:54] <ivoks> tseng: but i was told we can expect networkmanager next week in breezy
[09:54] <tseng> oh
[09:54] <tseng> thom++
[09:55] <thesaltydog> herve, ok. I'll keep it
[09:55] <seth_k> networkmanager *drool*
[09:55] <ivoks> ++++
[09:55] <siretart> seth_k: I have a copy here, but I will ping you again before uploading. If I forget that, please ping me ;)
[09:55] <seth_k> okay :) have a wonderful evening and thank you again!
[09:55] <siretart> +^\infinity
[09:56] <ivoks> tseng: if you still want deb...
[09:56] <siretart> seth_k: you're welcome :)
[09:56] <herve> ivoks, wifi-radar can co-exist with networkmanager
[09:56] <ivoks> herve: sure it can
[09:57] <siretart> ivoks: what wifi chipset do you use? madwifi? prism?
[09:57] <ivoks> http://people.ubuntu.com/~thom/network-manager/
[09:57] <ivoks> siretart: ipw2200
[09:57] <siretart> ah, ok. ic
[09:57] <ivoks> these are unstable, obsolete, unsuported repositorys
[09:57] <tseng> ivoks: hm do you know when that was updated
[09:57] <ivoks> do not use them
[09:57] <ivoks> tseng: ages ago :)
[09:57] <tseng> yeah
[09:58] <tseng> i used them then
[09:58] <tseng> made a few bug fixes so the thing worked at all
[09:58] <ivoks> hehe
[09:58] <ivoks> for me it works like this:
[09:59] <ivoks> notification starts (without icons) and runs untill IP is asked from DHCP
[09:59] <ivoks> then, it gets IP and crashes :)
[09:59] <tseng> http://people.redhat.com/dcbw/NetworkManager/0.4/
[09:59] <tseng> this is relatively recent
[10:00] <ivoks> yeah... rpms
[10:00] <tseng> and a tar
[10:00] <ivoks> yes
[10:00] <siretart> ivoks: does nm has wpa support already?
[10:01] <ivoks> siretart: don't know
[10:01] <ivoks> wifi-radar has :)
[10:01] <siretart> it has?!
[10:01] <ivoks> http://www.grad.hr/~ivoks/ubuntu
[10:03] <tseng> it configures
[10:03] <tseng> we'll see what happens next
[10:03] <ivoks> hm, not for me, on hoary
[10:03] <tseng> well i needed to add build-deps
[10:03] <tseng> im building the source
[10:03] <siretart> grad.hr seems to be offline
[10:03] <ivoks> siretart: yeah, power failure
[10:03] <ivoks> siretart: do you accept dcc send?
[10:04] <siretart> should work, mail preferred, but dcc is also ok
[10:04] <ivoks> my mail is offline now :(
[10:04] <ivoks>  DCC SEND request sent to siretart: wifi-radar_1.9.4-0ubuntu2_all.deb
[10:06] <herve> see you later
[10:06] <ivoks> tseng: build failed? :)
[10:06] <siretart> ivoks: did something got sent?
[10:06] <siretart> 22:06:42 [Freenode]  DCC SEND from ivoks [<IP_ADDRESS> port 32789] : wifi-radar_1.9.4-0ubuntu2_all.deb [29kB]
[10:07] <siretart> ivoks: I cannot receive from <IP_ADDRESS> ;)
[10:07] <ivoks> :))
[10:07] <ivoks> siretart: mail? :)
[10:07] <siretart> my hostmask<EMAIL_ADDRESS>[10:08] <ivoks> there it goes
[10:08] <ivoks> you got mail
[10:09] <siretart> thanks
[10:09] <ivoks> stoopid d-link's NAT
[10:15] <ivoks> siretart: is it ok?
[10:15] <siretart> ivoks: I still try to figure out what wpa modes it supports
[10:16] <siretart> I see that it has wpa support. thats great
[10:16] <siretart> does this deb work on hoary or does it need breezy?
[10:16] <ivoks> both
[10:17] <siretart> hui
[10:18] <siretart> ivoks: do you use it with wpa?
[10:19] <ivoks> no
[10:19] <ivoks> could you test it for me? :)