[10:36] <Kilos> afternoon everyone
[10:36] <Kilos> lurkers as well
[10:44] <hibana> hello world
[10:44] <Kilos> oh my goodness
[10:44] <Kilos> hows hibana
[10:44]  * hibana struggling without a gui again
[10:44] <Kilos> what happened
[10:45] <hibana> kernel updates including nvidia stuffs broke it all
[10:45] <Kilos> eish
[10:45] <hibana> now I can't even install the new drivers
[10:45] <Kilos> wow
[10:46] <hibana> and I even wasted my bandwidth by downloading the latest oneiric iso
[10:46] <Kilos> i use the default graphics drivers. had too many bad experiences with nvidia and ati drivers after updating
[10:46] <hibana> after writing the iso to usb and booting up it hangs at some stage
[10:47] <Kilos> eish
[10:47] <hibana> now I'm back to try make it work in maverick
[10:48] <Kilos> eina. thats why i am still on maverick as well
[10:48] <Kilos> maverick was a good release
[10:48]  * hibana just wish I could use copy and paste on the cli
[10:48] <Kilos> lol
[10:48] <hibana> then again I think I can
[10:52] <hibana> ahhh...  I just use screen and then I can copy and paste
[10:52]  * hibana busy struggling with NVIDIA-Linux-x86-290.10
[10:53] <Kilos> olg graphics card?
[10:53] <Kilos> old too
[10:54] <hibana> how can I install linux-restricted-modules?
[10:54] <Kilos> on cli?
[10:54] <hibana> linux-restricted-modules is nowhere to be found in the repos
[10:54] <Kilos> on maverick?
[10:55] <hibana> the NVIDIA driver requires that
[10:55] <hibana> Kilos: yep on maverick
[10:55] <Kilos> im checking synaptic
[10:57] <hibana> when I run the nvidia installer I get to a point where it says "The distribution-provided pre-install script failed!"
[10:57] <Kilos> dont see it in synaptic
[10:57] <Kilos> what does aptitude say
[10:58] <hibana> Kilos: nope, it's not there
[10:58] <Kilos> eish
[10:59] <nlsthzn> Hi ZA
[10:59] <Kilos> Couldn't find any package whose name or description matched "linux-restricted-modules"
[10:59] <Kilos> cant be in the repos
[10:59] <Kilos> hiya nlsthzn
[11:00] <Kilos> how do you install linux-restricted-modules
[11:00] <tumbleweed> hibana: don't run the nvidia installer, install the nvidia drivers through your package manager
[11:00] <Kilos> not in repos
[11:00] <hibana> tumbleweed: hmm.. I read that somewhere before
[11:00] <hibana> how do I know what to install
[11:01] <hibana> I had it running perfectly before the upgrade
[11:01] <hibana> and still have some nvidia packages installed
[11:01] <tumbleweed> hibana: generally speaking, installing things from the Ubuntu repositories is safe (otherwise the packages wouldn't be in Ubuntu)
[11:01] <tumbleweed> but installing random stuff you download off the internet. Well, who knows what that'll do
[11:02] <hibana> tumbleweed: I tend to agree with that
[11:02] <tumbleweed> uninstalling the nvidia drivers that nvidia provide is nigh impossible, they aren't designed to ever be uninstalled
[11:03] <hibana> tumbleweed: so where do I start? I have not yet installed the NVIDIA version
[11:03] <Kilos> hibana, what if you purge and use nouveau drivers
[11:04] <tumbleweed> hibana: install the nvidia-current package (if you need nvidia proprietory drivers)
[11:04] <Kilos> hiya tumbleweed you been through this before looks like
[11:05] <tumbleweed> Kilos: yeah, it crops up every now and then
[11:05] <hibana> tumbleweed: it is and was installed
[11:05] <Kilos> hehe
[11:06] <tumbleweed> hibana: and it's not working?
[11:06] <hibana> tumbleweed: should I try purging all nvidia packages?
[11:07] <hibana> how do I list installed packages without the description?
[11:07] <hibana> with aptitude
[11:09] <hibana> can I use pastebin on the cli?
[11:10] <Kilos> eish
[11:12] <hibana> hmm... lunchtime
[11:12]  * hibana wbb
[11:13] <Kilos> enjoy
[11:13] <Kilos> you can browse hey?
[11:27]  * hibana is back
[11:27] <Kilos> wow that was quick
[11:27] <Kilos> can you browse hibana
[11:27] <hibana> Kilos: I don't want to waste your time :-)
[11:27] <Kilos> i asked maaz to google
[11:27] <Kilos> lol thats all i got is time
[11:28] <hibana> tumbleweed: is there no pastebin app for the cli?
[11:28] <Kilos> got 2 links might help you
[11:29] <hibana> Kilos: I can browse with elinks
[11:29] <hibana> or links
[11:29] <hibana> or any of the other textmode browsers
[11:30] <Kilos> http://www.ubuntugeek.com/ubuntu-edgy-upgrade-common-problems-with-solutions.html
[11:30] <hibana> yikes, that's long
[11:30] <Kilos> http://www.ubuntugeek.com/common-problems-and-solutions-for-nvidia-restricted-drivers-after-ubuntu-810-intrepid-ibex-upgrade.html
[11:31] <Kilos> i dunno how to shorten them
[11:31] <tumbleweed> hibana: pastebinit
[11:31] <Kilos> they are old releases though
[11:31] <hibana> Kilos: no worriess
[11:32] <hibana> tumbleweed: great, thanks
[11:33] <tumbleweed> hibana: deleting your xorg.conf should switch you back to nouveau and you should be able to have a working GUI
[11:34] <tumbleweed> (err, unless the nvidia driver is still getting loadded early in boot.  I never remember how this all works, and don't have any ubuntu machines here with nvidia)
[11:34] <hibana> tumbleweed: http://pastebin.com/XMAbUmzc
[11:35] <hibana> those are all my installed nvidia stuffs
[11:36] <hibana> tumbleweed: let me try removing xorg and rebooting... I doubt that it will work... but I can try
[11:36] <hibana> but before I go there
[11:36] <hibana> let me give you my output of lspci
[11:37] <hibana> http://pastebin.com/LthXF5U3
[11:37]  * hibana <3 pastebinit
[11:38]  * hibana wbb
[11:38] <tumbleweed> hibana: check for anything blacklisting nouveau in /etc/modprobe.d
[11:39] <hibana> hmm... just got that... hang on
[11:41] <hibana> tumbleweed: http://pastebin.com/6fpv0bQY
[11:41] <hibana> tumbleweed: I guess those should not be blacklisted for now?
[11:42] <tumbleweed> if you want nouveau, then yes
[11:42] <tumbleweed> and blacklist nvidia instead
[11:43] <hibana> ahh... but let me try without xorg.conf first
[11:43]  * hibana wbb
[11:47]  * hibana just started irssi in a screen session on some remote system
[11:47]  * hibana wbb
[11:52] <inetpro> ok I'm back in the GUI but had to use nomodeset
[11:52] <inetpro> tumbleweed: ^^
[11:54] <tumbleweed> that presumably makes you happier :)
[11:54] <inetpro> damn...
[11:55] <inetpro> but now how the heck do I get the driver running properly
[11:55] <tumbleweed> what release are you on? what happened?
[11:55] <inetpro> tumbleweed: maverick
[11:57] <tumbleweed> so, presumably it was the linux security update 5 days ago that broke your setup?
[11:57] <inetpro> tumbleweed: very possible
[11:59] <inetpro> to be honest it all started yesterday evening when I switched my laptop on (after hybernating the previous evening)
[11:59] <tumbleweed> oh, I thought you said you'd just installed updates?
[11:59] <inetpro> suddenly my wireless network was dead
[12:00] <inetpro> so I plugged in the network cable and did a update
[12:00] <inetpro> then the update installed the latest kernel and a long list of other stuffs
[12:01] <inetpro> my previous updates were on the 17th according to my logs
[12:02] <inetpro> what is strange is that I've been working on this thing every day since then
[12:02] <tumbleweed> I can't see anyone else complaining about similar issues
[12:04] <inetpro> cat /var/log/dpkg.log | pastebinit -i -  # http://pastebin.com/CKY8LF77
[12:05] <tumbleweed> nvidia-current 285.05.09-0ubuntu1~maverick~xup1
[12:05] <tumbleweed> that's not a version in the official repositories
[12:06] <tumbleweed> are you using some crazy PPA?
[12:06] <inetpro> tumbleweed: hmm...
[12:06] <inetpro> let me see
[12:10] <inetpro> tumbleweed: grep -ih ppa /etc/apt/*/* | egrep -v "^#|^deb-src" | pastebinit -i - # http://pastebin.com/mJjyep53
[12:10] <inetpro> those are all the ppa's that I use
[12:10] <tumbleweed> ubuntu-x-swat <- just as I thought
[12:10] <inetpro> not sure where I got ubuntu-x-swat from
[12:11] <tumbleweed> there's a package called ppa-purge that can help clean that sort of thing up
[12:12] <tumbleweed> when yo uare getting something as core as a graphics driver from a PPA, expect occasional breakage
[12:12] <tumbleweed> kernel updates have massive QA doen before they ship
[12:12] <tumbleweed> but nobody 's going to check them against drivers in PPAs
[12:13] <inetpro> yikes
[12:13] <inetpro> obviously
[12:18]  * inetpro running ppa-purge ppa:ubuntu-x-swat/x-updates
[12:19] <inetpro> tumbleweed: thanks for the help so far
[12:21] <inetpro> ok, I guess this calls for a renoot?
[12:21] <inetpro> reboot*
[12:21] <Kilos> lol
[12:23] <inetpro> Eish!
[12:23] <Kilos> what now
[12:23] <inetpro> Inetpro on mobile
[12:24] <Kilos> oh my
[12:24] <inetpro> Screen still with big white blocks as before
[12:25] <Kilos> eina
[12:27] <inetpro> Need to start with nomodeset
[12:28] <tumbleweed> inetpro: you may need to rebuild your initrd
[12:28] <inetpro> ok... back online with yucky resolution
[12:29] <inetpro> tumbleweed: how?
[12:29] <tumbleweed> did you reverse the blacklistings yet?
[12:29] <inetpro> no
[12:30] <tumbleweed> first do that
[12:30] <tumbleweed> then run update-initramfs -u
[12:31] <inetpro> hmm... hang on
[12:31] <inetpro> in /etc/modprobe.d/nvidia-graphics-drivers.conf I have the following
[12:31] <inetpro> blacklist nouveau
[12:31] <inetpro> blacklist lbm-nouveau
[12:31] <inetpro> blacklist nvidia-173
[12:31] <inetpro> blacklist nvidia-96
[12:32] <inetpro> tumbleweed: what do you suggest I do?
[12:32] <tumbleweed> sounds good
[12:33] <inetpro> should I run  update-initramfs -u ?
[12:33] <tumbleweed> err, maybe you want to unblacklist the nvidia-* ones first
[12:33] <inetpro> ahh.. I thought so
[12:33] <inetpro> ok, hang on
[12:34] <inetpro> Rebooting
[12:35] <inetpro> Eish! No...
[12:35] <inetpro> Same thing
[12:38] <inetpro> tumbleweed: next step?
[12:42]  * inetpro reading https://help.ubuntu.com/community/NvidiaManual
[12:43] <inetpro> again
[12:48] <tumbleweed> inetpro: dmesg output, please
[12:49] <inetpro> # dmesg | pastebinit -i - # http://pastebin.com/JCAG0HuF
[12:50] <tumbleweed> the nvidia driver never loaded
[12:51] <tumbleweed> does modprobe nvidia load it?
[12:51] <tumbleweed> you have a very noisy wireless card :P
[12:51] <tumbleweed> oh, sorry, nouveau loaded
[12:51] <inetpro> tumbleweed: true
[12:51] <tumbleweed> I thought you blacklisted it?
[12:51] <inetpro> hmm... I have
[12:52] <tumbleweed> and then regenerated the initramfs, right?
[12:52] <tumbleweed> it loaded during initramfs execution
[12:53] <inetpro> tumbleweed: nope, have not done that
[12:53] <inetpro> hang on
[12:54] <inetpro> tumbleweed: guess I should reboot again?
[12:54] <tumbleweed> yes
[12:57] <inetpro> no, same thing
[12:58] <inetpro> # dmesg | pastebinit -i - # http://pastebin.com/J9ic0Vr0
[13:01] <inetpro> # cat /etc/modprobe.d/nvidia-kernel-nkc.conf
[13:01] <inetpro> alias char-major-195* nvidia
[13:02] <inetpro> options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660
[13:02] <inetpro> # cat /etc/modprobe.d/nvidia-graphics-drivers.conf
[13:02] <inetpro> blacklist nouveau
[13:02] <inetpro> blacklist lbm-nouveau
[13:02] <inetpro> #blacklist nvidia-173
[13:02] <inetpro> #blacklist nvidia-96
[13:03] <tumbleweed> what was the output when you regenerated teh initramfs?
[13:03] <tumbleweed> (do it again)
[13:03] <inetpro> # update-initramfs -u
[13:03] <inetpro> update-initramfs: Generating /boot/initrd.img-2.6.35-31-generic
[13:03] <inetpro> taht's it
[13:04] <tumbleweed> hrm, seems right
[13:05] <inetpro> tumbleweed: you wanna see the verbose output ?
[13:05] <tumbleweed> sure
[13:05] <inetpro> http://pastebin.com/JbfE0qqS
[13:08] <tumbleweed> clearly I'm missing something, but I can't see what
[13:10] <inetpro> tumbleweed: if we can fix this in the standard ubuntu I'm sure we will have a lot of other happy customers
[13:11] <tumbleweed> inetpro: it's not a problem in standard ubuntu
[13:11] <inetpro> I tried the latest version of ubuntu
[13:11] <inetpro> it does the same thing
[13:11] <inetpro> I can start with a clean install if you want
[13:11] <tumbleweed> and then enabled a ppa with the lastest X crack
[13:12] <tumbleweed> I'm sure the solution to the problem in front of you right now is simple, but I'm afraid that I can't see it
[13:13] <tumbleweed> maybe a clean install is your easiest way out
[13:13] <inetpro> I have Ubuntu Oneiric with me on another usb disk
[13:13] <inetpro> sadly my kubuntu one doesn't work
[13:13] <inetpro> ok, let me get that going
[13:14] <inetpro> I'll be back after installing quassel-client
[13:14] <inetpro> time for me to play with unity
[13:17] <inetpro> I'll call missionX
[13:19] <inetpro> Starting
[13:19] <inetpro> Hmm
[13:20] <inetpro> Starting installation with nomodeset
[13:25] <inetpro> Eish...
[13:27] <inetpro> ubiquity takes for ever and then crashes
[13:31] <inetpro> I'm stumped! Will have to find something else.
[13:31] <tumbleweed> why are you using nomodeset everywhere?
[13:32] <inetpro> What can I use if otherwise I can not get into the gui?
[13:33] <tumbleweed> that sounds like you may have bigger problems
[13:33] <tumbleweed> nouveau should support that card just fine
[13:34] <inetpro> I just get a big maze of white blocks on the screen if I don't use nomodeset
[13:34] <inetpro> And so do colleagues with the same hardware
[13:35] <tumbleweed> from the live CD?
[13:35] <inetpro> Yep
[13:35] <tumbleweed> what hardware?
[13:36] <inetpro> Mecer
[13:36] <inetpro> Model: W86CU
[13:43] <tumbleweed> that looks rather like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657736
[13:46] <inetpro> Very similar yes
[14:15] <Kilos> eish inetpro this is a stinker hey?
[14:28] <inetpro> Kilos: I will win it in the end
[14:29] <Kilos> its hard to understand how this happens when it was working before
[14:31] <inetpro> watch this space
[14:35] <Kilos> ok
[14:53] <inetpro> Kilos: the only problem is that there's other life as well
[14:54] <Kilos> lol
[14:54]  * inetpro trying to resize my casper-rw loop file
[14:55] <inetpro> think that is what's killing ubiquity
[14:55]  * inetpro found http://www.pendrivelinux.com/how-to-create-a-larger-casper-rw-loop-file/
[14:55] <Kilos> you having this prob on a clean install?
[14:56] <inetpro> Kilos: I'm not even there yet
[14:56] <inetpro> the installer crashes
[14:56] <Kilos> maverick as well?
[14:57] <inetpro> no oneiric but it has nothing to do with the distro or version
[14:57] <inetpro> I installed some additional stuffs on the live disk
[14:58] <Kilos> you added stuff to the iso then burned a cd?
[14:59] <inetpro> no
[14:59] <inetpro> while running off the live cd I installed stuff
[14:59] <Kilos> so what additional stuff then?
[14:59] <inetpro> s/live cd/live usb disk/
[15:00] <Kilos> ok
[15:00] <Kilos> but clean install will forst format then start to install
[15:00] <inetpro> like gnome-tweak-* screen, ++
[15:00] <Kilos> i lost now
[15:01] <inetpro> Kilos: you can run your OS from a live disk without installing
[15:01] <Kilos> didnt know you can install stuff then clean install
[15:01] <Kilos> yes
[15:01] <inetpro> a usb drive is rw
[15:02] <inetpro> read and write
[15:02] <Kilos> but dont you first have to mount the drive then do that
[15:02] <inetpro> Kilos: heh, it's mounted during the boot process
[15:03] <Kilos> is it if you are running from the live cd?
[15:03] <Kilos> i had to manually mount from live cd to fix grub
[15:11] <inetpro> Kilos: yes, while running on the live cd I installed additional stuff
[15:11] <inetpro> s/cd/usb/
[15:17] <inetpro> Kilos: the stuff that gets installed on the live disk lives in a file called casper-rw on the CD or the USB
[15:17] <Kilos> ah
[15:17] <inetpro> that file is actually just another raw partition
[15:18] <inetpro> or another ISO in itself
[15:32] <inetpro> ok the problem with ubiquity crashing was not the size
[15:33]  * inetpro busy running apt-get upgrade on the bigger live disk
[15:33] <inetpro> perhaps that will sort it
[15:39] <inetpro> hmm... this will take a while... now on 30%
[16:05] <Kilos> sjoe
[16:16] <nlsthzn> Hi all... seems my first install of Wordpress is now finally working \o/
[16:16] <superfly> ohi nlsthzn
[16:16] <nlsthzn> hey superfly :)
[16:17] <superfly> I don't know WordPress anymore... I know Drupal better, so these days it's easier and faster to do what I want in Drupal
[16:19] <nlsthzn> Cool, I don't know any of them... this is my first "server" etc...
[16:24] <Kilos> hi nlsthzn superfly
[16:39] <nlsthzn> Hi again uncle Kilos
[16:39] <Kilos> hehe
[16:44] <Kilos> goosie wen jy??
[16:45] <Kilos> inetpro, ^^
[16:45] <Kilos> hibana, ^^
[16:46] <Kilos> Maaz, coffee on
[16:46]  * Maaz puts the kettle on
[16:47] <nlsthzn> Maaz, tea please
[16:47] <Maaz> As soon as the kettle boils I will pour boiling water into your cup if you have the tea bag in already
[16:47] <nlsthzn> thanks Maaz
[16:48] <Kilos> 4 more days nlsthzn
[16:48] <nlsthzn> \o/
[16:50] <Maaz> Coffee's ready for Kilos!
[16:50] <Kilos> Maaz, ty
[16:50] <Maaz> Enjoy Kilos
[16:50] <nlsthzn> Maaz, thanks
[16:50] <Maaz> nlsthzn: Okay :-)
[17:49] <Kilos> looks like inetpro has blown up his pc or else gone fishing
[17:53] <inetpro> eish Kilos
[17:54] <inetpro> had to fetch kids and have dinner and all kinds of stuff in between
[17:54] <Kilos> wat gaan aan boetie
[17:54] <Kilos> lol ok
[17:54] <inetpro> updates take way to much space
[17:55] <inetpro> 1GB is not enough these days
[17:55] <Kilos> are you updating the usb drive?
[17:55] <inetpro> Kilos: yep and the thing was full again
[17:55] <Kilos> eish
[17:55] <inetpro> did some cleaning and broke libreoffice
[17:56] <inetpro> thought I would get away with that
[17:56] <Kilos> why not install and get it working then use remastersys to burn a dvd of your whole system
[17:56] <inetpro> but ubiquity wants everything up to date before it will be happy
[17:57] <Kilos> eish
[17:57]  * inetpro learned the hard way now
[17:57] <inetpro> don't let the system learn about new updates
[17:57] <Kilos> and its all bandwidth lost every time
[17:57] <inetpro> or it will want them all
[17:58] <Kilos> thats part of the reason i turned off updates
[17:58] <inetpro> but Kilos I must say the new ubuntu looks like you can work with it
[17:58] <Kilos> firefox alone used to kill me
[17:58] <Kilos> unity?
[17:58] <inetpro> yep
[17:59] <inetpro> but gimme some time before I tell you that it's nice
[17:59] <Kilos> lol
[17:59] <Kilos> gnome is nice
[18:39] <Kilos> night all. have a good successful evening and sleep tight
[18:43] <nlsthzn> Good night ZA
[19:01] <inetpro> eish... I give up for now with installing ubuntu
[19:01] <inetpro> ubiquity keeps crashing even after everything is updated
[19:02]  * inetpro is back on a kubuntu with yucky resolution
[19:04] <inetpro> am contemplating installing SUSE or something else
[19:04] <inetpro> or mint
[19:04] <inetpro> just can't waste to much bandwidth right now
[19:11] <inetpro> hmm... what's wrong with za.archive.ubuntu.com again?
[19:11] <Kerbero> no idea
[19:11] <Kerbero> but i saw that too
[19:11] <Kerbero> thought it was our network
[19:12] <inetpro> what other local repos do we have?
[19:12] <Kerbero> ftp.sun.ac.za
[19:13] <inetpro> thanks
[19:13] <Kerbero> np
[19:14] <Kerbero> ftp.sun is my primary repo
[19:14] <Kerbero> mirror.ac fallback
[19:14] <inetpro> can I use variables in the sources.list file?
[19:14] <inetpro> bad idea to replace all those lines every time you want to change a repo
[19:15] <Kerbero> copy paste
[19:15] <Kerbero> gedit -> replace
[19:15] <Kerbero> lol
[19:19] <superfly> inetpro: sources.list.mirror, sources.list.sun, etc
[19:19] <superfly> then just symlink the one you want
[19:20] <inetpro> superfly: hang on please go slow there
[19:20] <inetpro> I'm very tired of struggling by now :-(
[19:20] <inetpro> superfly: please explain that
[19:20] <superfly> inetpro: create separate files, so that each file contains that particular repo
[19:21] <inetpro> ahh
[19:21] <superfly> so, sources.list.sun contains the ftp.sun.ac.za repo
[19:21] <superfly> then you just create sources.list as a symlink to the particular one you want
[19:21] <inetpro> I gues the sun repos need to have ftp:// in front?
[19:23] <inetpro> eish
[19:24] <inetpro> I can't even get to ftp.sun.ac.za
[19:24] <inetpro> Telkom routing ftl!
[19:24] <inetpro> HOP 13  <IP_ADDRESS>  179.620 ms !X  178.880 ms !X  170.909 ms !X
[19:31] <inetpro> tumbleweed: now here's something I ddn't get before
[19:31] <inetpro> http://pastebin.com/91BNrCyE
[19:32]  * inetpro going to try rebooting again
[19:34] <inetpro> damn!
[19:34] <inetpro> now I need to make sure about this
[19:34] <inetpro> it started without having to do nomodeset
[19:35] <inetpro> but it was as if I had it set
[19:35] <inetpro> bad resolution... everything big
[19:35] <inetpro> now if only tumbleweed was still around
[19:37] <inetpro> that is after I set the repo to just archive.ubuntu.com
[19:37] <inetpro> perhaps za.archive may have played a role in messing up my working system?
[19:42] <inetpro> tumbleweed: my new dmesg >> http://pastebin.com/6rm0NuDE
[19:55] <inetpro> now where do I find linux-source-2.6.35-31-generic
[19:55] <inetpro> for maverick
[20:10] <superfly> inetpro: did you try https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657736/comments/45 ?
[20:11] <inetpro> superfly: where do I find the Additional Drivers feature?
[20:12] <superfly> inetpro: Kubuntu? K menu -> Applications -> System -> Additional Drivers
[20:13] <inetpro> superfly: ahh...
[20:13] <inetpro> doing that now
[20:15] <inetpro> superfly: no
[20:15] <inetpro> it found two drivers, NVIDIA accelerated graphics driver and Software modem
[20:16] <inetpro> both are perfectly installed and currently in use
[20:16] <inetpro> but I noticed something else
[20:17] <inetpro> on that same menu I see NVIDIA X server settings
[20:17] <inetpro> when I open that I get "You do not appear to be using the NVIDIA X driver.  Please edit your X configuration file (just run `nvidia-xconfig` as root), and restart the X server."
[20:19] <superfly> inetpro: try that
[20:19] <inetpro> have now run that with 'sudo nvidia-xconfig' and am about to restart
[20:19] <inetpro> Using X configuration file: "/etc/X11/xorg.conf".
[20:19] <inetpro> Backed up file '/etc/X11/xorg.conf' as '/etc/X11/xorg.conf.backup'
[20:19] <inetpro> New X configuration file written to '/etc/X11/xorg.conf'
[20:20] <inetpro> walla!
[20:21] <inetpro> or rather VOILLA!
[20:21] <superfly> ja, was about to say so
[20:22] <inetpro> UNBELIEVALBLE! That I had to struggle like this
[20:23] <inetpro> tumbleweed, superfly: Thanks for all your help
[20:28] <superfly> np
[21:34]  * hibana going in deep sleep mode again
[21:40] <Kerbero> Symmetria: mirror.ac.za seems down
[21:46] <inetpro> Kerbero: hmm... we need to teach Maaz the email address for the NOC at Tenet
[21:46] <Kerbero>  hehe
[21:46] <Kerbero> yeah
[21:46] <Kerbero> but symmetria said he will still have access to mirror
[21:47] <inetpro> sure, but he's not been very accessible lately
[21:48] <Kerbero> true that
[21:49] <inetpro> good night everyone


[01:01] <ailo_> ScottL, ping
[01:07] <ScottL> ailo_, pong
[01:14] <ailo_> Hi ScottL. Did you read the devel list? Seems like there's someone offering help. Got me thinking. Was going through the wiki pages, trying to find pages dedicated to development.
[01:14] <holstein> http://holstein.shacknet.nu:8227/stream.ogg
[01:15] <ailo_> holstein, alrite. Our favorite jazz radio station.
[01:17] <ailo_> ScottL: Some things have been worked on more than others, like discussing the -controls. But there seems to be a central place missing, where you can see what is being done, what needs to be done, and what is not being done. That sort of thing.
[01:18] <ailo_> ScottL: The new guy is asking for directions, and it would be really easy just to point him to some pages and then discuss what exactly he would like to do, and what needs to be done
[01:18] <ScottL> ailo_, sorry, haven't read much mail today, been working heavily on backporting to lucid
[01:19] <ScottL> ailo_, yeah, that's similar to what holstein suggested, just a nice dev page that links to things going on and where help might be needed
[01:19] <ScottL> just so people can see:  https://launchpad.net/~slavender/+archive/backports-testing/+packages
[01:20] <ailo_> ScottL: How does ther backporting work? You can do that anytime? I saw a wiki about that. I could help out.
[01:20] <ScottL> ailo_, wow, that guy's email sig is fookin' wicked cool :)
[01:21] <ScottL> ailo_,  oh yeah, i'll need people to help test these packages
[01:21] <ScottL> i'm hoping you, holstein, and maybe rlameiro can do help test (i'll test it as well)
[01:21] <ScottL> but my thinking is that the three of you should probably divide up the testing to make it go faster
[01:22] <ailo_> ScottL: How many packages do you have left? When you think you'll be done?
[01:22] <ScottL> once we have two people with success tests who comment in the bug report then i'll post a debdiff and it should be pushed pretty quickly
[01:22] <ScottL> i spoke with ScottK about this yesterday and we knocked out the plan in short order
[01:22] <ScottL> ailo_, re: packages and time - hold on, let me find the link
[01:23] <ScottL> by the way, this is an interesting video about hard real-time and soft real-time
[01:23] <ScottL> http://vimeo.com/6081746
[01:23] <ScottL> ailo_, here's the backports wiki: https://wiki.ubuntu.com/UbuntuStudio/Backports
[01:23] <ScottL> i've been updating it as i get something built or report a bug
[01:24] <ScottL> ailo_,  you could start with the backports from natty if you are interested, that would make a nice division of labor
[01:25] <ailo_> ScottL, Alrite. Nice work. I'll have a look.
[01:25] <ScottL> the idea is that i would _like_ to backport from natty if natty offers a later version of a package
[01:25] <ScottL> but sometimes they depend on a later version of some other package :(
[01:26] <ScottL> and ailo_ , i really recommend test building in a pbuilder environment because it will tell you if it can't satisfy a dependecy in lucid without having to wait for a ppa to build or cluttering up a ppa with a bunch of packages that won't build
[01:27] <ailo_> ScottL, So, the list of backports to Maverick is only started?
[01:27] <ScottL> btw, i'll respond to that email tomorrow morning while i do some other emails
[01:28] <ailo_> ScottL. From: Natty, that is
[01:28] <ScottL> ailo_, these are backports to lucid...from either maverick or natty
[01:28] <ScottL> i only tried to backport qtractor for the natty ones
[01:29] <ScottL> it was because i already had qtractor source code on my machine
[01:30] <ScottL> i am hoping to be done with the maverick backports tomorrow morning, then i get back onto the -lowlatency kernel again
[01:30] <ScottL> that's about 17 hours hence
[01:31] <ailo_> ScottL, Ok. I'll have a look at the Natty packages. It'll probably take a little more time for me to start with.
[01:32] <ScottL> ailo_, the top of the page has this link: https://wiki.ubuntu.com/UbuntuStudio/BackportsHowToHelp
[01:33] <ScottL> it's pretty much a step-by-step guide to do this using qjackctl as an example
[01:33] <ScottL> has lots of good packaging basics in it
[01:33] <ailo_> ScottL, Yep. Thanks. I think I've got all the wiki pages in my bookmarks now, though I may miss new ones, if they are made.
[01:34] <ailo_> I mean newly made pages, I might miss
[01:34] <ailo_> holstein is soloing away :P
[01:55] <ailo_> ScottL, Interesting video, about the -rt stuff!
[01:56] <ScottL> i haven't listened to it all yet, been focusing on the backporting
[01:56] <ScottL> ailo_, i think after natty one of the things i would like to focus on is the documentation, but probably primarily from a user perspective
[01:57] <ScottL> meaning getting work flows fleshed out more and documentation that will help users
[01:57] <ScottL> eh, patchage just took a big dump on me
[01:58] <ScottL> i had been avoiding installing every library and dependency under the sun until i got to patchage
[01:58] <ScottL> that's the nice thing about using pbuilder - it creates a chroot environment that has minimal packages and then when you attempt to build something
[01:59] <ScottL> in it then it realizes what is missing and install those in the pbuilder environment
[01:59] <ScottL> and since this is all temporary, when it's done it just drops everything and your basic system is unmolested
[01:59] <ailo_> ScottL: I think both for users and developers would be a good things. User documentation shouldn't be too hard to work out. There are tons of detailed manuals for most programs, so an Ubuntustudio specific documentation doesn't need to be that extensive. The Ubuntustudio doc on work flows should include most things and explain simply, is what I think.
[02:03] <ScottL> ailo_, that's true....and if we managed to simplify and make our developer documentation more effective then we could probably get more dev help
[02:03] <ailo_> ScottL, I will focus on documentation too, once other things are out of the way. Right now, I'm working a lot on my own stuff as well.
[02:04] <ailo_> ScottL, Pehaps while waiting for the release of Natty +1 alpha 1, I'll have time to work on that type of thing.
[02:05] <ailo_> ScottL, Are you getting a sense of what things are best done in what periods before a release? Perhaps a simple schedule could be made, when it makes most sense to focus on different things?
[02:06] <ailo_> +explaining when*
[02:08] <ailo_> It would be easier to ask for help once things like that are already mapped out. I think many people will have periods of time, when they have a lot of time to help.
[02:09]  * ailo_ is getting some coffee..
[02:36] <ScottL> ailo_, actually, i have been thinking about scheduling
[02:36] <ScottL> mainly because we always seem to be behind the curve LOL
[02:37] <ScottL> ailo_, i don't know if you can see this or not:  https://spreadsheets.google.com/ccc?key=0AkE-Lxi30H8wdGNCTF9fODltNjVOT2dPbm44V3ZLZEE&hl=en&pli=1#gid=0
[02:37] <ScottL> i wanted this just as a reminder to think about things before they're actually needed
[02:37] <ScottL> i also had been thinking about a 'ubuntu studio' google calendar that rlameiro had set up...that would be really nifty to set things up with a reminder
[02:37] <ScottL> and those that want can subscribe
[02:41] <ailo_> ScottL, Sounds like all good ideas to me. Maybe a release schedule, paralell to Ubuntu's would be good too. We should have some deadlines, followed by reviewing and testing for some things.
[02:44] <ScottL> ailo_, that was the general idea between the google calendar and my spreadsheet...just a reminder before something is due
[02:46] <ScottL> ailo_, also, i've started trying to build some of the backports from natty in pbuilder as is (right after apt-get source <package>) just to see if they build in lucid
[02:46] <ScottL> i dont' think many will :(
[02:46] <ScottL> BUT i'm recording what packages are missing for each package that fails to build
[02:47] <ScottL> and i might try to get some of the missing packages backported so we can backport more of our audio packages
[03:09] <ailo_> I think the most important thing for next release is to get the -lowlatency in. I just think that's the most fundamental part for the audio part. ScottL How about starting a duc wiki page on that?
[03:09] <ailo_> doc*
[03:11] <ailo_> Since I have been working on the controls, and even though I have limited experience on software development, I still think I could take charge of laying out some sort of a project planning page on that.
[03:33] <ScottL> ailo_,  here's what i've been working on for release planning: https://wiki.ubuntu.com/UbuntuStudio/ReleasePlanning
[03:33] <ScottL> doesn't mean that's the way it should be though
[03:34] <ailo_> ScottL, I already forgot about that page :P.
[03:35] <ScottL> lol
[03:36] <ScottL> ailo_, i've already gone through the natty backports, this way i can move back into the maverick stuff now that i know the natty package versions won't work
[03:43] <ScottL> hi raony_  :)
[03:46] <raony_> hey scottl :)
[03:46] <raony_> what's up ?
[03:47] <raony_> I'm reading the release plan and the bugs at launchpad ...
[03:49] <raony_> I'm still a bit lost about how to set up a station to actually be able to help !
[03:50] <raony_> it's better if i set up a virtualbox with the natty version of studio ?
[04:00] <ScottL> doh, he's gone already :(
[04:15] <ailo_> raony_, https://wiki.ubuntu.com/UbuntuStudio/ReleasePlanning
[04:15] <raony_> I'm reading
[04:16] <ailo_> raony_, As for software projects, there's the ubuntustudio-controls, which needs some attention.
[04:17] <ailo_> raony_, I've been working on a new version on the ubuntustudio-controls, but what I have done doesn't need to end up in the next release
[04:17] <raony_> what are your changes at this control ?
[04:19] <ailo_> raony_, I've made a new one almost from scratch, since some features have become outdated. Also, there have been some big plans for improving it, but I only got it to do some basic things. Add user to audio group, adjust memlock value and install restricted extras.
[04:23] <ailo_> raony_, It's not packaged yet. For the next release it would be good be more organized with the development of that app. paultag has been helping me with this project.
[04:25] <ailo_> raony_, You don't happen to know much about kernels, by any chance?
[04:25] <raony_> not really :/
[04:26] <raony_> but I'm here to learn :) just need that you guys point me the directions
[04:26] <raony_> what language you guys mainly use ? for example on the studio-controls ?
[04:27] <ailo_> raony_, It's been a python gtk project, though my version also uses shell scripts :/
[04:28] <raony_> well, I know python and shell script :)
[04:28] <raony_> never worked with gtk, but it's time learn !
[04:32] <ailo_> raony_, Here's the source for my version git clone git://gitorious.org/ubuntustudio-controls/ubuntustudio-controls.git ubuntustudio-controls
[04:33] <ailo_> raony_, You'll need to use it on Natty
[04:33] <raony_> how is the natty version of studio ?
[04:34] <ailo_> raony_, And if you decide to try it out, you'll notice from the source that shell scripts should be in /usr/lib/ubuntustudio-controls/ and the audio.conf file should be in /usr/share/ubuntustudio-controls/
[04:34] <raony_> are you using it inside a virtualbox or really installed in your pc ?
[04:34] <ailo_> raony_, I've installed it. It's pretty ok now. I installed ubuntu vanilla, though and added packages onto that.
[04:35] <ailo_> Installed on my machine, that is
[04:35] <raony_> all right, tomorrow I'm installing here and checking your code
[04:36] <ailo_> raony_, See you in tomorrows meeting?
[04:36] <raony_> for sure !
[14:55] <holstein> ailo__: hello :)
[14:55] <holstein> ScottL: morning
[14:56] <ailo__> Afternoon, holstein
[14:56] <raony__> 12:00 here ... :D
[14:57] <holstein> i see a lot of activity in the scroll from last nite
[14:57] <holstein> i'll have to read that
[14:57] <holstein> raony__: o/
[14:58] <raony__> I got the studio natty alpha-3 and I'm planning to install after this meeting
[14:58] <ScottL> morning holstein
[14:58] <holstein> i was just checking the mail to see if that was you raony__
[14:58] <ScottL> hi raony__ and ailo__
[14:58] <holstein> welcom
[14:58] <holstein> e
[14:59] <ScottL> holstein, are you up to finishing the menu update today?
[14:59] <holstein> ScottL: im off this afternoon
[14:59] <holstein> so, i should be able to try
[14:59] <holstein> natty is all updated
[15:00] <holstein> and ready to rock
[15:00] <holstein> ScottL: did you see the mail from erik?
[15:00] <holstein> about the site?
[15:00] <holstein> and not being able to make the meeting?
[15:01] <raony__> I read that, and I believe I can help him since I've been working more with webdevelopment nowadays :)
[15:01] <raony__> what you guys think ?
[15:02] <holstein> raony__: cool, we'll let ScottL know
[15:02] <holstein> and get you guys in touch with each other
[15:02] <Narwhal_Gym_Sock> Hello, all.
[15:02] <holstein> Narwhal_Gym_Sock: hey :)
[15:02] <holstein> paultag: you around?
[15:02] <Narwhal_Gym_Sock> I've been working on the web site as well on the dev list.  My name is Brian.
[15:03] <raony__> Hello Brian!
[15:03] <Narwhal_Gym_Sock> I didn't catch that last conversation, what's been discussed?
[15:03] <holstein> Narwhal_Gym_Sock: nothing yet
[15:03] <holstein> you're just in time :)
[15:03] <holstein> raony__ was offering assistance with the site
[15:03] <Narwhal_Gym_Sock> Excellent!
[15:04] <holstein> Narwhal_Gym_Sock: are you in the position to give a run down?
[15:04] <holstein> on what is going on?
[15:04] <holstein> site-wise
[15:04] <Narwhal_Gym_Sock> Yes, I can do that.
[15:05] <Narwhal_Gym_Sock> I've been working on the Impact theme.  You can see the original discussion for that here:
[15:05] <Narwhal_Gym_Sock> https://wiki.ubuntu.com/UbuntuStudio/TaskWebRevamp
[15:06] <Narwhal_Gym_Sock> The first 'alpha' (so to speak) of the theme is done.  I really just need people to test it.
[15:06] <holstein> COOL
[15:06] <raony__> are you using wordpress for that?
[15:06] <Narwhal_Gym_Sock> It is being done in Drupal.
[15:07] <Narwhal_Gym_Sock> I believe that is mandated by Canonical, although it's fine by me, as I like Drupla.
[15:07] <holstein> Narwhal_Gym_Sock: feel free to link us up in here for testing
[15:07] <holstein> yeah, drupal is nice
[15:07] <holstein> as long as the folk working on it are cool with it
[15:07] <holstein> Narwhal_Gym_Sock: to test, do you need a host?
[15:07] <raony__> indeed ... I prefer drupal :)
[15:08] <Narwhal_Gym_Sock> I'll need to upload the files to my server, then I'll link.  I'll have that done in a few minutes here.  I don't have a dev site running, I just use a local server on my machine (using XAMPP).
[15:08] <holstein> OK
[15:08] <Narwhal_Gym_Sock> So, those testing will need to be doing that, as well.
[15:08] <holstein> i can do that locally here
[15:09] <holstein> i would probably get one of the drupal turnkey linux appliance iso's
[15:09] <holstein> and run it in virtual box
[15:09] <holstein> something easy :)
[15:10] <Narwhal_Gym_Sock> Okay, so I'll get those files ready. They will include just the theme directories, a database for those who care to see the set-up I've been using, and a readme file with some release notes.
[15:10] <holstein> raboof: hey
[15:10] <holstein> https://wiki.ubuntu.com/UbuntuStudio/TaskWebRevamp
[15:10] <holstein> raboof: we were just looking at the site
[15:11] <raboof> hi ;) just curious ;)
[15:11] <holstein> and talking about testing with Narwhal_Gym_Sock
[15:11] <holstein> Narwhal_Gym_Sock: who is the web-team?
[15:11] <holstein> is that pretty much just you and erik right now?
[15:11] <Narwhal_Gym_Sock> Right now it is very bare bones, because I still have no idea what the plan is for the back end.  The theme will work out of the box, though.
[15:11] <Narwhal_Gym_Sock> Yeah, me and Eric and Scott.
[15:12] <holstein> cool
[15:12] <holstein> well, make sure you get raony__ 's info
[15:12] <holstein> if you need extra hands in there
[15:12] <Narwhal_Gym_Sock> I will do that.  And, naturally, we'll take as many helping hands as possible.
[15:13] <holstein> Narwhal_Gym_Sock: and like i said in the email
[15:13] <holstein> i think you guys should feel free to have a seperate meeting
[15:13] <holstein> whenever
[15:13] <holstein> IF needed
[15:13] <holstein> its challenging to find a time that works for everyone
[15:13] <raony__> when this website is supposed to be online ?
[15:14] <holstein> but, i think keeping a regular time will help with attendance
[15:14] <holstein> raony__: good question
[15:14] <raboof> i'd definitely go for shiny or comic rather than punk
[15:14] <Narwhal_Gym_Sock> Right now, it's a 'whenever it gets done' type of thing (like a lot of Linux stuff)
[15:14] <holstein> Narwhal_Gym_Sock: loosely for natty though right?
[15:14] <holstein> or shortly there-after
[15:14] <Narwhal_Gym_Sock> holstein: Natty would be the preference.  At least on my part.
[15:15] <holstein> Narwhal_Gym_Sock: is that realistic?
[15:15] <Narwhal_Gym_Sock> raboof: We'll be using the "Impact" theme for the site.  Although I'm going to try to develop some desktop artwork using the comic style.
[15:15] <raboof> i don't know it, but what i se on the wiki looks good
[15:16] <Narwhal_Gym_Sock> holstein: Not sure.  The theme could definitely be done by them.  As for the rest of it, well, I'm not sure.
[15:16] <holstein> well, i agree, its looking slick
[15:16] <holstein> ScottL: when you get a minute, pop over here, and talk about backporting
[15:17] <Narwhal_Gym_Sock> The whole process as to how we want to organize the content of the site, and then how we get it all uploaded to the server and set up, is still a mystery to me.
[15:17] <holstein> maybe we can get a little unofficial backporting team started
[15:17] <ailo__> Narwhal_Gym_Sock, I see there are some additions intended for the site, like a tutorial section, feature overview. How much of that is done?
[15:17]  * ScottL is catching up on backscroll
[15:17] <ScottL> holstein, i just now read eric's email
[15:17] <ailo__> Narwhal_Gym_Sock, Or maybe it's just easier we try it out
[15:18] <ScottL> Narwhal_Gym_Sock, i'm going to update the list of pages needed for the website for the immediate needs via email shortly
[15:18] <raboof> i'd say put as little content on the site as possible, and litter it with links to the wiki(s)
[15:19] <holstein> ^^ i like that too
[15:19] <raboof> (but don't take me too seriously, i don't even use ubuntu atm :) )
[15:19] <holstein> link to the buntu stuff thats already in place
[15:19] <holstein> ailo__: you want to tell us about the controls thingy?
[15:19] <holstein> that you and paultag are working on?
[15:20] <ailo__> I think we need to organize the wiki, work on documentation for both users and developers. But, I wouldn't mind a feature overview on the main site, with pictures.
[15:20] <holstein> most teams have a wiki team
[15:20] <holstein> maybe we should entertain that for the future
[15:21] <holstein> some folks that keep the studio wiki's clean and up to date
[15:24] <raony__> holstein: I will also try to help ailo with the studio-controls
[15:24] <raony__> he already sent me his code
[15:24] <ailo__> Well, to answer holstein, I've been working on a new version of the ubuntustudio-controls with some help from paultag. It's very simple. Makes it easier for new users to make sure they have realtime privilege. Here's a picture of it http://imagebin.org/141459
[15:25] <holstein> raony__: cool, i just read a little of the exchange you guys had :)
[15:25] <holstein> ailo__: do you need testers yet?
[15:26] <ScottL> so, i'm working on the backports for lucid:  https://wiki.ubuntu.com/UbuntuStudio/Backports
[15:26] <ScottL> there's a list of what i considered and how that played out with trying to backportr
[15:26] <ScottL> sometimes new versions use updated version of other packages that aren't in luid
[15:26] <ailo__> I'm not suggesting we use the code for future releases, though. paultag had an idea of making it pluginable. Also, I guess accessing realtime will change sooner or later too. There have been a lot of ideas on what to add to the controls, so it could be reallly be expanded.
[15:27] <holstein> https://wiki.ubuntu.com/UbuntuStudio/BackportsHowToHelp
[15:27] <ScottL> so say ardour from either maverick or lucid can't be backported to lucid because it requires a later version of a build package than is in lucid
[15:27] <ScottL> but there are still quite a few packages to backport
[15:27] <ScottL> i've build pretty much all of them and will need people to start testing them
[15:27] <holstein> ScottL: and that would be https://launchpad.net/~slavender/+archive/backports-testing/+packages
[15:27] <ScottL> the general plan is that i committed to building them and providing a test as well
[15:27] <ScottL> aye holstein
[15:28] <holstein> cool
[15:28] <holstein> ScottL: so, in lucid, add that PPA
[15:28] <ScottL> then we just need one additional tester to test the package and report on the associated bug report
[15:28] <holstein> and upgrade/test
[15:28] <ailo__> I can help with testing those
[15:28] <ScottL> once we have two testers on record in the bug report the backports team should move pretty quickly to push it into the official backports release
[15:29] <ScottL> i also hope to work on the -lowlatency kernel from instructions that abogani has given me
[15:29] <ScottL> i feel pretty confident that i should get them built today (time permitting of course)
[15:30] <holstein> ScottL: and the plan is to have that in natty?
[15:30] <holstein> as an option?
[15:30] <ScottL> holstein, good question :/
[15:30] <ScottL> persia had wanted to push it into the repos about a month ago (i guess) but it may be too late in the cycle, i'll have to see what his intentions are now
[15:31] <holstein> yeah, we need that kernel
[15:31] <ailo__> Considering how similar the -lowlatency is to the generic kernel, it would make sense to let it in even after feature freeze.
[15:31] <Narwhal_Gym_Sock> Sorry, everyone, my Internet just crapped out.
[15:31] <ScottL> i need to get off my arse about establishing an official Ubuntu Studio PPA so we can dump the -lowlatency kernel (if not in repo) and also an -rt kernel
[15:32] <holstein> ScottL: that would be a PPA we could add 'out of the box' ?
[15:32] <ScottL> ailo__, i got the impression that persia was just going to do it...sounded almost cavalier :P
[15:32] <holstein> ship with?
[15:32] <ailo__> ScottL, It would be great if he did :P
[15:32] <ScottL> holstein, if we updated a package to add the source line to sources.list, then yes
[15:32] <holstein> thats totally fine
[15:32] <holstein> either way then
[15:34] <ailo__> So, Narwhal_Gym_Sock, about the site. How can we test it? We download some files from you and try the site out locally?
[15:34] <ScottL> by the way, if people want to start testing the backports they can
[15:34] <ScottL> https://launchpad.net/~slavender/+archive/backports-testing/+packages
[15:35] <holstein> ScottL: these get backported to lucid or maverick?
[15:35] <holstein> or whatever?
[15:35] <holstein> do they need to be tested in both?
[15:35] <Narwhal_Gym_Sock> ailo: That is correct.  I'm getting those files ready to upload to my website as we speak, and then I'll send a link to everyone.
[15:36] <Narwhal_Gym_Sock> Anyone wanting to test will need to use XAMPP (or something similar).
[15:36] <raony__> why ?
[15:37] <ailo__> Narwhal_Gym_Sock, php and mysql?
[15:38] <Narwhal_Gym_Sock> ailo: Yes.  You will basically need to do a Drupal install yourself on your own local server, and then drop in my theme files and, optionally, upload the database I've been using.
[15:38] <ScottL> holstein, they get backported to lucid...most are coming from maverick and one from natty
[15:39] <ScottL> so just test in lucid
[15:39] <holstein> ScottL: i see
[15:39] <Narwhal_Gym_Sock> ail0: That last part is only necessary if you want to see the basic set-up I've been using.  Otherwise, the theme will work out of the box and you can set up your test site as you'd like.
[15:43] <ailo__> I have a local server running Apache and postgres. Drupal is new to me, so I'll have to see if I can get it all to work.
[15:45] <raony__> I want to ask something, I downloaded studio alpha-3 here to install here, but I tough about trying to upgrade from maverick first, how is that working right now ? I believe is better if I install from zero, am I right ?
[15:46] <holstein> also, http://www.turnkeylinux.org/drupal6
[15:46] <holstein> thats how i probably will do it
[15:46] <Narwhal_Gym_Sock> ailo: I'm not sure, but I believe Drupal needs to use MySQL.  Otherwise, it's really easy to install.
[15:46] <holstein> raony__: fresh install is usually faster
[15:46] <holstein> and preffered
[15:46] <Narwhal_Gym_Sock> Yes, I fresh install will save you many problems.
[15:47] <holstein> IF i were upgrading to natty, i would want to wait til at least beta too
[15:47] <raony__> ok, and what kernel it comes with ? -lowlatency or -rt ?
[15:47] <holstein> just incase
[15:47] <holstein> raony__: -generic
[15:47] <holstein> try it though
[15:47] <raony__> thanks
[15:47] <holstein> i have found that the -lowlatency is working quite well in natty
[15:47] <holstein> with my firewire device
[15:48] <ailo__> The -lowlatency kicks ass.
[15:48] <holstein> yeah ^^
[15:48] <holstein> most folk dont need either though
[15:48] <holstein> but, we need to have -lowlatency i think
[16:04] <holstein> well, i think we all kinda faded out
[16:04] <holstein> but, we got some things done
[16:04] <holstein> discussion mostly, and thats good
[16:05] <holstein> i'll try and paste our meeting in an email here in a bit
[16:05] <holstein> thanks all, ScottL raony__ Narwhal_Gym_Sock raboof ailo__ :)
[16:05] <ailo__> On making things easier for new user: I started working on a script a couple of months ago, that runs at startup to see if the system is tuned or not. Also, I would want to put the -controls in the notification area, where the user can easily find it. Have a button for help there. Let it be pluginable as paultag suggested.
[16:05] <holstein> and any idlers i missed
[16:06] <raboof> ;)
[16:06] <raony__> that's a good idea holstein.
[16:06] <raony__> the natty studio will be release together with the other releases April 28th ?
[16:06] <Narwhal_Gym_Sock> Thanks, everyone, I'll send a link to the site testing files to the list in a few minutes.
[16:07] <ailo__> Next meeting, a month from now?
[16:07] <holstein> ailo__: yup
[16:07] <holstein> first sunday of the month :)
[16:08] <raony__> all right!
[16:08] <ailo__> Sounds almost holy :)
[16:08] <raony__> I'm moving to natty, see you guys !
[16:21] <ScottL> i've done all the building for backporting i'm going to do at the moment, although there are a few notable exceptions in the wiki:
[16:22] <ScottL> alsa-tools: i'd like to research it more to see if this will affect other packages possibly and cause breakage
[16:22] <ScottL> gcdmaster: there already was a backports bug report for this, although i don't know if it will move without us doing something
[16:22] <ScottL> patchage: i need to research this also, nedko kinda makes things build weird and i think i may need to install a lot of packages
[16:23] <ScottL> rakarrack: saving this for holstein to build :)
[16:29] <Narwhal_Gym_Sock> Hey, everyone, here is a link to the website files for those who would like to do testing:
[16:29] <Narwhal_Gym_Sock> http://www.sunmachine.coop/ubuntu/impact_2011-02-26.tar.gz
[16:29] <Narwhal_Gym_Sock> I will send this to the list as well.
[17:32] <ScottL> holstein, do you need any further help with the menu update?
[17:33] <holstein> ScottL: yeah :)
[17:33] <ScottL> which point are you at currently?
[17:35] <ScottL> holstein,  where are you at now?
[17:35] <holstein> same as before
[17:36] <holstein> let me get some things sorted
[17:36] <holstein> and i'll PM you
[17:38] <ScottL> righty-o
[18:44] <ailo__> ScottL, I'll help testing the backports tomorrow. What's the deal then? What kind of comments? If the package is working, we just say it's working?
[18:44] <ailo__> on the bug reports
[18:53] <ScottL> ailo__,  aaaahhhh, i'm not sure exactly on the wording but I think just a note saying that you tested it and it worked
[18:54] <ailo__> ScottL, And then once three of us have confirmed, the packages are fit for baclporting?
[18:55] <ailo__> Was just installing drupal. If I get it going I'll try and share it with you guys. Don't have a lot of bandwidth, though...
[18:56] <ScottL> ailo__, only two confirmed are necessary (actually ScottK said only one was really necessary but normally it's two)
[18:56] <ScottL> and i'm going to test each as well
[18:56] <ScottL> i think if you follow some of the links on this page you will find examples of what worked to get previous backport bugs closed: https://bugs.launchpad.net/lucid-backports/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&fie
[18:56] <ScottL> ld.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
[18:57] <ScottL> ew
[18:58] <ailo__> ScottL, but the links to the bugs are all in https://wiki.ubuntu.com/UbuntuStudio/Backports, right?
[18:58] <ScottL> try this page instead:  https://bugs.launchpad.net/lucid-backports/+bugs?advanced=1
[18:58] <ScottL> under status make sure only "fixed released" is checked
[18:58] <ScottL> ailo__, yes, all links are on that page
[19:30] <ScottL> ailo__, i don't know if you had seen this already:  https://wiki.ubuntu.com/ScottLavender/scratchpad
[19:30] <ScottL> those are my notes from aboganni to build the -lowlatency kernel from his git tree
[19:30] <ScottL> i just ran through it really quick like and without any apparent problems and uploaded my changes to my ppa
[19:31] <ScottL> after it builds (hopefully correctly) i'll feel  100% good about it then
[19:33] <ailo__> ScottL, Nice, How about creating the source tree from scratch (using the Ubuntu kernel source)?
[19:36] <ailo__> The way it seems to be set up is using a sort of -lowlatency patch on top of the -generic, thought the patch is really only changing a few configs from what I can tell. I guess that belongs to what is still a mystical area, namely debian packaging
[19:37] <ailo__> Mystical to me* :)
[19:39] <ailo__> For a short term I think it will be enough just to hang on to those configs, but in the long term, someone will have to follow up on kernel feature updates.
[19:48] <ScottL> ailo__, lol, it tired to build the kernel before it had built the meta so i was missing the source
[19:49] <ScottL> i'll try to force the kernel to build again
[20:50] <holstein> ScottL: did you see my cop-out-ish PM?
[20:50] <holstein> im heading out the door
[20:50] <holstein> i
[20:50] <holstein> 'll
[20:50] <holstein> try and catch up with you later
[20:50] <holstein> and see if i can carve out some time
[20:50] <holstein> good meeting though i thought
[20:51] <ScottL> holstein, oh, lol, actually i didn't till now
[20:51] <ScottL> i can take of it all
[23:32] <ScottL> doh!  my kernel build needs linux-source-2.6.38-5.32 and can't find it :(
[23:38] <ailo__> ScottL, Don't you have the entire source from aboganis git repo?
[23:46] <ScottL> ailo__, i don't know
[23:46] <ScottL> ailo_, ^
[23:46] <ScottL> i thought it would have come with the -meta
[23:46] <ScottL> but i'm pretty ignorant about a lot of these things
[23:47] <ailo_> The -meta should not hold the actual kernel source, right? Only the -lowlatency itself.
[23:47] <ailo_> And the -lowlatency seemed to be identical to a -ceneric source tree, except for some additions. That is the way it seemed to me
[23:47] <ScottL> but then there was a -lowlatency package as well
[23:47] <ScottL> but i looked at all the packages the -meta built and the source is not in there
[23:48] <ScottL> i'll email abogani later tonight about it and he'll probably answer by the time i wake up
[23:49] <ailo_> ScottL, Probably better. :P


[02:48] <mup> PR snapcraft#915 closed: cache: cleanup logic to pass project name <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/915>
[03:12] <mup> PR snapcraft#916 opened: sources: missing command instead of package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/916>
[04:00] <mup> PR snapcraft#917 opened: wip <Created by elopio> <https://github.com/snapcore/snapcraft/pull/917>
[06:51] <mup> PR snapcraft#918 opened: create the deltas package/class with xdetal generation implementation <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/918>
[07:06] <foxmask> bonjello
[08:12] <tvoss> zyga: o/
[09:21] <oSoMoN> Mirv, when running the webbrowser-app snap that depends on ubuntu-app-platform, I’m seeing the following message at app shutdown: "libgcc_s.so.1 must be installed for pthread_cancel to work"
[09:22] <oSoMoN> Mirv, and indeed, usr/lib/x86_64-linux-gnu/libgcc_s.so.1 is not included in the ubuntu-app-platform snap, do you know why? It should be, given that it’s a direct dependency of liboxideqt-qmlplugin
[09:29] <Mirv> oSoMoN: the whole usr/lib is being exported, but it's not there. I guess you mean /lib/ ...
[09:30] <Mirv> oSoMoN: it should be part of Ubuntu Core
[09:30] <Mirv> oSoMoN: at least it looks to be for me
[09:30] <Mirv> oSoMoN: so on my platform using snap there is /lib/x86_64-linux-gnu/libgcc_s.so.1
[09:31] <oSoMoN> Mirv, indeed it’s part of ubuntu-core, but it looks like the app is not seeing it for some reason
[09:37] <oSoMoN> Mirv, I’ve reverted to the version of the webbrowser-app snap that ships all its dependencies (including oxide), and I’m not getting the error message about libgcc_s.so.1
[09:42] <Mirv> oSoMoN: I don't know how it'd be even possible to remove the Core's /lib path from the library search path. looking at the desktop-launch launcher, that also just adds new directories http://pastebin.ubuntu.com/23494754/
[09:43] <Mirv> oSoMoN: I assume your dep including snap has the $SNAP/lib/arch/libgcc_s.so.1 however?
[09:43] <Mirv> oSoMoN: I could export the /lib too from platform snap and add it to LD_LIBRARY_PATH, but I was under impression that would make no sense
[09:45] <oSoMoN> Mirv, I don’t think this should be necessary, it looks to me more like a bug in snappy itself, I’m filing a bug so we can track/investigate it
[09:47] <oSoMoN> Mirv, https://bugs.launchpad.net/snappy/+bug/1642900
[09:47] <mup> Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900>
[09:47] <mup> Bug #1642900 opened: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900>
[10:24] <binchen> hi, i have one question.. how a snap actually call the interface in another snap? I assume there should be some sort of IPC, right?
[10:25] <tvoss> binchen: it depends on the interface, some interfaces sit on top of IPC mechanisms (say DBus), others sit on top of the filesystem
[10:26] <binchen> tvoss: and they are transparent to the user?
[10:26] <tvoss> binchen think about an interface as a means to describe an interaction (arbitrary on purpose) and the permissions that are required to carry out the interaction
[10:26] <tvoss> binchen: transparent as in?
[10:27] <binchen> I mean the user don't aware of or care about what the actually ipc is
[10:28] <binchen> and the producer thus are free the change the way the method is called..
[10:29] <binchen> I come from a Android backgroud, and kind of trying to do a analogy here
[10:30] <binchen> in Android, a component can expose a service/interface through binder
[10:31] <binchen> and will always through binder..
[10:32] <binchen> I'm not sure if it is correct to equivalent a snap interface to the Binder interface though
[10:33] <binchen> http://docs.ubuntu.com/core/en/reference/interfaces
[10:49] <tvoss> binchen: not really, binder would be just another transport
[10:50] <tvoss> binchen: and yes, to a user, the underlying implementation is transparent
[10:51] <binchen> tvoss: pierrchen@localhost:~$ snap interfaces camera
[10:51] <binchen> Slot  Plug
[10:52] <binchen> is this expected? I'm using a kvm , and was trying to see what are included for the camera interface
[10:52] <binchen> I'm expecting see some kind of APIS.
[10:52] <binchen> but may be that expectation is wrong ..
[10:52] <tvoss> binchen: it's not apis, more like functional blocks
[10:52] <tvoss> binchen: an example would be location-observe
[10:53] <binchen> hmm...
[10:53] <binchen> so there is no need to know what are the APIs provided by a snap
[10:53] <binchen> or we just treat them as a whole function??
[10:54] <tvoss> binchen: well, as a package if you want so (to draw an equivalent to Android's java runtime)
[10:54] <tvoss> binchen: so in the snap world, interfaces help to wire functional requirements together
[10:54] <binchen> basically, I'm trying to see how snaps are talk to each others
[10:54] <tvoss> binchen: there is no canonical answer, depends on the functional block
[10:55] <binchen> especially, talk to the core snaps - iiuc, core snaps provided the core functionalitys such as camera, bluetooth,
[10:55] <tvoss> binchen: trying to rephrase: there is not the IPC as in Android, but apps and services are free to use to cover their requirements
[10:55] <binchen> OK, what about the core snapps
[10:55] <tvoss> binchen: nope, the core snap is really lightweight, camera, bluetooth and friends all come in via additional snaps
[10:56] <binchen> how a core snaps provided services to other "user snaps"?
[10:56] <binchen> OK
[10:57] <tvoss> for the core snap specifically, that happens on a filesystem level. the core snap mostly exports libc (I'm oversimplifying here, but I think you get the message)
[10:57] <binchen> is it possible we have two camera snaps, all declare provide camera functionality?
[10:57] <tvoss> binchen: sure
[10:57] <binchen> hm....won't there be problem, say both two camera snaps trying to use the /dev/vidoe nodes?
[10:58] <binchen> and they aren't aware of each other?
[10:59] <tvoss> ah, now we get to an interesting point. sure, but that's where interfaces come in handy, too
[10:59] <binchen> I may still didn't get the exactly meaning of interface here. I thought it is just a interface as it normal mean in java, for example
[11:00] <tvoss> nope, it is not an interface in the software engineering sense
[11:00] <binchen> yeah, I guess that is my biggest confusion so far :)
[11:00] <binchen> as  a software person :)
[11:00] <binchen> it is hard to get my head around that..
[11:01] <tvoss> okay, so let me follow up on your camera example: simultaneous access to /dev/video* whatever is not possible, so you would need an intermediate service, right
[11:01] <tvoss> binchen: no worries :)
[11:01] <binchen> "Interfaces allow snaps to communicate or share resources according to the protocol established by the interface. Each connection has two ends, a "plug" (consumer) and a "slot" (provider). A plug and a slot can be connected if they use the same interface name. The connection grants necessary permissions for snaps to operate according to the protocol."
[11:01] <binchen> from here http://docs.ubuntu.com/core/en/guides/build-device/interfaces
[11:01] <tvoss> the intermediate service, e.g. camera-service snap, would use an interface camera-hw-access
[11:01] <binchen> so what exactly happen after the plug?
[11:02] <binchen> I can understand the concept of plug/slot
[11:02] <tvoss> the interface camera-hw-access would contain code to make sure that camera-service can access /dev/video*
[11:03] <tvoss> applications using the camera would then use camera-service, which in turn could provide a slot for camera-access (note the missing hw :))
[11:03] <binchen> that make sense
[11:04] <binchen> just to make sure I understand you correctly, camera-hw-access is a snap right?
[11:04] <binchen> and it is not provided by canonical? could be anyone?
[11:04] <tvoss> nope, camera-hw-access is an interface, that describes how security policy has to be setup to allow a snap with a camera-hw-access plug to access /dev/video*
[11:04] <binchen> how about camera-service snap? who will provided it? Can we have two?
[11:05] <tvoss> binchen, sure, you can have two camera-service snaps, they both would have a plug for camera-hw-access
[11:05] <binchen> hha..
[11:06] <binchen> so what exactly is the pierrchen@localhost:~$ snap interfaces
[11:06] <binchen> Slot                    Plug
[11:06] <binchen> :bluetooth-control      -
[11:06] <binchen> :camera
[11:06] <binchen> the camera interface here?
[11:07] <binchen> is that the camera-hw or camera-service, or neither?
[11:07] <tvoss> in that list, there is something providing a slot for interface camera
[11:07] <tvoss> that's camera-hw
[11:07] <tvoss> binchen: for reference: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go
[11:07] <binchen> cool!!!
[11:07] <binchen> I guess that is whant I want to check out
[11:07] <tvoss> ack
[11:08] <tvoss> so camera.go is obviously hw and super simple (just access to a bunch of device nodes)
[11:09] <tvoss> a hypothetical camera-observe interface would be more sophisticated, capturing ipc specific requirements etc (in the example of camera service <-> apps)
[11:12] <binchen> is the only operation we can do to interface is to connect and disconnect?
[11:14] <binchen> and after connect it, you are able to access the resource (e.g the dev nodes in camrea interface)  in that package>
[11:15] <tvoss> yup, exactly
[11:16] <binchen> so, it's about security only
[11:17] <binchen> I checked other buildin interfaces
[11:17] <binchen> seems all AppArmor, SecComp related
[11:18] <binchen> so, what is the way to implement normal functionality/API exposing?
[11:19] <binchen> say one snap can do add(), substract()
[11:19] <binchen> and aonther snap want to use that functionality?
[11:20] <tvoss> binchen: so we typically use dbus for that, but the choice is ultimately up to you :)
[11:20] <tvoss> binchen: say you had your own idl/ddl and framework, you could use a unix socket as a transport
[11:20] <binchen> OK..
[11:21] <binchen> I get it
[11:21] <binchen> so the snap is more focus on the security side of things
[11:22] <binchen> its not about the idl/binder/dbus stuff
[11:22] <tvoss> binchen: the key thing really is: snappy does not have an opinion on the way communication is established, it just wants to know certain aspects about the connection (like security) to be able manage connections between plugs and slots for a given interface
[11:22] <tvoss> binchen: precisely that
[11:22] <binchen> I finally get that!
[11:22] <tvoss> binchen: *ideally* existing software would run unmodified.
[11:23] <binchen> yeah, otherwise, much bigger changes
[11:23] <binchen> to the legacy code
[11:24] <binchen> so snap is more a package innovation
[11:24] <binchen> not how you write your software :)
[11:27] <binchen> tvoss: really appreciate you taking your time answer my dumb questions!
[11:28] <tvoss> binchen, happy to, and there is no such thing as a dumb question :)
[11:28] <binchen> I'm heading for bed now. it is 10:30PM.  See you
[11:28] <tvoss> binchen: see you :) have a good night
[11:29] <binchen> have a good day!
[11:29] <tvoss> thx
[11:30] <mup> PR snapcraft#916 closed: sources: missing command instead of package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/916>
[11:33] <mup> PR snapcraft#912 closed: Add a gradle demo and test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/912>
[11:57] <iliv> what are other variables similar to $(DESTDIR) that can be used in custom Makefile's? specifically, I'm wondering if there is a variable that points to parts/$PAR_NAME/build directory?
[13:08] <didrocks> iliv: it's a good question, by convention, this is BUILDDIR in the debian world, but it doesn't seem that snapcraft has anything like this
[13:08] <didrocks> iliv: maybe time to open a feature request, you can override this in a custom plugin (inherited) meanwhile
[13:17] <iliv> didrocks, https://launchpad.net/snapcraft is this the project?
[13:19] <didrocks> iliv: correct!
[13:20] <iliv> diddledan, okay, I'll create a feature request. What are other variables besides $DESTDIR, though? And where can I look them up?
[13:25] <sergiusens> davidcalle dholbach and/or didrocks mind looking at https://github.com/snapcore/snapcraft/pull/919
[13:25] <mup> PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
[13:25] <didrocks> iliv: I just grepped in the snapcraft code directly, like the cmake plugin at snapcraft/plugins/cmake.py
[13:26] <didrocks> sergiusens: davidcalle will have a look (finishing a meeting right now) I think, thanks for the ping!
[13:26] <sergiusens> wait wait, are you a marketting manager now ? :)
[13:26]  * sergiusens does his Friday trol-lol-lol :-)
[13:27] <didrocks> rohlalala :)
[13:27] <mup> PR snapcraft#919 opened: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
[13:27]  * didrocks files more bugs on snapcraft as a revenge :)
[13:28] <sergiusens> didrocks I can just do what other projects do ;-)
[13:28] <sergiusens> wrt bugs
[13:28] <davidcalle> sergiusens: thanks, will have a look in a moment :)
[13:29] <sergiusens> davidcalle great, this will be fluctuating in the coming days as I implement declarative desktop files
[13:30] <davidcalle> sergiusens: 🎆
[13:30] <didrocks> sergiusens: tsssss, you wouldn't go that easy path, would you? :)
[13:30] <sergiusens> didrocks nah
[14:03] <Chipaca> tyhicks, jdstrand, is https://bugs.launchpad.net/snappy/+bug/1611078 actually fixed in xenial via #1628285 or is that separate?
[14:03] <mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <verification-failed-xenial> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <apparmor (Ubuntu
[14:03] <mup> Xenial):Confirmed> <linux (Ubuntu Xenial):Fix Released by jjohansen> <lxd (Ubuntu Xenial):Fix Committed> <apparmor (Ubuntu Yakkety):Fix Released by tyhicks> <linux (Ubuntu Yakkety):Fix Released by jjohansen> <lxd (Ubuntu Yakkety):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
[14:03] <mup> Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu
[14:03] <mup> Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285>
[14:03] <Chipaca> stgraber, and is it fixed in lxd on xenial?
[14:04]  * jdstrand defers to tyhicks
[14:05] <Son_Goku> sergiusens, any luck on the pluggable engines for (stage|build)-packages?
[14:07] <jjohansen> mup: 1611078 is the bug the kernel portion was done under, I believe tyhicks is also doing the user space sru for under that as well
[14:07] <mup> jjohansen: I apologize, but I'm pretty strict about only responding to known commands.
[14:08] <jjohansen> however you will note that the apparmor userspace component is not currently marked fix released for xenial
[14:09] <Chipaca> jjohansen, hence me asking
[14:09] <jjohansen> even the full set of srus, apparmor, kernel, lxd, and fuse there are still some bugs to iron out for some snaps
[14:09] <jjohansen> Chipaca: iirc there was still some verification to be done on the sru
[14:10] <Chipaca> fgimenez was trying to see if https://bugs.launchpad.net/snappy/+bug/1630789 was done, but to verify that from a xenial host is not possible because of this
[14:10] <mup> Bug #1630789: normal users can't run snaps inside of LXD containers <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:In Progress by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix Committed>
[14:10] <mup> <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789>
[14:10] <Chipaca> that is, there's no way for this one to be fixed before that one is fixed :-)
[14:11] <jjohansen> Chipaca: yeah, I would not call this fixed on xenal yep
[14:12] <Chipaca> fgimenez, I think I deserve a cookie for saving you some work. Shame I didn't notice you were doing this before... :-)
[14:12] <jjohansen> which does mean 160789 is not fixed either
[14:12] <Chipaca> jjohansen, that's fine, it's hairy but we'll get it sorted eventually
[14:13] <Chipaca> i don't mean to be rushing anybody, just that we know where we are
[14:13] <jjohansen> Chipaca: we are close
[14:14] <jjohansen> I'm not sure exactly what is left as tyhicks has been handling that while I try to squash bugs
[14:15] <zyga> jjohansen: hey, nice to see you again :)
[14:15] <jjohansen> hey zyga :)
[14:25] <fgimenez> Chipaca, a very big cookie, yes :)
[15:16] <didrocks> jdstrand: hey! so, I'm wondering why your alsa snap doesn't work for me as a snap and works for you (and seb). My only plausible explanation is that the system aplay is using the gstreamer backend and forward it to it, while the version you are shipping don't have that backend and sends directly to the card… My card may not support multiple streams hence the "device is busy" message?
[15:16] <didrocks> s/gstreamer/pulseaudio/
[15:17] <jdstrand> didrocks: I don't know. I git cloned it, snapcrafted it, installed it and it worked
[15:18] <didrocks> jdstrand: you didn't embeeded the pulseaudio configuration files on purpose though, right?
[15:18] <didrocks> or that may be ubuntu patches?
[15:18] <jdstrand> didrocks: I don't know how the locking on all of that works. no I didn't. did they end up there?
[15:19] <jdstrand> didrocks: you saw the snapcraft.yaml, right? I literally stage-packages and ship a few alsa config files. that's it. no source code, nothing fancy
[15:19] <didrocks> jdstrand: they are not in the snap while there is /usr/share/alsa/pulse-alsa.conf and /usr/share/alsa/alsa.conf.d/
[15:19] <didrocks> yeah, the alsa config files are cloned from upstream?
[15:19] <didrocks> (not from our ubuntu package)
[15:20] <didrocks> I thought you copied files from /usr/share/alsa and so, omitted the pulse thingy on purpose
[15:21] <jdstrand> didrocks: /usr/share/alsa/pulse-alsa.conf isn't going to be in the core snap though
[15:21] <jdstrand> didrocks: no. I grabbed those files from the ubuntu packaging
[15:21] <didrocks> I was thinking on the file that you copied in etc/
[15:21] <didrocks> ah interesting
[15:21] <didrocks> they are surely in the pulseaudio package
[15:21] <jdstrand> didrocks: and modified them to work well enough here
[15:22] <didrocks> hum libasound2-plugins:amd64: /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf
[15:22] <didrocks> yeah
[15:22] <jdstrand> $ ls -lR /snap/alsa-utils/current/|grep pulse
[15:22] <didrocks> jdstrand: I really wonder if this isn't card dependent… some accepting multiple streams, other not
[15:22] <jdstrand> [1]
[15:22] <jdstrand> there is nothing in the snap about pulse. I'm confused why you keep talking about pulseaudio files in /usr/share
[15:23] <didrocks> sorry, I probably misexplained myself
[15:23] <jdstrand> I mean, feel free to try to put the pulseaudio file in there-- maybe that works, but since this was about accessing the device directly I was keeping pulseaudio out of it
[15:23] <didrocks> so, my system aplay works well, but not the one from the snap "device is busy" with exactly the same parameters
[15:24] <jdstrand> I see. yeah, I don't know :)
[15:24] <didrocks> the only difference I can think of is that the system aplay, in /usr/share/alsa/ has those pulseaudio config and so, forward it to pulseaudio
[15:24] <jdstrand> like I said, I'm not claiming anything about that snap except that it worked here enough to develop security policy for the interface
[15:24] <didrocks> contrary to the one in the snap, and maybe my card isn't capable of handling multiple stream
[15:24] <didrocks> yeah
[15:25] <didrocks> if I can get it work and forward in pulseaudio, we may need 2 parts
[15:25] <didrocks> once with alsa-with-pulseaudio
[15:25] <didrocks> and one with alsa-only
[15:25] <jdstrand> ah, you are working on the part. ok, now things are making more sense to me :)
[15:25] <didrocks> (one of the example is timidity, which only has alsa support)
[15:25] <didrocks> yeah, but before working on the part, I need to get it working on my desktop :)
[15:25] <jdstrand> I suspect that would make sense-- to try to emulate what we are doing on Ubuntu
[15:26] <didrocks> that's why, out of this theory, I don't understand why it's working for you and not for me
[15:26] <jdstrand> I just don't really have any experience with alsa
[15:26] <didrocks> yeah, same :/
[15:26] <jdstrand> didrocks: perhaps start by forking my branch and then adding those pulse files in usr/share/alsa (modifying as needed)
[15:27] <didrocks> yeah
[15:27] <didrocks> I need to add a lot of pulseaudio libs as well
[15:27] <didrocks> for the module
[15:28] <sergiusens> davidcalle so are we good with snapcraft#919
[15:28] <mup> PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
[15:28] <sergiusens> ?
[15:28] <didrocks> jdstrand: I will just cross fingers that my theory is the correct one :)
[15:33] <jdstrand> didrocks: it wouldn't surprise me if it was. that is a big reason why things like pulseaudio exist-- limitations of hardware
[15:33] <didrocks> yeah, let's cross fingers. I'll keep you posted
[15:38] <tyhicks> Chipaca: Hi - the apparmor userspace fix of bug #1628285 has already landed - I've just updated the bug
[15:38] <mup> Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu
[15:38] <mup> Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285>
[15:39] <tyhicks> Chipaca: last I checked, there was still a kernel change needed to allow fuse filesystems to be mounted inside of user namespaces
[15:40] <tyhicks> Chipaca: you'll probably want to check with stgraber on that remaining issue because, AFAIK, he was handling the squashfuse stuff
[15:43] <stgraber> I believe you still need to manually install squashfuse, that's not something I can do much about though, I've requested the snapd team to make it a dependency quite a while ago...
[15:43] <stgraber> for my part, I made sure squashfuse is available in xenial, yakkety and zesty
[15:44] <stgraber> that's https://bugs.launchpad.net/snappy/+bug/1628289 which is still marked as New against snappy...
[15:44] <mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:New> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
[15:56] <davidcalle> sergiusens: yes, wfm
[15:56] <mterry> So I filed bug 1642350 about snapcraft in Launchpad silently ignoring a stage-package.  Does anyone know why that would happen?
[15:56] <mup> Bug #1642350: webbrowser-app silently being excluded from stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1642350>
[15:57] <stgraber> so quick question, related to https://github.com/snapcore/snapd/pull/2225, what happens if I add a "slots" entry which snapd doesn't know about yet?
[15:57] <mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap (LP: #1634880) <Created by kalikiana> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2225>
[15:58] <stgraber> I'd like to add "slots: [lxd]" to the lxd snap to make that ^ interface useful, but I don't want to suddenly break anyone who doesn't have a recent enough snapd
[16:28] <didrocks> jdstrand: I think the only way to get something clean is to rebuild alsa-lib (but I don't know how to not hardcode /snap). There is no way to define a dynamic plugin directory (for the pulse one)
[16:29] <didrocks> even adding to LD_LIBRARY_PATH, it's still looking at it in /usr/lib…
[16:29] <jdstrand> didrocks: boo :)
[16:29] <jdstrand> didrocks: at least that can be done in a part...
[16:30] <didrocks> jdstrand: yeah… I have a very very big hammer workaround for the deadline at least
[16:42] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/183
[16:42] <mup> PR snap-confine#183: Detach the hostfs version of /sys <Created by zyga> <https://github.com/snapcore/snap-confine/pull/183>
[16:42] <zyga> jdstrand: a trivial branch that may unbreak docker
[16:43] <zyga> jdstrand: the diff is long because of test data changes (but in very expected ways)
[16:43] <zyga> jdstrand: looking at this I'd like to do /dev and /proc as well, this would cut down on weird filesystems showing up twice
[16:44] <zyga> jdstrand: once this lands I'll run a pass of snapd tests against snap-confine master
[16:44] <zyga> jdstrand: and a related apparmor question, is there a confinement option for umount to say unount but only when MNT_DETACH was passed?
[16:46] <zyga> lool: ^^ any opinions on /dev and /proc
[16:47] <lool> zyga: I'd suggest doign the same on devpts, dev and proc
[16:47] <lool> seems consistent since these aren't accessible anyway
[16:47] <zyga> lool: all of /dev (includes devpts)
[16:48] <zyga> lool: yeah, I'll follow up after I get a +1 from jdstrand
[16:48] <zyga> (or tyhicks if he wants to look)
[16:48] <lool> ok; I usually have to bind mount devpts separately in chroots, but I dont know about mount namespaces behavior there
[16:48] <zyga> lool: we have that in /dev
[16:48] <zyga> lool: this is the one from "outside" that nobody is supposed to use anyway
[16:49] <zyga> lool: I think that it makes sense, we want access to host / classic files (e.g. fonts) but not to the duplicated fileystems like /proc which we bind mount anyway
[16:49] <lool> can I get an unconfined shell in the right namespace with snap run?
[16:50] <zyga> lool: easily with nsenter
[16:50] <zyga> lool: not with snap-confine
[16:51] <zyga> lool: just try nsenter -m/var/lib/snapd/ns/$SNAP_NAME.mnt
[16:51] <zyga> lool: very useful!
[16:51] <zyga> lool: you cannot have a space after -m, it's totally annoying
[16:51] <zyga> er
[16:51] <zyga> sorry
[16:51] <stgraber> zyga: can you answer my earlier question? Is it safe to add "slots: [lxd]" to the lxd snap even if some/most snapd don't know what that interface is yet?
[16:51] <zyga> lool: that path is /run/snapd/.ns/$SNAP_NAME.mnt
[16:52] <zyga> stgraber: sorry I didn't see that earlier, the answer is 1) yes 2) it must not clash with any plug (plug and slot names must be unique in one snap) 3) the store will choke on that
[16:52] <zyga> stgraber: snapd ignores unknown interfaces
[16:52] <stgraber> zyga: sounds good
[16:52] <lool> zyga: that's great, cause I could now confirm that this fixes docker
[16:52] <lool> umount --lazy /var/lib/snapd/hostfs/sys
[16:53] <zyga> lool: great to know, please add this to the pull request
[16:53] <jdstrand> zyga: ack, I'll look. I don't see anything in man apparmor.d about detach
[16:53] <zyga> lool: I plan to work on live namespace mutation soon after classic confinement, what you just did will be done by snapd on interface changes :)
[16:53] <lool> zyga: and also that unmont dev along is enough
[16:53] <jdstrand> zyga: jjohansen would know for sure (he'll be back later)
[16:54] <zyga> lool: thanks
[16:54] <jdstrand> zyga and lool: note that snap-confine has special handling of devpts
[16:54] <zyga> right
[16:58] <lazyPower> Hey, do we know if there is a weechat snap or a WIP of one?
[16:58] <lazyPower> i checked uappexplorer, not sure if there's a better place to look
[16:58] <lazyPower> before i tackled snapping up weechat i thought it would be best to ask the community at large
[16:59] <lool> zyga: these are the fses I would expect apps to try to access, but there might be more and generally this pollutes mount output; would you be able to simply unmount everything under /var/lib/snapd/hostfs?
[16:59] <didrocks> lazyPower: not that I know of. I would be interested by it, running weechat currently :)
[16:59] <lazyPower> didrocks patch-pilot me? :D
[16:59] <jdstrand> zyga: ok, approved. now can you reciprocate and review 181 and 182?
[16:59] <zyga> lool: I could detach all of hostfs
[16:59] <jdstrand> zyga: :)
[17:00] <zyga> jdstrand: yes!
[17:00] <zyga> jdstrand: taking my laptop on the go and going to review those two
[17:00] <didrocks> lazyPower: heh, with pleasure! (but not today, EOW now ;))
[17:00] <didrocks> lazyPower: I don't think it would be complex
[17:00] <lazyPower> ack, i'll circle back on Monday with my WIP didrocks
[17:00] <didrocks> (famous last words…)
[17:00] <didrocks> yeah ;)
[17:00] <lazyPower> i tried this before and ran into issues with the addons
[17:00] <lazyPower> it was the perl/tcl backend stuff iirc
[17:00] <jdstrand> zyga: sure, please don't have it interrupt your evening or weekend
[17:00] <didrocks> right, that's my fear
[17:00] <lazyPower> but i nuked that disk and didnt have it pushed anywhere, like a swell developer making swell decisions :|
[17:01] <didrocks> lazyPower: classical :)
[17:01] <didrocks> lazyPower: good luck then and talk to you on Monday! :)
[17:04] <zyga> jdstrand: no worries, I'm not working today but since I love my job I'm doing it anyway :)
[17:15] <jdstrand> zyga: ok, well, only if you love my PRs can you work on them :)
[17:15] <jdstrand> zyga: seriously though, thank you :)
[17:16] <zyga> jdstrand: my pleasure :)
[17:38] <snap_question> I am building a snap that has a package that build 7 tools in the /usr/local/bin and /usr/local/sbin and would like to expose all of them. Is there a way to wildcard the the app command? I have done this already with filesets and stage being $binaries and snap being $binaries.
[17:38] <jdstrand> roadmr: can you pull r798? no code changes, just an update to the base declaration that has the new interfaces that were committed this week
[17:38] <zyga> snap_question: no, you have to mention each one separately
[17:39] <snap_question> so I tried to do that but I ran into an issue where I would have to do packagename.executable1 , packagename.executable2
[17:39] <snap_question> and so on to get each executable to run
[17:42] <jdstrand> snap_question: yes, that is a limitation of the current implementation. you get one 'top' command such that if the command name is the same as the snap name, you may refer to it as 'snapname' rather than 'snapname.command'
[17:42] <jdstrand> snap_question: work is actively underway to make it possible to remove that restriction
[17:42] <roadmr> jdstrand: sure thing
[17:42] <jdstrand> there may be a bug on it
[17:44] <jdstrand> snap_question: https://bugs.launchpad.net/snappy/+bug/1607748
[17:44] <mup> Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748>
[17:45] <jdstrand> snap_question: in the short term, you might use an alias as a workaround until this is implemented. eg alias bar=foo.bar
[17:47] <snap_question> Was knocked offline but just asked the question regarding publishing all the apps using the apps: flag in yaml
[17:48] <snap_question> Was there an updated message about running the executable without listing the snappackage.executable1, snappackage.executable2, etc...
[17:49] <zyga> 18:42 < jdstrand> snap_question: yes, that is a limitation of the current implementation. you get one 'top' command such that if the command name is the same as the snap name,
[17:49] <zyga>                   you may refer to it as 'snapname' rather than 'snapname.command'
[17:49] <zyga> 18:42 < jdstrand> snap_question: work is actively underway to make it possible to remove that restriction
[17:49] <zyga> 18:42 < roadmr> jdstrand: sure thing
[17:49] <zyga> snap_question: ^^
[17:49] <zyga> 18:42 < jdstrand> there may be a bug on it
[17:49] <zyga> 18:44 < jdstrand> snap_question: https://bugs.launchpad.net/snappy/+bug/1607748
[17:49] <mup> Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748>
[17:52] <jdstrand> roadmr: thanks!
 thanks for restating the responses
 looks like the LXD issue is exactly what I'm seeing.
[17:54] <snap_question> Some of the tool suites I am looking to put into snap have like 7-10 or more executables in them, hopefully a compromise is found
[17:56] <zyga> dillema: should I spread test locally in qemu and get less battery life or send them to linode and use more data?
[17:57] <jdstrand> snap_question: well, as mentioned, people are working on that so it works better for people
[17:58] <zyga> snap_question: it's just a matter of non-conflicting namespaces, many projects have a myriad of tools that could be better aggregated (this is a simplification but it's not uncommon). snapd supports one top-level command per project now because it was easier (snap name registration doubles as top level command registration) but we're working on unconstrained support for additional top level cmmands
[17:58] <zyga> commands*
[17:59] <zyga> jdstrand: offtopic, I'm working on a new tool that allows to inspect squashfs files at a raw level, analyzing each byte on disk and mapping it to some data structure
[17:59] <zyga> jdstrand: it's in very early stages of development now but if you'd like to see a specific feature please let me know
[17:59] <snap_question> zyga: understood, is the best place to keep an eye on this on the bug#1607748 page or is there a different status page to watch
[17:59] <zyga> jdstrand: the goal is visual inspection, forensics and looking for hidden data or maliciously crafted files
[18:00] <zyga> jdstrand: it's a pure python codebase for now
[18:00] <jdstrand> zyga: this is something that tyhicks and I might want to see inre store reviews
[18:00] <zyga> snap_question: I think that one is the best, also look for announcements of new snapd releases
[18:00] <zyga> snap_question: my magic ball says 2.20
[18:01] <zyga> jdstrand: the code associates each data structures with particular intervals in the analyzed object and can do simple reporting and human readable dumps
[18:01] <zyga> jdstrand: plus, fun way to learn squashfs :)
[18:04] <jdstrand> I bet!
[18:04] <jdstrand> it might mean we can skip the resquash test or it might show what is wrong with the resquash test
[18:11] <zyga> jdstrand: quick question https://github.com/snapcore/snap-confine/pull/181/files#diff-e6f0d601e8a1dea1cff5b48e16c13661R512 -- why are you using strncmp for the rest but not for x86_64 and i686?
[18:11] <mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
[18:13] <jdstrand> zyga: because uname will return longer strings and we want them to match. eg, armv7l
[18:14] <jdstrand> zyga: that should be 'arm'
[18:14] <jdstrand> this is the methodology lxc uses
[18:15] <zyga> jdstrand: I see
[18:15] <zyga> jdstrand: I added a few comments, look at https://github.com/snapcore/snap-confine/pull/181#discussion_r88708613
[18:15] <mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
[18:15] <zyga> jdstrand: other than that I'll merge it and iterate with tiny tweaks and some unit tests
[18:25] <jdstrand> zyga: thanks!
[18:28] <sergiusens> davidcalle so I merged, how often are the docs updated?
[18:29] <Kurdiez> I had to install Ubuntu Core on regular Ubuntu I had on PC to start using snappy. I am kind of having hard time understanding the Ubuntu Core. Does it also become a layer on top of the OS like JVM and you are forced to program with the SDK given by the Ubuntu Core?
[18:30] <Kurdiez> For example, opening socket connection or writing files to disk.
[18:30] <mup> PR snapcraft#919 closed: docs: update GUI related integrations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
[18:36] <tptr> hi, release question: the latest image here http://cdimage.ubuntu.com/ubuntu-snappy/16.04/ does not have the  mmcblk driver. (so cannot be installed on an Intel stick pc for example). This is the place where the latest stable snappy release is published, right?
[18:49] <kyrofa> Kurdiez, no, not at all. The OS itself is structured a bit differently though, and applications need to abide by a certain set of rules. That's not to say that they need to use a specific SDK to write a file, they just need to write files in a specific location
[18:50] <Kurdiez> Well, I understand the whole contain snaps file activities within its own folder
[18:50] <Kurdiez> due to security reasons, I like that part
[18:50] <kyrofa> Kurdiez, right. Not folder, more like "area" (since it's multiple folders), but you get the idea
[18:51] <kyrofa> Kurdiez, but yeah, no special SDK needed, no specific language needed, etc
[18:51] <Kurdiez> but i'm just worried about any other run time restrictions I would get
[18:51] <Kurdiez> It seems like you are given a way to talk to snaps using some kind of sdk that is provided to you
[18:51] <kyrofa> Kurdiez, so snaps are confined in a number of different ways. One is filesystem access (there are a limited number of places snaps can write), the other is syscall access (there are a limited number of things a snap can do)
[18:52] <kyrofa> Kurdiez, by default, it's quite restrictive, i.e. you can't open sockets, etc. But if you declare in your snap that you need such a capability (i.e. by utilizing "plugs") you can expand your sandbox a bit
[18:52] <Kurdiez> what if I want process from one snap to manually signal the process in another snap?
[18:54] <kyrofa> Kurdiez, that's likely the `process-control` interface
[18:55] <Kurdiez> ok... is there document that tells me what is restricted?
[18:55] <Kurdiez> I read their website but couldn't find it
[18:55] <Kurdiez> it'd be nice to know up-front what i can't do
[18:55] <Kurdiez> before deciding to use it
[18:55] <Kurdiez> If I am to migrate current code into snap packages.
[18:56] <kyrofa> Kurdiez, this might be helpful: https://github.com/snapcore/snapd/wiki/Interfaces
[18:57] <kyrofa> Kurdiez, by default you can run apps and services and read/write files in specific areas. Beyond that, you need to use those interfaces to expand the capabilities
[18:58] <Kurdiez> oh snap...
[18:58] <Kurdiez> so anything not provided by these interfaces here
[18:58] <Kurdiez> I can't do
[18:58] <Kurdiez> that's the idea behind snappy platform?
[18:59] <kyrofa> Kurdiez, essentially. And new interfaces are being added all the time, so if you find something missing, please log a bug
[18:59] <Kurdiez> Thanks for the help kyrofa. You are the man.
[19:00] <kyrofa> Kurdiez, need to hit the network? Use network/network-bind. Want to play sound? Use pulseaudio. You get the idea :)
[19:00] <Kurdiez> so if I write C code, i still have to manage garbage collection myself
[19:00] <kyrofa> Kurdiez, and then, since interfaces are connections, a user can simply break the connection at any time (see your current connections via `snap interfaces`)
[19:00] <kyrofa> Kurdiez, yeah, snaps don't change the game there :)
[19:01] <Kurdiez> which I like. If I wanted garbage collection, I would probably install jvm snap and run java code I guess
[19:01] <kyrofa> Kurdiez, indeed
[19:01] <Kurdiez> thank you
[19:02] <kyrofa> Kurdiez, any time-- let us know if you have any questions as you explore!
[19:34] <jjohansen> zyga: not atm, there is an out of tree patch that could give that ability but nothing currently in yakkety/xenial kernels. It would be possible to drop it onto those kernels in an sru, but any such work would need to be scheduled with ty hicks and ratliff
[19:39] <Ardinis> Hello, is there any limitation for using snappy on ubuntu core?
[20:19] <jdstrand> mhall119: hey, I'm working on https://github.com/snapcore/snapd/pull/1613 and since apachelogger isn't here, I'm coming to you. do you know of two kde snaps that talk to each other over dbus in the manner that this PR is trying to address?
[20:19] <mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[20:20] <jdstrand> I've solved the binding to a well-known name case fine but would like to verify the connection policy
[20:32] <zyga> jjohansen: I don't think this is required, I was just curious, thank you for the explanation
[21:42] <_markfeatherston> How would I go about mounting a snap rw?  I need to tweak a file in the core snap for a test and I'm assuming this is the simplest way to do it.
[21:42] <_markfeatherston> the obvious mount -o rw,loop doesn't seem to work
[21:48] <_markfeatherston> nm, found unsquashfs
[21:54] <mup> PR snapcraft#920 opened: Ensure staged files are included in the prime step <Created by josepht> <https://github.com/snapcore/snapcraft/pull/920>
[22:09] <kyrofa> _markfeatherston, yeah, you can't actually mount squashfs images as rw
[22:09] <kyrofa> _markfeatherston, you can use unsquashfs and re-squash a modified version, as you found, or you can use overlayfs for temporary tweaks
[22:10] <_markfeatherston> good to know there is another option, I'll remember overlays next time.  Thanks
[22:10] <_markfeatherston> I found a bug in probert bringing up new hardware, trying to fix that
[22:21] <tedg> jdstrand: Did you see my ping the other day about disabling interface checking on devmode snaps?
[22:21] <tedg> jdstrand: WRT uploading to the store.
[23:10] <lzyPwr> Silly question that i cant seem to find in the docs or the playpen. I'm working on a weechat snap and i need to pass some args to the cmake builder. is there a way for me to pass these args to the cmake build process?
[23:10] <kyrofa> lzyPwr, indeed, run `snapcraft help cmake`
[23:11] <lzyPwr> ah, thanks for the pointer
[23:11] <kyrofa> lzyPwr, you'll see a description of the `configflags` option
[23:11] <kyrofa> lzyPwr, sure thing :)


[07:27] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4346 Needs rebuild due to higher version at destination
[08:07] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4347 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[09:47] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4347 Diff missing
[10:21] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4348 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[10:28] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4347 Proposed pocket
[11:50] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4349 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[12:29] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4349 Failed to build
[13:29] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4348 Failed to build
[18:21] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/4343 Preparing packages
[18:51] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/4343 Generating diffs
[18:52] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/4343 Successfully built