[00:48] <Han> bjornar__, did they forget to strip it?
[06:07] <salamanderrake> https://gist.github.com/salamanderrake/24ec786fe65c808c9453e1c08106bd89
[06:08] <salamanderrake> issues with nvidia
[06:09] <lotuspsychje> salamanderrake: upgrade or clean install?
[06:10] <salamanderrake> sorry
[06:10] <salamanderrake> upgrade
[06:10] <salamanderrake> dist-upgrade
[06:10] <lotuspsychje> salamanderrake: from 15.10?
[06:10] <salamanderrake> no
[06:10] <salamanderrake> in 16.04
[06:10] <lotuspsychje> ?
[06:11] <lotuspsychje> salamanderrake: wich version did you have before 16.04
[06:11] <salamanderrake> I did a apt-get update && apt-get dist-upgrade
[06:11] <salamanderrake> 16.04
[06:11] <lotuspsychje> so its a clean install, and you updated to latest
[06:12] <lotuspsychje> salamanderrake: wich grahics card chipset and driver loaded please?
[06:12] <salamanderrake> no not a clean install
[06:12] <salamanderrake> nvidia 960
[06:12] <salamanderrake> with nvidia-361 drivers
[06:13] <salamanderrake> well it was a clean install
[06:13] <salamanderrake> but this is after several updates
[06:13] <lotuspsychje> upgrade means, from one version to another
[06:13] <lotuspsychje> salamanderrake: you just stayed on 16.04 and updated to latest
[06:14] <salamanderrake> yeah
[06:14] <lotuspsychje> ok
[06:14] <salamanderrake> but its called dist-upgrade
[06:14] <lotuspsychje> !dist-upgrade
[06:15] <lotuspsychje> so you are already on the new version of ubuntu
[06:15] <lotuspsychje> anyway...
[06:15] <lotuspsychje> salamanderrake: what other drivers showup your additional drivers section?
[06:16] <salamanderrake> what do you mean?
[06:17] <salamanderrake> oh to be fair, I forgot to mention, these are not official drivers
[06:17] <lotuspsychje> salamanderrake: did the drivers by default not work good?
[06:17] <salamanderrake> there are from here, https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[06:18] <salamanderrake> no vulkan support with the default drivers
[06:18] <lotuspsychje> salamanderrake: did you try them all?
[06:18] <salamanderrake> not yet
[06:18] <salamanderrake> but nvidia-361/364 and nouveau will not load
[06:19] <lotuspsychje> salamanderrake: well i would advise to test all default ubuntu drivers, showing up your list
[06:19] <lotuspsychje> salamanderrake: like 352-updates etc
[06:19] <lotuspsychje> salamanderrake: and after you tested them all, file a new bug
[06:19] <lotuspsychje> !bug
[06:22] <salamanderrake> sudo apt-get install nvidia-352-updates ....installs 361-updates???
[06:22] <lotuspsychje> salamanderrake: no 352 was just an example mate
[06:22] <lotuspsychje> salamanderrake: thats why i would like you to go see your additional drivers section
[06:23] <lotuspsychje> to see wich drivers are available for you
[06:23] <lotuspsychje> its the hardware icon
[06:23] <salamanderrake> what I mean is why would 352-updates install 361-updates?
[06:23] <salamanderrake> I am in xfce4 not unity
[06:24] <lotuspsychje> salamanderrake: ubuntu searches best drivers for your system, if one is not available it will forward to another
[06:25] <salamanderrake> how do I get to 'additional drivers' ?
[06:25] <lotuspsychje> salamanderrake: not sure where additional drivers is in xubuntu
[06:25] <salamanderrake> this is not xubuntu, its just unity dies if I don't have a working driver so I have to run xfce4
[06:26] <lotuspsychje> right
[06:27] <salamanderrake> found it
[06:28] <lotuspsychje> salamanderrake: great!
[06:28] <salamanderrake> its in software & updates
[06:29] <salamanderrake> may need to reboot
[06:29] <salamanderrake> but I am going to bed
[06:29] <lotuspsychje> ok
[06:29] <lotuspsychje> good luck mate
[06:29] <salamanderrake> thanks
[08:31] <lordievader> Good morning.
[08:36] <Rovanion> Good morning lordievader
[08:37] <Rovanion> I got a question: Do I need any special package to get gtk-inspector?
[08:37] <Rovanion> I've tried running "GTK_DEBUG=interactive pavucontrol" but I don't get the gtk-inspector window.
[08:38] <lordievader> Hey Rovanion
[08:39] <Rovanion> Xenial does have gtk 3.18 if I'm not mistaken and gtk inspector should be included since 3.14.
[08:39] <lotuspsychje> !info gtk-inspector
[08:39] <lotuspsychje> !info gtk
[08:39] <Rovanion> I'm not stat simple...
[08:39] <Rovanion> s/stat/that/
[08:40] <solsTiCe> hi. no big bug coming from beta 2 yet? I can install confidently beta 2 ? apart from the swap bug
[08:41] <k1l> if you need to ask dont use alpha/betas :)
[08:41] <solsTiCe> :-)
[08:41] <Rovanion> solsTiCe: It probably goes without saying but you shouldn't install the beta if you don't want to beta-test, i.e. experience bug.
[08:41] <Rovanion> s/bug/bugs/
[08:42] <k1l> and it depends heavily on your hardware, software and usage if you experience some bugs.
[08:42] <solsTiCe> I plan to reinstall but it's a shame to install now a 1510 given that 1604 is so close from coming out
[08:42] <Rovanion> Yup, for example on my hardware the Xenial kernel paniced on suspend caused by low battery.
[08:43] <Rovanion> While mainline didn't.
[08:43] <k1l> solsTiCe: why is that a shame? you can upgrade to 16.04 anytime untill july
[08:43] <solsTiCe> Rovanion: if it's a upstream bug, it light not be fixed when 1604 come out
[08:43] <Rovanion> solsTiCe: It was not present upstream.
[08:44] <solsTiCe> Rovanion: ok
[08:44] <solsTiCe> go for 1510 then
[08:44] <Rovanion> Turns out I needed to install libgtk-3-dev to get the inspector.
[09:14] <lotuspsychje> !yay Rovanion
[09:23] <Rovanion> And if anyone in here has gtk experience any help with this issue would be greatly appreciated: http://askubuntu.com/questions/752204/remove-grey-border-around-pavucontrol-in-16-04
[11:24] <yboa56QRE7> hi. What is this new option in the installer that enable to turn off secure boot ? which third party driver don't support secure boot ?
[11:25] <yboa56QRE7> why wasn't it a problem before ?
[12:30] <meena> i made a huge mistake
[12:30] <meena> i mean, hello happy people
[12:30] <meena> i'm looking for help with systemd
[12:30]  * meena plays spoopy music in the background
[13:11] <bjornar__> Han: seems like
[13:22] <BluesKaj> Howdy all
[13:22] <Han> bjornar__, use file(1) to know for sure.
[13:25] <BluesKaj> howdy all, again
[13:27] <bjornar__> Han, dont have that here atm, either or, the file should not be of that size!
[13:42] <thresh>     qemu: W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-i386/Packages.xz  Hash Sum mismatch
[13:42] <thresh>     qemu: W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial/universe/binary-i386/Packages  Writing more data than expected (9439129 > 9438897) [IP: <IP_ADDRESS> 80]
[13:42] <thresh> any idea?
[13:42] <thresh> (and hello)
[13:43] <salamanderrake> https://gist.github.com/salamanderrake/391c342aa64d32e7386071ea31f1c0d0 this is with official nvidia drivers package was installed
[13:46] <k1l> official nvidia means? the one from the website?
[13:47] <k1l> thresh: either wait, change mirrors or rm the apt lists
[13:49] <thresh> k1l: would rm -rf /var/lib/apt/lists/* be enough?
[13:49] <k1l> yes
[13:49] <thresh> I guess I could add that to preseed/late_command, then
[13:49] <thresh> thanks
[13:49] <salamanderrake> k1l: the ones from ubuntu, and not some ppa
[13:50] <k1l> salamanderrake: is "linux-generic" installed?
[13:50] <thresh> oh in that it's already there :|
[13:50] <thresh> s/that/fact/
[13:50] <thresh> I guess I'll wait for the release then
[13:50] <salamanderrake> linux-generic/xenial,now <IP_ADDRESS>.17 amd64 [installed]
[13:51] <k1l> salamanderrake: so look at dmesg what happening
[13:53] <k1l> salamanderrake: looks like there is no nvidia module build. so there must have been an error when installing the nvidia
[13:53] <k1l> so look at the syslogs what happening now. and look at the apt logs if there was an error
[13:56] <salamanderrake> k1l: http://paste.ubuntu.com/15567920/
[13:57] <salamanderrake> k1l: that is /var/crash/nvidia-361.0.crash
[14:01] <k1l> salamanderrake: well, file  bug then
[14:01] <salamanderrake> ok
[14:17] <Han> thresh, looks like a server side problem, I have it as well.
[14:18] <Han> Will automatically be fixed in a while.
[14:20] <salamanderrake> k1l: Error! Bad return status for module build on kernel: 4.4.0-16-generic (x86_64) is the error
[14:20] <thresh> Han: thanks!
[14:20] <salamanderrake> k1l: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/+bug/1564425
[14:26] <salamanderrake> you think it could be because I have cc and c++ pointed to clang instead of gcc/g++?
[14:28] <rud0lf> hello i have a problem installing ubuntu 16.04 with liveusb
[14:28] <salamanderrake> yeah thats the problem k1l
[14:29] <rud0lf> when i select 'remove 14.04 and install 16.04' it says it's gonna install ext4 on 6-th partition (it's my current swap partition) and swap on 5-th (it's my ext4 partition with ubuntu 14.04)
[14:30] <rud0lf> so i'm gonna end with 8 gigs for ubuntu and 120 gigs swap space :(
[14:31] <Beelsebob> heya, I'm trying to get gstreamer's ffmpeg plugin installed, and I can't seem to get xenial to understand that I want to use trusty-media's repository; it keeps telling me
[14:31] <Beelsebob> E: The repository 'http://ppa.launchpad.net/mc3man/trusty-media/ubuntu xenial Release' does not have a Release file.
[14:31] <Beelsebob> N: Updating from such a repository can't be done securely, and is therefore disabled by default.
[14:32] <Beelsebob> I've told apt Acquire::AllowInsecureRepositories true; in apt.conf
[14:32] <Beelsebob> but to no avail
[14:32] <BluesKaj> rud0lf, choose "something else" in the partitoner for ubuntu or manual for kubuntu/kde/plasma install, then you can setup th epartition without interfernce from the automatic app
[14:32] <rud0lf> BluesKaj: won't it mess with grub?
[14:33] <rud0lf> i've seen something similar on ubuntu installation manual
[14:33] <rud0lf> nvm, i read it wrong
[14:33] <rud0lf> wish me luck
[14:34] <BluesKaj> nope.grub will update  at he end of the install or id not then you can update it afterwards, depending on whether you have other OSs installed
[14:37] <meldron> hey guys, anybody tried installing ubuntu to a zfs 'partition'?
[14:52] <BluesKaj> meldron, why?
[15:01] <Nukien> meldron, Works fine, but not from regular installer.  Just wanted you to understand my frustration
[15:17] <Pici> bjornar__: even if you do --no-install-recommends ?
[15:18] <BluesKaj> and substitute insult would be more appropriate :-)
[15:19] <bjornar__> Pici, I really dont know, but I mean -- anyway
[15:20] <bjornar__> And funnily it does not depend on setuptools, which is the only this that is more or less allways required
[15:20] <Pici> er, okay....
[15:21] <bjornar__> Pici, the package I want is ~500k .. I get 600Mb .. see the point?
[15:22] <Pici> bjornar__: I do. But you probably installed it with the recommended dependencies.. which are optional. This is the case for every package you install.
[15:22] <bjornar__> Pici, look yourself
[15:23] <Pici> I don't have a 16.04 test system here.
[15:23] <bjornar__> then leave this channel immediately! ;)
[15:24] <BluesKaj> bjornar__, which package ?
[15:24] <Pici> BluesKaj: python3-pip
[15:24] <bjornar__> BluesKaj, python3-pip
[15:25] <BluesKaj> hmm, 554Kb installed size , it must be bringing other packages with it
[15:28] <BluesKaj> bjornar__, it's installing 7 associated packages/dependencies as well
[15:29] <bjornar__> BluesKaj, yeah, and that makes some 100ds of mbs?
[15:46] <BluesKaj> bjornar__, muon doesn't show the size of the dependencies
[15:49] <BluesKaj> I use the package manager as a reference for package info etc... still use the real muon , not the new muon discover that's default on Kubuntu Xenial
[15:50] <solsTiCe> hi. why does one is forced to turn off "Secure boot" with bcmwl-kernel-source wifi module ? It was working fine before except some bug may be
[16:11] <monester> hi all! I've faced a bug with installation of uwsgi-plugin-python - package is failing during postinst, fix is already proposed to debian, but when it would be backported to ubuntu?
[16:24] <jubo2> y0
[16:24] <jubo2> last day to get 16.04 before release month
[16:24] <jubo2> everyone rush
[16:25] <teward> monester: fix *proposed* to debian, or fix *already released* to Debian?
[16:25] <jubo2> then swamt the support stuff with prerelease problems
[16:25] <jubo2> I like Kubuntu16.04 .. a lot
[16:26] <jubo2> still room for improvement but GUI that'd make 90's users drool
[16:28] <jubo2> I've been operating mah computers since '87'ish
[16:29] <jubo2> I had friends who had.. one had some weird video game console we could play pong on
[16:29] <jubo2> then another friend got Commodore 64
[16:30] <jubo2> There were some really good games
[16:30] <jubo2> Broderbund was one awesome game studio in those times
[16:31] <monester> teward it is released https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818116
[16:31] <jubo2> The helicopter game Broderbund Games made was so awesome taking game design and technological advancement
[16:31] <teward> monester: um, no, that's not 'fixed'
[16:31] <jubo2> sprites graphics
[16:31] <teward> monester: it's still open?
[16:32]  * jubo2 10 yr plan: "Get wealthy enough to purchase machine that will run Elite Dangerous with gameable speed."
[16:32]  * meena considers some infinite screaming into the void
[16:32] <monester> teward: it is "Fixed in version uwsgi/2.0.12-5", and I can see it in packages.debian.org
[16:32] <meldron> Nukien: so i install a system an then copy all the files?
[16:33] <meldron> BluesKaj: cause i want to use it for my ssd
[16:33] <meena> i've updated this joyful systemd bug, which makes my computer take ~2+ minutes to reboot https://github.com/systemd/systemd/issues/1620
[16:33] <jubo2> I want to play Elite Dangerous.. twas 80's last I really gamed it
[16:34] <meena> i'm super looking forward to running systemd in production on servers…
[16:40] <monester> teward: yeah, bug is reopened, sorry for bothering . I was looking on cached page
[16:40] <Nukien> meldron, Yup, that's one way. I have a script to handle it if you want - pastebin.com/fa83QrBk
[16:40] <Nukien> Runs from a livecd
[16:41] <meldron> Nukien: thanks i will look into it
[16:42] <jubo2> Win Eurojackpot yes.. Now I gotta go degut some vendace
[16:42] <jubo2> Then I'ma make mi mix of coarse wheat flour and salt
[16:42] <jubo2> cast iron pan, lot of oil, would use butter but couldn't afford
[16:43] <jubo2> flip-flip-flip-flip in the flours-'n-salt mix
[16:43] <jubo2> fry till cruch. Serve with lemon and mayo of fav choice of coocuissineur
[16:44] <meldron> Nukien: oh it looks quite sufisticated
[16:48] <BluesKaj> meldron, why zfs though, what's the advantage over ext4?
[16:50] <BluesKaj> brb, gotta switch server
[17:28] <jtaylor> mh turns out the upgrade space estimate is way off ._.
[17:28] <jtaylor> said it needed 2.6g, 3.9g was not enough and not even close to done
[17:32] <rud0lf> is it normal that every item in software center is marked as proprietary?
[17:50] <squirtle> o/ any known issues with 16.04 and surround sound.  seems once I install nvidia driver selecting 6 channels in alsamixer doesn't stick after a reboot (and I never get the oppertunity to set 5.1 from the new sound settings interface)?!
[18:08] <Squarism> so anyone tried unity8?
[18:14] <k1l_> !unity8
[18:14] <k1l_> its not the standard desktop in 16.04
[18:15] <meldron> BluesKaj: what do you mean? it has several features ext4 is missing
[18:16] <Squarism> k1l_, Has its status changed from 15.10? I mean will it be presented to "non-expert" users as a valid choice for typical productivity work? Or more a "at your own risk" !!EXPERIMENTAL!!
[18:17] <Pici> Well, it would require people to install it manually, which is not something that all users are comfortable with.
[18:18] <Squarism> Pici, was that for me?
[18:18] <Pici> Squarism: kinda.
[18:19] <TJ-> meldron: and OpenZFS on Linux is missing features that ext4 has; such as SSD/SCSI TRIM/DISCARD support
[18:25] <BluesKaj> meldron, it's your call, but definitely not recommended for ubuntu and it's flavours
[18:27] <jtaylor> neat, upgraded my first main desktop to 16.04 and despite open source amd drivers it feels a lot snappier
[18:28] <jtaylor> the new font is normal?
[18:29] <jtaylor> with fonts I never know if its intentional or some config problem ._.
[18:29] <jtaylor> looks weird but probably because its new
[19:09] <meldron> BluesKaj: just wanted to try it, why is it not recommended
[19:12] <meldron> whats your opinion about btrfs?
[19:16] <BluesKaj> !zfs
[19:16] <BluesKaj> !btrfs
[19:17] <TJ-> meldron: there might be some teething problems as ZFS is integrated into Ubuntu fully. It's intention is for virtualised systems typically used in hosting services, etc.
[19:18] <Pici> Not to mention the whole licensing thing, which hasn't fully been digested, imho.
[19:20] <meldron> Pici: licensing is the last of my worries
[19:21] <Pici> meldron: I personally don't really care.. but if Canonical was told to remove it from the OS, I wouldn't really like it if I was running that locally.
[19:27] <TJ-> Licensing isn't as big an issue as is made out, although it is interesting
[19:38] <meldron> hm
[19:39] <meldron> so I am really undecided NOW
[19:39] <meldron> sorry
[19:42] <jonathan_zz> brfs has a lot of fans but. I think the fans are mostly people who like sacrificing something for something else they think they can use or need.
[19:42] <jonathan_zz> btrfs*.
[19:43] <jonathan_zz> a bit like... cutting off an ear so you'll have less air resistance as you run ;-) :P.
[19:44] <jonathan_zz> every distro does btrfs differently. OpenSUSE just has a tool built around it.
[19:45] <jonathan_zz> mostly because of the snapshotting ability. And thin LVM is not supported by grub, nor readily available in a new installation.
[19:46] <jonathan_zz> it is very troublesome to use thin LVM on a root volume, and impossible on boot.
[19:47] <jonathan_zz> OpenSUSE's leader (Brown Richard) is a great fan of btrfs because you can basically version files with it.
[19:48] <TJ-> we've seen a lot of data corruption bugs with it over the last 24 months or so that I recall
[19:48] <jonathan_zz> I just call him Brown Richard lol.
[19:48] <jonathan_zz> I suppose so, I wouldn't be surprised :).
[19:49] <jonathan_zz> They keep saying how stable it has become which kinda proves that stability has been an issue right.
[19:50] <jonathan_zz> It was like that Theme Hospital clone of which they said "It doesn't crash as often anymore".
[19:50] <jonathan_zz> haha
[19:51] <jonathan_zz> (original TH was rock stable).
[19:52] <TJ-> Well, if the F-35 can have crashing computers, we can't complain about BTRFS :)
[19:53] <jonathan_zz> for a moment I thought that was a fedora version :p (has been reading too much on linux).
[19:54] <Nukien> ZFS works perfectly under Ubuntu, 14.04 or 16.04. There is no clean "install to zfs" yet, but that will be coming
[19:54] <Nukien> If you do it manually, it works swimmingly
[19:55] <Mikelevel> xfs works fine too
[19:55] <jonathan_zz> i stick to ext3 :p.
[19:55] <jonathan_zz> I have no need for other filesystems whatsoever at this point.
[19:56] <k1l_> wasnt support for ext3 stopped? ext4 is the actual ext FS
[19:56] <jonathan_zz> I tried XFS and was meaning to benchmark it, but never got around it I think. But you can't shrink XFS, and that sucked.
[19:57] <jonathan_zz> maybe you'd confuse the ext4 driver with the ext3 filesystem. in that sense.
[19:57] <jonathan_zz> it might be the ext4 driver running ext3 filesystems.
[19:59] <jonathan_zz> just with less features, that's all.
[20:01] <TJ-> I like where the kernel is headed... separating the notion of 'block storage device' from 'naming scheme', that path will lead to the eradication of file systems :)
[20:02] <jonathan_zz> hah?
[20:02] <jonathan_zz> that's like saying you can eradicate roads by voting to abolish road signs.
[20:02] <jonathan_zz> haha
[20:03] <jonathan_zz> I mean eradicating filesystems would be something you'd need to choose and THEN implement, it couldn't just happen by happenstance right.
[20:04] <TJ-> no, it's actually a great concept. right now the FS drivers are tied into the block layer; some recent discussions about capabilities for some specialised devices raised some discussion about benefits of separation
[20:04] <jonathan_zz> like oh we did something to the kernel now we have solved the mystery of life on other planets.
[20:04] <TJ-> it came out of Linus strongly rejecting some patches that added an IOCTL
[20:05] <jonathan_zz> so the goal is for FS drivers to no longer have access to block devices, hence rendering them inoperational :P.
[20:06] <TJ-> last 2 paras of http://lwn.net/Articles/680708/
[20:06] <jonathan_zz> waaa I have to pay for that.
[20:07] <TJ-> worth every penny
[20:07] <jonathan_zz> unless I instantly time warp into 7 april!
[20:07] <jonathan_zz> *changes his computer clock*
[20:07] <TJ-> or you can wait 2-4 weeks until it becomes open
[20:07] <jonathan_zz> *darn it doesn't work * :P.
[20:08] <TJ-> oh, it's only a week's wait from publication and that was published March 24th
[20:08] <jonathan_zz> actually considering the amount of free material on the web I can also read, I consider that $7 better spent on a sandwich :p.
[20:09] <TJ-> LWN has in-depth articles about Linux  and by Linux kernel devs
[20:13] <jonathan_zz> hm hm and I have hunger :p.
[20:13] <jonathan_zz> ha
[20:29] <bjornar> Can someone try to pull this one in time for 16.04
[20:29] <bjornar> https://github.com/systemd/systemd/pull/2928


[08:06] <elfy> morning
[09:21] <knome> morning elfy
[09:21] <knome> elfy, let's go through the poll pad once you've "got" "feedback" from the list
[09:21] <elfy> knome: yep
[09:22] <knome> elfy, i mean i think it's obvious that i've given my feedback in the form of contributing to the pad... and if nobody has more comments, let's do some of it
[09:22] <elfy> yea :)
[09:22] <knome> elfy, there are currently 3 different questions/ways of asking there, we might want to cut down to two
[09:22] <elfy> btw the old stuff is still there I saved versions
[09:23] <elfy> not got time to talk now - just about to toddle of to work
[09:23] <knome> good
[09:23] <knome> same here
[09:23] <knome> well except i'm not wandering to work next..
[09:23] <elfy> perhaps later this evening - pleia2 might be about too
[09:23] <elfy> heh - yea :)
[09:24] <knome> maybe, let's see how my schedule turns out
[09:43] <ochosi> morning
[09:46] <ochosi> i'm sorta surprised at how civilised the discussions on the ml are going
[09:50] <knome> why on earth do i not have the permissions to create files on a SD card i just formatted
[10:36] <brainwash> bluesabre: heh, I was pretty sure that you understood what I meant (-> backport keybind xml from vivid to trusty/utopic)
[10:37] <brainwash> bluesabre: the branches were not created before the package was accepted into proposed, right?
[10:38] <brainwash> does the new abiword version 3.0.1 have a new feature? it autostarts after login..
[10:39] <brainwash> same in for the guest session
[10:39] <brainwash> the guest session is also missing whisker menu
[10:39] <brainwash> what is going on? =S
[11:00] <bluesabre> brainwash: did you hit "Save Session" on your logout window?  abiword does not install into autostart
[11:01] <brainwash> no
[11:01] <brainwash> the guest session should even start a clean session
[11:01] <bluesabre> thats true
[11:01] <bluesabre> not sure whats going on for you there
[11:03] <bluesabre> sounds like maybe your xdg-xubuntu folders got messed up
[11:03] <brainwash> what about the whiskermenu entry? is it missing for you?
[11:04] <brainwash> in the guest session I mean
[11:04] <bluesabre> nope
[11:04] <brainwash> checked the logs and xfce4-session does not seem to start abiword
[11:04] <ochosi> hey bluesabre
[11:04] <brainwash> up-to-date + -proposed?
[11:05] <brainwash> hi ochosi
[11:05] <ochosi> hey brainwash
[11:05] <bluesabre> brainwash: you know its a bad idea to actually use -proposed as a daily driver
[11:05] <brainwash> it is a test system
[11:06] <bluesabre> -proposed is a broken system... packages get rejected from -proposed before landing in the archive
[11:06] <bluesabre> heya ochosi
[11:07] <bluesabre> up to date and not proposed for me
[11:07] <ochosi> bluesabre: did i miss anything since i took off?
[11:07] <bluesabre> merged a greeter fixes branch...
[11:07] <ochosi> ah nicxe
[11:07] <ochosi> nice
[11:08] <ochosi> so is anything missing for 2.0?
[11:08] <bluesabre> not sure, but probably not
[11:08]  * bluesabre wishes he could get andrew p. to join irc
[11:09] <bluesabre> also, I'm planning on trying to clean up https://bugzilla.xfce.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=REOPENED&list_id=20846&product=Xfce4-settings&query_format=advanced&resolution=--- this weekend
[11:11] <ochosi> right
[11:11] <ochosi> that looks like work
[11:13] <ochosi> we seem to have two display dialog related bugs that people seem to encounter time and again, there is one related to displayport (which i can't test) and the other related to the minimal dialog popping up all the time
[11:14] <bluesabre> yeah, for the tv stuff, I think its bad drivers... I found a bug in there and fixed it, but it still won't work for them unless the display settings just completely forget about what was attached previously
[11:14] <ochosi> hm, right
[11:14] <ochosi> yeah, that's possible
[11:14] <ochosi> btw, are you ok with wontfixing this one? https://bugzilla.xfce.org/show_bug.cgi?id=11132
[11:14] <bluesabre> and thats what makes the mini settings pop up indefinitely
[11:15] <bluesabre> yeah, dead space between the two screens makes it possible to lose things... so thats kind of dumb
[11:15] <ochosi> same as that: https://bugzilla.xfce.org/show_bug.cgi?id=10889
[11:15] <ochosi> (yeah, it's totally dumb...)
[11:17] <bluesabre> yup, wontfix that either
[11:17] <bluesabre> apply buttons are old-school, we only use them when needed (display settings)
[11:18] <bluesabre> ochosi: will you be around this weekend?
[11:18] <ochosi> yup, more or less
[11:19] <bluesabre> cool
[11:19] <bluesabre> maybe we can do a -settings sprint then and wipe some things out :)
[11:21] <ochosi> alrighty :)
[11:21] <ochosi> would make sense to clean up there some mor
[11:21] <ochosi> e
[11:23] <brainwash> we got informed by errors.ubuntu.com
[11:23] <brainwash> bug 1415683
[11:23] <bluesabre> oh hey
[11:23] <bluesabre> I was just about to mention that
[11:23] <bluesabre> in my paste buffer even
[11:23] <brainwash> :D
[11:23] <bluesabre> https://errors.ubuntu.com/problem/7f085ba4e6c070ba9abb8d336c3f5c91007c09ac
[11:24] <brainwash> what does it say?
[11:24] <bluesabre> its just the stack trace
[11:24] <bluesabre> whos the person behind xfdesktop?
[11:25] <bluesabre> they can probably read it a bit easier
[11:25] <brainwash> eric
[11:25] <brainwash> which ubuntu releases?
[11:25] <bluesabre> eric_the_idiot: see above ^
[11:26] <bluesabre> 14.04, 14.10, 15.04
[11:26] <brainwash> ok
[11:26] <bluesabre> they stopped seeding it to trusty because of that issue
[11:26] <brainwash> you cannot read anything unless you have been approved to do so
[11:26] <bluesabre> you just have to sign up
[11:26] <bluesabre> and say "I work on xubuntu bugs"
[11:26] <brainwash> I know
[11:26] <brainwash> well, eric will have to
[11:26] <brainwash> or you share the stacktrace
[11:27] <bluesabre> eric_the_idiot: http://paste.ubuntu.com/9935131/
[11:28] <bluesabre> let me know if I can help there
[11:31] <brainwash> bluesabre: will you prepare a new xubuntu-default-settings build for trusty-proposed?
[11:31] <bluesabre> yeah... is the utopic one ok?
[11:32] <brainwash> yes, the utopic one should be fine
[11:32] <brainwash> I'll inform the people then, so that they wait for the proper build for trusty and don't test yet
[11:33] <bluesabre> k
[11:39] <bluesabre> brainwash: does this one need to have all the "Primary" keys instead of "Control"?
[11:50] <brainwash> bluesabre: yes
[11:50] <bluesabre> k
[11:51] <brainwash> I've created the branch with this commit before the final release of trusty.. but it did not get merged right away
[11:53] <brainwash> there are no keybind reassignments or new keybinds across trusty/vivid/utopic, so these releases should ship an identical keybind xml
[11:54] <brainwash> oh lol.. I launch the lubuntu session and abiword is started too
[11:55] <bluesabre> sudo updatedb; locate abiword.desktop
[11:55] <brainwash> there is nothing in .config/autostart
[11:58] <bluesabre> did locate find anything?
[12:01] <bluesabre> also, should there be any changes except to etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml ?
[12:02] <brainwash> only to this xml file
[12:03] <brainwash> locate only lists the normal application desktop file and the app-install one
[12:03] <bluesabre> not sure what is starting it then
[12:04] <bluesabre> does the xml portion here seem to be what we're looking for, it really is only the Control > Primary changes
[12:04] <bluesabre> http://paste.ubuntu.com/9935714/
[12:04] <brainwash> it's not xubuntu specific, so we can ignore it for now
[12:06] <brainwash> I guess so, you could diff the resulting xml with the vivid one
[12:06] <brainwash> there should be no difference
[12:08] <bluesabre> yup, no diff
[12:08] <brainwash> great
[12:12] <bluesabre> pushed
[12:15] <brainwash> thanks
[12:16] <brainwash> you will ping someone to accept it into -proposed, or? :)
[12:36] <bluesabre> usually not necessary, but did
[13:35] <brainwash> I tell firefox to download a file and lock the screen (light-locker). after unlocking I see that firefox stopped the download
[13:35] <ochosi> well, your seat does become inactive when you lock the screen
[13:35] <ochosi> so i'm not terribly surprised
[13:35] <brainwash> I know that
[13:35] <ochosi> that's why music-playback stops
[13:35] <brainwash> but light-locker breaks too many use cases
[13:36] <ochosi> right, so why are you sounding surprised?
[13:36] <ochosi> just use late-locking
[13:36] <brainwash> how?
[13:36] <brainwash> I use the keybind to trigger light-locker
[13:37]  * ochosi sighs
[13:38] <ochosi> use xscreensaver then
[13:38] <ochosi> it's not like anybody is *forced* to use light-locker
[13:38] <ochosi> that's the beauty of linux, you can un/install packages and modify your setup
[13:38] <brainwash> exactly, we should revert to xscreensaver until light-locker does not break any of use cases
[13:39] <ochosi> add it to the agenda and state your case in the next meeting
[13:39] <brainwash> ok
[15:00] <knome_web> hullo
[15:01] <elfy> hello
[15:01] <slickymasterWork> hey new knome
[15:01] <slickymasterWork> hey elfy
[15:01] <knome_web> are we into the meeting already? :)
[15:01] <elfy> will be tomorrow :)
[15:01] <slickymasterWork> isnt' that just tomorrow
[15:01] <slickymasterWork> ?
[15:02] <knome_web> oh...
[15:02] <elfy> :)
[15:02] <knome_web> really?
[15:02] <knome_web> haha.
[15:02] <elfy> yea - really :)
[15:02] <slickymasterWork> silly new knome
[15:02] <elfy> would I lie to you ...
[15:02] <knome_web> i shall quit then and spend time with other people here...
[15:02] <elfy> bye :)
[15:02] <knome_web> elfy: if that earned you a cuppa... yes
[15:03] <ochosi> hf knome_web
[15:03] <knome_web> ta
[15:03] <knome_web> you too
[15:03] <slickymasterWork> lol
[15:03] <elfy> hi slickymasterWork too
[15:03]  * knome_web facepalms
[15:03] <elfy> bad move when all webby - gets stuck everywhere ...
[16:25] <brainwash> elfy: do you know why the idea of dropping the games came up?
[16:26] <brainwash> just read the discussion on the mailing list
[16:26] <slickymasterWork> brainwash, the idea was originally started by knome and I
[16:28] <brainwash> after elfy said to drop them?
[16:28] <brainwash> :D
[16:28] <brainwash> I will have to check the logs
[16:30] <slickymasterWork> it was after one of this years' firsts meetings
[16:30] <slickymasterWork> don't recall now which one
[16:40] <elfy> wasn't too long back
[16:41] <elfy> I Think ti came about re one of the games and CSD
[16:43] <brainwash> 2015-01-14
[16:43] <brainwash> [22:48] <brainwash> should gnome-mines be replaced too? I noticed that it uses CSD too now
[16:43] <brainwash> [22:49] <elfy> I'd lose games completely given the chance
[16:43] <brainwash> [22:49] <brainwash> you can't do that!
[16:43] <brainwash> [22:49] <slickymaster> +1 on that
[16:43] <elfy> yea
[16:43] <elfy> changed my mind now
[16:45] <brainwash> close the discussion!
[16:45] <brainwash> :)
[16:53] <slickymasterWork> let it roll brainwash
[16:54] <brainwash> no, let it go, let it go!
[16:54] <baffledbear> It's interesting to see what people's opinions are on the subject.
[16:55] <ochosi> as long as they remain on topic, it is
[16:55] <slickymasterWork> exactly
[16:55] <baffledbear> True. The ones that are asking for new games to be added are less interesting.
[18:49] <knome> the discussion about removal of games was one thing that was brought up (into my mind) along with the other removal/replacement discussions about GIMP/LO
[18:50] <knome> (it isn't like these ideas just popped to our minds 5 minutes before we sent out the mails, they have been discussed for a longer time already)
[18:50] <ali1234> if CSD are a problem in some gnome app then remember we might be able to do a straight swap for the mate version
[18:50] <ali1234> calculator springs to mind
[18:50] <ali1234> i don't think mate forked gnome games
[18:51] <knome> once the dust has landed on keeping/dropping games, it's time to do a proposal round of new games
[18:51] <knome> not necessarily on the mailing list though, we already have the data from there..
[19:41] <elfy> knome: makes some sense
[19:42] <elfy> ali1234: I have indicator-sound, whatever bug 1411959 was about appears to have done the trick
[19:57] <elfy> Unit193: did the 64 bit core image one - all worked fine for me on vb
[20:01] <Unit193> elfy: Nothing broken?  Nice.  I'll do 32 then.  Did you by chance grab the package list?
[20:01] <elfy> nope
[20:02] <elfy> that's not actually something I am EVER likely to do by chance :D
[20:03] <elfy> whatever command I might need isn't one I'd know - quick enough to boot it and see though :)
[20:04] <Unit193> https://sigma.unit193.net/packs I think I had you run that, except rather than using less, pipe to a file (going to compare it to your last one.    Ah, great.
[20:11] <elfy> yea - I did see something beforehand
[20:18] <Unit193> Couple of interesting differences..
[21:39] <brainwash> bluesabre: found the trigger which launches abiword on my system automatically
[21:39] <brainwash> http://fossies.org/linux/abiword/plugins/collab/backends/telepathy/unix/org.freedesktop.Telepathy.Client.AbiCollab.service.in
[21:41] <Unit193> So I take it others have it where the indicators mostly work, but with glitches?  Click an indicator to activate the menu, click it again to deactivate or click on another indicator and it will not deactivate.
[21:42] <ochosi> for me it mostly deactivates when i click another indicator
[21:42] <ochosi> but it doesn't open that indicator menu upon first click
[22:05] <pleia2> knome, elfy - fosdeming this weekend, not around much (currently at philadelphia airport, woo)
[22:05]  * pleia2 brought her xubuntu t-shirt :D
[22:06] <Unit193> pleia2: Yey!  Have fun!
[22:08] <pleia2> thanks :)
[22:21] <knome> pleia2, have fun!


[00:28] <akgraner> ok so for mailing list issues - you can ping - pleia2 nhandler cody-somerville or myself - for ubuntu-news or ubuntu-news-teams
[00:28] <cody-somerville> :-)
[00:30] <akgraner> cody-somerville, I noticed you were admin on -teams did you not want to be on -news?
[00:30] <akgraner> or can I add you to -news as well?
[00:30] <akgraner> the only thing that should ever go out on ubuntu-news is the newsletter
[00:31] <cody-somerville> Are we referring to the mailing lists here?
[00:31] <akgraner> cody-somerville, sorry that backward
[00:31] <akgraner> you are on -news mailing list
[00:31] <cody-somerville> I was going to say :)
[00:31] <akgraner> but not on -teams
[00:31] <akgraner> ubuntu-news-team
[00:32] <cody-somerville> I'm subscribed to ubuntu-news-team but not an admin of that mailing list.
[00:32] <akgraner> so if you don't mind I am going to add you to it as well so the it is the same list of contacts for both
[00:33] <akgraner> cody-somerville, nhandler Pendulum  - the reason I wanted to add two more people even with the measures that are in place we are still getting spam making it to the mailing list and into the archives
[00:35] <Pendulum> akgraner: was that aimed at me or pleia2?
[00:35] <akgraner> so I was hoping that if I got some more experience ML admins helping maybe we could get that reduced - plus I am not getting to all the stuff that needs to be moderated in the most timely manner these days :-(
[00:35] <akgraner> Pendulum, sorry
[00:35] <Pendulum> s'cool :)
[00:35] <Pendulum> pleia2: ^^
[00:35] <akgraner> pleia2, that was for you
[01:56] <zkriesse> akgraner: ty!
[01:56] <akgraner> you're welcome
[01:56] <akgraner> cjohnston, did you send nigelb and nhandler those scripts?
[01:58] <cjohnston> they are on lp
[01:58] <cjohnston> with a merge request
[01:58] <zkriesse> pleia2: ping
[02:01] <cjohnston> akgraner: i just merged them in
[02:01] <akgraner> oh can you show nhandler and nigelb that as well
[02:01] <akgraner> I would like a couple people to know all that good stuffs
[02:01] <cjohnston> k
[02:04] <cjohnston> akgraner: are there other scripts that are used
[02:04] <cjohnston> outside of what I uploaded and what nhandler uploaded?
[02:07] <nhandler> cjohnston: Thanks a lot. I'll make a few changes tomorrow to make the package actually comply with the licenses
[02:07] <cjohnston> ok
[02:08]  * cjohnston is off to bed
[02:08] <cjohnston> g'nite
[16:52] <cjohnston> hey akgraner
[16:54] <akgraner> cjohnston, hey!
[16:54] <cjohnston> rough night.. :-(
[16:54] <akgraner> :-(
[16:54] <akgraner> want to postpone?
[16:54] <cjohnston> nah
[16:54] <akgraner> it's not a problem
[16:55] <akgraner> give me about 10 minutes I want add a couple more things to this issue and I am going to show you what to do :-)
[16:55] <cjohnston> cool
[16:55] <cjohnston> debating.. expresso?
[16:55] <cjohnston> lol
[16:56] <akgraner> cjohnston, in the meantime look over this spreadsheet
[16:57] <akgraner> https://spreadsheets.google.com/ccc?key=0AtKZelXU8Y2LdFFxY0RhLVdaZU9xNk5zdTZIbFEyQVE&hl=en
[16:57] <akgraner> I'll be adding it to the wiki but for now I am just adding stuff to this spreadsheet
[16:58]  * akgraner feels a but full of fail at the moment - but this too shall pass :-)
[16:58]  * maco passes akgraner a cup o' chamomile
[16:59] <akgraner> maco, thanks! :-)
[16:59] <cjohnston> hey maco
[16:59] <maco> hi cjohnston
[16:59] <akgraner> anyone who wants to bookmark the spreadsheets can it's the steps to creating the newsletter and some howto's as well
[22:01] <akgraner> The new edition of the Ubuntu Weekly Newsletter is now available here:
[22:01] <akgraner> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue197  (sorry for the delay)
[22:02] <zkriesse> akgraner: cool
[22:02] <zkriesse> akgraner: how ya doing?
[22:49] <pleia2> hm, was https://lists.ubuntu.com/archives/ubuntu-news-team/2010-June/001099.html not appropriate for UWN or just get lost in the delay?
[22:51] <pleia2> good job for finally getting it out though :)
[22:51] <akgraner> pleia2, sorry I missed that
[22:51] <akgraner> I'll add it in the next issue
[22:51] <pleia2> thanks, it was a pretty big deal for the california team :)
[22:51] <pleia2> real press coverage in a real newspaper
[22:52] <akgraner> yeah that's great!


[06:14] <helpful-foss-dev> hello everyone
[06:15] <helpful-foss-dev> i am wanting to refer to another user in a bug report comment on launchpad
[06:15] <helpful-foss-dev> what is the syntax for doing so?
[06:15] <helpful-foss-dev> i wasn't able to find some documentation about that
[06:15] <helpful-foss-dev> thank you for any info.
[06:16] <helpful-foss-dev> e.g. in some systems one puts the symbol at-sign before the user name
[06:16] <helpful-foss-dev> i wonder if that is the case here, or there is some other syntax.


[16:55] <tsimonq2> Unable to find plasma-discover_5.27.8.orig.tar.xz.asc in upload or distribution.
[16:55] <tsimonq2> Files specified in DSC are broken or missing, skipping package unpack verification.
[16:55] <tsimonq2> That's a new one?
[16:56] <tsimonq2> The upload I did had no source.
[16:56] <cjwatson> not especially ...
[16:56] <tsimonq2> *no orig
[16:56] <tsimonq2> I just don't know where to start on looking at a solution, hm :/
[16:56] <cjwatson> It was in your .dsc
[16:56] <cjwatson> (apparently)
[16:58] <tsimonq2> cjwatson: Thank you :) that was a simple one...


[01:38] <micahg> asac: I can give you dev membership without upload rights if you want
[02:59] <BenC> Any reason why packages.ubuntu.com contents search isn't working for saucy?
[03:07] <ScottK> Hasn't been set up yet.
[03:07] <ScottK> Rhonda handles it both for Ubuntu and Debian.  Not sure what's blocking it.
[05:12] <pitti> xnox: erk, your update-manager merge (common dialogs) broke quite a lot -- got the tests mostly fixed again, but this dropped UpdateManager/UpdateProgress.py which was still being included
[05:18] <dylan-m> pitti: Eep, I thought I had those tests passing.
[05:18] <pitti> dylan-m: the pep-8 and pyflakes errors were simple, I got these committed
[05:19] <pitti> dylan-m: it looks like I'd replace UpdateProgress(main) with something like get_backend(self, InstallBackend.ACTION_UPDATE) ?
[05:19] <pitti> in ./tests/test_update_error.py
[05:19] <dylan-m> pitti: I'll be happy to work through these tomorrow, if you'd like :)
[05:23] <dylan-m> pitti: Hang on, just going to jog my memory on that one, but I think that's right. The Update / Install backends were stuck together, if I remember correctly.
[05:30] <pitti> dylan-m: hm, I'm afraid I can't figure it out without truly understanding what's going on there :/
[05:30] <dylan-m> Hm, action-done isn't a signal any more, either, so that'll need to be changed to just call the hidden method _action_done. Should take the same arguments.
[05:35] <pitti> dylan-m: ok, in bzr I now fixed all failures except this one
[05:36] <dylan-m> Hm, are there some existing failures trying to import DistUpgrade.DistUpgradeCache, or is that just me?
[05:37] <pitti> not with "env -u LANGUAGE LANG=C nosetests3" here
[05:38] <dylan-m> Ah, yes, using the right version of nosetests helps :)
[05:54] <dylan-m> pitti: Okay, that one is fixed! https://code.launchpad.net/~dylanmccall/update-manager/test_update_error-fix
[05:55] <pitti> dylan-m: ah, nice header_markup() fix, I changed that differently in trunk but I'll take your version
[05:55] <pitti> dylan-m: thanks!
[05:57] <dylan-m> pitti: I thought about just using get_text instead of get_label, but some translations could add Pango markup for some reason (not sure if they should, though), so that could cause some unusual failures
[05:57] <pitti> ah, overlong line again
[05:58]  * pitti fixes
[05:58] <pitti> yay, all pass now
[05:58] <pitti> time for another "real life" test, and then I'll upload
[05:58] <dylan-m> pitti: d'oh! This is what happens when I use the wrong text editor.
[05:58] <pitti> dylan-m: pep8 test was failng
[06:02] <pitti> xnox: unping, all good now
[06:04] <dylan-m> pitti: Yay! Sorry about the trouble :) I really appreciate good unit tests, and I'm really glad you're keeping on top of them! I really need to fix my ugly habit where I always forgetting to run them when they're there.
[06:05] <pitti> dylan-m: heh, thanks for the fast fix
[06:05] <pitti> dylan-m: all I did was to drop the obsolete threads_init() call, and that got me into some more work :)
[06:11] <dylan-m> Oh, right, I was brushing my teeth. Err, good night, then! :)
[06:12] <pitti> dylan-m: night!
[06:43] <dholbach> good morning
[07:59] <tvoss> pitti, ping
[08:00] <pitti> hey tvoss
[08:07] <Laney> dobey: well, those changes alone aren't enough to make the autopkgtests pass
[08:08] <Laney> I'll give you what I have atm but it's unfortunately still not enough - it seems to block forever at some point even though they were passing when I ran them manually
[08:08] <Laney> kind of annoying that adt-run buffers output so you don't get it at all if you have to ctrl-c :/
[08:11] <pitti> Laney: you can tail -f the stdout/stderr files in the tmp dir
[08:12] <Laney> pitti: oh really? let me try this
[08:12] <Laney> I was playing with --output-dir and --log-file
[08:13] <pitti> Laney: that works as well in run-adt-test, you can ssh into the VM and tail -f the files in /tmp/adtmp/...
[08:13] <pitti> ssh -p 54323 ubuntu@localhost
[08:13] <pitti> (get the precise port from the initial output or from the qemu command line)
[08:16] <dholbach> we're at 62 sponsoring items - does anyone have a bit of time today to go through a few?
[08:21] <xnox> pitti: cool, thanks. sorry about that.
[08:31] <cjwatson> pitti: Please could you merge subversion?
[08:32] <pitti> ugh, did I make the error of touching it?
[08:32] <pitti> ah, a no-change rebuild
[08:32] <cjwatson> Yeah :)  Or I can do the merge if you like
[08:32] <pitti> cjwatson: I'll have a look
[08:33] <pitti> I don't even see it on MoM, perhaps it's still catching up
[08:34] <xnox> barry: i think i got broken icon in emacs24, it was a combination of having a server on the tty and launching a new gui instance.... it turned into a "?"
[08:35] <cjwatson> MoM got stuck.  I've poked it
[08:35] <cjwatson> Should catch up within an hour or so I hope
[08:41] <cjwatson> Is there a good example package anywhere which uses both the autotools and setup.py?  I need/want to use the autotools for C parts of this project, but I already have setup.py in place for the Python parts ...
[08:43] <pitti> cjwatson: merged, test sbuild running now
[08:43] <pitti> http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/subversion/sid/revision/22 FTW :)
[08:47] <mpt> ev, how do you track bugs that, when fixed, will alter the apparent error rate but not the actual error rate? For example bug 1196740.
[08:47] <ev> mpt: we don't at present
[08:48] <ev> didn't we come up with a plan for that at the January sprint?
[08:49] <mpt> ev, if so, it isn't mentioned in https://wiki.ubuntu.com/ErrorTracker#Cross-release_comparisons
[08:51] <ev> mpt: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit# - "How do we handle anticipating more errors?"
[08:52] <ev> there's no implementation for this yet though
[08:53] <mpt> aha, DetectedSince, DetectedUntil
[08:54] <mpt> but there's no field for that in the database?
[09:01] <ev> mpt: not yet, no
[09:03] <ev> my priority at the moment is getting error reporting working on mobile and server, while working through this datacenter move (then back population jobs, woo) and testing acunu analytics for possible use. Detected{Since,Until} is just not something I'll have time for in the near future
[09:05] <ev> dpm: you're my hero for the workaround in https://bugreports.qt-project.org/browse/QTBUG-32225
[09:06] <dpm> ev, no worries, Wellark is the person to credit, he suggested it to me :)
[09:06] <ev> thanks to the both of you then :)
[09:07] <seb128> hum
[09:07] <dpm> :-)
[09:07] <seb128> update-manager is hanging on a " [debconf-communi] <defunct>"
[09:27] <ev> seb128: do you know what the plan is for mobile with respect to dbus services that currently require authentication via policykit? Are we going to start shipping 10-vendor.d configs setting ResultActive=yes for the phablet group?
[09:29] <ev> the background for this being that we currently have com.ubuntu.WhoopsiePreferences which controls access to /etc/default/whoopsie. On the desktop, it requires an admin user to enter their password via polkit to call the dbus methods. My understanding is that we don't want to ask the user to reauthenticate when changing system settings on the phone.
[09:32] <seb128> ev: no, I don't know, it's on my list of things to check with the sdk/security teams, the previous times I asked people didn't really know/think about it yet
[09:32] <seb128> ev: I'm not sure we even have polkit on the touch image atm (the UI is GTK as well which is an issue)
[09:33] <pitti> cjwatson: ah, it finally finished building, uploaded svn
[09:33] <ev> seb128: *nods* thank you
[09:34] <seb128> ev: yw ... I'm going to try resume discussions about that and I will include you
[09:34] <ev> very much appreciated, thanks
[09:50] <capdenuca> anyone over here?
[09:50] <cjwatson> Just ask - don't ask to ask
[09:52] <capdenuca> do u know how to get a mirc user?
[09:52] <cjwatson> I'm not sure how a Windows IRC client is relevant to this channel?
[09:53] <capdenuca> cuz i m new on this...
[09:54] <cjwatson> I think you're confused and want some other channel.  I'm not sure which.
[09:54] <cjwatson> This channel is for development of Ubuntu.
[09:55] <quadrispro> hello everybody
[10:26] <ev> mpt: got a second?
[10:48] <ev> mpt: so it's not going to centre, because the toolkit defaults to left-aligned for captions and does not expose that property: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/ListItems/Caption.qml#L57
[10:48] <ev> think I should file a bug for that?
[10:49] <mpt> ev, no, that's fine, all captions should line up the same.
[10:49]  * ev nods
[10:56] <seb128> ev: what are you trying to do?
[10:57] <ev> seb128: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings (righthand mockup)
[11:01] <seb128> ev: you can do http://paste.ubuntu.com/5867801/
[11:02] <seb128> ev: but please open a bug on the toolkit asking them to allow changing the alignement
[11:02] <ev> seb128: sure, but I'm more keen on staying consistent
[11:02] <seb128> ev: consistant with what?
[11:02] <ev> the rest of the interface
[11:02] <seb128> ev: caption will not do what you want anyway
[11:02] <ev> it's going to look weird if we have some captions left aligned and some centred
[11:03] <ev> as mpt also seemed to suggest
[11:03] <seb128> ev: ok, well still caption is going to be weird, they have colored background
[11:03] <seb128> ev: cf. https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1194513
[11:03] <xnox> ev: file:///usr/share/ubuntu-ui-toolkit/doc/html/qml-ubuntu-components-listitems0-standard.html
[11:03] <seb128> xnox, you can't wrap in standard, see ^
[11:04] <xnox> ev: List Items -> progression. It's a left aligned text with progress arrow on the right. I would have used that standard element.
[11:04] <xnox> seb128: yeah, sucks =)
[11:05] <ev> xnox: I'm already using progression - we're talking about the caption item
[11:06] <xnox> oh, isee.
[11:06] <xnox> I got ubuntu-sdk guru answer a question on centered wrapping for me here: http://askubuntu.com/questions/308088/how-to-make-a-centred-wrapped-and-padded-container-of-elements-in-qml
[11:06] <xnox> which does work in a Column.
[11:09] <seb128> xnox, http://paste.ubuntu.com/5867801/ works
[11:09] <seb128> xnox, but ev doesn't want to use non standard elements
[11:10] <xnox> seb128: ok. I don't think I've done inheritance yet.
[11:10] <seb128> xnox, the system settings are mostly listitems
[11:10] <seb128> see e.g the about settings
[11:11] <seb128> we have random alignments and hacking there ;-)
[11:11] <xnox> seb128: ok. i think i've asked yesterday, but is anybody working on porting chewieui / indicators-client / wifi portion into the system settings?
[11:11] <seb128> xnox, ted
[11:11] <seb128> xnox, well, he's working on the indicator
[11:12] <seb128> but the idea is that the indicator is gmenu based code sent to unity which renders it through a qmenumodel/unitymenumodel
[11:12] <seb128> we plan to reuse the model in system settings
[11:12] <seb128> since most of the items/actions will be shared
[11:13] <xnox> seb128: but there is slight differences in design, the system settings has more options.
[11:13] <seb128> right
[11:13] <seb128> the indicators services will have several "profiles"
[11:13] <seb128> e.g different layouts they export
[11:13] <seb128> one for desktop
[11:13] <seb128> one for greeter
[11:13] <seb128> one for phone
[11:13] <seb128> one for settings
[11:14] <seb128> the service basically has all the items that will be used and actions
[11:14] <seb128> then you build models with the layout/actions you need
[11:14] <xnox> seb128: what should I do for oobe then, cause i also need "connect to network" step.
[11:14] <seb128> talk to ted
[11:14] <xnox> ted, talk to me =)
[11:14] <seb128> but it should be "hit the menu/action though unitymenumodel", I'm not sure how that works though
[11:14] <seb128> it's a bit early for ted
[11:15] <xnox> yeah, and not idling via irc proxy. Right. will poke him in late afternoon.
[11:37] <ev> xnox, seb128: if you have some free time: https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385
[11:39] <seb128> ev: thanks, I will try to review/comment today
[11:40] <seb128> ev: could you or mpt update the design on https://wiki.ubuntu.com/SystemSettings to list that panel because it's not there at the moment? (should it really be a main category item in rather rather than a subpanel in security&privacy for example)?
[11:41] <seb128> ev: oh, it's in https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone
[12:04] <mpt> Ugh, why did I think it was top level?
[12:04] <mpt> Sorry, ev
[12:04] <mpt> Memory malfunction
[12:05] <ev> mpt: so it should be accessible from "Security & Privacy"?
[12:05] <mpt> ev, yes
[12:06]  * ev nods
[12:07] <ev> I'll fix that in the MP
[12:07]  * Laney pauses reviewing :P
[12:07] <ev> oh boo :)
[12:07] <ev> do feel free to pick apart the rest of it
[12:07] <Laney> just saw some from seb anyway
[12:08] <seb128> Laney, I did a quick one before lunch, it would still be good if you would review/comment
[12:08] <Laney> I'll take Round Two after those are addressed
[12:08] <seb128> especially on the cpp code, I glanced to that one only
[12:08] <seb128> thanks
[13:27] <obounaim> Hi everybody
[13:27] <obounaim> Is there a way in Ubuntu to get the number of users of a given package
[13:32] <geser> not really, you could look at the popcon data but it's only a *very* rough estimate
[13:35] <obounaim> Ok thanks
[13:35] <obounaim> but where can I find this popcon data?
[13:35] <pitti> cjwatson: libapache2-svn is NBS now, removing
[13:35] <cjwatson> I already did
[13:35] <pitti> or, someone already did that
[13:35] <cjwatson> Thanks
[13:37] <geser> obounaim: http://popcon.ubuntu.com/
[13:45] <obounaim> thanks
[13:53] <obounaim> is popularity-contest installed by default in Ubuntu?
[13:53] <debfx> obounaim: yes, but submission is opt-in
[13:56] <obounaim> so it sends data about installed packages by defaults right?
[13:57] <debfx> obounaim: no, only when you configure it to do so (I think the installer has a checkbox that is disabled by default)
[13:58] <obounaim> ok
[13:58] <obounaim> so what did you mean by "opt-in"?
[14:02] <geser> exactly that, the user has actively to enable it during installation (opt-in) otherwise no data gets send
[14:05] <obounaim> ok thanks
[14:45] <caribou> when a submitted debdiff fixes two existing bugs, should it be uploaded to both bugs or only one ?
[14:46] <caribou> sorry to bug you about this here but didn't get an answer in #ubuntu-bug
[14:58] <infinity> caribou: It should mention both bugs in the changelog.  Don't really care where the diffs go, best to just find a sponsor and get it sorted.
[14:59] <caribou> infinity: well that's the danted fixes we talked about yesterday. Both bugs are outlined in the changelog
[15:00] <infinity> caribou: Toss me a diff, and I'll look at sponsoring it.
[15:00] <caribou> infinity: I completed the SRU template  & subscribed the appropriate teams.
[15:01] <caribou> infinity: they're attached here : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
[15:01] <caribou> I can send them over by mail if you want; both precise & saucy
[15:02] <caribou> infinity: I added the search snippet you suggested yesterday
[15:03] <caribou> infinity: both tested on saucy & precise, 32 & 64 bit
[15:03] <infinity> caribou: I'll look at the bug(s) in a second.
[15:03] <caribou> infinity: no rush,I'm almost done for the week
[15:05] <dobey> who is it again that is most appropriate to ping about busted bzr imports of package uploads? wgrant and who else? i pinged wgrant last night before i left, but unfortunately didn't get a reply :-/
[15:06] <infinity> dobey: I think xnox has been looking into import issues.
[15:06] <dobey> xnox: have you? :)
[15:07] <xnox> dobey: what package?
[15:07] <xnox> dobey: yeah, i have access to the imported and _some_ experience in it.
[15:08] <dobey> xnox: software-center failed
[15:08] <dobey> http://package-import.ubuntu.com/status/software-center.html#2013-07-05%2021:56:29.968306 is the error
[15:09] <dobey> seems to be a common problem though, those missing revisions from james_w :-/
[15:46] <dpb1> slangasek: Hi -- upstart question.  I have a non-forking daemon that is early exiting (log file permissions are wrong).  Is there a way to catch this error so the "start daemon" command fails?  Or is that not something to worry about?
[15:48] <tedg> cjwatson, Do you expect the $(pkgdir)/.click/$(pkgname)/manifest path to remain constant?
[15:48] <tedg> cjwatson, At least in the near term.
[15:48] <stgraber> dpb1: so it's not exiting non-null before it's done double-forking? otherwise I'd expect upstart to notice the failure and make the start call fail
[15:49] <dpb1> stgraber: this is a non-forking daemon (running in foreground)
[15:57] <stgraber> hmm, not sure that's possible for a non-task to return a failure to start when it's not forking
[16:10] <dpb1> :( ok  I thought post-start could be helpful, but it seems to ignore exit codes from therewq
[16:14] <slangasek> dpb1: so you have no 'expect' stanza; which means upstart believes the job is successfully started as soon as it has exec'ed the program.  I'd say you want to change it so upstart can know that it's failed, if you care about 'start' not returning success when the startup hasn't succeeded.
[16:16] <cjwatson> tedg: Yes.
[16:17] <tedg> cjwatson, cool, thanks!
[16:17] <cjwatson> tedg: Though it's actually $(pkgdir)/.click/info/$(pkgname).manifest ...
[16:18] <stgraber> slangasek: but how would you do that with a non-forking service (as seems to be the case here)?
[16:18] <tedg> cjwatson, Ah, sorry, I wrote from memory instead of cut-and-paste.  I was planning to look again :-)
[16:19] <dpb1> slangasek: hmm.  So, adding a post-start "sleep 5" for instance prints the "daemon stop/waiting", but I still get a 0 exit code from the service command.  And I get 0 exit from status as well, which doesn't seem right?  Unless I'm missing something.
[16:19] <dpb1> (which is likely)
[16:19] <slangasek> stgraber: 'expect stop' is the least intrusive
[16:20] <slangasek> dpb1: 'sleep 5' just means that upstart thinks that a) the main program started successfully, b) the post-start script exits successfully, so 'service' (or 'start') returns success.
[16:37] <dpb1> slangasek: http://paste.ubuntu.com/5868569/ -- I worked up a paste that demonstrates what I'm talking about.  Hopefully it makes more sense than my prose.  How do I get non-zero exit status when the daemon is not running?
[16:39] <jbicha> mardy: could you approve https://code.launchpad.net/~jbicha/gnome-control-center-signon/fix-build-with-control-center too?
[17:04] <slangasek> dpb1: sorry, I understood already exactly what you were asking for, it must be my answers which were unclear. :)  The easiest way for upstart to reliably know whether your non-daemon process has launched successfully is to use 'expect stop', and modify your program to raise SIGSTOP when it considers itself successfully started
[17:04] <slangasek> dpb1: (probably something that you want to have as a commandline option to the program, since raising SIGSTOP isn't normally something you'd do when run from the commandline)
[17:08] <dpb1> slangasek: intersting.  I'm looking into that now, thanks.
[17:10] <slangasek> dpb1: documentation in init(5), though that doesn't add much over what I've already said
[17:11] <dpb1> slangasek: OK, thanks.  I'm still curious though why service status is not showing an error when the daemon is not running (and upstart knows it is not).  If I switch over to SIGSTOP, that will suddenly start working, I hope? :)
[17:12] <dpb1> by error, I mean, exit status
[17:16] <slangasek> dpb1: that seems like a bug in the service command
[17:20] <dpb1> Tracing, it's just a pass-through to status, which is a call to initctl, which also shows the same behavior.  I'll look for a bug.
[17:21] <dobey> xnox: hey. were you able to get software-center branch import fixed up?
[17:23] <slangasek> dpb1: it's not a bug in initctl, whose exit codes are defined to represent success/failure of the dbus calls, not anything about the service status
[17:23] <slangasek> dpb1: it may be a bug in the service command, I'm not sure
[17:23] <dpb1> slangasek: not this? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/552786  seems the same?
[17:24] <slangasek> dpb1: comment #11 - this is about return codes from upstart-job, which is deprecated
[17:25] <slangasek> dpb1: is this on saucy? precise?
[17:25] <xnox> dobey: i did requeue it...
[17:25] <dpb1> slangasek: precise
[17:25] <xnox> dobey: $ bzr branch lp:ubuntu/software-center
[17:25] <xnox> Most recent Ubuntu version: 13.05-0ubuntu2
[17:25] <xnox> Packaging branch status: CURRENT
[17:25] <slangasek> dpb1: ok - then yes, that version of service may be affected by that bug in upstart-job
[17:25] <xnox> yes.
[17:27] <dobey> xnox: ah cool, thanks! :)
[17:27] <dpb1> slangasek: ah, gotcha.  initctl also shows this behavior though.  Is there a way to poll the service status more reliably on precise?
[17:28] <slangasek> dpb1: initctl is *supposed* to behave that way
[17:28] <slangasek> things that want a different exit code for running/not-running need to parse the initctl output and do their own mapping to error codes
[17:28] <slangasek> this is what 'service' is meant to do
[17:28] <slangasek> (or upstart-job, depending on which iteration)
[17:29] <dpb1> slangasek: ok, thanks.  that helps.
[17:29]  * dpb1 stops sucking up all of slangasek's time now
[17:29] <slangasek> fwiw, it looks like this issue is still present in the saucy version of service
[17:33] <dpb1> slangasek: yes, I'm seeing that, thanks.  I wonder what puppet has done to workaround it.  probably parse I guess
[17:33] <slangasek> I believe so
[17:33] <ev> mardy: so I tried your suggestion of subclassing QDBusInterface, but I'm running into a segfault deep in the bowels of the generated code: http://paste.ubuntu.com/5868715/ (diff against lp:~ev/ubuntu-system-settings/diagnostics) and http://paste.ubuntu.com/5868718/
[17:34] <ev> I can't seem to figure out what's going on here
[18:42] <Snow-Man> hrmmm, ipv6 for the systems behind us.archive.ubuntu.com appears to be non-functional this afternoon. :(
[21:07] <dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/saucy/ubuntu-meta/drop-u1-gnome/+merge/174471 please? :)
[21:20] <infinity> dobey: If by "sponsor", you mean update the seeds, maybe...
[21:25] <dobey> infinity: i guess that's what it means. i just want to get ubuntuone-client-gnome gone :)
[21:25] <dobey> (anyway, i'm gone now. thanks.)
[21:29] <infinity> dobey: Uploaded.
[22:44] <cjwatson> barry: Hum.  Does ./run-tests in lp:click fail for you (you'll need to "./configure && make" first, nowadays)?
[22:44] <cjwatson> barry: I get an outstandingly weird failure: http://paste.ubuntu.com/5869503/
[22:45] <barry> cjwatson: `apt-get purge python-configparser` and try again ;)
[22:45] <slangasek> hah
[22:45] <barry> slangasek: yeah ;)
[22:46]  * slangasek punches configparser in the exception handler
[22:47] <barry> slangasek, cjwatson i had a long chat today with upstream.  most of the failures we saw really are bugs in the code that uses configparser, not in configparser itself.  configglue, but virtue of using configparser broke its api which caused the cascading problems.  virtualenv is at fault here (and it's really insane anyway) but upstream has promised to make configparser more bullet proof
[22:47] <cjwatson> Right - but why am I seeing '/usr/bin/python3.3', '/usr/lib/python2.7/dist-packages/virtualenv.py' ... there?
[22:48] <cjwatson> It's true that purging python-configparser fixes it; I was just put off by what appeared to be attempts to run Python 2 code in Python3
[22:49] <barry> cjwatson: that's virtualenv's insanity.  it re-invokes itself with the version of python its creating the venv for but does it in a python 2 context.  yes, it's fscking nuts, but that's the way it works!  the bullet proofing i mentioned is to make configparser python 3 compatible for exactly this reason, even though it isn't intended to run under python 3 normally (because py3 has the real configparser)
[22:50] <barry> iow, venv will execute some py2 code under py3
[22:50]  * barry boggled
[22:52] <cjwatson> owwwwwwwwwwww
[22:52] <cjwatson> gotcha.  I think. :)
[22:55] <barry> don't ask me *why* it does that ;)
[22:57] <cjwatson> argh freaking python-debian out of sync in pip
[22:57] <cjwatson> barry: remind me how you got click's tests working in python3.2 despite the cheeseshop version of python-debian being confused?
[22:57] <cjwatson> I remember you talking about this but not the resolution ...
[22:57] <barry> virtualenv --system-site-packages ...
[22:57] <barry> ignores pypi for anything you already have installed
[22:58] <cjwatson> ah.  can tox pass that along?
[22:58] <barry> errr, yeahhh.  let me look that up
[22:58] <cjwatson> or do I just need to make the virtualenv by hand first?
[22:58] <barry> cjwatson: http://testrun.org/tox/latest//config.html#confval-sitepackages=True|False
[22:59] <cjwatson> Hm, sitepackages=True already in tox.ini
[23:00] <cjwatson> Oh, maybe this is because my python3.2 build has the wrong site-packages
[23:02] <cjwatson> Much better, woo
[23:02] <cjwatson> Thanks
[23:02] <barry> np!
[23:28] <cjwatson> beuno: Do we have anything anywhere yet about what the click app download arrangements are going to be - URLs etc.?
[23:29] <cjwatson> beuno: ... never mind, just found it on https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex


[18:11] <j4m3s> SpamapS, you around?
[19:16] <j4m3s> is it possible to specify how many times a program will fork for the expect stanza?
[19:19] <SpamapS> j4m3s: I am now, sorry, whats up?
[19:19] <SpamapS> j4m3s: no, you can do 1 (expect fork) or 2 (expect daemon)
[19:19] <SpamapS> j4m3s: any reasonable program should only ever fork that many times to become the eventual master process anyway
[19:19] <j4m3s> bigcouch forks 33 times before
[19:19] <SpamapS> I doubt that
[19:19] <SpamapS> j4m3s: those are probably threads
[19:20] <SpamapS> the advice in the cookbook isn't entirely accurate.. I'm convinced the clone bits need to be re-evaluated
[19:21] <j4m3s> well i used the cookbook to determine the fork count
[19:22] <j4m3s> SpamapS, this is what i have so far
[19:22] <j4m3s> http://pastie.org/private/okibfp83s2oi5lb6emag
[19:23] <SpamapS> j4m3s: erts should have a "don't daemonize" flag somewhere..
[19:23] <SpamapS> err, not erts, but erl
[20:25] <j4m3s> SpamapS, so if i start a process in pre-start and i want to stop it in post-stop, but it's not being killed. what am i doing wrong? http://pastie.org/private/apk4xedro2xtrbinygsg
[20:26] <SpamapS> j4m3s: that looks like it should, in theory, work
[20:27] <j4m3s> because it tells me it stop the job, and the main process is stopped but the other one still exists
[20:27] <SpamapS> j4m3s: btw, your start on is crap.   "runlevel [2345]" is what you want (Unless you're on a release of Ubuntu before 11.10, then you want 'net-device-up IFACE=whateveryourethXis'
[20:27] <j4m3s> lol
[20:27] <SpamapS> j4m3s: pgrep isn't exactly an exact science
[20:28] <SpamapS> j4m3s: perhaps log the pid you try to kill
[21:12] <j4m3s> SpamapS, can you tell me if this variable usage is not allowed in upstart 0.6.5? http://pastie.org/private/wk1pteb9vmdkbmepkicq
[21:12] <j4m3s> specifically line 21 & 22
[21:13] <j4m3s> ie. it works with line 22 and doesn't work with line 21
[21:16] <SpamapS> j4m3s: there is no expansion in env statements, even in the latest upstart
[21:16] <j4m3s> SpamapS, that answers that! thx again!
[21:18] <j4m3s> SpamapS, does that mean i couldn't do var=$foo:/usr/bin ; env PATH=$var ?
[21:27] <SpamapS> j4m3s: correct, that will not work
[21:39] <j4m3s> SpamapS, will variable expansion work in an exec stanza?
[21:43] <SpamapS> j4m3s: yes
[21:43] <SpamapS> exec and script are fine
[21:43] <SpamapS> and start/stop on too
[21:43] <SpamapS> and instance
[21:47] <j4m3s> SpamapS, so i am trying to use $EMU in the exec and it's not being set properly any ideas? http://pastie.org/private/ti12eytjhg23h07evyohww
[22:01] <SpamapS> j4m3s: in a script statement, you don't want to say 'env XXX...'
[22:01] <SpamapS> j4m3s: just XXX=...
[22:01] <SpamapS> j4m3s: and you don't need to export it
[22:01] <j4m3s> SpamapS, ok gotcha
[22:01] <SpamapS> j4m3s: as the shell that you're setting it in, is the one evaluating the exec line
[22:03] <j4m3s> SpamapS, can you have two execs in a script statement?
[22:04] <SpamapS> j4m3s: sure, but only one will happen because exec replaces the current process
[22:04] <SpamapS> j4m3s: you can background stuff tho
[22:04] <SpamapS> foo1 & exec foo2
[23:09] <j4m3s> SpamapS, is it possible to do something like TMP=`env VAR=$foo` within a script statement?
[23:11] <j4m3s> SpamapS, is there another way i can set an environment variable in that shell that can handle variable expansion?
[23:12] <j4m3s> SpamapS, http://pastie.org/private/df0a1urpr2ajq1dslzjaq


[08:07] <fgimenez> good morning
[08:08] <mvo> hey fgimenez, good morning
[08:08] <fgimenez> hi mvo :)
[08:09] <dholbach> good morning
[08:16] <mvo> hey dholbach, good morning
[08:21] <dholbach> hey mvo
[09:04] <davidcalle> Good morning
[10:03] <JamesTait> Good morning all; happy Monday, and happy Button Day! 😃
[11:23] <dholbach> mvo, from which ppa would I get the most up-to-date ubuntu-snappy-cli for devel and 15.04 respectively?
[11:32] <mvo> dholbach: generally ppa:snappy-dev/tools is a good one, what do you need it for? we also have daily build ppas
[11:32] <sergiusens> ogra_, dholbach how do I update https://developer.ubuntu.com/en/snappy/guides/porting/ ?
[11:32] <ogra_> sergiusens, didnt someone give you write access to that ?
[11:32] <davidcalle> sergiusens, login with http://developer.ubuntu.com/openid/login
[11:33] <sergiusens> ogra_, yes, but not sure if there is a markdown source synced from it
[11:33] <davidcalle> sergiusens, ah, no md source
[11:33] <sergiusens> davidcalle, grat, I'll take the bullet tonight, wasn't easy to edit from the web for me :-P
[11:34] <dholbach> mvo, the question came up if we could automatically import a snappy manpage (I found out that 'snappy man' creates one)
[11:34] <davidcalle> sergiusens, if you struggle with the editor, ping me or dholbach anytime :)
[11:34] <sergiusens> I'll ping mhall as you guys might be sleeping when I decide to edit this ;-)
[11:35] <dholbach> mvo, maybe during the build one could be generated? :)
[11:35] <sergiusens> dholbach, if you can, Chipaca and myself failed to hook it up correclty in debian/rules
[11:36] <dholbach> sergiusens, ok, I'll take a look
[11:36] <davidcalle> sergiusens, naah, I'll just give you dholbach phone number, he is awake all night! :p
[11:36] <Chipaca> um
[11:36] <Chipaca> sergiusens: I have "man snappy"
[11:36] <Chipaca> sergiusens: from debian/rules
[11:36] <sergiusens> davidcalle, oh, I have him on telegram, I can wake him up :-P
[11:36] <sergiusens> Chipaca, oh, then it was already done and I forgot
[11:36] <Chipaca> sergiusens: don't you?
[11:37] <Chipaca> $ dpkg -S snappy.1
[11:37] <Chipaca> ubuntu-snappy-cli: /usr/share/man/man1/snappy.1.gz
[11:37] <sergiusens> Chipaca, yes
[11:37] <dholbach> Chipaca, you're right, thanks O:-)
[11:38] <Chipaca> sergiusens: i did this when i added 'snappy man' :)
[11:38] <sergiusens> let me rephrase, **I had a hard time** and then you created a working branch ;-)
[11:39] <sergiusens> dholbach, there is no man in ubuntu core though
[11:39] <dholbach> sergiusens, no worries - this would be for importing into the dev site
[11:39] <Chipaca> dholbach: note the manpage also lists internal commands, as it's a zero-effort automatic thing generated from the thing that does commandline parsing
[11:40] <dholbach> Chipaca, that's good to know
[11:40] <Chipaca> dholbach: ideally those internal ones would be pruned (but upstream isn't amenable to patches)
[11:41] <dholbach> mvo, the last ubuntu-snappy-cli uploads to that ppa are from july
[11:41] <mvo> Chipaca: for some unexplained reason that has changed recently and the patch to hide stuff is in. at the same time the drop-priv stuff will soon vanish
[11:41] <Chipaca> mvo: seriously? woo! we should merge that in
[11:41] <mvo> dholbach: hm, then you will need the daily one from ppa:snappy-dev/image
[11:42] <mvo> Chipaca: yeah, no explanation just the github message "merged #XY"
[11:42] <dholbach> mvo, great - thanks
[11:42] <Chipaca> mvo: there's 5 internal commands, not just drop-priv. And some more that could probably do with being reclassified as internal.
[11:43] <Chipaca> mvo: e.g. booted is internal, but firstboot isn't?
[11:43] <Chipaca> ah, wait, first_boot is
[11:43]  * Chipaca learns to read
[13:35] <ogra_> hmpf
[13:36] <ogra_> sergiusens, Chipaca, do we have some kind of "inetd plugin"  in snapcraft ? i wonder how to snap up a service that relies on it
[13:36] <Chipaca> ogra_: we do not
[13:36] <ogra_> ah sad
[13:36] <Chipaca> ogra_: we'd have to expose one more service flag for that
[13:36] <Chipaca> which is totally doable, but needs doing :-)
[13:36] <ogra_> well, not sure if thats very common
[13:37] <ogra_> (people packaging inetd depending services)
[13:37] <Chipaca> ogra_: OTOH, all you need to turn an inetd plugin into a regular service is netcat
[13:37] <ogra_> yeash
[13:37] <ogra_> thats my fallback idea
[13:37]  * Chipaca oversimplifying complex engineering problems since 1976
[13:37] <ogra_> i'm just wondering if it is a common task ... in which case a snapcraft option would make sense
[13:38] <Chipaca> ogra_: file a bug, see how many people me-too it?
[13:38] <ogra_> yeah, will do
[13:39] <Chipaca> ogra_: don't forget to say «don't comment with “me too”», so people comment with “me too”
[13:39] <ogra_> +1
[13:39] <ogra_> :D
[13:40] <ogra_> geez
[13:40] <ogra_> so i tried to snap up approx (which caused the above question) ... and just noticed the resulting snap is 74MB !!
[13:40] <ogra_> thats half an OS !
[13:40] <ogra_> (or even a full one)
[13:44] <sergiusens> ogra_, build it from source!
[13:45] <ogra_> heh
[13:45] <ogra_> crazy talk !
[13:54] <Chipaca> ogra_: https://gist.github.com/chipaca/58552b58a1a75cd1607b
[13:55]  * Chipaca hugs rsalveti
[13:56] <ogra_> Chipaca, dude ! why is that not snapped !
[13:57] <Chipaca> ogra_: because i'd need to change it for small memory systems
[13:57] <Chipaca> ogra_: or clean it up
[13:57] <Chipaca> ogra_: maybe even merge in whatever's gone on with TinyHTTPProxy in the 3+ years since I did this to it
[14:03]  * rsalveti hugs Chipaca
[14:27] <rtg> lool, hey, can you have a look at git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me why my snapcraft.yaml doesn't copy files into the snap from staging ?
[14:28] <ogra_> rtg, did you find a way to generate the initrd yet ?
[14:28] <rtg> ogra: I ruthlessly butchered rootstock to do so
[14:28] <ogra_> lol
[14:29] <ogra_> you should really take the livecd-rootfs snippet for that :)
[14:29] <ogra_> rootstock adds a massive overhead
[14:30] <rtg> ogra_, the first thing I did was to only go one level deep. I didn't need to do nested qemu. hence the major surgery, but I did extract the concepts I needed.
[14:31] <ogra_> well, you need the nested qemu chroot if you are actually buildin for another arch
[14:31] <ogra_> but only then
[14:32] <ogra_> beyond that a simple "debootstrap --variant=minbase" should be fine
[14:32] <rtg> for now I'm just trying to get amd64 working
[14:33] <ogra_> debootstrap --variant=minbase + PPA setups for the different special kernels + the snappy specific packages needed in the initrd
[14:33] <ogra_> that should be all you need
[14:33] <ogra_> then just install your meta and pull out the files from the tree you need
[14:33] <rtg> ogra_, what snappy specific packages do I need in the initrd ?
[14:34] <ogra_> initramfs-tools-ubuntu-core at least ... i have to chekc livecd-rootfs
[14:34] <rtg> ogra_, that sounds familiar
[14:34] <ogra_> (there are a few more)
[14:35] <sergiusens> rtg, how about building the kernel instead of using the deb?
[14:35] <sergiusens> for people building alternate trees
[14:36] <rtg> sergiusens, that is the next example I'm gonna work on
[14:36] <sergiusens> great
[14:36] <sergiusens> rtg, after we have this I guess I'll start using your stuff to create a proper plugin that wraps all this in
[14:36] <rtg> sergiusens, I thought I'd do a snap for each reference kernel, plus one as an example for building from source
[14:41] <lool> rtg: you need to make install to DESTDIR
[14:42] <rtg> lool, in the Makefile plugin ?
[14:42] <lool> rtg: in the Makefile itself, yup
[14:42] <lool> rtg: snapcraft sets DESTDIR to the right di
[14:42] <lool> dir
[14:42] <rtg> lool, cool, now I see that in the examoples
[14:49] <fgimenez> elopio_, the jenkins instance is ready to go, you have access to the canonistack dashboard as the ues-snappy-integration-tests user, right?
[14:50] <elopio_> fgimenez: yes.
[14:50] <mvo> fgimenez: is it possible to run the new integration test machinery against the branch https://github.com/mvo5/snappy/tree/feature/native-security-policygen-regen ? or is that not possilbe (yet?)
[14:51] <fgimenez> elopio, ok, it's created for that user, there's also a floating ip assigned to it, the webhook should point to it
[14:51] <fgimenez> elopio, sure, the -src flag is the branch and the new repo flag the repo location, like https://github.com/user/snappy
[14:52] <fgimenez> elopio, in that case -src native-security-policygen-regen -repo https://github.com/mvo5/snappy
[14:53] <fgimenez> mvo, ^ :)
[14:53] <elopio> mvo: ^
[14:53] <elopio> mvo, fgimenez, but we can't yet generate an image with taking the snappy deb from the branch, right? We can just overwrite the snappy binary for now.
[14:54] <fgimenez> elopio, yes, snappy and snapd binaries
[14:54] <mvo> elopio: that should be ok, I'm curious if the integration test shows any regressions. if its a lot of work for you I can just merge and see the results from the normal integration test run. this needs to go in, but of course the less disruption the better :)
[14:54] <fgimenez> mvo, whenever you make a PR or add commits to an existing one the job is triggered anyway, once the webhook is in place
[14:56] <mvo> fgimenez: ok, is it worth waiting for the webhook, i.e. is this happening really soon? no problem if not, I'm ponering if I merge now or wait a little bit, but I'm more on the merge-now side currently
[14:57] <fgimenez> mvo you can set it up right now :) this is the url http://<IP_ADDRESS>:8081/ghprbhook/, the events ticked should be "Pull request" and "Issue comment"
[14:58] <fgimenez> mvo, it is in the "Settings -> Webhooks & services" section of the repo
[14:58] <mvo> fgimenez: aha, nice. let me try that
[14:59] <fgimenez> mvo, the jenkins instance is at http://<IP_ADDRESS>:8080, only accessible from the vpn
[15:01] <elopio> fgimenez: I'm not sure where I got the idea that uboot was not changing snappy_ab on update. Maybe it was a bug, or maybe it came from the voices in my head.
[15:02] <fgimenez> elopio, :) iirc i've seen it not being changed, anyway now the code is a lot cleaner
[15:03] <ogra_> rtg, http://paste.ubuntu.com/13299329/ try turning that snippet into a script and you should get something that is identical to the device tarballs that livecd-rootfs creates today ... without all the rootstock overhead
[15:04] <ogra_> (there are some live-build specifics in there you need to replace but thats minor)
[15:05] <rtg> ogra_, I thought the goal was to build a snap, not a device tarball
[15:06] <ogra_> rtg, you want the same contents in both
[15:06] <ogra_> they should be absolutely identical except that one is a squashfs img and the other is a tarball
[15:07] <rtg> ogra_, even the YAML file ?
[15:07] <ogra_> thats something mvo needs to answer ... :)
[15:08] <ogra_> you definitely want the same initrd and you want the right PPA used for the right suabarch
[15:08] <ogra_> and afaik mvo used the existing device tarballs during the all snaps development as input
[15:08] <rtg> ok. I am close to being able to build the snap. I have some permissions issues. then I'll look at this.
[15:21] <asac> would personally be awesome if we could make the kernel plugin capable of cross compiling
[15:22] <asac> rtg: ogra_ sergiusens: ^
[15:22] <asac> just as input
[15:22] <rtg> asac, when built from source it certainly will be.
[15:22] <sergiusens> asac, I'm fine with per plugin x-compile
[15:23] <ogra_> asac, trivial ...
[15:23] <ogra_> (but needs qemu-user-static for the initrd chroot ... that will limit us)
[15:24] <asac> rtg: are we doing the "built from debs in archive" variant first?
[15:24] <asac> guess yeah, then its later
[15:24] <rtg> asac, yup, that is what I'm working on
[15:24] <asac> sergiusens: isnt x- something we used for something else?
[15:24] <ogra_> asac, rtg, the initrd generation will always have to be deb based FWIW
[15:25] <ogra_> we dont have a way to "just generate" one without that
[15:25] <rtg> ogra_, fortunately the kernel makefile has a deb target
[15:25] <asac> i thoguht we do generic initrd that is in the OS
[15:26] <asac> so we dont need that in kernel
[15:26] <ogra_> we *could* do the same we do for touch and actually geneare the initrd inside a package build ... but then you need to be sure to never need modules for booting
[15:26] <asac> mvo: ?
[15:26] <sergiusens> asac, x as in cross
[15:26] <sergiusens> not sure what else you speak of ;-)
[15:26] <mvo> asac: sorry in a meeting
[15:26] <asac> sergiusens: yeah, thought we used x- for another implicit meaning... like local plugins, but think we moved away from that
[15:26] <asac> all fine
[15:26] <ogra_> asac, we cant ... specifically with the new requirement for squashfs
[15:26] <ogra_> you need the modules
[15:26] <asac> ogra_: i think its the spec to have initd in OS snap
[15:26] <sergiusens> asac, we have that still (x for extension)
[15:26] <asac> and just say kernel folks have to built in what they need
[15:26] <ogra_> thats not possible
[15:26] <ogra_> you need to find the rootfs from the initrd
[15:27] <asac> well, it technically would get copied
[15:27] <ogra_> which means you need to support the disk type, controller, filesystem
[15:27] <asac> to the boot paertition from the OS
[15:27] <asac> but the one and only initrd is in the OS snap ... so we dont need to build it turning kernel buil;d
[15:27] <ogra_> asac, that still wont have the right contents
[15:27] <asac> thats how i understand at least one of the proopsals
[15:27] <ogra_> you need the kernel modules inside the initrd
[15:27] <asac> ogra_: we can say you cant put them there\
[15:27] <asac> like what you suggested for long time :)
[15:27] <ogra_> then you cant boot
[15:27] <mvo> asac: generic initrd is on the roadmap *but* right now we need the squashfs and nls modules (iso8859) so we can't have a module-less iniitrd
[15:28] <sergiusens> ogra_, asac rtg can't we make initrd mount the modules from the kernel?
[15:28] <ogra_> asac,  if we can have it module less, we can do the same as for touch
[15:28] <ogra_> sergiusens, you still need to find them
[15:28] <asac> so you need modules only in the initd if you need them to mount the rootfs afaik
[15:28] <asac> so thats disk drivers, filesystem types etc.
[15:28] <ogra_> sergiusens, so all needed modules for that need to be there
[15:28] <ogra_> asac, right
[15:28] <rtg> sergiusens, yeah, what ogra_ said
[15:29] <asac> once you have rootfs (or a partition that hosts the modules) you can go and load modules
[15:29] <sergiusens> ogra_, then it is a no brainer to just include it in the kernel
[15:29] <ogra_> asac, network cards for things like remote keys for encrypted rootfs
[15:29] <asac> hmm
[15:29] <sergiusens> it is not really a generic kernel, is it?
[15:29] <asac> well, so there is still stuff that is rather a configuration etc.
[15:29] <ogra_> sergiusens, if we actually want saushfs inside all kernels, sure ;)
[15:29] <ogra_> sergiusens, it is -generic
[15:29] <ogra_> thats the prob :)
[15:29] <asac> dont think the factory keys would go into the initrd ... at least i never anticipated that
[15:29] <sergiusens> ogra_, it always going to be loaded for core
[15:29] <ogra_> asac, no, the keys live on a remote server
[15:30] <ogra_> asac, but you need to obtain them via network
[15:30] <ogra_> at least in one specific arch we support today
[15:30] <ogra_> sergiusens, from where ?
[15:31] <sergiusens> ogra_, from the kernel itself
[15:31] <ogra_> note that i would love nothing more than to use the same setup we have for the touch initrd in core
[15:31] <ogra_> but as long as we hard depend on modules we cant
[15:37] <rtg> sergiusens, how do you inspect a snap ? seems like there was a dpkg option that I read about somewhere
[15:38] <ogra_> rtg, dpkg-deb -x /part/to.snap
[15:38] <ogra_> that will unpack it
[15:38] <sergiusens> rtg, -c should work to just list
[15:38] <ogra_> or that :P
[15:39] <rtg> alrighty, looks like my snap has stuff in it. would y'all care to clone git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me if I'm on crack ?
[15:41] <ogra_> rtg, you definitely want the snappy-image ppa in your chroot ...
[15:41] <ogra_> that often contains a newer initramfs-tools-ubuntu-core
[15:42] <ogra_> beyond that the rootstock bit looks good
[15:42] <ogra_> err
[15:42] <rtg> ogra_, do you intend to use the PPA for production as well ?
[15:42] <ogra_> rtg, why $BOOTLOADER ?
[15:42] <ogra_> the bootloader has to go into the oem (or in the future "gadget") snap
[15:43] <ogra_> rtg, yes
[15:43] <rtg> ograthe bootloader only has an impact when installing the kernel in the chroot. it is otherwise unsued
[15:43] <ogra_> the PPA is used during distro freezes etc
[15:43] <ogra_> rtg, we dont use any of the distro setup for bootloaders anyway
[15:43] <rtg> ogra_, ok, I'll get that PPA logic added.
[15:44] <ogra_> (no update-grub in grub setups, no flash-kernel for uboot)
[15:44] <ogra_> in fact you would break stuff using them
[15:45] <ogra_> the rootfs should have all you need bootloader wise (binaries) ... the oem/gadget snap should have all confguration for bootloader setups
[15:45] <rtg> ogra_, but there is no grub logic in the kernel snap, right ?
[15:46] <ogra_> right
[15:46] <ogra_> neither grub binaries nor config
[15:47] <rtg> ogra_, so run snapcraft on this project and inspect the snap. I think it is right
[15:47] <rtg> aside from needing the PPA
[15:48] <ogra_> rtg, oh, and you want linux-image-signed on all amd64 installs
[15:48] <rtg> ogra_, easy enough
[15:48] <ogra_> and preferably even a higher meta
[15:48] <ogra_> like linux-signed
[15:49] <rtg> what do you need the headers for in the chroot ?
[15:49] <ogra_> so you get linux-firmware ... and where wanted linux-image-extra installed
[15:49] <ogra_> you dont need the headers ... but then you simply dont copy them before the squashing
[15:49] <rtg> ogra_, I'll check, but I think those meta package pull in the right bits
[15:49] <ogra_> but you need firmware
[15:50] <rtg> ogra_, I think the kernel depends on linux-firmware
[15:50] <ogra_> ok
[15:50] <ogra_> on -extra too ?
[15:51] <rtg> ogra_, yup
[15:52] <rtg> ogra_, I think what we want installed is linux-signed-image-generic.
[15:52] <ogra_> then it should indeed be fine
[15:52] <ogra_> yeah
[15:57] <rtg> ogra_, this PPA ? ppa:snappy-dev/image
[15:57] <ogra_> rtg, yeah
[18:08] <rtg> sergiusens, ogra_: I've got a kernel snap which appears to install OK in a KVM, but I can't figure out where all the /lib or /boot bits have gone, nor does the new kernel get booted. Any thoughts ?
[18:09] <ogra_> rtg, well, it needs to land in /boot/grub/a|b somehow currently ... not sure if it still needs to in the all snaps case
[18:09] <ogra_> mvo_ is your man here
[18:10] <rtg> ogra_, is there a way to specify which a|b ?
[18:10] <ogra_> the one thats not in use usually
[18:11] <rtg> that is what I thought. perhaps I'll dump my troubles on the snappy mailing list
[18:11] <ogra_> but all that stuff has completely changed in all-snaps so i cant tell if it is still the case for such a setup
[18:21] <sergiusens> rtg, the only person who really knows the details here is mvo_
[18:22] <rtg> sergiusens,  any idea how you force an a|b switch ?
[18:23] <sergiusens> rtg, an install should make the switch, it is all managed by grub, so grubenv away (look at grub.cfg for the exact vars) or just edit grub.cfg
[18:26] <rtg> hmm, hacking grubenv was fatal
[18:36] <mkarliner> newbie question. I've made a snap on AMD64 , how do I create a version for  RPi?
[18:51] <tedg> mkarliner: Probably easiest way is to just build it on the RPi itself.
[18:52] <mkarliner> But all the instructions are for using snapcraft
[18:53] <mkarliner> That is, all the 'create a snap' tutorials start with apt-get install etc, etc.
[18:53] <tedg> mkarliner: Yes, you probably want to setup snapcraft in an LXD or Docker container and then run it.
[18:53] <tedg> mkarliner: We do realize this is non-ideal right now, working on better solutions.
[18:54] <mkarliner> I've done that, what I'm trying to understand is how to make the cross platform target, or is there a native way
[18:55] <tedg> No, we don't really have a way to cross-compile
[18:55] <mkarliner> OK, so is there a tutorial on how to create a snap on a RpI?
[18:57] <tedg> There's one in progress, but I don't think it is completed yet.
[18:58] <mkarliner> Can you give me any clues?
[19:08] <dwaite> is it possible to grab (or self-build) a newer release of docker on snappy?
[19:14] <dwaite> unlike apt, it doesn't seem I can just add an external source to get this, and I don't see anything in the tools to enable me to build a framework, just apps
[19:14] <dwaite> is this a limitation of snappy?
[19:23] <tedg> mkarliner: You need to install lxd or docker on your RPi and then you can build with snapcraft. That's the tutorial in a nutshell.
[19:23] <mkarliner> Thanks, I'll give it a go
[19:23] <tedg> dwaite: I think they're all built by hand right now. Generally, most things don't need to be frameworks though.
[19:35] <serg_> Hi
[19:36] <serg_> how can i try my snappy app before deploying into ubuntu store?
[19:38] <kyrofa> serg_, you've created the .snap?
[19:38] <serg_> yes
[19:38] <kyrofa> serg_, do you actually have Ubuntu Core installed anywhere? On a device or a VM?
[19:39] <serg_> virtualbox
[19:40] <kyrofa> serg_, just sideload it there
[19:40] <serg_> sorry, can you explain it step-by-step?
[19:41] <kyrofa> serg_, sure! First, get your .snap into the VM
[19:41] <kyrofa> serg_, then you can install it with `snappy install <my_snap>.snap`
[19:41] <dwaite> Snappy looks interesting, but limiting the infrastructure I can actually use to older "supported" versions just won't work for my environment. I need the new networking features in recent docker releases.
[19:42] <kyrofa> serg_, assuming you have SSH access to the VM, just use scp to get the .snap on there
[19:43] <dwaite> the autopilot updates are really nice, but not if it limits what I can actually run
[19:45] <serg_> thank you, but now i have other problem
[19:45] <serg_> No signature, or no origin signature
[19:45] <serg_> which is this?
[19:47] <serg_> how can i bypass this verification?
[19:48] <rtg> serg_, sudo snappy install --allow-unauthenticated
[19:48] <serg_> too much thanks
[21:06] <rtg> sergiusens, so where do I find a 16.04 KVM image ?
[21:06] <sergiusens> rtg, mvo has one in his people.c.c, let me see.
[21:06] <sergiusens> rtg, http://people.canonical.com/~mvo/all-snaps/
[21:06] <sergiusens> rtg, there's a u-d-f there that should work too
[21:11] <rtg> sergiusens, hmm, that image isn't exactly network capable AFAICT
[21:20] <sergiusens> rtg, I am not sure, haven't tested it
[21:21] <sergiusens> rtg, you can try and u-d-f with what is there and using your snap
[21:21] <rtg> sergiusens, well, I'll have to get back to it tomorrow. I'm EOD