[09:38] <popey> on 16.04, my laptop tells me the snappy command doesn't exist anymore, and if i try to run it i get told to install snappy or ubuntu-snappy-cli - ubuntu-snappy-cli is the latest version (<IP_ADDRESS>)
[09:38] <popey> has the snappy command completely gone now?
[09:40] <davidcalle> popey: yep
[09:41] <davidcalle> popey, snappy -> snap
[09:45] <popey> ah! I see the issue
[09:46] <popey> snap install foo.snap (for sideloading) goes looking in the store.
[09:46] <popey> you have to snap install ./foo.snap
[09:46] <davidcalle> popey: indeed, on it's way to being fixed
[09:47] <davidcalle> its*
[09:48] <popey> yay
[09:57] <Gunther_> Hi everyone! May I ask the question, how to build a kernel snap if the ubuntu app store is not available and therefore the download step in the snapcraft plugins fails.
[10:01] <ogra_> Gunther_, heh, good question, i guess you would have to hack up the kernel plugin to use a local initrd.img file that you grab before building the snap
[10:01] <ogra_> sounds like a good wishlist bug :)
[10:01] <Gunther_> ogra_, I thought so ...
[10:02] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the os snaps for all arches
[10:02] <ogra_> you can either loop mount it or use unsquashfs to pull the initrd out of /boot from there
[10:03] <Gunther_> Cool. I will try to extend the kernel.py plugin with an according option
[10:04] <ogra_> you might hit bug 1569337 btw
[10:04] <ogra_> (recent initrds use lzma, the plugin hardcodes gzip)
[10:06] <Gunther_> I already patched this: https://bugs.launchpad.net/snapcraft/+bug/1569337/comments/2
[10:06] <Gunther_> but since the download fails, I cannot test iut
[10:08] <ogra_> yeah :/
[10:18] <popey> is there some magic to getting X apps to run inside a snap?
[10:18] <zyga> popey: use the 'x11' plug
[10:18] <popey> it's like it can't see the xserver, do we need to do the old export DISPLAY?
[10:18] <popey> oh, got an example zyga ?
[10:18] <zyga> popey: you shoudn't have to
[10:18] <zyga> popey: just stick this into your snapcraft.yaml
[10:18] <zyga> plugs:\n  x11:
[10:19] <zyga> and reinstall it
[10:19] <popey> okay, will try, thanks
[10:20] <popey> it doesn't like that
[10:20] <popey> argument of type 'NoneType' is not iterable
[10:21] <zyga> popey: maybe update snapcraft
[10:21] <zyga> popey: that's the right syntax
[10:21] <zyga> (this should be reported to sergio)
[10:21] <popey> i have 2.7
[10:36] <Gunther_> ogra_: thanks for your help, my prototype kernel.py with local os.snap seems to work
[10:39] <popey> zyga: odd, I can find no reference to x11 in the snapcraft source I just pulled from github
[10:39] <zyga> popey: it's a bug, it seems that the validator tries to iterate over None
[10:40] <zyga> popey: foo: (with the colon at the end) is an empty collection but it sesems it gets parsed to None
[10:40] <zyga> popey: you can try plugs:\n x11:\  interface x11
[10:40] <zyga> sergiusens: ^^
[10:40] <zyga> popey: mind the spaces (precisely)
[10:42] <popey> Issues while validating snapcraft.yaml: The 'x11' property does not match the required schema: 'interface x11' is not valid under any of the given schemas
[10:42] <popey> http://paste.ubuntu.com/15807938/ is my yaml
[10:44] <sergiusens> zyga, popey I haven't released the latest snapcraft yet; I am still waiting for a good snapd binary that works with https://github.com/ubuntu-core/snappy/pull/910 for our examples tests to pass
[10:44] <zyga> sergiusens: I see
[10:44] <sergiusens> this branch isn't merged yet https://github.com/ubuntu-core/snapcraft/pull/441
[10:44] <popey> ok
[10:44] <popey> thanks
[10:45] <sergiusens> I tried to manually test locally and it still doesn't work (given snapd in the archive doesn't work either)
[10:51] <zyga> sergiusens: what were the failures?
[10:56] <sergiusens> zyga, the one you fixed last night
[10:57] <sergiusens> zyga, I also don't have replacement logic for `snappy services`
[10:57] <zyga> sergiusens: that's rm -rf'd now
[10:57] <zyga> sergiusens: it's coming back after a redesign after release
[10:57] <zyga> sergiusens: how does snapcraft uses it?
[10:57] <sergiusens> zyga, so I don't know how to see the failures if services started or not
[10:57] <sergiusens> zyga, to see if our services started
[10:58] <sergiusens> zyga, how can I see this from the desktop for a service running inside snappy?
[10:58] <sergiusens> systemctl doesn't cut it
[10:58] <zyga> sergiusens: you'd have to use systemd yourself :/
[10:58] <sergiusens> or please upload a new ubuntu core to the store
[10:59] <sergiusens> zyga, yeah, systemctl from desktop does not list things in ubuntu-core
[10:59] <zyga> sergiusens: why is systemctl not sufficient? AFAIR that's what we used internally
[10:59] <sergiusens> so tell me how to call it
[10:59] <zyga> hmm?
[10:59]  * zyga doesn't understand something
[10:59] <zyga> are we talking about cross-host testing?
[11:02] <sergiusens> zyga, no
[11:02] <sergiusens> if you try what i say you will see
[11:03]  * sergiusens starts babysitting hour
[11:07] <Gunther_> Hmmm is it possible to build a kernel.snap from a binary linux-image-xxx.deb package?
[11:08] <ogra_> yes, it is, but you need to do it maunually
[11:09] <Gunther_> I understand
[11:10] <kyrofa_> Good morning
[11:11] <ogra_> Gunther_, line 370-595 ... http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build (that does tarballs alongside though)
[11:11] <ogra_> you can do it withour a chroot by simply using "dpkg -x" to unpack the deb and manually create a snap.yaml and meta dir
[11:49] <Mikaela> When and how will I be able to install snaps on normal Xenial? https://insights.ubuntu.com/2016/04/13/snaps-for-classic-ubuntu forgets to mention it.
[11:50] <kyrofa_> Mikaela, by the time it's released, I'd say
[11:51] <Mikaela> I see, thanks
[11:51] <ogra_> shouldnt that work already ?
[11:51]  * ogra_ thought all bits are in place with mvo's latest landings
[11:53] <ogra_> sergiusens, your latest G+ post is private
[12:04] <mvo> Mikaela, ogra_ it is possible today :) we just don't have a lot in the store yet
[12:05] <Mikaela> nice, does it come by itself or should I install some package?
[12:06] <zyga> Mikaela: just wait a few days or apt-get install snapd
[12:06] <zyga> Mikaela: we're still making improvements
[12:06] <Mikaela> ok
[12:09] <ogra_> zyga, ubuntu-snappy-cli rather ;)
[12:10] <sergiusens> ogra_, yeah, not sure why that is the default now
[12:10] <ogra_> (that is what also was seeded recently)
[12:10] <zyga> ogra_: no? it was renamed to snapd
[12:11] <sergiusens> ogra_, mvo jdstrand btw, don't we want to rename the ubuntu-core-launcher package to snap-launcher?
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy desktop
[12:12] <ogra_>  * (ubuntu-snappy-cli)
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy server
[12:12] <ogra_>  * (ubuntu-snappy-cli)
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$
[12:12] <ogra_> zyga, ^^^
[12:12] <ogra_> (it depends on snapd though)
[12:12] <ogra_> sergiusens, you have 8 days :P
[12:13] <zyga> hmm, I wonder what's the point of both packages
[12:13] <zyga> one still ships some directories
[12:14] <ogra_> well, if we want top rename we need to do it now ... there is no way to change the seeds after release
[12:14] <ogra_> (except by hacking meta packages directly and getting them out of sync with the world)
[12:16] <ogra_> mvo, infinioty uploaded a new livecd-rootfs ... do you need any of the changes from the PPA version ? (they will be overridden for the next image build)
[12:16] <dpm> so dholbach, popey, davidcalle, just read the omgubuntu article, captures snaps on the desktop pretty accurately and nicely :)
[12:19] <popey> yeah, i sent him a tweet. he was worried it was all over the place and untidy, i reassured him that he'd "got" it
[12:20] <popey> also, sa bdfl shared it, so it must be fine ㋛
[12:21] <dpm> popey, indeed, I think it's really good
[12:22] <dpm> dholbach, davidcalle, so as I said on the e-mail the /desktop page is published, but I've held off to publishing the subpages until the examples work
[12:24] <dholbach> dpm, sounds good
[12:24] <dholbach> dpm, yeah, it's a nice article
[12:24] <dpm> dholbach, just going through your e-mails now
[12:26] <niemeyer> zyga, jdstrand: Can we merge https://github.com/ubuntu-core/snappy/pull/802?
[12:27] <niemeyer> The idea is getting interfaces in very quickly when necessary, or rejecting them.. we cannot leave these reviews hanging around
[12:27]  * sergiusens migrates to coffee shop to re supply
[12:28] <Gunther_> Another silly question (just because looking at kernel builds is sooo boring). Is it possible to extend an existing kernel.snap with a custom kernel module? In this case a device driver for a pci measument board.
[12:28] <Gunther_> The sources for the driver are available but they are not part of the linux kernel
[12:29] <dpm> dholbach, what's the new LP team you created again?
[12:32] <jdstrand> niemeyer: I had not been looking at that very closely since my first review because interfaces code wasn't working yet and I didn't quite know how things were changing
[12:33] <jdstrand> but I can take another look
[12:33] <jdstrand> (ie, there was no way to test it)
[12:36] <jdstrand> zyga: are interfaces supposed to be autoconnecting with snapd that is in xenial now?
[12:38] <jdstrand> zyga: cause focuswriter from the desktop examples is not getting unity7 autoconnected. dholbach's doc on desktop examples also seems to have things that are not autoconnecting
[12:38] <dholbach> dpm, ~snappers
[12:38] <dpm> cool, thanks
[12:38] <zyga> jdstrand: I haven't tried packaged snapd today.
[12:39] <zyga> jdstrand: autoconnection is merged but I'm not sure when the release was cut
[12:39] <zyga> jdstrand: we're aiming for one more release today
[12:39] <zyga> jdstrand: with full control over connect/disconnect
[12:39] <jdstrand> it says '19 hours' ago
[12:40]  * zyga tries focuswriter
[12:41] <dholbach> mvo said he'd do an upload soon
[12:41] <jdstrand> I see
[12:42] <dpm> JamesTait, on bug 1555569, is this now supposed to be fixed on the store side?
[12:42] <jdstrand> zyga: if I do: 'snap interfaces', all I see is 'slot plug'. how do I connect things? (even if that is in the pending upload)
[12:42] <zyga> jdstrand: snap connect
[12:42] <zyga> jdstrand: snap disconnect
[12:42] <zyga> jdstrand: and snap interfaces
[12:42] <zyga> jdstrand: that's broken today (it has little effect)
[12:43] <zyga> jdstrand: it doesn't setup security of anything yet
[12:44] <jdstrand> zyga: so I (will) need to specify both the plug and the slot for each connection?
[12:44] <zyga> jdstrand: see --help
[12:44] <zyga> there are some shortcuts
[12:44] <zyga> jdstrand: some may not fully work but some do
[12:44] <jdstrand> ah, --help
[12:44] <zyga> jdstrand: I'll polish that and get it to spec with the first SRU release
[12:44] <jdstrand> I tried 'help' and '-h'
[12:44] <JamesTait> dpm, I don't actually know what the current state of that is - the summary field from the manifest will be surfaced directly in the API, so it won't be used as title.
[12:45] <JamesTait> dpm, nessita would probably be your best bet.
[12:45] <dpm> thanks JamesTait
[12:45] <jdstrand> zyga: is 'snap interfaces' supposed to list available interfaces or just connected interfaces?
[12:46] <zyga> jdstrand: available and connected
[12:46] <zyga> jdstrand: what do you see?
[12:46] <zyga> jdstrand: you have to snap install ubuntu-core
[12:46] <jdstrand> I literally see 'slot plug'
[12:46] <zyga> jdstrand: (it is not auto installed yet)
[12:46] <jdstrand> that is it
[12:46] <zyga> jdstrand: UX could be improved there :-)
[12:46] <jdstrand> $ sudo snap interfaces
[12:46] <jdstrand> slot plug
[12:47] <jdstrand> $
[12:47] <jdstrand> zyga: I have ubuntu-core installed
[12:47] <jdstrand> $ snap list
[12:47] <jdstrand> Name         Version    Developer
[12:47] <jdstrand> focuswriter  0.1        sideload
[12:47] <jdstrand> ubuntu-core  16.04.0-24 canonicalubuntu-core  16.04.0-24 canonical
[12:47] <zyga> jdstrand: can you restart snapd?
[12:47] <jdstrand> whoops, that pasted twice
[12:48] <jdstrand> sudo systemctl restart snapd?
[12:48] <zyga> jdstrand: anyway; that part still needs love
[12:48] <zyga> jdstrand: yep
[12:48] <jdstrand> $ sudo snap interfaces
[12:48] <jdstrand> slot plug
[12:48] <mvo> zyga: there is a git tag for 1.9.1 if you want to double check what went in and what did not
[12:48] <zyga> mvo: thanks, good idea
[12:48] <mvo> dholbach: there will be one today, maybe even two, I ask in the standup
[12:49] <zyga> jdstrand: ok, the version you have doesn't have the REST API wired to anything
[12:49] <jdstrand> that would explain that
[12:49] <zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
[12:49]  * zyga focuses on finishing this last essential bit
[12:50] <jdstrand> zyga: is that repo going to be in mvo's upload?
[12:50] <zyga> jdstrand: yes, that has landed since
[12:50] <zyga> jdstrand: but connect/disconnect working hasn't
[12:50] <zyga> (I'm still hacking on it)
[12:50]  * jdstrand notes that he is being asked about this stuff a lot (not sure why they aren't asking here, but, there you go...)
[12:50] <zyga> jdstrand: no worries :-)
[12:51] <dholbach> mvo, go go go!
[12:51] <jdstrand> zyga: what repo should I be looking at? I need to fix confinement for a few things
[12:51] <nessita> dpm, hi!
[12:51] <jdstrand> and testing the desktop snap examples, etc, etc
[12:52] <nessita> dpm, about the title and summary, there is a thread that summaries all the details, let me get you the details
[12:52] <dpm> nessita, I'm on that thread
[12:52] <dpm> nessita, but I was wondering if the bug report needs updating
[12:52] <dpm> as by the status of it it seems no one is working on it, which from the mailing list thread, you guys are
[12:54] <nessita> dpm, have the link handy?
[12:54] <dpm> nessita, sure -> https://launchpad.net/bugs/1555569
[12:55] <oly> hi, i have just been trying out snappy for apps everything went well until i uploaded a snap
[12:55] <oly> package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks
[12:55] <nessita> dpm, basically summary is that we have completed the work on summary/description, and for title we are now using the snap name "moon-buggy", until snapcraft and snap grow capabilities for defining a Title section
[12:56] <oly> any ideas what i can do with that error ? this is a very basic python app with one dependancy on python-gi
[12:56] <zyga> jdstrand: hmm repo?
[12:56] <jdstrand> zyga: I used your word
[12:56] <zyga> jdstrand: you can just build snapd locally yourself
[12:56] <jdstrand> 07:49 < zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
[12:56] <zyga> jdstrand: (interfaces.Repository is an internal code construct)
[12:56] <oly> also can i try and run snaps locally in a VM
[12:56] <zyga> jdstrand: use snapd from master from now
[12:56] <zyga> jdstrand: that will show you what's connected
[12:56] <jdstrand> zyga: ok, that's fine
[12:56] <zyga> jdstrand: won't let you conenct yet
[12:57] <zyga> jdstrand: you can always look at /var/lib/snapd/{apparmor,seccomp}/profiles to see what's "live"
[12:57] <jdstrand> zyga: ah, master is what I was looking for. I thought you meant some other fork/branch
[12:58] <jdstrand> zyga: well, I can manually edit /var/lib/snapd/{apparmor,seccomp}/profiles if I have to. I was trying to get a picture of how stuff works for myself, devs, etc
[12:58] <jdstrand> I guess that will have to wait a bit longer
[13:03] <vances> Q: What is the proper method to enable IP forwarding?  I did 'sudo mount -o remount,rw /' and edited '/etc/sysctl.conf' to set 'net.ipv4.ip_forward = 1'.
[13:04] <zyga> vances: hmm interesting question, you can have a snap that just toggles the /proc filesystem directly
[13:04] <zyga> vances: it would have to use one of the interfaces that allow that
[13:06] <vances> Although the above method gets the kernel parameter set after a reboot it still doesn't seem to forward IP between interfaces.
[13:06] <vances> Routing table looks fine.
[13:07] <vances> iptables is all ACCEPT
[13:07] <vances> Is there some additional security I need to deal with?
[13:10] <Mikaela> minor bug: /etc/profile.d/apps-bin-path.sh comment talks about /snaps/bin when in reality it uses /snap/bin and /snaps doesn't even exist. Should I report this or see if it's already reported or is mentioning here enough?
[13:10] <zyga> Mikaela: yes, please report it
[13:11] <Mikaela> ok, doesn't seem to be reported at https://bugs.launchpad.net/ubuntu/+source/snapd
[13:11] <zyga> vances: I'm sorry I cannot help you today
[13:11] <davidcalle> dpm: thanks for updating the /desktop page, I've pushed the new /snappy one out as well today
[13:11] <davidcalle> dpm: with great difficulty if you've seen my email
[13:14] <ysionneau> sergiusens hi! Any idea about my udf issue? https://lists.ubuntu.com/archives/snappy-devel/2016-March/001668.html
[13:14] <Mikaela> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1569892
[13:18] <dpm> davidcalle, I've seen it, good work!
[13:19] <jdstrand> dholbach: hi! B5 in your known issues should not be green as of this second.
[13:19] <jdstrand> dholbach: that is what I was just discussing with zyga
[13:19] <dpm> davidcalle, the db issue seems to be a bit of a concern. We might as well talk to upstream about it
[13:19] <Mikaela> also nmap complained about `can not find a snappy os` until I installed `ubuntu-core`, not sure how I should report it, but I assume that is known issue?
[13:19] <dholbach> jdstrand, is this a fix which landed somewhere?
[13:20] <jdstrand> dholbach: they said autoconect landed in master
[13:20] <jdstrand> dholbach: but it isn't in the archive yet
[13:20] <dholbach> ok
[13:20] <dholbach> I'll note that down then
[13:20] <dholbach> zyga, which PR was this?
[13:20] <zyga> dholbach: fix for what?
[13:20] <ogra_> Mikaela, hmm, that is supposed to happen autonmatically
[13:20] <ogra_> mvo, isnt it ? ^^^
[13:20] <Mikaela> it seems it didn't for me for some reason
[13:20] <dholbach> zyga, autoconnect
[13:21] <zyga> dholbach: I don't really remember but it was merged in 1.9.1
[13:21] <dholbach> oh...
[13:21] <dholbach> jdstrand, just said that it's in master but not in the archive yet
[13:21] <dholbach> or was it a fix for autoconnect?
[13:21] <zyga> dholbach: no, that's not the same
[13:21] <zyga> dholbach: that's connection visibility
[13:21] <ogra_> Mikaela, well, "supposed" ... i'm not sure it is there yet
[13:21] <zyga> ogra_: its not
[13:21] <davidcalle> dpm: we have a few ideas of things to try before going upstream, I'd also like Robin's advice
[13:21] <jdstrand> oh, sorry I misunderstood
[13:22] <ogra_> technically your first "snap install" should install ubuntu-core ahead of anything else
[13:22] <dholbach> zyga, jdstrand: can we add a line for this then, so we can track it separately?
[13:22] <jdstrand> dholbach, zyga: I can say 100% certain autoconnect is not in 1.9.1
[13:22] <dholbach> I'm losing track :)
[13:22] <zyga> jdstrand: hmmmmmm
[13:22] <zyga> jdstrand: and master?
[13:22] <jdstrand> zyga: unity7 is suppoosed to autoconnect?
[13:22]  * zyga cares less about 1.91
[13:22] <jdstrand> let me uninstall and install
[13:23] <zyga> jdstrand: yes
[13:23] <dholbach> can we file a bug for what exactly is not working right now and track it there?
[13:23] <zyga> dholbach: many things are not working
[13:23] <dholbach> zyga, one example we look at together :)
[13:23] <zyga> dholbach: filing abug before i'm done is not useful yet
[13:23] <zyga> dholbach: wait until today evening
[13:24] <dholbach> ok... it's just that jdstrand asked for the list of known issues to be updated and I couldn't quite figure out what exactly had changed
[13:24] <jdstrand> dholbach: I think it is sufficient to say it is not fixed in <IP_ADDRESS>
[13:24] <dholbach> ok
[13:24] <jdstrand> I don't want to distract zyga
[13:25] <jdstrand> I just want the spreadsheet to reflect reality :)
[13:25] <jdstrand> cd
[13:25] <dholbach> wfm! :)
[13:25] <jdstrand> cd meh
[13:25] <jdstrand> heh
[13:25] <jdstrand> that kinda summarizes how I feel (cd meh :)
[13:25]  * dholbach hugs jdstrand
[13:25]  * jdstrand steps away for a moment
[13:26]  * jdstrand hugs dholbach :)
[13:46] <Mikaela> where can I find the bug reports for specific snaps? /snap/bin/tmux returns "Bad system call" and /snap/bin/nmap is unable to resolve localhost or ping <IP_ADDRESS> "Socket creation in sendConnectScanProbe: Permission denied (13)". I think they are known, but I would like to follow their statuses and cannot wait for snappy to become production ready (nmap and tmux there already report being newer versions than
[13:46] <Mikaela> the Xenial repo ones)
[13:49] <ogra_> Mikaela, yxou can contact the author https://uappexplorer.com/app/nmap.joetalbott (see the "support" tab)
[13:50] <ogra_> (same goes for https://uappexplorer.com/app/tmux.shawn111 )
[13:50] <beuno_> josepht, you have a fan!
[13:50] <beuno> shawnwang, so do you
[13:50] <ogra_> it is up to the snap creator to provide a bug url in the store data
[13:50] <jdstrand> dholbach: fyi, apparmor 2.10.95-0ubuntu2 is out of proposed and should fix policy loads on reboot
[13:50] <ogra_> if they didnt, direct mail is the best bet
[13:50] <Mikaela> I see
[13:51] <ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy is pretty helpful until the store has a proper web ui on its own
[13:52] <Mikaela> I think it's probably enough that the authors were pinged on IRC :)
[13:52] <josepht> Mikaela: I'll take a look at nmap.
[13:52] <josepht> Mikaela: is that the armhf or amd64 version?
[13:52] <shawnwang> Mikaela, thanks, let me check it
[13:53] <Mikaela> amd64
[13:53]  * ogra_ assumes the security system simply changed underneath them ...
[13:56] <josepht> Mikaela: can you give me a paste of 'snappy list -v' please?
[13:56] <ogra_> josepht, no more "snappy"
[13:56] <ogra_> it is "snap" now
[13:56] <Mikaela> josepht: snap says "error: unknown flag `v'"
[13:57] <ogra_> (everything changed within the last week)
[13:57] <Mikaela> ah, so that is why everyone talks about snappy :)
[13:57] <ogra_> yeah :)
[13:57] <josepht> ogra_: did that change not come as an update?
[13:57] <ogra_> it did
[13:58] <shawnwang> Mikaela, SNAP=/snaps/tmux.sideload/current /snaps/tmux.sideload/current/command-tmux.wrapper
[13:58] <dholbach> jdstrand, excelltn
[13:59] <dholbach> jdstrand, hum... not on archive.u.c yet?
[13:59] <shawnwang> Mikaela, you can try this to avoid the launcher issue
[14:00] <Mikaela> shawnwang: zsh: tiedostoa tai hakemistoa ei ole: /snaps/tmux.sideload/current/command-tmux.wrapper
[14:00] <Mikaela> (file or directory does not exist)
[14:02] <shawnwang> Mikaela, SNAP=/snaps/tmux.shawn111/current /snaps/tmux.shawn111/current/command-tmux.wrapper
[14:02] <shawnwang> Mikaela, sorry, wrong path
[14:03] <Mikaela>  shawnwang same error even when I correct /snaps to /snap
[14:03] <jdstrand> dholbach: it is getting there: https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2
[14:03] <jdstrand> probably just need a publisher run
[14:03] <sborovkov> Hello. I am on snappy on RPI 3. With latest kernel and os snap. Previously I could install snap with this command snappy install screenly-....snap to install from file. Now that does not work. can someone tell me how I can install snap from local file now?
[14:04] <dholbach> jdstrand, cool
[14:04] <Mikaela> shawnwang: I am on Ubuntu Classic (MATE) 16.04 amd64, in case that wasn't clear and you are giving me instructions for some other platform
[14:04] <shawnwang> Mikaela, yes... I run it on Ubuntu Classic 16.04 amd64
[14:05] <Mikaela> shawnwang: is it possible that you could be missing some updates?
[14:06] <shawnwang> Mikaela, you still got "Bad system call"?
[14:06] <ogra_> sborovkov, use "snap install"
[14:06] <ogra_> the "snappy" command is gone
[14:06] <sborovkov> ogra_: I did. When I pass filename, it says snap not found
[14:06] <sborovkov> When I gave it full path it returned this error
[14:06] <Mikaela> shawnwang: with your commands I get "no such file or directory", if I run /snap/bin/tmux directly I get the bad system call
[14:07] <sborovkov> error: unable to find task with id "52c91e31-7113-26bb-1804-5980e7d74de1
[14:07] <Mikaela> shawnwang: I don't have /snaps and in /snap I see directories: bin  nmap  tmux  ubuntu-core
[14:09] <shawnwang> Mikaela, apt-cache policy ubuntu-snappy, maybe we use different version of ubuntu-snappy
[14:09] <mvo> Mikaela: if you freshly installed snapd then the $PATH is not quite correct, needs a one time login. the bad systemscall is probably because the tmux does not quite have the right security profile yet
[14:09] <mvo> Mikaela: dmesg also often has some useful information
[14:10] <Mikaela> shawnwang: if you mean snapd <IP_ADDRESS>
[14:10]  * Mikaela reboots to see if that changes anything
[14:10] <ogra_> shawnwang, ubuntu-snappy-cli ... you do not want ubuntu-snappy installed
[14:10] <ogra_> (it was a mistake that it was seeded initially, remove it if you have it)
[14:11] <shawnwang> ogra_, Mikaela, let me upgrade my ubuntu-snappy-cli
[14:13] <Mikaela> After reboot /snap/bin/tmux and /snap/bin/nmap throw me `aa_change_onexec failed with -1. errmsg: No such file or directory`
[14:15] <shawnwang> Mikaela, could you try SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
[14:16] <Mikaela> shawnwang: works, except that it has decided that my tmux.conf has unknown option utf8 twice
[14:17] <shawnwang> Mikaela, nice
[14:17] <Mikaela> set -g utf8 & set-window-option -g utf8 on ==> I guess that if new tmux says that these options don't exist, I am just going to remove them from my tmux.conf
[14:17] <shawnwang> Mikaela, https://github.com/shawn111/tmux.snap/blob/master/snapcraft.yaml
[14:18] <shawnwang> Mikaela, here is my snapcraft.yaml
[14:18] <Mikaela> shawnwang: I fear I don't understand that as I am not a developer
[14:19] <niemeyer> jdstrand: About the bluez interface, understood.. I'm just concerned about introducing a streamlined way to introduce new interfaces
[14:19] <niemeyer> jdstrand: This is a major blocker for anyone trying to use snappy, so we need to be agile handling such requests
[14:20] <shawnwang> Mikaela, maybe I missing some config
[14:20] <niemeyer> jdstrand: It's better to introduce something basic and the polish it, than to block for an undetermined amount of time
[14:24] <shawnwang> ogra_, is it a right way to call snap command? like SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
[14:25] <shawnwang> ogra_, or, should I use /snap/bin/tmux directly?
[14:27] <zyga> dholbach: what's that snap I should try to instal
[14:27] <zyga> dholbach: I have a branch locally, I'd like to test any desktop snaps you can give me
[14:28] <dholbach> zyga, I don't know which problem you solved and which might be working now... jdstrand?
[14:28] <ogra_> shawnwang, no idea, i never run them directly since that breaks :)
[14:28] <zyga> dholbach: anything you have
[14:28] <ogra_> you need the env the ubuntu-core-launcher sets up
[14:28] <dholbach> zyga, jstrand: focuswriter from lp:snappy-desktop-examples?
[14:29] <shawnwang> ogra_, yep, like mvo mention I might miss security profile
[14:29] <zyga> dholbach: k, I'll try
[14:30] <zyga> FYI: I fixed a few bugs that would be breaking stuff earlier
[14:31] <jdstrand> niemeyer: I totally agree and we'll get there
[14:41] <jdstrand> zyga: fyi, someone mentioned you recommended modifying files to not use the launcher to work around lack of unconfined and/or developer mode. I suggest instead modifying the apparmor profile to be in complain mode and the seccomp profile.
[14:41] <josepht> I see the same issue as sborovkov when sideloading a snap or trying to install a snap from the store (ubuntu-core in this case)
[14:42] <ogra_> joyeah, seems sideloading is gone atm ...
[14:42] <zyga> jdstrand: snappy will refresh those profiles
[14:42] <ogra_> josepht, ^^^
[14:42] <zyga> jdstrand: won't refresh the wrappers
[14:42] <zyga> ogra_: sideloading is not gone, should work okay
[14:42] <ogra_> josepht, there is supposed to be a --developer-mode option to the install command ...
[14:42] <ogra_> but thats not there yet
[14:42] <ogra_> zyga, how
[14:43] <zyga> ogra_: yep, it's not there yet :/
[14:43] <zyga> (but just UX issue)
[14:43] <ogra_> :)
[14:43] <zyga> ogra_: snap instal ./path/to/some/snap.snap
[14:43] <josepht> ogra_: same happens with a store snap
[14:43] <ogra_> oh
[14:43] <ogra_> that sounds rather like a bug :)
[15:09]  * zyga has a still-crazy branch that is relatively stable for controling interfaces
[15:09] <zyga> dholbach: none of the snaps work though
[15:09] <zyga> dholbach: only cap-test
[15:09] <zyga> dholbach: I tried scummvm with home plug connected
[15:10] <zyga> dholbach: focuswriter starts but nothing shows up
[15:10] <zyga> (it doesn't crash, just has no windows)
[15:10] <dholbach> :-/
[15:11] <zyga> although...
[15:11] <zyga> kwi 13 17:10:42 zyga-thinkpad-w510 audit[11161]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=11161 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7f0edad24e2a code=0x0
[15:11] <zyga> jdstrand: ^^ is that a seccomp denial?
[15:11] <ogra_> yes
[15:12] <zyga> dholbach: ^^ fix that and maybe it will run
[15:12] <zyga> that looks like getsockopt
[15:12] <zyga> missing network plug?
[15:13] <dholbach> zyga, how?
[15:13] <zyga> dholbach: identify why that syscall is not allowed, put it in an interface
[15:13]  * zyga tries with network
[15:17] <jdstrand> zyga: yes
[15:17] <jdstrand> on amd64:
[15:17] <jdstrand> $ scmp_sys_resolver 55
[15:17] <jdstrand> getsockopt
[15:18] <jdstrand> (you need to run scmp_sys_resolver on the target arch so if not amd64, run it on the device)
[15:19] <elopio> ogra_: the job that takes the os snap from cdimage is ready, triggered when the snap changes. But there are a couple of problems. The upload fails a lot because of the store, so I have to retry it like 4 times. And once it's uploaded it needs a manual review to go into the edge channel.
[15:19] <jdstrand> zyga: mvo mentioned getsockopt is needed for nvidia systems. see the thread I just responded to
[15:19] <zyga> ah
[15:19] <zyga> I have an nvidia GPU here
[15:20] <jdstrand> there you go
[15:20] <elopio> everything we could automate is already automated. So I'll be dealing daily with the manual parts for now.
[15:20] <jdstrand> you may have some other issues
[15:20] <jdstrand> (again, see thread)
[15:22] <ysionneau> hmm zyga here I get Apr 13 15:21:21 localhost kernel: [ 6322.540900] audit: type=1326 audit(1460560881.937:63): auid=1000 uid=1000 gid=1000 ses=1 pid=2081 comm="ld-linux-armhf." exe="/snaps/libshdata.sideload/LWKbJCCgHVhJ/lib/ld-linux-armhf.so.3" sig=31 arch=40000028 syscall=289 compat=0 ip=0x76ef44d6 code=0x0
[15:22] <ysionneau> is it seccomp denial?
[15:23] <ysionneau> (I'm on RPI2)
[15:23] <ysionneau> it's written audit...
[15:23] <zyga> maybe
[15:23] <ysionneau> and in the user space console logs I get 'bad syscall'
[15:23] <ysionneau> 289 is "send"
[15:23] <ysionneau> although, I've put syscalls: [send] + network-client/network-listener/network-service caps
[15:27] <zyga> ysionneau: that's not supported
[15:27] <zyga> ysionneau: that's old-security
[15:27] <zyga> ysionneau: you need plugs: [network]
[15:27] <zyga> ysionneau: or plugs: [network, network-bind]
[15:32] <ysionneau> oh, old-security isn't supported anymore?
[15:32] <ysionneau> I can still see them in the snapcraft/examples
[15:41] <pmp> hi, I'm using snappy on raspi2
[15:42] <pmp> following a snappy update yesterday it refused to boot on the newly installed kernel (4.4.0xxx vs 4.3.0)
[15:43] <pmp> this was a nice way to see snappy working well, when a kernel update has failed
[15:43] <pmp> is this expected behaviour
[15:43] <pmp> I mean the new kernel not working well?
[15:44] <pmp> It stops right after "uncompressing kernel"
[15:49] <ogra_> pmp, is that a 16.04 image ?
[15:49] <pmp> yes
[15:50] <ogra_> (it needs an updated gadget snap too, could be that your old snappy is not capable of updating that yet)
[15:50] <ogra_> so either roll back, or re-flash
[15:50] <ssweeny> zyga, hate to be a pest but is there an ETA for review of my bluez PR?
[15:50] <ogra_> snappy uis still changeing a lot ... especially the images
[15:50] <zyga> ssweeny: today
[15:50] <ssweeny> zyga, awesome :)
[15:51] <zyga> ssweeny: sorry, fighting one last fire
[15:51] <pmp> ogra_: the roll-back is done automatically, but after each boot it tries to update
[15:51] <ssweeny> zyga, no worries. just getting queries from my team since we finish a sprint today
[15:52] <pmp> ogra_: my original image dates from I'd say 4 weeks ago, is that too old?
[15:52] <ogra_> yeah, snappy was nearly completely re-done (once again) and the big changes only landed last week or are still in flux
[15:53] <pmp> ogra_: iirc I grabbed the udf from ~mvo somewhere, is that still the right place to fetch the image for rpi2?
[15:53] <ogra_> i'd actually build my own, i dont think mvo  had the time to update them
[15:54] <ogra_> but yes, you need the latest u-d-f from his dir
[15:54] <pmp> ogra_: yes that scary part: downloading a 11MB binary from somewhere and execute it
[15:54]  * pmp is fearless
[15:55] <pmp> ogra_: thx for the hint
[15:55] <ogra_> mvo is a totally trustworthy person though ... (you will notice he only takes so much from your bank account after you ran his binaries)
[15:55] <ogra_> ;)
[15:59] <zyga> zyga@zyga-thinkpad-w510:~/work/src/github.com/ubuntu-core/snappy/cmd/snap$ focuswriter.run
[15:59] <zyga> Qt: Session management error: None of the authentication protocols specified are supported
[15:59] <zyga> dholbach: ^ focuswriter
[15:59] <zyga> dholbach: closer but no idea what's next
[16:00] <zyga> kwi 13 17:59:22 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1460563162.514:194): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=25780 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=49 compat=0 ip=0x7f983a472d37 code=0x0
[16:00] <ogra_> moar syscalls .... yay
[16:03] <zyga> sys_shmctl
[16:03] <davidcalle> mvo: ogra_ zyga, is snappy-remote still a thing?
[16:03] <zyga> davidcalle: nope
[16:03] <ogra_> nah
[16:04] <davidcalle> Thanks :)
[16:05] <davidcalle> kyrofa_: do you know when we can expect an updated https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md ? At first glance, snappy-tools, snappy try and snappy-remote need to go.
[16:05] <dholbach> zyga, thanks for looking into this
[16:05] <dholbach> I need to run now - have a good one everyone!
[16:06] <kyrofa> davidcalle, we have a bug for it-- we can crank it out pretty quickly, though aren't people using developer.ubuntu.com?
[16:07] <davidcalle> kyrofa: we import the doc from you guys :) I've just removed them from there, though, with the announcement.
[16:07] <davidcalle> https://developer.ubuntu.com/en/iot/build-apps/get-started
[16:07] <kyrofa> davidcalle, oh! I didn't know that import was up and running
[16:08] <davidcalle> kyrofa: it's not, we run a manual thing :)
[16:08] <kyrofa> davidcalle, ah :) . Yeah we'll move that one closer to the top of the pile, thanks for the reminder
[16:09] <davidcalle> kyrofa: no worries, we'll sync with you next time we manually import or land the actual importer.
[16:10] <kyrofa> davidcalle, please do, I'm looking forward to that
[18:35] <netphreak> Hi, guys!
[18:35] <netphreak> I'm having trouble getting a homebuilt snap package start after install.
[18:35] <netphreak> http://paste.ubuntu.com/15818026/
[18:38] <kyrofa> netphreak, is this on the desktop?
[18:38] <ogra_> netphreak, snap install ubuntu-core
[18:39] <ogra_> (probably sudo ;))
[18:40] <netphreak> yes, i'm on desktop
[18:45] <elopio> noise][: any news about my 401? Should I report a bug somewhere maybe?
[18:46] <netphreak> thx solved the issue ;)
[18:46] <netphreak> One step closer - i now get the following error:
[18:46] <netphreak> http://paste.ubuntu.com/15818225/
[18:47] <netphreak> my snap craft looks the following:
[18:47] <netphreak> http://paste.ubuntu.com/15818261/
[18:50] <michaelrose> so question since snappy packages are limited as far as access to the filesystem how do they manage to open your files
[18:51] <michaelrose> ex a pdf reader, suppose I could open a file via the terminal via xdg-open or via direct invocation of the program, by clicking on the pdf in my file manager, by selecting the book in calibre
[18:55] <ogra_> michaelrose: most likely similar to what happens on the phone today ... via a system service
[18:55] <ogra_> (called the content-hub on the phone)
[18:56] <ogra_> but thats not yet existing
[18:56] <ogra_> (for desktop)
[19:34] <swami_> need help on downloading kernel source from ubuntu.com and its kicking me out each time. I am behind the firewall; but has the set proxy correctly and able to download kernel.org's or some others without issue
[19:35] <swami_> anyone can help?
[19:36] <swami_> for eg: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_v3.18, how to download this using git clone? any othe settings?
[19:37] <zyga> swami_: I don't think there are any; perhaps download it without the proxy in the way
[19:39] <swami_> dont think proxy is an issue. because I am able to download others from external website. Am I missing something?
[19:39] <josepht> swami_: git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git
[19:40] <zyga> swami_: works for me, try without a proxy
[19:40] <swami_> hmm, thanks zyga.
[19:40] <swami_> I tried this josepht
[19:40] <swami_> have tried git:// http:// and https://
[19:41] <swami_> is there any git/ssh settings that I should consider about?
[19:41] <zyga> swami_: it looks like your proxy is just broken
[19:42] <zyga> swami_: if it is any consent, I have never seen a corpo proxy that didn't break everything apart from websites
[19:42] <zyga> s/consent/comfort/ (I guess)
[19:42] <swami_> when I tried the above command, it shows me this:
[19:42] <swami_>  git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git Cloning into 'ubuntu-vivid'... fatal: unable to connect to kernel.ubuntu.com: kernel.ubuntu.com[0: <IP_ADDRESS>]: errno=Connection timed out
[19:43] <swami_> got http, it shows: Cloning into 'ubuntu-vivid'... fatal: repository 'http://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/' not found
[19:43] <swami_> *for
[19:44] <josepht> swami_: only git:// and https:// work for me.  I imagine http:// isn't being served.
[19:46] <swami_> for git, connection timed out. for https, below. :(
[19:46] <swami_> Cloning into 'ubuntu-vivid'... fatal: unable to access 'https://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
[19:47] <jdstrand> beuno: hey, could someone sync review tools r627? this removes old-security, fixes a couple bugs and makes sdoc stuff work ok again
[19:48] <JanC> sounds like a broken proxy indeed...
[19:49] <swami_> thanks. how to verify that proxy is working? some other ways to check
[19:55] <michaelrose> so regarding the content hub, A) what does that mean for non ubuntu machines B) does that mean that the content hub replaces xdg-open et al C) does that mean all of the above ways to open the pdf still work seamlessly or do they have to be rewritten to take it into account
[20:03] <beuno> jdstrand, sure
[20:04] <michaelrose> reading this https://developer.ubuntu.com/en/phone/platform/guides/content-hub-guide/ sort of looks like I couldn't just open a file from the filesystem with an arbitrary app seems like I would have to open the owning app, say the gallery app for pictures
[20:05] <michaelrose> and pic an app to share it with kind of android style
[20:06] <michaelrose> although the receiving app can use say the gallery app is a file picker
[20:10] <michaelrose> mostly what I'm wondering is how easy it will be to rip apart a snappy package and use it on a non ubuntu system that doesn't have content hub or any of that junk


[05:36] <pitti> Good morning
[05:36] <pitti> balloons: I'm now, but I suppose you are off already
[07:25] <melodie> hello


[06:36] <dholbach> good morning
[12:36] <cjohnston> mornin
[13:55] <jcastro> http://shouldiuseacarousel.com/
[13:55] <jcastro> this is brilliant
[13:59] <daker> jcastro: it's using the Ubuntu font
[16:02] <dholbach> off to go BBQ'ing
[16:02] <dholbach> see you later :)
[23:55] <bkerensa> jono: collect the monies
[23:55] <bkerensa> :)


[00:00] <pwnguin> the decentralized vcs recognizes that development already happens that way, and pushing a distrbuted VCS helps set up a centralized point to track all these distributed changesets
[00:01] <LaserJock> sure
[00:02] <LaserJock> but to me it sort of makes one wonder if the goal of centralizing the FLOSS world in LP is a workable idea
[00:03] <pwnguin> the only way to reconcile this is to imagine that some day they'll release the code, I guess ;)
[00:05] <LaserJock> pwnguin: well, that's certainly the plan
[00:06] <LaserJock> Mark said today that he expects an API by July
[00:06] <LaserJock> I think that's a big hurdle for them
[00:07] <ScottK2> What was today?
[00:07] <LaserJock> I thought so
[00:08] <LaserJock> yeah, today
[00:09] <pwnguin> anyways, what about the brainstorm code? ;)
[00:09] <LaserJock> "I'm pretty confident that you will be able to do anything with bugs or branches programatically by the end of July"
[00:10] <tonyyarusso> Why should it need to be the canonical instance if it can track itself, and therefore still have all of the data that a canonical instance would have?
[00:10] <LaserJock> the idea was that people should use launchpad.net, not just launchpad
[00:11] <pwnguin> tonyyarusso: probably along the lines of "50 dollars and you can fork ubuntu!"
[00:11] <tonyyarusso> Well I know that's the idea, but I don't know why they think forcing that on people is okay.
[00:11] <LaserJock> having launchpad being able to talk to each other to a level where it's effectively the same thing
[00:11] <LaserJock> because if they didn't then it's just like having gforge or trac/bugzilla
[00:12] <LaserJock> the idea is to create a common FLOSS workspace that holds bugs, blueprints, code, packages for everything
[00:13] <tonyyarusso> meh, I don't write code yet, but if/when I do I won't be comfortable hosting it on a platform that flies in the face of the entire ideal set.
[00:13] <LaserJock> so the only way to get that with multiple instances is to effectively make it possible to make the instances a part of a gigantic whole
[00:13] <pwnguin> google code/
[00:13] <pwnguin> ?
[00:15] <RAOF> There are at least 3 closed codehosting sites widely used for open source projects that I can pick off the top of my head :)
[00:15] <pwnguin> exactly.
[00:16] <tonyyarusso> So why add more?
[00:16] <tonyyarusso> I'd rather host my own subversion repository, personally.
[00:16] <pwnguin> because none of them are effective at distro sized projects/
[00:16]  * pwnguin has his ? button inspected
[00:16] <ScottK2> LaserJock: But it's not a FLOSS workspace.
[00:17] <Fujitsu> tonyyarusso: Because SourceForge sucks. Bad.
[00:17] <bmk789_> is there a MOTM?
[00:17] <Fujitsu> bmk789_: No, MOTU covers it.
[00:17] <bmk789_> ah i see thanks
[00:17] <LaserJock> ScottK2: I believe that is the goal, no?
[00:18] <pwnguin> recall that scott's hatred for lp is more than just copyrights
[00:18] <tonyyarusso> It's been stated as a goal, but I'm judging things on actions rather than vague promises until I see something hinting otherwise.
[00:18] <ScottK2> LaserJock: It's a stated goal, but it's not an actuality.  There's no timeline and IMO the developers are not at all community oriented, so even if the code were freed tomorrow it would be a long time before much changes.
[00:19] <LaserJock> I believe most projects hosted on LP are FLOSS
[00:19] <ScottK2> True, but beside the point.
[00:19] <LaserJock> well, you said it wasn't an actuality
[00:19] <ScottK2> It's not a FLOSS anything
[00:19] <LaserJock> but I'm not exactly seeing how it's not
[00:20] <ScottK2> It's proprietary.
[00:20] <LaserJock> it's for FLOSS I wasn't saying it *was* FLOSS
[00:20] <ScottK2> Ah.
[00:20] <LaserJock> I agree with you that it's not FLOSS currently
[00:20] <ScottK2> Well as I've said before I consider that a fatal flaw.
[00:20] <LaserJock> but I see no reason to doubt that it won't one day be FLOSS
[00:21] <ScottK2> My perspective on that has only hardened as I've interacted with their developers and tried to help make it better.
[00:21] <ScottK2> I see no reason to believe it will be.
[00:21] <LaserJock> in general Mark's been fairly trustworthy on these things
[00:21] <LaserJock> most of the devs are FLOSS guys
[00:21] <ScottK2> They don't much act like it IMO.
[00:21] <LaserJock> part of it has already been opened
[00:21] <LaserJock> though it is not much
[00:21] <LaserJock> but they are
[00:21] <ScottK2> I agree that he intends to open it, I just don't think the necessary preconditions are achievable.
[00:22] <LaserJock> ah
[00:22] <LaserJock> well, I can go a bit there
[00:22] <LaserJock> I think it'll ultimately work
[00:22] <Fujitsu> LaserJock: WHat part has? Storm isn't actually part of it yet...
[00:22] <LaserJock> I thought they were using it
[00:22] <Fujitsu> I guess cscvs, but that's about it.
[00:22] <Fujitsu> LaserJock: It's scheduled for the next release or two, IIRC.
[00:23] <LaserJock> ah
[00:23] <LaserJock> so there's 2 parts
[00:23] <LaserJock> not much, but something anyway
[00:23] <tonyyarusso> How long has it been since he first promised to open it?  Two years?  More?
[00:24] <LaserJock> probably a bit longer
[00:24] <LaserJock> he's never set a time though
[00:24] <Fujitsu> The FAQ has said it for about 3 years.
[00:24] <tonyyarusso> If you can't follow through on a promise like that in 12 months or less, you lose credibility in my eyes.
[00:24] <LaserJock> why?
[00:24] <Fujitsu> tonyyarusso: It said it would likely take years.
[00:25] <tonyyarusso> Fujitsu: They can say whatever they want.  Fact is, after the first year, I no longer trust that claim until the day it comes true.
[00:26] <LaserJock> well, whatever
[00:26] <LaserJock> I really couldn't care less
[00:27] <LaserJock> Mark and Canonical say they're gonna open source it when the time is right
[00:27] <LaserJock> and I haven't seen anything to make me thing that's changed
[00:27] <LaserJock> it's being worked on
[00:27] <LaserJock> even if it's not as fast as I'd like
[00:27] <pwnguin> what negative effects would be seen if it were released say... today?
[00:28] <Fujitsu> pwnguin: A complete loss of income from it, perhaps?
[00:28] <LaserJock> that'd just add to the problem they're already trying to fix
[00:28] <pwnguin> does LP have anything money related?
[00:28] <LaserJock> yes
[00:28] <LaserJock> commercial projects have to pay for LP
[00:28] <Fujitsu> pwnguin: Yes, and a lot more features to encourage that are coming.
[00:28] <azeem> LaserJock: commercial project which are FLOSS?
[00:29] <LaserJock> azeem: no
[00:29] <LaserJock> I don't think so anyway
[00:29] <tonyyarusso> See, that's the thing.  We've been given no technical reasons, but there are financial reasons, so I'm inclined to believe it's completely a financial matter, which bothers me.
[00:29] <LaserJock> proprietary I guess
[00:29] <LaserJock> tonyyarusso: they give technical reasons
[00:29] <azeem> ok, cause you said it was targetted at FLOSS projects above
[00:30] <Fujitsu> tonyyarusso: We do have technical reasons.
[00:30] <LaserJock> azeem: yes, but they have to pay the bills ;-)
[00:30] <Fujitsu> The point of Launchpad vanishes if it is split up.
[00:30] <tonyyarusso> LaserJock: What, "we don't want to be embarrassed by someone seeing our code"?
[00:30] <azeem> k
[00:30] <tonyyarusso> Fujitsu: not if it was properly designed...
[00:30] <LaserJock> tonyyarusso: come on! I just gave you reasons
[00:31] <LaserJock> azeem: it's free for FLOSS projects but proprietary projects have to pay. Pay the bills while encouraging FLOSS
[00:31] <azeem> "Thank God nobody's looking at this comment, or my reputation would be ruined." -- Gordon Matzigkeit in the Solaris boot-loader code
[00:31] <tonyyarusso> LaserJock: What's the difference between being able to track everything in one location and forcing everyone to use the one location directly, other than what URL you type in?
[00:31] <LaserJock> tonyyarusso: it discourages collaboration
[00:31] <tonyyarusso> LaserJock: how?
[00:31] <tonyyarusso> Nobody can collaborate on LP anyway.
[00:31] <LaserJock> sure they can
[00:32] <tonyyarusso> not unless they're on the dev team...
[00:32] <LaserJock> packagers can files bugs on upstreams
[00:32] <LaserJock> bzr branches, etc.
[00:32] <LaserJock> all in the same place
[00:32] <tonyyarusso> You could do that the way I said too.
[00:32] <LaserJock> whereas we already know how hard it is to deal with 1000's of upstreams
[00:32] <LaserJock> with different websites, bug trackers, etc.
[00:32] <tonyyarusso> If all of the LPs can talk to each other, it's the same as being one.
[00:33] <LaserJock> yes
[00:33] <LaserJock> but they don't have that yet
[00:33] <LaserJock> so that's part of what Mark's talking about
[00:33] <RAOF> Which is a technical reason :)
[00:33] <LaserJock> the API needs to get finished
[00:33] <tonyyarusso> Then that's what they should have been working on this whole time.
[00:33] <LaserJock> they have been
[00:34] <tonyyarusso> I don't believe that it.  They added support for other trackers in that time, but not their own?
[00:34] <LaserJock> no
[00:34] <LaserJock> they don't have full support
[00:34] <LaserJock> vcs imports have to be done by hand
[00:34] <tonyyarusso> Could have gotten the work done faster with more input anyway, so it would have been easier to accomplish by starting open right off the bat.
[00:34] <LaserJock> they are working around stuff trying to provide services for us
[00:34] <RAOF> tonyyarusso: But LP needs to be reasonably code- and nearly totally design-stable before you can open it without introducing incompatibilities later.
[00:34] <LaserJock> but tracking another LP with translations, bugs, branches, blueprints, answers, etc. is a *much* bigger task
[00:35] <pwnguin> tonyyarusso: i suppose the idea is that they will make a service akin to git -- distributed bug tracking that can push bug reports around multiple trackers
[00:35] <Fujitsu> Translations in particular would be near impossible.
[00:35] <tonyyarusso> RAOF: So have people review additions and offer direction.
[00:35] <kitterma> Gotta run (getting on a plane)
[00:35] <tonyyarusso> pwnguin: precisely.
[00:35] <pwnguin> tonyyarusso: automatically. which isnt done anywhere yet ;0
[00:36] <tonyyarusso> meh, like I said, this is a priority for me, so I'm staying at arm's length until something changes.
[00:36] <RAOF> tonyyarusso: But if the point is that you don't want people forking it until it can talk to itself, how does that review help?
[00:37] <RAOF> Not that I wouldn't *prefer* having LP open sourced, and it could probably fulfil the same role, but it's not like there aren't reasonable reasons for it :)
[00:38] <tonyyarusso> RAOF: The forks could talk too...
[00:38] <tonyyarusso> people don't just fork randomly either, and when they do, users will follow the better one usually.
[00:38] <pwnguin> tonyyarusso: the forks could talk, right up until either side updates
[00:39] <tonyyarusso> pwnguin: at which point you'd know the code necessary to talk to the update
[00:39] <tonyyarusso> Here's what it comes down to:  Can LP talk to my self-hosted web page with my code?
[00:40] <RAOF> tonyyarusso: No, probably not.  But why are you self-hosting?
[00:40] <tonyyarusso> RAOF: because I don't want to be on LP / sourceforge / etc.
[00:41] <tonyyarusso> Because I'm not comfortable trusted my open code to a closed service.
[00:41] <tonyyarusso> Therefore, for me personally, LP fails at "bringing everything together", but I don't want to accept its conditions of participation.
[00:42] <RAOF> Right.  So when it's open this will go away, and you won't be self-hosting?
[00:45] <tonyyarusso> Correct.
[00:45] <tonyyarusso> Well, provided they also fix a few "pet bugs" in functionality, but that's quite likely :)
[01:14] <farruinn> I'm trying to get pbuilder to use a local repo on /var/caches/archive but when I run pbuilder update --bindmount /var/cache/archive --override-config --othermirror "deb file:///var/cache/archive/ gutsy/" it says "Ign file: gutsy" for Release.pgp, Release, and Packages.
[01:30] <YokoZar> ScottK: Hey, I put up a new Wine package on review and \sh has been gone for a few days.  Care to take a look?
[01:35] <RAOF> YokoZar: The most cursory scan suggests the question: Why is it versioned as 0.9.57-0ubuntu1-1?
[01:40] <tonyyarusso> Any MOTUs have a minute to upload the updated conduit?  2 ACKs already given.
[01:50] <Hobbsee> pwnguin: launchpad clearly can't be released as a FLOSS project today, because then everyone would see the amount of hacks, and general crack in launchpad, and would then refuse to use it for their projects, due to it's quality.
[01:50] <Hobbsee> this is simple.
[01:52] <Hobbsee> see the interesting crack surrounding how launchpad implements private bugs.
[01:52] <Hobbsee> (when the entire librarian, which all files get stored on, is public)
[01:58] <superm1> crimsun, it was bug 200044.  sorry i've been out for part of the evening
[01:58] <ubotwo> Launchpad bug 200044 in mythbuntu "MythTV 0.21 Suite backport" [Undecided,New] https://launchpad.net/bugs/200044
[02:16] <YokoZar> RAOF: oh whoops, that was a typo when I did uupdate.  If that matters I can fix it, however we'll likely have another Wine package after this one too
[02:16] <YokoZar> RAOF: at which point it'll be 0.9.58-0ubuntu1
[02:22] <RAOF> YokoZar: It's still a good idea to fix up this candidate, even if the next one may come (hasn't .57 been recently released?)
[02:22] <YokoZar> RAOF: Yes it will be 2 weeks for the next one
[02:23] <RAOF> YokoZar: So, the question becomes... why not wait those 2 weeks? :)
[02:23] <YokoZar> RAOF: Because Hardy only has 0.9.56
[02:24] <YokoZar> RAOF: my package fixes some other bugs too (ubuntu specific)
[02:24] <RAOF> Right.  _That_ is a reason :)
[04:10] <ianweller> hi, i've packaged some software for fedora, and the developer of the upstream has asked me to find a maintainer for ubuntu. is anyone interested and/or where else could i ask
[04:12] <tonyyarusso> ianweller: you'll probably have better luck if you say what the package is.  (and note that it's a weekend, and therefore sparsely populated)
[04:12] <ianweller> flam3.com
[04:12] <ianweller> do you think i should ask tomorrow
[04:13] <tonyyarusso> yes.
[04:13] <ianweller> k.
[04:13] <ianweller> will do
[04:13] <tonyyarusso> the mailing list is also an option with a wider audience.
[04:13] <ianweller> ok
[04:13] <tonyyarusso> You can also file a bug and tag it with "needs packaging"
[04:16] <ianweller> tonyyarusso: so 'needs packaging' is a tag, with or without quotes?
[04:18] <tonyyarusso> ianweller: without
[04:18] <tonyyarusso> there might even be a hyphen in that - see if you can find another one and copy it.
[04:19] <tonyyarusso> the wiki has instructions for new packages somewhere as well - start at https://wiki.ubuntu.com/MOTU and look around (don't remember the path right now)
[04:19] <ianweller> kthx
[06:37]  * RAOF wonders idly why there's a 30 sec pause in the middle of his boot process with no I/O or CPU load.
[06:38] <pwnguin> are you up to date?
[06:38] <StevenK> Sounds like a spin with sleep
[06:38] <pwnguin> there was a changelog in usplash about SLEEP 0 causing a bit of spin ;)
[06:39] <RAOF> How up to date is up to date?  The lappy is up to date as of ~8 hours ago.
[06:41] <Fujitsu> RAOF: Is it during the `hahahah I'm going to confuse you into thinking I'm a live CD' part of usplash?
[06:43] <RAOF> Fujitsu: I'm not quite sure where that bit is :).  Now that I come to think of it, it's probably not entirely usplash's fault; the pause is still there without splash, and occurs at the "loading kernel drivers" (or somesuch) phase.
[06:43] <Fujitsu> RAOF: Hardy's usplash recently started doing the side-to-side scrolly thing during initramfs, like the live CD does throughout the boot process.
[06:43] <Fujitsu> It thoroughly confused me the first time I saw it.
[06:44] <pwnguin> it looks like it booted fine for me
[06:44] <Fujitsu> RAOF: I ask because my laptop hangs for about 30 seconds in initramfs, unless I force the clocksource to HPET.
[06:44] <RAOF> Oh, that.  That's been there for ages.  I probably see it more than you, 'cause it takes a while for me to enter the passphrase.
[06:44] <pwnguin> though it is about a second longer than last time ;)
[06:45] <Fujitsu> RAOF: I use LUKS too...
[06:45] <RAOF> Fujitsu: No, I don't think that's me.  I go from grub(2) to passphrase-entry in a couple of seconds.
[06:45] <Fujitsu> OK, so that's not your problem.
[06:45] <pwnguin> ok, so if readahead's job is to prime the read cache for boot
[06:46] <pwnguin> why do i have so much disk activity even after it's done?
[06:48] <tonyyarusso> Hmm, activity eh?  Anyone have a minute to upload the already-ACKed new version of conduit?
[06:51]  * RAOF is puzzled by the lack of nspluginwrapper maintainer scripts.  Don't we do something on install to make it work?
[06:53] <RAOF> asac: Ping! I'm having a look at bug #196540 , and it seems we could almost sync it.  Is it blocking on you for any particular reason?
[06:53] <ubotwo> Launchpad bug 196540 in nspluginwrapper "Merge nspluginwrapper <IP_ADDRESS>-2 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/196540
[06:55] <RAOF> Ah, I see now.  You don't need to do any nspluginwrapper configuration; flash needs to call it during *it's* postinst.
[06:56] <dholbach> good morning
[07:05] <torkel> siretart: can you please extened my membership of the fai launchpad team?
[08:19] <siretart> torkel: sure, just a sek
[08:20] <torkel> siretart: thanks
[08:49] <asac> RAOF: not sure ... are there any significant improvements in that version?
[08:52] <slytherin> asac: A question. Do you plan to update your PPA to include latest svn snapshots of network manager?
[08:58] <asac> slytherin: eventually yes
[08:58] <asac> but not today ;)
[08:58] <slytherin> asac: Take your time. Thanks. :-)
[09:38] <RAOF> asac: It apparently fixes the "if you have too many flash objects running nspluginwrapper crashes" bug.
[09:54] <asac> RAOF: hmmm what about ia32-libs-gtk ... is that still a depends of the debian package?
[09:57] <RAOF> It is, yeah.
[09:57] <RAOF> Our ia32-libs provides it, but it's a little ugly.
[09:58] <RAOF> The sid package builds, installs, and works correctly, though.
[09:59] <RAOF> asac: Although, of course, now that I try and verify that it fixes all my flash problems I can no longer reproduce them with the original Ubuntu package.  Grrr.
[10:01] <asac> hehe
[10:04] <RAOF> It seems I can watch zeropunctuation, which used to be a sure-fire nspluginwrapper crash.
[11:10] <allee> siretart: please renew my launchpad fai team membership
[11:12] <\sh> siretart: mine too pls :)
[11:14] <siretart> allee: already done, \sh: done :)
[11:14] <allee> siretart: thx
[11:14]  * \sh hugs siretart  :)
[11:36] <torkel> siretart: what is the status of FAI in hardy? unionfs is still somewhat problematic, right? Anything else?
[11:37] <siretart> torkel: well, problematic in the sense that it renders fai basically unusable, yes
[11:38] <siretart> bug #197006
[11:38] <\sh> siretart: what do we need to make it usable? :
[11:38] <ubotwo> Launchpad bug 197006 in linux-meta "NFS over Unionfs prevents updating existing files" [Undecided,New] https://launchpad.net/bugs/197006
[11:38] <torkel> siretart: I will find out in about 8 minutes :-)
[11:38] <siretart> \sh: basically fixing that bug, or prodding on #ubuntu-kernel to get that one fixed
[11:39] <\sh> siretart: hmm for hardy this will be a hard thing...and I'm still waiting for my new hardware for setting up FAI here...I'm not in the position right now to play around with fai :(
[11:41] <proppy> oy
[11:41] <ryanhaig1> im trying to rebuild nautilus without tracker integration on gutsy, i have downloaded the source but I dont know what to change to disable tracker, is it a command line option when using debuild or do i need to change a file?
[11:44] <Iulian> Hey
[12:19] <allee> siretart, \sh:  when we can find a way to get grub the mbr installed, we have some anoying bug in error log,  but I assume a more or less working fai.
[12:20] <siretart> allee: err, and the unionfs problem?
[12:20] <allee> siretart: /target and /tmp  is  a normal or tmpfs  so most things work
[12:21] <siretart> sure, but for me, fai fails to setup things like /etc/resolve.conf and /etc/apt/sources.list
[12:21] <allee> siretart: I've removed so files from fairoot, e.g, /etc/resolv.conf  and the the boot procedure can create it
[12:22] <allee> siretart: it's all a hack, but better than nothing.  So after plains ugly hacks *shudder*, AFAICS only grub left
[12:24] <siretart> allee: oh, do you have a list of files that need to be removed? if yes, I'd suggest that we commit that to our branch and update the packages in hardy
[12:24] <siretart> I'd like to have something almost usable, even if its just a hack
[12:24] <siretart> for the grub problem, I *think* my student has found a solution for that
[12:24] <siretart> need to check with him
[12:25] <\sh> hmmm? grub in mbr?
[12:25] <\sh> that was working the last time
[12:25] <allee> siretart: I've check what I added last Thursday to the nfsroot-hooks
[12:25] <allee> \sh: for me last week:  no OS found on disk
[12:26] <allee> \sh: ah, right the menu.lst was empty.  Nothing added by update-grub
[12:26] <siretart> allee: which branch did you commit to?
[12:28] <siretart> allee: https://code.launchpad.net/fai/+branches does not list any updates on the branches from you?
[12:28] <allee> siretart: no commit yet, just tried to get it somehow working.  I've used nfsroot-hook scripts to remove
[12:28] <siretart> allee: aah, sorry I misread you
[12:32] <allee> siretart: can you ask your student about the grub solution?   I plan to try again as soon as I get rid of 'urgent' TODO in my inbox
[12:33] <siretart> allee: I need to write him an email
[12:34] <allee> siretart: ok, thx
[12:35] <torkel> allee: it is not as easy as creating $target/boot/grub before running update-grub?
[12:35] <allee> torkel: that not the problem.  even menu.lst is there, but the kernel list automaticly added by update-grub is empty
[12:36] <torkel> allee: oh
[12:37] <allee> torkel: and when I found this stop last week, so no idea where is goes wrong yet
[12:38] <torkel> allee: it seems to be working for me. My current showstopper is that it can't find my lvm:s after the installation
[12:39] <allee> torkel: oh, maybe -12 kernel changed something
[12:41] <torkel> allee: I guess I have to add dm_mod to the initramfs
[12:43] <allee> siretart: if we have fixes for hardy, what branch to use?  A ~<user>/fai/fai-<whatever> or merge to on off the two ~fai/fai/* branches?
[12:44] <\sh> allee: well, yes...I managed to use a default kernel name with a self build kernel ;)
[12:45] <allee> \sh: :)
[12:45] <\sh> allee: this menu.lst post-install thingy never worked for me in a good way ;)
[12:46] <\sh> 7topic Congrats to Scott Ritchie for the first Wine Upload in Ubuntu :)
[12:46] <allee> \sh: never had problems in dapper,feisty (had ot skip gutsy)
[12:47] <\sh> allee: well, right now I'm happy that I don#t have this setup again...combots ade :)
[12:48] <siretart> allee: just commit to trunk-ubuntu
[12:48] <allee> siretart: okay
[12:50] <allee> siretart, \sh, torkel: any idea how to have the ubuntu-kernel guys ponder about the unionfs problem?  Or did they?
[12:50] <siretart> allee: I didn't manage to get any reaction about that on #ubuntu-kernel
[12:50] <siretart> I suspect they are too busy with other stuff :(
[12:52] <allee> so maybe we all join #ubuntu-kernel  and fire a 'please have a look at  bug #197006'  to fix the bad charma ubuntu kernel tend to have.
[12:52] <ubotwo> Launchpad bug 197006 in linux-meta "NFS over Unionfs prevents updating existing files" [Undecided,New] https://launchpad.net/bugs/197006
[12:56] <\sh> siretart: subscribe ubuntu-kernel ,-)
[12:57] <siretart> isn't it already?
[12:58] <\sh> siretart: nope...only fai developers...but ben is also contacted...but I would push it directly to the kernel team
[12:58] <\sh> ah benc commented already it seems
[12:58] <\sh>   Ben Collins  wrote 6 seconds ago:  (permalink)
[13:01] <siretart> I'm already talking to ben on #ubuntu-kernel
[13:01] <\sh> ah cool
[13:26] <torkel> it should be enough to use unionfs=aufs right?
[14:25] <siretart> torkel: yes. you can add this to the fai-chboot command
[14:27] <torkel> siretart: it looks like it uses unionfs anyway
[14:29] <torkel> on the other hand the machine installed with unionfs (I removed resolv.conf* and mtab in the nfsroot)
[14:34] <siretart> torkel: wait, you need to pass 'union=aufs'
[14:34] <siretart> sorry, I misread
[14:34] <torkel> ah
[14:35] <siretart> the parameter is documented in /usr/share/doc/live-initramfs/parameters.txt, IIRC
[14:48] <emgent> heya people
[15:08] <RainCT> hey
[15:10] <siretart> ScottK: congrats to DMship!
[15:41] <\sh> phew
[15:42] <\sh> lighttpd + php as fcgi is much more performant then apache + mod_php5...how nice
[15:47] <mario_limonciell> hey ScottK2, would you be able to look over a backport bug?  I'm getting a barade of emails about why this hasn't been backported yet, and it still needs a backporter to look at it.
[15:48] <ScottK2> Sure
[15:48] <mario_limonciell> I've attached build logs and such to it. bug 200044
[15:48] <ubotwo> Launchpad bug 200044 in mythbuntu "MythTV 0.21 Suite backport" [Undecided,New] https://launchpad.net/bugs/200044
[15:50] <ScottK2> mario_limonciell: How important are the themes?  That's a lot of package Newing for the archive admins to do.
[15:51] <mario_limonciell> well they have new metrics.  they are a urgency.  the display just won't look right otherwise
[15:51] <mario_limonciell> er a lower urgency
[15:51] <mario_limonciell> is what i meant to say
[15:51] <mario_limonciell> if a different diff.gz/dsc could be uploaded for the backport, i'll take them off the recommends
[15:51] <mario_limonciell> so that they dont need to be NEWed
[15:53] <ScottK2> Let's leave it and see if they complain then.
[15:53] <mario_limonciell> okay
[15:53] <ScottK2> I also need a statement that the packages install and run on Gutsy.
[15:54] <mario_limonciell> well i sent the exact same packages to the mythbuntu-trunk ppa
[15:54] <mario_limonciell> and have a variety of users there
[15:54] <ScottK2> Sure.  I figure it does, but I need you to say that it works in the bug.
[15:54] <mario_limonciell> i'll get someone to throw on ack on the bug
[15:55] <ScottK2> mario_limonciell: How about you do that for the main packages and then make a separate bug for the recommeds as those are less urgent.  I expect it'd take a while to test all those anyway.
[15:56] <mario_limonciell> Ok.
[16:14] <emgent> geser, ping
[16:15] <geser> Hi emgent
[16:15] <emgent> geser, hi, can you open task in bug #191205 ? i can only nominate affected release.
[16:15] <ubotwo> Launchpad bug 191205 in wml "[wml] [CVE-2008-0665] [CVE-2008-0666] insecure temporary files" [Low,In progress] https://launchpad.net/bugs/191205
[16:17] <geser> emgent: done
[16:17] <emgent> thanks
[16:18] <persia> emgent: You might just ask for a task to be opened generally, as there are several people who can do so :)
[16:20] <DktrKranz2> geser: had you the occasion to test new dietlibc candidate on amd64?
[16:20] <emgent> persia, hehe i know, all >= motu can, but i usually ask to last uploader :P
[16:20] <geser> DktrKranz2: not yet, what kind of test are needed?
[16:20] <persia> emgent: That's typically only useful when attempting to merge someone else's changes, as they may be coordinating with upstream or Debian.
[16:21] <emgent> persia, ok
[16:24] <DktrKranz2> geser: applications segfaults at startup, rebuilding them against new dietlibc-dev should solve it. For instance, util-vserver (run vserver-info - SYSINFO) or slidentd (just run slidentd as shown in bug 86823).
[16:24] <ubotwo> Launchpad bug 86823 in slidentd "Slidentd immediately segfaults" [Undecided,In progress] https://launchpad.net/bugs/86823
[16:24] <mario_limonciell> ScottK2, okay i got a few folks to comment on the bug
[16:24]  * ScottK2 looks again
[16:25] <DktrKranz2> (any other help from amd64 users is appreciated too)
[16:26] <DktrKranz2> I tested on sparc and ppc and it should work now.
[16:27] <ScottK2> mario_limonciell: Ack'ed to the archive.
[16:27] <mario_limonciell> thanks
[16:56] <huats> ScottK2: hello
[16:56] <huats> ScottK2: just a question : is there any limit date to finish the python-xml removal ?
[16:57] <huats> (not really sure where it fits in the various freezes)
[17:27] <mruiz> hi all
[18:01] <ScottK2> huats: Sooner the better, but I'd say definitely before the beta
[18:04] <huats> ok
[18:59] <RainCT> hellboy195: heya
[18:59] <hellboy195> RainCT: ahoi :)
[18:59] <RainCT> I'm starting to think that patches hate me :)
[18:59] <hellboy195> RainCT: no merge working for you O_o ?
[19:00] <RainCT> I'm looking at cfingerd
[19:00] <RainCT> and it had rejects
[19:00] <RainCT> but don't worry will apply those manually :P
[19:00] <RainCT> ahhhh
[19:00]  * RainCT runs against the wall :P
[19:01] <hellboy195> RainCT: but you can trust me. I build every merge and all build fine
[19:01]  * RainCT downloads the source from *Debian*
[19:01] <RainCT> :P
[19:01] <ScottK2> That'll do it (I've done that)
[19:01] <hellboy195> RainCT: lol
[19:05] <RainCT> hellboy195: wow, that's a old package :)
[19:07] <hellboy195> RainCT: hmm. That's the problem if no one approves it earlier. I forgot all about this package
[19:07] <RainCT> heh
[19:07] <RainCT> first changelog entry (in a different format than the current ones): Wed May 5 13:20:21 1996  Martin Schulze<EMAIL_ADDRESS>[19:07] <RainCT> :)
[19:08] <hellboy195> RainCT: ^^ long living
[19:09] <RainCT> hellboy195: ok, uploading. if it fails to build I kill you ;)
[19:10] <hellboy195> RainCT: Hmm but first the other MOTUs will kill you because you have the responsibility ;) ^^
[19:10] <RainCT> :P
[19:12] <RainCT> hellboy195: that's the smae I always thought when I subscribed u-u-s to a debdiff of mine ;). "if I did something wrong and installing the resulting package lets computers explode it's the MOTU's fault" ;P
[19:13] <RainCT> nah but it builds fine :)
[19:13] <hellboy195> RainCT: as I said ;)
[19:13] <RainCT> s/smae/same
[19:14] <hellboy195> RainCT: you are slowly. next merge ;)
[19:16]  * RainCT is starting to hate python and mono packages. all the time they want unnecessary higher dependencies when installing stuff build for hardy in gutsy :)
[19:25] <hellboy195> DktrKranz: buona sera :)
[19:26] <DktrKranz> hellboy195, Guten Abend :)
[19:26] <hellboy195> DktrKranz: great :D
[19:26] <hellboy195> DktrKranz: btw, I found a new victim. I forced RainCT to approve 3 merges ^^
[19:26] <DktrKranz> \o/
[19:27] <DktrKranz> what about beagle?
[19:27] <DktrKranz> news about it?
[19:27] <hellboy195> DktrKranz: no :(. but that's really a shame ...
[19:29] <RainCT> hellboy195: I can't download libnxml
[19:29] <RainCT> dget: curl libnxml_0.18.1-4.dsc http://ftp.debian-ports.org/debian/pool/main/libn/libnxml/libnxml_0.18.1-4.dsc failed
[19:30] <RainCT> (getting it from lenny seems to work)
[19:30] <hellboy195> RainCT: you have strange problems with my merges ^^
[19:31] <RainCT> heh
[19:32] <hellboy195> DktrKranz: of course you are also invited as usual ^^
[19:32] <Adri2000> where should .mo files be installed? /usr/share/locale/$LANG/ or /usr/share/locale/$LANG/LC_MESSAGES/ ? is there a policy or something about that?
[19:34] <slangasek> Adri2000: [...]/LC_MESSAGES/ is the subdirectory that's in the path
[19:34] <slangasek> if you're installing them as part of a package, /usr/share/locale/$LANG/LC_MESSAGES/ is generally correct
[19:34] <slangasek> language packs install them elsewhere
[19:37] <DktrKranz> hellboy195, I'm planning to do some, I hope to reduce queue a bit, if Hardy allows me to do them (I'm having some troubles recently)
[19:37] <hellboy195> DktrKranz: hey. Always mind: "NO Stress" ;)
[19:38] <hellboy195> DktrKranz: but you know that I'm always happy if someone approves my merges :)
[19:38] <Adri2000> slangasek: ok. filezilla build system puts them in /usr/share/locale/$LANG/ and the upstream author tells me it doesn't matter because wxwidgets (which filezilla uses) can handle both locations. so is there a standard, policy or something which says they should rather be in LC_MESSAGES/ ?
[19:38] <RainCT> hellboy195: was that clean-la thing added in cdbs 0.4.49ubuntu5?
[19:38] <hellboy195> RainCT: yep
[19:38] <DktrKranz> hellboy195, I used to be, so I know how it feels :)
[19:39] <hellboy195> DktrKranz: heh
[19:40] <slangasek> Adri2000: well, there's the gettext documentation, I guess; and there's the general principle that it's rude to clutter directories that aren't yours. :)
[19:40] <slangasek> Adri2000: but as far as a policy saying the files *have* to be under LC_MESSAGES/, I don't think so
[19:42] <Adri2000> ok I'll take a look at the gettext documentation, thanks :)
[19:42] <wattazoum> hello,
[19:44] <wattazoum> I am looking for a Mentor :-) . I am very dynamic and I have a great sense of well accomplished jobs. And I'd like to contribute a lot to Ubuntu
[19:44] <wattazoum> :-)
[19:44] <wattazoum> any mentor interessed :-D
[19:46] <hellboy195> wb Daviey
[19:46] <hellboy195> wb DktrKranz
[19:46] <hellboy195> Daviey: sry ^^
[19:46] <RainCT> wattazoum: please check the wiki for information on how to get a mentor :)
[19:46] <hellboy195> DktrKranz: sto andando via means "I keep moving on"?
[19:46] <DktrKranz> hellboy195, "Quitting"
[19:47] <hellboy195> hmm
[19:47] <RainCT> wattazoum: but you don't need one to start contributing to packaging
[19:48] <RainCT> hellboy195: uploading the 3th one ;)
[19:49] <hellboy195> RainCT: great. time for 3 new ones
[19:49] <RainCT> lol
[19:49] <wattazoum> RainCT, Thank you ! That's what I didn't understand ... How to contibute without being a MOTU ?
[19:50] <hellboy195> RainCT: now I'm disappointed. Although I did quite a lot merges it always great to hear the common phrase: Uploaded. Thanks for you work.   You should take a lot at DktrKranz ;)
[19:51] <DktrKranz> hellboy195, do you think "Uploaded, it's 150 EUR" sounds better?
[19:51] <RainCT> wattazoum: I'm searching the links for you (my connection is damn slow today :/)... There's a "sponsorship process" through which you can get a MOTU to check your work and upload it
[19:51] <hellboy195> DktrKranz: maybe :P
[19:51] <wattazoum> RainCT, I found this : https://wiki.ubuntu.com/MOTU/Mentoring/Contributor
[19:52] <hellboy195> RainCT: as punishment I'm assigning 3 more ones to you :P
[19:52] <RainCT> noooo :)
[19:52] <DktrKranz> RainCT, in the meantime, hellboy195 will push five more on the queue :)
[19:52]  * RainCT hides
[19:53] <RainCT> heh
[19:53] <hellboy195> DktrKranz: argh. school is stupid. but next week I'll do :D
[19:53] <RainCT> hellboy195: By the way, do you want the bill by email or airpost?
[19:53] <hellboy195> RainCT: hmm. don't send it for now. You know. More merges are on the way ^^
[19:54] <RainCT> wattazoum: see this too https://wiki.ubuntu.com/MOTU/GettingStarted
[19:54] <wattazoum> RainCT, oki
[19:54] <hellboy195> RainCT: no to be serious. Thank you very much :)
[19:54] <ScottK2> mok0: Did you ever come up with any additional wxwidgets2.6 fixes?
[19:54] <ScottK2> mok0: And how's serpentine?
[19:54] <RainCT> wattazoum: if you prefer a mentor of course feel free to request one though :)
[19:55] <RainCT> hellboy195: no, thank *you* ;)
[19:55] <mok0> ScottK2: No to both questions... I've been busy
[19:55] <hellboy195> RainCT: now I'm happy ^^
[19:55] <mok0> ScottK2: upstreams patches to serpentine made it fail
[19:55]  * RainCT adds "say thanks -- 5€" to the bill
[19:55] <hellboy195> RainCT: but they were easy ones so I suppose they were ok and not a lot of work for you
[19:56] <mok0> ScottK2: IMHO serpentine is very immature and I'm not really enthusiastic about it
[19:57] <wattazoum> RainCT, well , if there is no need for one, I prefere letting the place to someone who need it more. I already have some programming and packaging background and I can learn easily by myself  :-)
[19:57] <RainCT> wattazoum: great :)
[19:57] <wattazoum> ^^
[19:58]  * wattazoum is going to read some documentation ;-)
[19:58] <wattazoum> see you soon :)
[19:58] <RainCT> cya wattazoum :)
[19:59] <ScottK2> mok0: So if we went ahead and uploaded your last debdiff that would at least solve the python-xml problem and not do any actual harm?
[19:59] <ScottK2> mok0: for serpentine ^^^
[20:00] <mok0> ScottK2: err, no
[20:00] <ScottK2> OK
[20:00] <mok0> ScottK2: I need to check it some more
[20:00] <ScottK2> OK.
[20:00] <mok0> ScottK2: what was the problem with wx 2.6? Sorry I forgot
[20:01] <ScottK2> mok0: With that one you needed to change the python version to 2.4 and later and I asked you to look and see if you could fix anything else while you were at it.
[20:01] <ScottK2> Since the package has a number of open bugs
[20:02] <mok0> Ah, ok
[20:02] <mok0> I'll put it on my todo
[20:04] <ScottK2> It seemed a shame to upload for the one line packaging change ...
[20:05] <mok0> ScottK2: It is necessary to require Python >= 2.4 in debian/control because the libxml replacement stuff was introduced with that version -- is my understanding anyway
[20:06] <ScottK2> mok0: Agreed.  It needs to be uploaded, but I wanted to see if there was anything else worth including at the same time.
[20:06] <mok0> ScottK2: I understand. Good point
[20:06] <mok0> ScottK2: I'll look at those other open bugs and see if I can solve them
[20:07] <ScottK2> Thanks.  Debian might be a good source of patches too.
[20:08] <mok0> ScottK2: ok
[20:37] <nxvl> ScottK2: did you know if there is any python-binding of ncurses
[20:37] <POX_> urwid?
[20:37] <ScottK2> I don't know
[20:37] <POX_> (there's one in std lib as well)
[20:37] <ScottK2> But POX_ is generally reliable on python things, so I'd look into that
[20:38] <ScottK2> that/those
[20:38] <nxvl> ScottK2: thnx!
[20:40] <POX_> http://docs.python.org/dev/howto/curses.html
[20:40] <POX_> http://excess.org/urwid/
[20:41] <candrews> I'm attempting to package mod_auth_cas, I have everything done, except when I try to load the module into apache, I get this error: /usr/lib/apache2/modules/mod_auth_cas.so: /usr/lib/apache2/modules/mod_auth_cas.so: undefined symbol: authcas_module
[20:42] <candrews> Can someone help?
[20:48] <hellboy195> RainCT: now we have a problem
[20:49] <james_w> candrews: it sounds like something went wrong while building, such that something wasn't linked correctly.
[20:50] <candrews> do you have any ideas on how i can figure out what went wrong?
[20:51] <james_w> candrews: look in the source code for "authcas_module" and see what it is meant to be.,
[20:52] <candrews> grep authcas_module * -i
[20:52] <candrews> Yields no results.
[20:52] <candrews> Where is it getting that it needs to load something by that name?
[20:53] <james_w> candrews: I don't know, possibly in the build somewhere, possibly apache expects it to be there.
[21:03] <candrews> Thanks - that helped me figure it out. https://bugs.launchpad.net/ubuntu/+bug/199754
[21:05] <Legendario> hi. can anyone give me a hint on this error message here? http://paste.ubuntu-nl.org/59185/
[21:06] <mok0> Legendario: look at line 3
[21:06] <slangasek> don't try to copy things to a directory before you've made sure it exists?
[21:07] <Legendario> mok0, but this is on the makefile... how can i correct it?
[21:08] <mok0> Put "usr/share/applications" in the file <package>.dirs
[21:08] <Legendario> slangasek, i tried using dh_installdirs by creating a debian/package.dirs file, but i don't know if i did it right
[21:08] <mok0> Legendario: and make sure debian/rules uses dh_installdirs
[21:09] <slangasek> mok0: that won't trigger before the install target
[21:09] <slangasek> Legendario: the upstream build rules should be fixed
[21:09] <mok0> slangasek: ah, it's a bug in upstream Makefile...
[21:09] <mok0> I see
[21:10] <mok0> the quick and dirty way is to make it in rules
[21:10] <mok0> "mkdir -p debian/lives/usr/share/applications/"
[21:10] <slangasek> very dirty
[21:11] <Skiessi> is archive.ubuntu.com updated more often than it's mirrors?
[21:11] <mok0> slangasek: but very quick :-P
[21:12] <mok0> Legendario: I suggest you go with the quick and dirty to get it to work, and when it does, move the fixes into a patch to upstream's Makefile
[21:13] <Legendario> mok0, what about the package.dirs, isn't it supposed to work?
[21:13] <mok0> Skiessi: no, the mirrors are updated more often than the archive
[21:13] <mok0> :-P
[21:13] <Skiessi> ok
[21:13] <mok0> Legendario: try it
[21:14] <Legendario> mok0, gonna do it right away...
[21:14] <Skiessi> anyway, does anyone know why the sound system is broken in 2.6.24-12?
[21:15] <Legendario> mok0, thanks
[21:15] <mok0> Legendario: did it work?
[21:15] <Legendario> you too slangasek
[21:15] <slangasek> Skiessi: because of bug #200338
[21:15] <slangasek> Legendario: n/p
[21:16] <mok0> bug 200338
[21:16] <Legendario> mok0, i'm doing it now. tell you guys later
[21:16] <Skiessi> that doesn't say anything
[21:16] <Skiessi> to anyone
[21:16] <mok0> ubotu?
[21:16] <Skiessi> no, a bug report
[21:16] <mok0> ubotu's dead :-(
[21:16] <Skiessi> bug report says there's a bug and that's it
[21:16] <mok0> Skiessi: the bot usually gives us a link
[21:17] <Skiessi> I know
[21:17] <mok0> Skiessi: you can help by providing more information. Your system, versions, sound card... etc
[21:17] <mok0> Skiessi: on LP
[21:18] <Skiessi> kk... but it has worked for someone?
[21:19] <Skiessi> *some people?
[21:19] <mok0> Skiessi: I am running 2.6.24-11 and that has no problems. Haven't rebooted in several days
[21:19] <slangasek> mok0: no, no more information is needed, the bug report documents that the fix is released and it's only a matter of the binaries being built.
[21:19] <Skiessi> but in 2.6.24-12
[21:20] <mok0> slangasek: ok
[21:24] <Legendario> mok0, it didn't work. I guess i have to try the "dirty way". Am I supposed to use a variable like $(CURDIR). I mean on both methods?
[21:25] <mok0> Legendario: Put it in the "build" rule, so the directory will exist before upstream's Makefile tries to install things in it
[21:25] <mok0> Legendario: you can use $(CURDIR) in the mkdir statement I wrote above
[21:26] <mok0> Legendario: but you don't need it if you call dh_testdir in the build rule and you don't change directory in there
[21:27] <Legendario> mok0, dh_testdir is there. So I am just going to put your statement in it.
[21:29] <mok0> Legendario: if it works, patch upstream's Makefile to create a directory $DESTDIR/usr/share/applications
[21:30] <Legendario> mok0, ok.
[21:32] <torkel> siretart: so far I have had better luck by removing mtab and resolv.conf from the nfsroot and using unionfs that using aufs.
[21:33] <torkel> siretart: I'm not sure what goes wrong with aufs though
[21:46] <protonchris> ScottK2: Do you mind taking a look at bug 190744 and giving it another ACK if you are still ok with it.  You ACKed it before, but there have been a lot of changes and I want to make sure that motu-release is ok with it before I subscribe u-u-s.
[21:52] <ScottK2> protonchris: Looking
[21:53] <protonchris> ScottK2: thanks
[21:53] <ScottK2> protonchris: Done
[22:17] <emgent> heya people
[22:36] <reduz> Hi People! Any chance I can get my app ChibiTracker (http://www.chibitracker.com) packaged and included in Ubuntu? I don't run Ubuntu myself (so i can't package it) but I get several emails from users asking why it is not available for Ubuntu
[22:36] <reduz> The app is pretty much finished and stable, and has very minimum dependencies
[22:38] <mok0> reduz: what's the license?
[22:38] <reduz> GPL v2
[22:39] <RainCT> reduz: Hi. There's feature freeze now for Hardy, so you have two options: a) Wait and get it into Intrepid, or b) Get a Feature Freeze exception for Hardy
[22:39] <mok0> I'll file a needs-packaging bug for it, then people can pick it up for intrepid
[22:40] <reduz> RainCT, I'm fine if it's up for intrepid, i really have no hurry myself
[22:40] <reduz> mok0, thanks!
[22:40] <mok0> reduz: np
[22:46] <mok0> reduz: bug 200783
[22:46] <mok0> https://bugs.edge.launchpad.net/ubuntu/+bug/200783
[22:46] <ubotwo> Launchpad bug 200783 in ubuntu "[needs-packaging] ChibiTracker -- a portable impulse tracker" [Undecided,New] https://launchpad.net/bugs/200783
[22:47] <ubotwo> Launchpad bug 200783 in ubuntu "[needs-packaging] ChibiTracker -- a portable impulse tracker" [Undecided,New]
[22:47] <mok0> ubotu, where are you?
[22:53] <awen_> how do you make a watch-file if the version is included twice in the url? ... like http://sk1project.org/downloads/uniconvertor/v1.1.1/uniconvertor-1.1.1.tar.gz
[23:36] <Legendario> mok0, it worked. Now i just need you guys to review it on http://revu.tauware.de/details.py?package=lives
[23:36] <mok0> Legendario: great
[23:36] <Legendario> and figure out how to make a patch... :-D
[23:36] <mok0> good for you!
[23:38] <Legendario> mok0, thanks for all the help
[23:38] <mok0> Legendario: np!
[23:40] <Legendario> mok0, only one thing: what file should i patch? The makefile.in or makefile.am?
[23:40] <mok0> Legendario: Makefile.am
[23:40] <Legendario> ok
[23:40] <mok0> Legendario: and then you need to re-run automake and autoconf
[23:41] <mok0> Legendario: It is questionable if it's the best solution
[23:42] <Legendario> mok0, what?
[23:43] <mok0> Well, it's a lot to rebuild the autotools system just because of a missing mkdir statement
[23:44] <mok0> Legendario: send the patch upstream with greetings
[23:44] <mok0> Legendario: and create the directory in debian/rules. That
[23:44] <mok0> s
[23:44] <mok0> what I would do....
[23:45] <dijital1> j /#osx
[23:45] <dijital1> hmmm
[23:48] <Legendario> mok0, ok. that's what i am going to do either...
[23:48] <Legendario> ;-)
[23:49] <mok0> Legendario: of two evils, choose the lesser :-)


[08:08] <coalwater> ClaseBot: poke
[08:09] <coalwater> hm, pleia2 u around ?
[14:39] <facoman> hola
[14:40] <SergioMeneses> facoman, saludos


[02:05] <nemo> bug #661494
[02:06] <nemo> I was wondering if I could get a response on practicality of my request
[05:59] <kaushal> hi
[05:59] <kaushal> can some one please guide me about https://lists.ubuntu.com/archives/ubuntu-server/2010-November/004806.html ?
[06:01] <ebroder> kaushal: this isn't a support channel. you can get help with server issues in #ubuntu-server
[06:02] <kaushal> ebroder: ok
[06:24] <tjaalton> gobby claims "unknown host" when trying to contact gobby.u.c.. haven't been able to connect in a while. what's up with it?
[06:25] <ebroder> tjaalton: you're using gobby-0.5 with its default port?
[06:25] <tjaalton> ebroder: whatever is in lucid/maverick
[06:25] <ebroder> you need to specifically grab the gobby-0.5 package, and run gobby-0.5 (not just gobby)
[06:25] <tjaalton> great
[06:25] <ebroder> it's been in ubuntu for a while; just hasn't been the default
[06:26] <tjaalton> oh lucid does have that
[07:22] <YokoZar> who took over the papercuts project?
[07:22] <YokoZar> (or is it languishing)
[07:22] <ebroder> i think vish is leading the charge
[07:23] <ebroder> backed up by some combination of jcastro, ivanka, and sense
[07:35] <maco> cjwatson: happy birthday!
[11:15] <cjwatson> maco: thanks :-)
[11:22]  * geser adds the DMB meeting on Monday 19:00 UTC to bdrung's schedule
[12:37] <bdrung> geser: it could be too tight timewise. i'll be there, but i can't promise to be on schedule.
[13:32] <bilalakhtar> Sorry for asking this twice, but:
[13:32] <bilalakhtar> Is bug 668764 suitable to be SRUed?
[13:33] <bilalakhtar> I have a working patch, and there are very few chances of regressions
[13:33] <bilalakhtar> Moreover, the patch is very small
[13:34] <Riddell> bilalakhtar: you should probably subscribe ubuntu-sru and ask
[13:35] <bilalakhtar> Riddell: thanks, doing that. I am asking this on the channel since I can upload to the package, and we should not count on 'a way back' since it has to cross the process once it is in -proposed
[13:36] <bilalakhtar> Even if it doesn't, it SHOULD pass the process
[13:36]  * bilalakhtar stays on the safe side and assigns ubuntu-sru
[14:11] <bdrung> bilalakhtar: yes, that's worth a SRU
[14:11] <bilalakhtar> hmm, okay then, I will upload it to -proposed
[14:12] <bdrung> bilalakhtar: IIRC, the current process is to upload it to -proposed and get it then reviewed
[14:12] <bilalakhtar> bdrung: yes, that is what I know, but I wanted to be a bit more careful :D
[14:13] <bdrung> small bug fixed are worth a sru in most cases
[14:16] <bilalakhtar> bdrung: uploaded to proposed, now waiting for it to be accepted into -proposed and then verified and then checked thoroughly and then moved :D
[14:22] <ScottK> Riddell: Would you please promote libweather-ion5 to main.  It got dropped into Universe by mistake and it's preventing the rest of KDE from building.
[16:13] <biohazard> hi
[16:13] <biohazard> anyone there
[16:13] <biohazard> i need some help
[16:14] <biohazard> could anyone help me
[16:15] <biohazard> could anyone helps me ?
[16:15] <ansgar> biohazard: Try #ubuntu for user support.
[17:12] <pitti> slangasek: I can unreject it, I'll have a look
[17:18] <pitti> slangasek: done


[03:31] <Matt27> Heyo, I've been struggling with getting cc_chef module running. Keep hitting a `File not found` error and I've got 0 clue what I'm missing
[03:32] <Matt27> https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-and-run-chef-recipes
[03:32] <Matt27> My cloud-init file has lines 51-86 in it. Anything obvious that I'm missing/messing up?
[03:33] <Matt27> 2022-10-31 03:28:53,217 - util.py[DEBUG]: Running module chef (<module 'cloudinit.config.cc_chef' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_chef.py'>) failed
[03:33] <Matt27> Traceback (most recent call last):
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/stages.py", line 876, in _run_modules
[03:33] <Matt27>     freq=freq)
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/cloud.py", line 54, in run
[03:33] <Matt27>     return self._runners.run(name, functor, args, freq, clear_on_fail)
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/helpers.py", line 185, in run
[03:33] <Matt27>     results = functor(*args)
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/config/cc_chef.py", line 508, in handle
[03:33] <Matt27>     util.ensure_dirs(param_paths)
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/util.py", line 1535, in ensure_dirs
[03:33] <Matt27>     ensure_dir(d, mode)
[03:33] <Matt27>   File "/usr/lib/python3.6/site-packages/cloudinit/util.py", line 1588, in ensure_dir
[03:33] <Matt27>     os.makedirs(path)
[03:33] <Matt27>   File "/usr/lib64/python3.6/os.py", line 220, in makedirs
[03:33] <Matt27>     mkdir(name, mode)
[03:33] <Matt27> FileNotFoundError: [Errno 2] No such file or directory: ''
[03:36] <Matt27> I've gone through the source code and really the only thing I can see is I haven't specified validation_key https://github.com/canonical/cloud-init/blob/49e01b4298252c1405cbbf316f5433f371c2cc75/cloudinit/config/cc_chef.py#L70 but I think in the chef template the key is passed through via the cert? I'm super new to cloud-init so its been a steep
[03:36] <Matt27> learning curve lol
[04:36] <Matt27> Also just looking a bit further into this, seems like 'chef_license' is being added into the CHEF_RB_TPL_PATH_KEYS and causing issues. My python is pretty average, so would this be getting set here: https://github.com/canonical/cloud-init/blob/49e01b4298252c1405cbbf316f5433f371c2cc75/cloudinit/config/cc_chef.py#L88
[04:36] <Matt27> I can't find any other reference to the chef_license, and its somehow ending up in the PATH_KEYS var
[04:38] <Matt27> It gets set on https://github.com/canonical/cloud-init/blob/49e01b4298252c1405cbbf316f5433f371c2cc75/cloudinit/config/cc_chef.py#L67 but still doesn't reference the chef_license key in the definition, so is there a step I'm missing somewhere?
[14:18] <minimal> is there any way with network-config v1 or v2 to specify ethtool settings (other than WoL) for interfaces?
[17:33] <meena> falcojr: I think https://github.com/canonical/cloud-init/pull/1779 is ready for re* review
[17:33] -ubottu:#cloud-init- Pull 1779 in canonical/cloud-init "Net: add BSD ifconfig(8) parser and state class" [Open]
[18:53] <falcojr> I'll try to get to it soon. The canonical employees are going to be less active this week as we're at an in person engineering meeting all week.
[18:54] <minimal> falcojr: I assume this will impact on the 22.4 release schedule then
[18:55] <falcojr> Bah, yes. Probably next Tuesday.
[20:24] <meena> falcojr: might be good to rework my schedule next week with all of y'all's schedule in mind /cc jrm