[10:33] <Odd_Bloke> smoser: I've submitted https://github.com/gabrielfalcao/HTTPretty/pull/238, which should fix the problem.
[12:48] <yaronr_> any reason why on gce, cloud-init would set hostname to 'localhost' instead of the machine id?
[13:02] <Odd_Bloke> yaronr_: No; anything in cloud-init.log to suggest what's happening?
[13:03] <yaronr_> i'm starting a new cluster now, i'll check the journald
[13:04] <yaronr_> problem is, there's too much going on there, separating the wheat from the chaff is challenging
[13:04] <Odd_Bloke> yaronr_: What distro?
[13:04] <yaronr_> coreos 612.1
[13:05] <yaronr_> using the same distro on aws doesn't have this problem
[13:05] <yaronr_> having all hostnames set to 'localhost' is a problem..
[13:05] <Odd_Bloke> yaronr_: What version of cloud-init?
[13:06] <yaronr_> how can I check?
[13:06] <yaronr_> best guess would be 1.3.3
[13:09] <Odd_Bloke> yaronr_: `cloud-init --version` should do the trick.
[13:09] <yaronr_> :)
[13:13] <smoser> coreos is not this cloud-init
[13:14] <yaronr_> 'cloud-init: command not found'
[13:14] <Odd_Bloke> This conversation has followed the classic #cloud-init debugging pattern; I ask questions for a while and then smoser comes in with the right answer. :p
[13:15] <smoser> :)
[13:15] <smoser> but Odd_Bloke actually fixes things and writes good tests.
[13:15] <smoser> so he's good to hvae around
[13:16] <yaronr_> so.. how shall I debug the hostname issue then?
[13:17] <Odd_Bloke> yaronr_: Maybe ask in #coreos?
[13:17] <yaronr_> to paraphrase from star-trek: it's dead, jim...
[16:04] <harlowja_at_home>  yo yo, fyi i'm be out camping/hiking/biking/climbing today/tommorow, so don't cause to much trouble :)
[17:45] <smoser> harlowja_away, have fun.
[22:30] <Linuturk> is there a way to phone_home a string?


[03:07] <zul> meh...i dont wanna do anything tonight
[03:26] <mjg59> BenC: Did you get the sdhci and swsusp patches I sent?
[04:38] <BenC> mjg59: Yeah, I got them thanks
[04:38] <mjg59> BenC: Cool
[06:55] <Keybuk> /usr/include/stdint.h:56: error: conflicting types for 'uint64_t'
[06:55] <Keybuk> /usr/include/linux/types.h:96: error: previous declaration of 'uint64_t' was here
[06:55] <Keybuk> that's not nice
[06:28] <Kamion> Has anyone heard from BenC today?
[06:28] <Kamion> I need to get in touch with him urgently
[06:57] <zul> no i havent
[07:16] <Kamion> ah, power's out
[09:32] <zul> BenC: welcome back
[09:53] <BenC> zul: not sure how long I'll be back
[09:53] <BenC> storm isn't being very nice around here
[12:10] <jbailey> BenC!
[12:10] <jbailey> *punce*
[12:10] <jbailey> pounce, even.
[12:10] <jbailey> BenC: I finaly got the PSU replaced in my G5.  Current edgy kernel seems to still puke on the SATA drive.
[12:10] <jbailey> I haven't tried a 2.6.18-rc5 yet.  I'll do that over the weekend and let you know.
[12:11] <BenC> jbailey: ok
[12:12] <jbailey> Besides, at that point I can bug benh =)


[01:51] <slim> تحشو فيه و تنعسو
[01:54] <optimus_> Boa noite a todos online!
[01:54] <optimus_> Alguém que fale português?
[01:55] <slim> not me
[03:40] <family> Hi is there a software where i can download zoom?  a video conference device
[04:34] <mate|67873> Hello, I am new to MATE (coming from i3) Is there a way to make Workspaces only apply to my Primary Monitor?
[04:35] <mate|67873> My idea scenario would be change between workspaces only affects primary monitor and others monitors remain the same
[05:43] <wallace_> Just installed Ubuntu Mate on my Raspberry Pi When the setup utility was setting the time zone i clicked on the pacific time zone of USA near mexico... now the calendar is giving me days and months in Spanish... can't figure out how to get it in English... any hlep would be appreciated
[05:44] <wallace_> ...gracias
[05:45] <wallace_> :-)
[05:49] <\9> try to go to system → settings → personal → language settings from the menu
[05:49] <\9> you should be able to set the language there
[05:58] <wallace_> I see system -> preferences -> personal -> language support
[05:58] <wallace_> yup... did it a pop up menu says that the changes will occur at the next reboot thank you and gracias
[05:59] <wallace_> a pop up window rather
[06:45] <wanglaoren> exit
[07:07] <sid_> I run Ubuntu Mate on Virtual Box - with Windows 10 Host - I added the Virtualbox extention ...but I am not able to access the Shared folder that I setup during installation.. Am I doing something wrong?
[07:09] <sid_> i am new to Linux so ...looking for help from any  experienced user
[09:44] <Amis> Hello! What is the actual name of the "Software updater" program?
[09:44] <Amis> As in... file name
[11:49] <tercio> soy nuevo en ubuntu mate 16.04
[11:49] <tercio> que pasos debo seguir para dejarlo lo mejor configurado
[18:38] <Guest68595> iIf I allow Mate to partition my drive does it create a swap and home partition?
[18:38] <Mikelevel> swap yes , home no
[18:38] <Guest68595> ok
[18:39] <Guest68595> ok thanks
[18:49] <maxstirner_> Hi, can anyone help me?
[18:51] <\9> nope
[19:17] <ali1234> spooky
[21:11] <ouroumov> flexiondotorg, hello
[21:16] <ouroumov> flexiondotorg, not sure if anyone's seen this: https://github.com/mate-desktop/pluma/pull/202
[21:16] <ouroumov> It's a bounty ;]
[22:31] <fernando> hola
[22:32] <Guest11394> hola
[23:20] <CyberCyborg> hello


[10:39] <mup> PR operator#749 opened: typing for storage.py <Created by PietroPasotti> <https://github.com/canonical/operator/pull/749>
[14:07] <mup> PR operator#748 closed: Edited test charm to support metadata v2, drop untested v1 fields <Created by pengale> <Merged by pengale> <https://github.com/canonical/operator/pull/748>


[08:12] <macogw> i have had really annoyingly big issues with installing feisty from cd (i can upgrade over the internet from edgy just fine), and i *think* it's to do with OOo because it's an OOo file that can't be copied when ubiquity segfaults and it's OOo that won't install claiming dependency problems when i try to install ubuntu-desktop from the alternate cd (with apt-cdrom add) after doing a "text only install" from alternate cd (alternate cd fails if
[08:12] <macogw> i let it try to install the gui by default)
[08:13] <macogw> i burned only at 4X speed, i checksum'd the isos (i downloaded it 2x for live, once alternate), i checksum'd the burned disks, and i did "check disk for defects" before installing.
[08:14] <macogw> i used the alternate cd to successfully on two friends' computers, so i know it works fine in general and is a good burn
[08:16] <macogw> i used one of the live cds last night to install on my other friend's new computer which has unsupported nvidia graphics (had to get the .run from nvidia.com), and tried using that same (obviously working) disk today to install with "ubiquity --debug" on my laptop which is 99% supported (2 of the 4 slots on my 4-in-1 card reader lack working drivers but hey all 4 lacked drivers in dapper and that installs fine)
[08:19] <macogw> my cd drive is fine, my hard drive is fine.  i can install dapper or edgy with no problem. it's -just- feisty.  it is driving me insane.  as far as i can tell, feisty has no compatibility issues with my laptop.  i can upgrade to it from edgy without a problem.  and while yay i can do that, that's a workaround.  it should be installable from the cd.  after ubiquity crashes, everything in the live environment tends to go to hell, so the first t
[08:19] <macogw> ime with --debug i couldnt get the logs off (it said i didnt have permission to use vi or gedit or nano!), but this time i managed to get them.  the log suggests that it's a bad cd drive (but i can install dapper/edgy, so no) or bad cd (but i can install on other comps with this cd, so no), so that doesn't help.  all i know is it says it's an OOo file where it fails, and the fact that OOo is what refuses to install on ubuntu-desktop with a wo
[08:19] <macogw> rking text-mode-only install makes me think that its linked to that
[08:20] <macogw> does anybody have any suggestions of a way to get more info about whats wrong to pin it down?
[08:47] <evand> macogw: take a look at /var/log/syslog, look for device errors.  If you're confused as to what they mean, paste them here (without flooding, of course)
[08:47] <macogw> there's tons of squashfs errors
[08:48] <macogw> i watched the output with tail -f to see it as it broke
[08:52] <macogw> however, this looks like its the actual cause of the segfault (it had squashfs errors before the crash with no effect, but crashed at this part) http://paste.ubuntu-nl.org/28763/
[08:56] <macogw> which is python error stuff
[09:00] <cjwatson> macogw: if there are squashfs errors first, then those are the cause
[09:00] <cjwatson> and I'm afraid that it *is* due to a problem with your CD drive or with the disk
[09:00] <macogw> all 3 disks?
[09:00] <cjwatson> it is probably just on the edge of some tolerance or other
[09:00] <cjwatson> then chances are the CD drive
[09:00] <cjwatson> I'd recommend getting a drive lens cleaning kit and using it
[09:01] <superm1_> perhaps the brand of the blank disks that you had purchased
[09:01] <macogw> then how did i install edgy?
[09:01] <cjwatson> I have no idea, but if it were a genuine problem with the CD images it would affect everyone, not just you
[09:01] <cjwatson> there's a faint possibility that the kernel driver for your CD drive has regressed somehow
[09:02] <cjwatson> but some physical problem would definitely be the first thing I'd investigate
[09:02] <macogw> so i should ignore the python exception about invalid literals then?
[09:02] <cjwatson> we've had the squashfs maintainer working on making squashfs fail more obviously rather than the live environment just gradually going to hell in a handbasket, which should make it easier to report such errors properly
[09:03] <cjwatson> the python exception is almost certainly a knock-on effect - it's just the first thing that happened to visibly fall over
[09:03] <macogw> the problem with hell in a handbasket is that it makes it impossible to open a text editor and see the logs
[09:03] <cjwatson> you're screwed anyway in this case
[09:04] <cjwatson> the live environment isn't going to last long once read errors from the CD start zapping random bits of important stuff
[09:04] <macogw> one error that i noticed on the live cd after it goes to hell is that adding applets to the panel gets OAFIID errors popping up
[09:04] <cjwatson> what that python exception actually means is that some subsidiary program that ubiquity was running crashed, or possibly printed garbage
[09:05] <macogw> which is something i had happening on installed-feisty during the unstable bit
[09:05] <macogw> OAFIID is what gconf refers to things as though O_o
[09:05] <cjwatson> could easily be the same sort of thing, code for "program fell over"
[09:06] <cjwatson> "panel failed to communicate with applet" or some such
[09:06] <macogw> mmm where do you get one of those cleaning things?
[09:06] <cjwatson> in the UK, electronics stores stock them
[09:06] <macogw> i really dont wanna try sending my laptop back to the manufacturer.  those idiots think reinstalling windows fixes it
[09:06] <macogw> they reinstalled windows when the problem was overheating due to hardened thermal grease
[09:06] <cjwatson> no, I doubt that would help
[09:07] <superm1_> in the US, best buy, frys, or any shop that sells cds
[09:07] <cjwatson> the cleaning kits usually look like CDs with little brushes attached
[09:07] <macogw> mmmk
[09:07] <cjwatson> I'd be interested in the logs from the alternate CD install to ensure it's the same thing
[09:07] <macogw> how do i get logs from that one?
[09:07] <cjwatson> I suspect the reason OOo is affected both times is that it and its dependencies are just so damned big that statistically it's quite likely
[09:07] <macogw> alternate cd wont automount my flash drive for me to save them
[09:08] <macogw> well on alternate if i do a non-gui install, it works fine and installs
[09:08] <macogw> but its not very pleasant to not have a gui
[09:08] <cjwatson> if you have the machine connected to a network, you can go back to the main menu, select "save debug logs", start up a mini web server from there, and connect to the machine via HTTP
[09:08] <macogw> i can only have one computer online at a time and i would have no idea how to do what you just said
[09:09] <cjwatson> I mean a local network; do you have ethernet connections between multiple machines at home?
[09:09] <macogw> no
[09:09] <macogw> there's only one machine here usually
[09:09] <macogw> i'm just home from school with my laptop and havent convinced them to get wireless so i can use my computer
[09:10] <cjwatson> ah. if it has a floppy drive, then the "save debug logs" option can use that
[09:10] <macogw> laptops dont have floppy drives
[09:10] <macogw> at least not nowadays
[09:10] <cjwatson> otherwise you have to mount the flash drive by hand from tty2
[09:11] <macogw> used to be you could yank out the cd drive and put in the floppy drive, but that wont work running from a cd :p
[09:11] <cjwatson> USB floppy drives still exist
[09:11] <macogw> :-/ how do you mount a flash drive?
[09:11] <macogw> i mean, i can mount hard drives
[09:11] <macogw> because its not hard to figure out which hdb or sdb wasnt there before
[09:12] <cjwatson> if there's no hd* or sd* for it, you may just not be able to
[09:12] <cjwatson> you can look at the logs ('nano -v /var/log/syslog' on tty2, page down to near the end) and see if there are obvious input/output errors
[10:58] <tepsipakki> hum, netcfg could/should have a longer dhcp-timeout, or a configurable one
[10:58] <cjwatson> it is configurable
[10:58] <tepsipakki> really?
[10:59] <cjwatson> preseed netcfg/dhcp_timeout
[10:59] <cjwatson> it's an integral number of seconds, default 15
[10:59] <tepsipakki> not in feisty though :)
[10:59] <tepsipakki> but good to know
[10:59] <cjwatson> is too
[10:59] <cjwatson> that's been around for several releases
[11:00] <tepsipakki> hum, not in my debconf-selections.. I'll dig elsewhere
[11:00] <cjwatson> it was introduced in netcfg 1.13, pre-dapper
[11:01] <cjwatson> it may well not be in debconf-get-selections, but that doesn't really indicate anything since it's never asked and just fishes the default out of templates
[11:01] <cjwatson> it's documented in the installation guide in the preseeding appendix
[11:01] <tepsipakki> ok, excellent
[11:06] <tepsipakki> yeah, there it is.. shame on me
[01:02] <CIA-19> ubiquity: cjwatson * r2127 ubiquity/ubiquity/frontend/mythbuntu_ui.py: PEP-8 import spacing
[02:28] <CIA-19> ubiquity: cjwatson * r2128 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): - Suppress some spurious uncaught exceptions on startup.
[02:38] <CIA-19> ubiquity: cjwatson * r2129 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): take oem_config_title out of language_questions and handle it separately; fixes crash in language_treeview signal handler
[02:39] <cjwatson> superm1_: that should address the problem that (IIRC) you reported
[02:39] <cjwatson> one of those things you have to see yourself before it's obvious ...
[03:15] <CIA-19> ubiquity: cjwatson * r2130 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): set window title correctly in OEM mode when changing language too
[03:18] <CIA-19> ubiquity: cjwatson * r2131 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): set username_edited when hardcoding user name to oem
[03:18] <cjwatson> gar, that didn't work either
[03:19] <evand> heh
[03:22] <CIA-19> ubiquity: cjwatson * r2132 ubiquity/gui/glade/stepLanguage.glade: oem id entry should activate default
[03:25] <CIA-19> ubiquity: cjwatson * r2133 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[03:25] <CIA-19> ubiquity: - Don't reconfigure the username entry box as a combo box if
[03:25] <CIA-19> ubiquity:  migration-assistant didn't find any users.
[03:25] <cjwatson> that's more like it
[03:25] <cjwatson> evand: is the test I added there the right one?
[03:27] <evand> indeed it is
[03:27] <evand> thanks
[03:28] <cjwatson> that's actually been bugging me for ages but it was never serious enough to bother fixing until it interfered with oem work just now :)
[03:29] <cjwatson> commit early, commit often ...
[03:29] <evand> indeed
[03:29] <cjwatson> right, time to take the dog for a w-word
[03:29] <cjwatson> (she gets excited if you unwarily say that word without obfuscation)
[03:30] <evand> hahaha
[03:30] <evand> what breed?
[03:30] <cjwatson> labrador/rottweiler cross
[03:30] <evand> adorable
[03:30] <cjwatson> utterly placid
[03:30] <evand> sounds big though.  I've seen some quite large rotties in my day.
[03:31] <cjwatson> http://userpic.livejournal.com/57407285/106700
[03:31] <cjwatson> yes, she's a fair size
[03:32] <cjwatson> not like an Irish wolfhound or anything, but
[03:32] <cjwatson> weighs 40-odd kilos
[03:32] <evand> cute
[03:34] <thom> 40kg is pretty sizeable, yeah :-)
[03:53] <cjwatson> oh, I see why ubiquity isn't managing to install packages from the CD
[03:54] <cjwatson> it needs to emulate some stuff that base-installer does, to bind-mount /cdrom into /target and configure apt-cdrom a bit differently
[04:56] <CIA-19> ubiquity: cjwatson * r2134 ubiquity/ (debian/changelog scripts/install.py):
[04:56] <CIA-19> ubiquity: * Replicate the apt configuration done by base-installer (trust CD-ROMs,
[04:56] <CIA-19> ubiquity:  allow unauthenticated packages if debian-installer/allow_unauthenticated
[04:56] <CIA-19> ubiquity:  is true, bind-mount /cdrom into /target, and configure apt-cdrom/apt not
[04:56] <CIA-19> ubiquity:  to mount CD-ROMs).
[04:56] <cjwatson> that's not quite enough though - something also needs to actually install stuff
[05:04] <CIA-19> ubiquity: cjwatson * r2135 ubiquity/scripts/install.py: factor out reading of apt-installed file
[05:24] <superm1_> cjwatson, ooh looks interesting, installing packages that are on the cd in a apt-cdrom compatible repository :)
[05:26] <cjwatson> that was actually intended a long time back
[05:26] <cjwatson> looks like it's been broken though
[05:30] <superm1_> AH
[05:30] <superm1_> oops, ah
[06:26] <CIA-19> ubiquity: cjwatson * r2136 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): let's make fullname and username insensitive too if they're uneditable
[06:27] <evand> getting GNOME to ignore partitions seems to be hit or miss.  bug 110904
[06:27] <evand> ah, no ubotu
[06:28] <cjwatson> perhaps he's using Kubuntu; it's not clear
[06:28] <cjwatson> or indeed Xubuntu
[06:29] <evand> oh wow, that didn't even occur to me
[06:29] <cjwatson> both of those definitely had some breakage in that area in feisty
[06:29] <cjwatson> I've added a comment
[06:29] <evand> thanks
[06:57] <CIA-19> ubiquity: cjwatson * r2137 ubiquity/ (82 files in 3 dirs):
[06:57] <CIA-19> ubiquity: * Install packages passed to apt-install even if they aren't on the live
[06:57] <CIA-19> ubiquity:  filesystem, as long as they're available from the apt archive on the CD
[06:57] <CIA-19> ubiquity:  (LP: #114296).
[06:59] <cjwatson> phew, that was more work than I expected ...
[07:00] <CIA-19> ubiquity: cjwatson * r2138 ubiquity/scripts/mythbuntu/mythbuntu_install.py: mythbuntu duplication => more work for Colin
[07:29] <CIA-19> ubiquity: cjwatson * r2139 ubiquity/scripts/mythbuntu/mythbuntu_install.py: remove trailing whitespace
[07:39] <CIA-19> ubiquity: cjwatson * r2140 ubiquity/scripts/mythbuntu/mythbuntu_install.py: let install_extras deal with installing drivers and services
[07:40] <cjwatson> superm1_: I hope r2140 works; I haven't tested it ...
[07:42] <CIA-19> ubiquity: cjwatson * r2141 ubiquity/scripts/mythbuntu/mythbuntu_install.py: imports no longer needed
[07:42] <cjwatson> vim highlights trailing whitespace in python by default, I think, though not if on a line by itself
[07:42] <cjwatson> I use 'let python_highlight_all = 1' which may be implicated; not sure
[07:43] <evand> hrm, it might be that I don't have syntax highlighting enabled by default, so I wouldn't notice such things unless I turned it on
[07:43] <cjwatson> really? I couldn't live without it enabled by default
[07:43] <CIA-19> ubiquity: cjwatson * r2142 ubiquity/scripts/mythbuntu/mythbuntu_install.py: unnecessary constructor
[07:43] <cjwatson> it's nearly the first thing I do on new machines
[07:45] <evand> heh
[07:49] <CIA-19> ubiquity: cjwatson * r2143 ubiquity/ (9 files in 3 dirs): more trailing whitespace
[08:06] <superm1> cjwatson, i'll see if there is any breakage tonight when i get home
[08:06] <superm1> thanks
[09:07] <evand> cjwatson: Is LVM by default just blocked on changes to Ubiquity to support it, or are there technical reasons why it's not a path we intend on pursuing?
[09:09] <evand> LVM came up a few times in UDS discussions (backups for one), and mpt mentions it in his reply to your email on ubuntu-devel-discuss.
[09:25] <superm1> evand, just speculating: but i'd expect there to be a gui management tool for volumes too before it was by default?
[09:25] <superm1> similar to the tool that red hat ships on their boxes
[10:29] <cjwatson> that class of thing is certainly the reason we opted not to do it by default after investigating it
[10:29] <cjwatson> (that decision was actually before ubiquity existed)
[10:29] <cjwatson> but certainly nowadays ubiquity support would have to be added
[10:33] <superm1> have you looked into adopting red hat's existing tool?
[10:33] <superm1> i don't know off hand what the license is on it
[10:35] <cjwatson> we looked it a while back and concluded it really wasn't good enough to inflict on all users
[10:35] <cjwatson> it's a pretty high bar, unfortunately
[10:37] <evand> ah, indeed
[10:38] <cjwatson> it's been two years, though
[10:42] <superm1> last i looked at their tool was maybe a year ago, and i wasn't "happy" with it persay, but it did the trick for the purpose/.  i'm assuming this spec will be revisited in Boston this year though, at which point it can be reinvestigated
[10:44] <cjwatson> I'd be very happy if it were better now, and we should certainly get to the point of being able to do LVM in ubiquity ...
[10:44] <cjwatson> (and kickseed, etc. etc.)
[10:44] <superm1> what is kickseed?
[10:46] <evand> kickstart -> preseed file
[10:47] <superm1> i was going to ask about that: preseeding isn't active in ubiquity atm then - so on the cds, when file=..../ubuntu.seed and such, does it actually do anything?
[10:47] <evand> yes
[10:48] <evand> ubiquity noninteractive
[10:48] <evand> makes use of it
[10:48] <superm1> that was just added as a frontend though right?
[10:48] <evand> indeed
[10:49] <evand> but preseeding is active in ubiquity
[10:49] <superm1> well for the mythbuntu frontend however, it won't be relevent yet then
[10:49] <evand> the only problem is that pages that already have all their questions answered do not gracefully skip to the next page, which I'm working on ever so slowly
[10:49] <cjwatson> superm1: ubiquity has always had some level of preseeding, even if not complete
[10:49] <superm1> okay
[10:50] <cjwatson> at least ever since it was called ubiquity - not in the initial ubuntu-express implementation
[10:50] <cjwatson> superm1: we use it for language pack selection, in particular
[10:51] <cjwatson> for example the Kubuntu preseed file has:
[10:51] <cjwatson> d-i     pkgsel/language-pack-patterns   string language-pack-kde-$LL kde-i18n-$LL
[10:51] <cjwatson> and ubiquity honours that
[10:51] <superm1> Is that in the ubuntu preseed file though?
[10:51] <superm1> or just kubuntu
[10:51] <cjwatson> it's in everything except Ubuntu
[10:51] <cjwatson> the default for that question is set to make sense for Ubuntu
[10:52] <superm1> which would be how i missed it then - looking only at the ubuntu preseed
[10:52] <cjwatson> right, the Ubuntu preseed file is not very interesting
[10:52] <cjwatson> in fact it was empty for a long tim
[10:52] <cjwatson> e
[10:52] <cjwatson> (nonexistent)
[10:53] <mirkobuholzer> I did some tests with evan's branch with preseeding and works nicely ...
[10:53] <cjwatson> I haven't tried out the automation stuff yet, I must confess
[10:53] <cjwatson> hopefully I'll get Evan to give me a demo next week
[10:54] <evand> indeed!
[10:59] <cjwatson> the bandwidth in the London office is fantastic for mucking about with CD images
[10:59] <cjwatson> we basically have something like Ethernet to the datacentre
[10:59] <evand> now if only I had the space to store them all
[10:59] <cjwatson> that's what the big vmware-server box is for
[11:00] <evand> yeah, I'm definitely going to build one once I move
[11:00] <evand> I'm running it on here, but 250GB...not enough.
[11:01] <cjwatson> yeah, I need a chunk more disk too :-/
[11:03] <evand> do I have access to the LP wiki?    I get the gist of it from the spec description.
[11:05] <cjwatson> evand: see /msg


[00:08] <ion> wmp: Any errors about the file in syslog?
[00:08] <wmp> ion: no
[00:10] <wmp> ion: i have networking problem, maybe could you help me?
[00:10] <wmp> my server down and i dont know how to up this...
[00:13] <ion> wmp: Feel free to describe the problem. I or someone else might be able to help.
[00:13] <wmp> http://pastebin.com/TPeqPELc
[00:13] <wmp> i want to run bridge on eth0
[00:13] <wmp> with normal eth0 configuration all works good
[00:14] <wmp> but with this bridge i cannot connect to server
[00:23] <ion> How about if you remove auto eth0, iface eth0 inet manual?
[00:23] <wmp> ion: nothing
[00:23] <wmp> ion: this same...
[00:25] <ion> I’m afraid i don’t see the problem then. Perhaps someone else has ideas.
[17:35] <bradleymeck> is there a way to set the uid numerically it looks like setuid expects a name only


[07:23] <zyga> good morning
[07:26] <qengho> zyga: good...morning
[07:40] <ngaio> hi all good morning / afternoon. Hey how do I minimize the amount of packages being pulled down when I do a pull. I'm on a metered Internet connection and pay by the MB. I'm taking my first steps to building a snap, and it seems when I pull one part, it downloads all over again the same packages for another part
[07:43] <qengho> ngaio: Could you not clean up the part that downloads a lot?
[07:43] <ngaio> qengho, I didn't clean anything
[07:43] <ngaio> all I did was one pull, then another
[07:44] <qengho> ngaio: what kind of section do you have that lists packages?
[07:45] <ngaio> where can i copy & paste a sample?
[07:45] <qengho> paste.ubuntu.com
[07:46] <ngaio> http://paste.ubuntu.com/16486317/
[07:46] <ngaio> there is a problem with the pyzmq package-- i can't figure out how to specify the version
[07:46] <ngaio> it's failing there
[07:46] <ngaio> but that's a different problem
[07:47] <qengho> probably "pyzmq=15.1.0", fwiw
[07:47] <qengho> That's an APT-ism.
[07:47] <ngaio> I couldn't find that anywhere in the online docs or in the comments in the plugin source
[07:47] <qengho> Oh, but that's not the package you mean.
[07:48] <ngaio> no it's not an ubuntu package.... it's a pypi package
[07:48] <qengho> Different kind of package, right?
[07:48] <qengho> Right.
[07:49] <qengho> ngaio: For development, I think you can probably put a full local filename path instead of Ubuntu packages, and perhaps of Python packages, and your local cached files will be used instead. I think. Maybe. Possibly.
[07:50] <ngaio> qengho, that would be a big help when it comes to my internet usage, if it works!
[07:50] <qengho> ngaio: I have never tried it for "package" things, just for large source tarball sources.
[07:52] <qengho> ngaio: The snapcraft sources are not too hard to read. You should look into what the python source does, to see if it takes a version.  $ dpkg -L snapcraft
[07:53] <qengho> ngaio: And if versions are a common thing to specify, then file a bug report to ask for it.  $ ubuntu-bug snapcraft
[07:57] <qengho> And even "debpackage=version" doesn't work. Sigh.
[07:57] <qengho> Bed time.
[08:03] <ngaio> qengho, thanks for your help... I'm looking at the source now
[08:36] <morphis> zyga: ping
[08:41] <zyga> morphis: o/
[08:41] <zyga> morning
[08:41] <morphis> zyga: morning
[08:41] <morphis> zyga: have a first draft for a pulseaudio slot part of the interface
[08:42] <morphis> zyga: but wondering if we don't want to do an audio interface too which abstracts the kernel access for audio devices
[08:42] <zyga> neat! what's the pull request number?
[08:42] <zyga> morphis: like alsa?
[08:42] <morphis> zyga: no PR yet
[08:42] <morphis> zyga: like also, yes
[08:42] <zyga> morphis: so pulse would consume alsa and expose pulse?
[08:42] <morphis> yes
[08:42] <zyga> mmm, I guess the answer is, perhaps
[08:42] <zyga> but I'd wait with that for a real consumer
[08:43] <zyga> and for hooks
[08:43] <morphis> ok
[08:43] <zyga> e.g. you assign alsa, cannot use pulse yet
[08:43] <morphis> then lets add those things to the pulse interface for now
[08:43] <zyga> it's sensible just more complicated to model
[08:43] <zyga> yep
[08:43] <morphis> sth like hw-assign doesn't exist anymore, right?
[08:43] <zyga> morphis: correct
[08:43] <morphis> good
[08:44] <morphis> zyga: either I base my PR on top of yours or I do a new one covering yours and mien at the same time
[08:46] <zyga> morphis: is there an actual difference?
[08:46] <zyga> morphis: do you have an idea when we can land pulseaudio record lockout?
[08:46] <zyga> morphis: and I wonnder if you saw my message about the memory leak last night
[08:46] <morphis> zyga: (message) saw it and fixed the leak
[08:46] <morphis> zyga: the change needs testing and review
[08:47] <morphis> zyga: and need to find out who maintains pulse these days :-)
[08:47] <morphis> maybe seb128 knows
[08:47] <zyga> morphis: do you have a plan to SRU it anytime soon?
[08:47]  * seb128 doesn't know anything
[08:47] <seb128> hey there :-)
[08:47] <zyga> seb128: hey :)
[08:47] <morphis> zyga: no concrete
[08:47] <morphis> seb128: hey
[08:48] <seb128> morphis, zyga, TheMuso maintains pulseaudio for us
[08:48] <seb128> you can find him on #ubuntu-desktop/devel
[08:48] <morphis> seb128: thanks!
[08:48] <seb128> but he's .au based might be off for the evening already
[08:48] <seb128> yw
[08:48] <morphis> zyga: I must say I never did a real SRU yet
[08:49] <morphis> so would be good if we could just hand this to somebody
[08:49] <seb128> morphis, zyga, I can help you ... what serie do you want to SRU to?
[08:49] <morphis> seb128: xenial
[08:49] <seb128> just get a bug on launchpad with the patch
[08:49] <zyga> morphis: can you build pulse in a ppa somewhere
[08:49] <seb128> and give me the number
[08:49] <seb128> we can handle the SRU process
[08:49] <zyga> morphis: or just listen to seb128
[08:49] <morphis> seb128: sounds great!
[08:50] <morphis> seb128, zyga: have it in https://requests.ci-train.ubuntu.com/#/ticket/1428 already but still under testing
[08:50] <seb128> morphis, we need a bug anyway for SRU process
[08:50] <morphis> seb128: ok, let me create one then
[08:51] <fgimenez> hey mwhudson, i'm getting http://paste.ubuntu.com/16486677/ while trying to execute snappy's integration test suite and have been told that you could help me with that
[08:52] <fgimenez> mwhudson, sorry if that's not the case :) could you please have a look at it?
[08:52] <zyga> morphis: is there any tiny app we can use to demo the fact that recording is forbidden
[08:53] <morphis> zyga: on the way building one
[08:53] <morphis> seb128, zyga: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1583057
[08:53] <seb128> morphis, thanks
[08:56] <seb128> morphis, zyga, lol, I though you guys wanted to fix a leak ... adding a new module is not going to be as easy by SRU rules
[08:57] <zyga> seb128: it's data privacy leak ;)
[08:57] <zyga> seb128: can we get help somewhere?
[08:57] <zyga> summon some super powers or something?
[08:57] <morphis> seb128: :-)
[08:57] <seb128> zyga, no, need to play by the rules, https://wiki.ubuntu.com/StableReleaseUpdates
[08:57] <seb128> zyga, but basically could you put the rational/test case/regression potential
[08:58] <seb128> like rather is "needed for snappy"
[08:58] <seb128> we can get it uploaded&co
[08:58] <seb128> I'm just unsure the SRU team is going to be too happy about it
[08:58] <zyga> seb128: understood, we'll do our best
[08:59] <mwhudson> fgimenez: huh
[08:59] <mwhudson> fgimenez: go version?
[09:00] <zyga> morphis: I think we should test this thoroughly on random non-snappy apps to ensure there's no impact
[09:00] <zyga> morphis: and play the only-affects-snappy card as a regression potential
[09:00] <mwhudson> fgimenez: also, reproduction instructions?
[09:00] <mwhudson> fgimenez: i guess it must either be s390x or yakkety?
[09:00] <morphis> zyga: that is the plan
[09:00] <morphis> zyga: the module shouldn't have any impact on non-snappy apps
[09:01] <morphis> and still simply allows recording
[09:01] <morphis> zyga: you have time to test this one too?
[09:01] <zyga> morphis: yes, I will gladly help
[09:01] <morphis> great
[09:02] <zyga> especially now when I'm just about as sleepy as I can
[09:07] <morphis> zyga: :-)
[09:08] <fgimenez> mwhudson, yes, yaketty, more about the environment http://paste.ubuntu.com/16486953/
[09:09] <fgimenez> *yakkety
[09:09] <mwhudson> fgimenez: ok, i think that should be working so i'll have a poke
[09:13] <fgimenez> mwhudson, ok thanks, to reproduce from a working $GOPATH "mkdir -p ./github.com/ubuntu-core && cd ./github.com/ubuntu-core && git clone https://github.com/ubuntu-core/snappy && cd snappy && go run ./integration-tests/main.go"
[09:14] <fgimenez> in fact from $GOPATH/src
[09:23] <mwhudson> fgimenez: well hooray, it works for me
[09:24] <mwhudson> fgimenez: can you run go run -x ./integration-tests/main.go and show me the output
[09:25] <fgimenez> mwhudson, sure http://paste.ubuntu.com/16487054/
[09:29] <mwhudson> fgimenez: doesn't look like you're running /usr/bin/go
[09:29] <mwhudson> fgimenez: /home/fgimenez/src/go/pkg/tool/linux_amd64/compile
[09:29] <mwhudson> fgimenez: i don't maintain that one :-)
[09:34] <fgimenez> mwhudson, oops thanks! will try with the package version, sorry for the noise
[09:35] <mwhudson> fgimenez: heh nw
[11:28] <sborovkov> Hello, asked this question yesterday, but no one answered. May be better luck today. Let's say I install snap in --devmode. If I upgrade to newer version of snap - can I automatically remove --devmode somehow
[11:40] <kyrofa> Good morning
[12:55] <morphis> zyga: you had time to take a final look at https://github.com/ubuntu-core/snappy/pull/1036 ?
[13:00] <zyga> morphis: not fully but I think we should land it
[13:00] <morphis> zyga: ok, then lets do that
[13:01] <morphis> zyga: so when you merge it today, when will we have it in xenial?
[13:01] <zyga> morphis: next week
[13:01] <zyga> morphis: every Wed AFAIR
[13:01] <morphis> end of next week?
[13:01] <zyga> morphis: we have one SRU in the pipe now
[13:01] <zyga> morphis: if it lands now it will be released next week
[13:06] <zyga> jdstrand: do you have any last comments on n-m interface?
[13:09] <noizer> Hi zyga
[13:10] <noizer> zyga how are you?
[13:10] <noizer> zyga I have a strange problem with copying the armel build (chroot) to my snap
[13:10] <noizer> zyga here you got a minified yaml file of my snap http://paste.ubuntu.com/16490708/
[13:11] <noizer> zyga and thats the error [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/
[13:11] <noizer> staticfiles/build/./armel/usr/share/zoneinfo/localtime'
[13:14] <jdstrand> zyga: I want to go through the recent comments, yes. I have a couple of meeting so it will be a couple of hours
[13:14] <jdstrand> meetings*
[13:16] <zyga> jdstrand: sounds good, thank you
[13:16] <zyga> noizer: hey :-)
[13:17] <zyga> noizer: sudo won't work there
[13:17] <zyga> noizer: as in, in is not allowed
[13:17] <zyga> noizer: I would suggest you to put this into a wrapper script and not put everythiong on one long line
[13:18] <noizer> zyga ok but my snapcraft build won't build :s
[13:19] <zyga> noizer: why?
[13:21] <noizer> zyga  [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/
[13:21] <noizer> staticfiles/build/./armel/usr/share/zoneinfo/localtime'
[13:22] <zyga> noizer: I'm not sure what that error means, perhaps this should be reported to snapcraft
[13:22] <noizer> zyga Wait I will try some other things and then report it if it is nec.
[13:23] <zyga> noizer: I would also suggest you to make the snap manually
[13:23] <zyga> noizer: just use mksquashfs on it, put meta/snap.yaml in place
[13:23] <zyga> noizer: and see what happens
[13:23] <morphis> zyga: how do I get the bot to run all tests on my PR?
[13:24] <morphis> wasn't there a command to do that?
[13:25] <zyga> morphis: "retest this please"
[13:25] <zyga> but it may be picky as it may not let you do it
[13:25] <zyga> let me run that for you
[13:25] <noizer> zyga Ok I'll try that
[13:29] <zyga> morphis: running now
[13:30] <zyga> morphis: n-m one
[13:30] <morphis> zyga: thanks
[13:39] <Facu> question: when packaging a snap, where should I put the "man" page?
[13:41] <qengho> Facu: it doesn't matter, because outside "man" can't find it.
[13:41] <Facu> qengho, how the man pages, or this kind of documentation in general, is handled in the snap world?
[13:42] <qengho> Facu: You might want to add a new app: help: command: cat $SNAP/formatted_man_page
[13:42] <morphis> zyga: do we have any possiblity to populate udev rules from a snap?
[13:43] <morphis> and not as part of an interface?
[13:43] <Facu> qengho, ack, thanks
[13:54] <zyga> morphis: no, but an interface can
[13:54] <zyga> morphis: what do you need?
[13:54] <zyga> morphis: (so a permanent snippet on a slot could do it)
[13:54] <morphis> zyga: for modem-manager we have device specific udev rules
[13:55] <morphis> and putting them into a interface is not what we should do
[13:56] <zyga> morphis: hmmmmm
[13:56] <zyga> morphis: perhaps it is, just in the slot definition itself
[13:56] <zyga> morphis: we talked about having device specifc stuff in a slot, (pinging ricmm for context if needed)
[13:56] <zyga> morphis: think about it
[13:56] <morphis> zyga: you mean as parameter?
[13:56] <zyga> morphis: we could have a "hardware-enablement" interface or similar
[13:57] <morphis> yes
[13:57] <zyga> morphis: and we'd stick it on the kernel snap
[13:57] <zyga> morphis: and connect to mm
[13:57] <zyga> morphis: (so the plug would gain the real power)
[13:57] <zyga> morphis: but the slot would say what the powers are
[13:57] <morphis> hm
[13:57] <morphis> zyga: kernel / gadget snap sounds like a possible thing
[13:57] <zyga> morphis: I'm going to pick up kids from school now, bbl
[13:58] <zyga> morphis: ping me with details please or use email
[13:58] <morphis> zyga: will do
[15:11] <kyrofa> elopio, are you around today?
[15:30] <zyga> re
[16:02] <jdstrand> mhall119 (CC Trevinho): hey, you said in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 'and am also getting some apparmro denials' -- what were they? if they are the ones I mentioned in the MP then I think there is more work to do on the MP
[16:08] <didrocks> hey kyrofa, how are you?
[16:08] <kyrofa> didrocks, hey! How's Texas?
[16:08] <kyrofa> And I'm doing well :)
[16:09] <didrocks> kyrofa: rainy :p
[16:09] <kyrofa> Yikes
[16:09] <kyrofa> All legs of my flight were delayed because of thunderstorms over that area
[16:10] <kyrofa> And it's still going?
[16:10] <didrocks> no, it's stopped right now
[16:10] <kyrofa> Oh, okay
[16:10] <didrocks> but it was quite impressive :)
[16:10] <kyrofa> I bet it was!
[16:10] <didrocks> yeah :)
[16:10] <didrocks> I was wondering how you generally approach this: I'm trying to snap galculator, but as most of project, they hardcode datadir at compile time to fetch resources at runtime
[16:11] <didrocks> but ofc, then, nothing is available at runtime on /share ;)
[16:11] <kyrofa> Ah yes
[16:11] <kyrofa> Pretty typical problem
[16:11] <didrocks> and ofc, changing datadir in the configure flag make it install relative to that path
[16:11] <didrocks> so that doesn't even workaround the issue
[16:12] <didrocks> (be installed in /snap/galculator/current/snap/galculator/current/share/foo for instance)
[16:12] <kyrofa> So the way I solve it typically depends on the project. Lots of projects that need to reach out like that also support configuration files. No go there?
[16:12] <didrocks> well, I can setup datadir=/snap/galculator/current as a workaround for now
[16:12] <didrocks> but
[16:12] <jdstrand> zyga: hey, I had a number of PRs for unity7 interface that I was hoping would be in 2.0.4, but it seems they weren't committed. should I be doing something differently?
[16:12] <didrocks> then, it influences the installation path
[16:13] <jdstrand> aiui, I request, it gets a review, but then I was told someone else needs to commit
[16:13] <kyrofa> didrocks, yeah, I see what you mean
[16:15] <didrocks> kyrofa: apart from patching upstream, I don't have a good idea on how to resolve this
[16:15]  * seb128 is interested as well
[16:15] <kyrofa> didrocks, so no config file, and no runtime flag available either?
[16:16] <didrocks> nothing that I saw in the code
[16:16] <kyrofa> didrocks, I've not actually encountered a project that was so inflexible
[16:16] <kyrofa> didrocks, yeah the only option I see left is to maintain a fork and try to move a runtime flag upstream
[16:16] <kyrofa> (or a config file, if you like that better)
[16:16] <ogra_> hexedit !
[16:16] <kyrofa> ogra_, hahaha
[16:17] <didrocks> kyrofa: no way to patch I guess?
[16:17] <kyrofa> didrocks, not yet, but you're not the first to ask
[16:17] <zyga> jdstrand: no, I guess just bash me more often
[16:17] <zyga> jdstrand: 2.0.4 is last Friday
[16:17] <didrocks> which is making taking all goodness of getting things from last upstream hard
[16:17] <kyrofa> didrocks, it needs some thoughtful design
[16:18] <zyga> jdstrand: 2.0.5 aka 2016W20 is next week so don't worry, we'll just merge them
[16:18] <seb128> didrocks, kyrofa, Trevinho made a quilt plugin in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 to apply a patch at build time
[16:18] <seb128> sharing one of the existing workarounds invited by people around
[16:18] <Trevinho> it's hacky, eh...
[16:18] <seb128> Trevinho, good morning! ;-)
[16:18] <Trevinho> seb128: hey... Sort of :)
[16:19]  * zyga wonders where is the person that was working on arch support
[16:19] <didrocks> thanks seb128, Trevinho, kyrofa
[16:19] <didrocks> kyrofa: yeah, it's quite hackish and will need to rewrite a good part of upstream
[16:19] <didrocks> and I bet GNOME is mostly the same
[16:19] <didrocks> seb128: do you have any GNOME app snapped at all? (and working :p)
[16:20] <seb128> didrocks, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
[16:20] <seb128> didrocks, our list if issues is on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue
[16:20] <Trevinho> jdstrand: mhmh... I've got the thing running here unconfined, but yes... maybe it doesn't work unconfined because it can't access to some local files.. .I didn't check that yet...
[16:20] <seb128> didrocks, the branch from Trevinho I just pointed has some improvement I'm looking at now
[16:20] <kyrofa> didrocks, which files are we talking about here?
[16:20] <seb128> like generating caches are runtime
[16:21] <ogra_> zyga, blackout24 you mean ?
[16:21] <Trevinho> jdstrand: probably hello-unity python installer has something wrong...
[16:21] <jdstrand> Trevinho: right, I'm talking about when not using --devmode
[16:21] <ogra_> (obviously not here atm)
[16:21] <Trevinho> or it's wrong the way snapcraft handles it
[16:21] <jdstrand> Trevinho: and the accesses indicate it is using some weird paths
[16:21] <didrocks> kyrofa: lp:~didrocks/+junk/galculator-snap for instance, here is the output (installed with --devmode): http://paste.ubuntu.com/16494689/
[16:21] <Trevinho> seb128, didrocks: my plan was to move those script in something like a build plugin that can generate something at build time
[16:22] <zyga> ogra_: thanks!
[16:22] <didrocks> seb128: yeah, like the gdk pixbuf issue as well ^
[16:22] <Trevinho> since something (like gsettings cache, or mime or icon cahces) can be done at that level
[16:22] <Trevinho> seb128: it would be quite easy to do. We can do it.
[16:23] <kyrofa> didrocks, ah, so indeed something gnome-specific
[16:23] <didrocks> kyrofa: well, Mate for this case, but yeah
[16:23] <seb128> gtk*
[16:23] <Trevinho> seb128: however, as discussed in bug #1551716, we should fix snapcraft to allow patching in a native way (or imho, just runing a script in between source pulilng and building). sergiusens if you can comment in what's your preferred approach in that, I could come with a PR.
[16:23] <seb128> didrocks, seems like we are getting bind mount interfaces though, so that are going to be able to make things like mimetypes or pixbuf loaders work
[16:24] <didrocks> seb128: oh, so we will be able to bindmount some files?
[16:24] <seb128> Trevinho, imho we require to apply patches to upstream code to work on snap we loose
[16:24] <zyga> didrocks: we're getting support for that
[16:24] <seb128> didrocks, seems o
[16:24] <seb128> so
[16:24] <zyga> didrocks: there is a bug open on snappy and ubuntu-core-launcher
[16:24] <zyga> didrocks: ~ next week
[16:24] <kyrofa> didrocks, yeah, we need that for fonts, locales, etc.
[16:25] <didrocks> kyrofa: zyga: ok, that wouldn't help that .ui file though (which is part of upstream's project)
[16:25] <didrocks> basically in one Makefile.am:
[16:25] <didrocks> uidir = $(datadir)/galculator/ui
[16:25] <zyga> though note that it's not a way to just load random files from classic
[16:25] <didrocks> so changing datadir change uidir, which is where things are stored
[16:25] <seb128> didrocks, the --prefix=... should work for that case though?
[16:26] <kyrofa> Trevinho, seb128 yeah at least from my perspective I keep getting conflicting requests about patching/not patching and how it relates to contributions upstream
[16:26] <Trevinho> jdstrand: yeah... it's weird that those paths are hardcoded. Not sure what's doing the setup.py under the hood, but it doesn't seem anything particular hard... However I just focused in getting compoments to run. So... if you want o check the code further, I leave that in hold for a while
[16:26] <didrocks> seb128: hum, using --prefix=/snap/galculator/current/ ?
[16:26] <kyrofa> sergiusens may have more information-- he'll be back on Monday
[16:26] <seb128> didrocks, yes
[16:27] <zyga> didrocks: note that /snap might change some day, it's better (though harder) to really understand $SNAP
[16:27] <seb128> didrocks, otherwise get upstream to use gresources and have the .ui including in the binary ;-)
[16:27] <Trevinho> kyrofa: well, patching is something we need to provide... People can't just fork a project when a patch can live without having to care about pulling at every upstream update.
[16:27] <seb128> zyga, well, those are defined at buildtime
[16:27] <seb128> zyga, those being the code function calling things on a path
[16:27] <Trevinho> kyrofa: and Mark gave is +1, if I read correctly that bug.
[16:28] <seb128> same for locales and bindtextdomain()
[16:28] <seb128> they do
[16:28] <seb128> bindtextdomain ("domain", LOCALEDIR)'
[16:28] <zyga> seb128: and all of that can be moved
[16:28] <didrocks> zyga: yeah, but here, we are quie in a blocked situation
[16:28] <zyga> seb128: note that snap name can be changed too
[16:28] <seb128> zyga, so what do you suggest doing?
[16:28] <didrocks> seb128: sure, that's totally doable for delivering that this week…
[16:29] <zyga> this is fine for a short term solution but IMHO patching the world to understand $SNAP in various low-level toolkits would be best
[16:29] <kyrofa> Trevinho, ah, so did gustavo. Okay, that clears things up, I guess I missed that conversation
[16:29] <seb128> that's bong
[16:29] <seb128> we message snap as a way for upstream to ship their code unmodified by distro
[16:29] <zyga> seb128: why?
[16:29] <seb128> and now we tell them they need distro patches to work on our system
[16:29] <seb128> head -> desk
[16:29] <zyga> seb128: that doesn't mean some middleware layer must stay oblivious to what snaps are
[16:29] <zyga> seb128: we had to patch nearly all major pieces
[16:30] <zyga> seb128: (ask morphis)
[16:30] <seb128> well, you loose adoption at this point
[16:30] <seb128> the interfaces yes
[16:30] <zyga> seb128: well, what is your suggestion?
[16:30] <jdstrand> Trevinho: I may be able to work with what it there
[16:30] <zyga> seb128: no, for paths
[16:30] <seb128> but if you need to patch "randomcalc" code to change it's paths
[16:30] <zyga> seb128: --prefix is never correct for a snap (it can move around)
[16:30] <jdstrand> zyga: ack, thanks
[16:30] <seb128> I suggest fixing that ^
[16:30] <seb128> and making a predictable prefix
[16:31] <zyga> seb128: that's a design decision that we've commited to
[16:31] <zyga> seb128: this is not my decision but we shouldn't build everything against that
[16:31] <seb128> well, it's fine
[16:31] <seb128> it's just going to slow down adoption
[16:31] <seb128> if upstream need to "fix" their code to work on snappy
[16:31] <zyga> seb128: I suspect that is true
[16:31] <zyga> seb128: but only for middleware pieces
[16:31] <zyga> seb128: (most things should not care much)
[16:32] <seb128> they do though
[16:32] <zyga> seb128: but I agree in principle
[16:32] <seb128> any gettext program calls
[16:32] <seb128>  bindtextdomain ("domain", LOCALEDIR)'
[16:32] <seb128> to read translations
[16:32] <zyga> seb128: well, we could patch glibc (we plan to anyway)
[16:32] <seb128> where LOCALEDIR is $prefix/usr/locale
[16:32] <zyga> seb128: and a few other things to make that code correct in a snappy context
[16:33] <seb128> and to fix calculator loading its .ui from $prefix/usr/share/ui you patch calculator
[16:33] <seb128> you fork the world and end up maintaining patched versions of everything
[16:33] <zyga> seb128: with $SNAP being relocatable, we have no other choice really
[16:33] <didrocks> seb128: I don't see that specific issue (hardcoded paths) being in the bug list, should I open one or did I mis it?
[16:33] <seb128> sounds like deb based ubuntu :p
[16:33] <zyga> seb128: I mean that all of those patches should end up upstream
[16:33] <zyga> seb128: or at least in ubuntu as patches for deb-based snaps
[16:33] <seb128> didrocks, I mentioned it on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282 which is one of those cases
[16:33] <zyga> seb128: anyway, sorry for derailing your discussion
[16:33] <seb128> didrocks, but yeah, feel free to open one
[16:33] <didrocks> seb128: let me open an explicit bug about it, shall we?
[16:33] <didrocks> yeah
[16:34] <seb128> thanks
[16:34] <didrocks> ok, building with --prefix, and see how it goes
[16:34] <seb128> zyga, it's not derailing, don't worry
[16:35] <seb128> zyga, I'm ready to bet that you are going to figure out at some point that you need a way to fix that path problem other than asking every app in the world to patch their code to have a if (getenv(SNAP...)) hacks
[16:35] <seb128> but let's see
[16:35] <zyga> seb128: a kernel patch perhaps? :)
[16:35] <zyga> something like /proc/self
[16:35] <seb128> yeah
[16:35] <zyga> seb128: though I think smart patches in glibc could do 90% of the work
[16:35] <seb128> or maybe you need to divert libc and other libs in a wrapper changing the paths on fly for you :p
[16:36] <zyga> seb128: we though ot LD_PRELOAD library or a runtime helper (added at link time) to "cure" some common issues
[16:36] <seb128> I can see how one gets there
[16:37] <seb128> but you are working around in hackish way for issues selft created :-/
[16:37] <seb128> well the bind mount is at least going to solve a part of those
[16:37] <seb128> locales, mimetypes, fonts, etc
[16:37] <zyga> seb128: until we do personal and we expect those snaps to still work
[16:37] <zyga> seb128: we have to be careful with bind mounts
[16:37] <zyga> seb128: there's a reason we bind mount the os snap over regular ubuntu today
[16:38] <didrocks> seb128: hum, modifying prefix modify destdir as well…
[16:38] <seb128> didrocks, you can make install DESTDIR=..., which is what deb do
[16:39] <kyrofa> seb128, that's what the autotools plugin does
[16:39] <didrocks> yeah, unsure you can do that easily with snapcraft, kyrofa ^
[16:39] <zyga> (sooner or later you will start patching, this is barganing phase of kubler-ross :/
[16:39] <didrocks> kyrofa: hum, maybe I'm doing something wrong, but here is what I changed:
[16:39] <didrocks> kyrofa:     configflags: ["--prefix=/snap/galculator/current/usr/"]
[16:39] <kyrofa> didrocks, have you tried doing this standalone? Make sure the build system actually respects DESTDIR correctly?
[16:39] <didrocks> and nothing else
[16:40] <kyrofa> didrocks, because I've run into a few that don't
[16:40] <kyrofa> didrocks, ohh, wait, try this
[16:41] <morphis> seb128: this problem does not only affect us but also apps for xdg-app need adjustments from what I saw
[16:41] <kyrofa> didrocks, there are two ways to install something. Set a prefix and install (in which case is goes to the prefix), or use DESTDIR to put it where you want it to go
[16:41] <zyga> kyrofa: prefix and destdir serve different purpose but I'm sure you know that
[16:41] <didrocks> kyrofa: yeah, I know that, did packaging for years ;)
[16:41] <morphis> seb128: I don't see that $SNAP should be part of every opensource software but every software should be relocatable and not hardcode any paths
[16:42] <seb128> morphis, most are relocatable but the destination is defined at build time
[16:42] <morphis> seb128: right, and that is something which has to change somehow
[16:42] <kyrofa> didrocks, yeah I figured you knew that from autotools, but what I mean to say is that the autotools plugin also supports that
[16:42] <didrocks> kyrofa: what's the right combination then? I did try to set install-via desdir
[16:42] <didrocks> destdir
[16:42] <seb128> morphis, that's not going to change overnight and sort of conflicting with the goal of what main apps to be snapped by next week
[16:42] <didrocks> (you have the branch, right?)
[16:42] <kyrofa> didrocks, so: was there another flag you can use instead of prefix to get it using the right file?
[16:42] <zyga> morphis: very true, this is a dual transition: from debs to snaps and from fixed prefix to "portable" installation
[16:42] <morphis> seb128: I know that somebody tried something like overlayfs but somehow that didn't worked out
[16:43] <zyga> morphis: overlayfs breaks aa
[16:43] <zyga> seb128: would it change anything if we gave each app process a bind mount to /snap
[16:43] <zyga> seb128: I mean to $SNAP
[16:43] <didrocks> kyrofa: uidir is defined from datadir, which is set from prefix
[16:43] <morphis> seb128: for network-manager/modem-manager/bluez we're patching things to understand $SNAP for now
[16:43] <zyga> seb128: like /snap/self
[16:43] <didrocks> but setting prefix seems to change make install dest directory
[16:43] <morphis> seb128: but we're not putting those patches into any debian package
[16:43] <zyga> seb128: being always bind mounted to /snap/$SNAP_NAME/$SNAP_REVISION/
[16:44] <morphis> seb128: see https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/
[16:44] <kyrofa> didrocks, eh... let me clone this thing. Hold on
[16:44] <morphis> seb128: somewhat is this an interim solution
[16:44] <zyga> (or perhaps a symlink though that is harder)
[16:45] <morphis> zyga: yeah
[16:46] <morphis> seb128: and something like --prefix=/snap/galculator/current/usr didn't really worked for us
[16:46] <seb128> zyga, yeah, I guess having a stable path would make things much easier
[16:46] <roadmr> jdstrand: hey, click-reviewer-tools r651 is finally out on the store. Apologies for the dlay
[16:46] <zyga> seb128: we should be able to at least prototype something like that next week but I cannot promise the design will be approved
[16:46] <morphis> as that will still end up as /snap/galculator/current/snap/galculator/current/usr
[16:46] <seb128> morphis, you are getting n-m/bluez/etc upstream to take patches snap specific?
[16:46] <morphis> seb128: if you don't strip the prefix again
[16:46] <morphis> seb128: no
[16:47] <morphis> seb128: we will not bring those patches upstream
[16:47] <morphis> seb128: but longer term upstream needs to be relocatable at runtime
[16:47] <seb128> right
[16:47] <zyga> patch glibc, qt, gtk and you'll see most people not noticing
[16:47] <zyga> (with a grain of salt)
[16:48] <zyga> people bundle gtk/qt on windows so it has to "work"
[16:48] <morphis> zyga: glibc/qt/gtk should be fine mostly
[16:48] <zyga> morphis: yeah? including things like locale and fonts?
[16:48] <morphis> seb128: and you can also write wrapper scripts like https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/bin/networkmanager to adjust things like HOME or LD_LIBRARY_PATH
[16:48] <morphis> zyga: that is why I said "mostly" :-)
[16:48] <kyrofa> didrocks, any chance you have your snapcraft recipe pushed somewhere?
[16:49] <seb128> didrocks, hum, the --prefix= thing doesn't work because make install is going to install in that dir as well and you end up with having /snap/galculator/current/snap/galculator/current/usr as morphis said
[16:49] <zyga> morphis: one more thing, we're getting support for controling environment variables from interfaces
[16:49] <zyga> morphis: so we'll be able to pre-seed sensible variables for the most common stuff
[16:49] <zyga> morphis: and also use interfaces to influence that
[16:49] <morphis> zyga: sounds good
[16:49] <seb128> morphis, right, that's we do, e.g http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc
[16:49] <zyga> (e.g. set something to see classic fonts when classic font interface is connected)
[16:49] <morphis> zyga: I have a feeling that we two should sync up somewhere soon on what is coming and planed etc.
[16:49] <morphis> feel like there are certain things we're really interested in
[16:49] <seb128> morphis, that's quite hackish though, I doubt any upstream maintainer is going to find that being clean/something they can to do :p
[16:50] <didrocks> kyrofa: sure, it's at lp:~didrocks/+junk/galculator-snap. I did try then multiple combinations of prefix and destdir…
[16:50] <didrocks> seb128: exactly
[16:50] <morphis> seb128: I would simply ignore the "clean" part of this for now and get it working
[16:50] <morphis> seb128: I remember that loic started with binary search&replace on NetworkManager coming from a deb
[16:51] <seb128> morphis, that's what we are doing, but are also asked to get upstream adoption, which is more difficult in that case
[16:51] <morphis> seb128: absolutely
[16:51] <didrocks> kyrofa: another way is to move the whole datadir directory after install, even setting an incorrect prefix
[16:51] <morphis> zyga: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 is something we should provide from snappy
[16:51] <kyrofa> didrocks, yeah, but then you're talking custom plugin or yucky makefile (I had to do that for apache)
[16:51] <didrocks> yep
[16:52] <didrocks> kyrofa: any better idea for now? :p
[16:52] <kyrofa> didrocks, experimenting, give me a minute
[16:52] <zyga> OMG :)
[16:52] <zyga> morphis: thanks!
[16:53] <morphis> jdstrand: you already had time to look on the nm interface?
[16:56] <zyga> morphis: https://bugs.launchpad.net/snapcraft/+bug/1583259
[16:56] <zyga> jdstrand: ^^
[16:56] <zyga> tyhicks: (we talked about this at the sprint) ^^
[16:56] <zyga> tyhicks: and gustavo wants it so I think we have agreement for the general direction
[16:56] <zyga> seb128: ^^ I'd love to know if you have suggestions on what some defaults might be when people connect the unity7 interface to make more things work out of the box
[16:56] <morphis> zyga: sounds good
[16:57] <morphis> zyga: couldn't we also add a set of env variables from the gadget snap?
[16:57] <zyga> morphis: that's somewhat more risky, can you give me a use case as a thought experiment?
[16:58] <morphis> zyga: like on Ubuntu Touch we're supplying different env variables directly from the device tarball to adjust runtime behaviour
[16:58] <zyga> morphis: remember nobody will review gadget snaps
[16:58] <zyga> morphis: that's a lot of power
[16:58] <morphis> zyga: like the device specific GU value
[16:58] <zyga> morphis: I see, that's an interesting case
[16:58] <morphis> zyga: why that?
[16:59] <zyga> morphis: is that something mir consumes or something that each snap needs to have set?
[16:59] <morphis> and we're adding more of them like to adjust the wifi management for different BSPs etc.
[16:59] <zyga> morphis: why nobody will review gadget snaps?
[16:59] <morphis> yes
[16:59] <zyga> morphis: because we want many people to make devices and reviews don't scale
[16:59] <morphis> same would apply for snaps, right?
[16:59] <zyga> morphis: so the only choice is to confine and limit gadget snaps and let us land them without review
[17:00] <zyga> morphis: yes but specifically the gadget snap has a very strong power over each device, we should not just let arbitrary things to go through it
[17:00] <zyga> morphis: perhaps a gadget snap could announce meta-data that each snap could see?
[17:00] <morphis> possible
[17:00] <zyga> morphis: and snaps could then opt-into loading some things (just a random idea)
[17:00] <morphis> yeah
[17:01] <morphis> off to the future
[17:01] <zyga> morphis: I see the need for this but I don't see a solution that's not a compromise over something
[17:01] <zyga> yep
[17:01] <morphis> zyga: most important thing for us will be udev rules supplied by either the gadget or kernel snap
[17:02] <zyga> morphis: can you open a bug on that and add some back story (enough for us to drive the design discussion)
[17:02] <zyga> morphis: I think this will be a gadget/kernel-snap (both perhaps) hardware-specific interface but I may be wrong
[17:02] <zyga> morphis: specifically if snaps have to specifically connect to it
[17:02] <zyga> morphis: and what exactly should be in those udev rules
[17:03] <morphis> zyga: sure, can open that tomorrow
[17:03] <zyga> morphis: thanks
[17:14] <ssweeny> zyga, I'm trying to genericise the slotAppLabelExpr function and my go-fu is weak. Is there a way to make that function take either a slot or plug or do I need to make wrapper functions to call that logic?
[17:27] <jdstrand> morphis: been in meetings all morning (both on the schedule and impromptu). I'm done with those for the day so going to eat then look at all the PRs, starting with nm
[17:27] <morphis> jdstrand: great!
[17:28] <jdstrand> zyga: interesting. I'm going to point tyhicks at that too since he is looking at something related to env handling
[17:31] <oparoz> Will installing snaps on Ubuntu on Windows be supported?
[17:32] <ogra_> heh
[17:32] <ogra_> unlikely
[17:32] <oparoz> OK :)
[17:32] <ogra_> unless windows grows some kernel fetures
[17:32] <ogra_> *features
[17:33] <oparoz> Yeah, I was wondering what would be limiting the concept. Systemd might be another issue
[17:35] <ogra_> systemd, apparmor, seccomp
[17:35] <kyrofa> oparoz, yeah basically our entire confinement story is missing there, I imagine
[17:36] <oparoz> That's a bit too much to make it work :)
[17:38] <zyga> ssweeny: no generics in go, you need to fork it
[17:38] <ssweeny> zyga, ack, thanks
[17:38] <zyga> ssweeny: you might be able to move the common part to a helper that just takes the raw data (apps AFAIR)
[17:38] <ssweeny> zyga, yeah that's what I was thinking. Just wanted to make sure I wasn't missing some idiomatic go thing that would be super easy :)
[17:39] <zyga> ssweeny: I'm still new to go but I'm pretty sure there's no generics around
[17:40] <ssweeny> zyga, apparently you can switch on type which is neat but I'd still have no idea how to pass the slot/plug in without them implementing the same interface at least
[17:41] <zyga> ssweeny: you cannot switch types, you can "upcast" interface{} to a real type but you cannot "cast it" to something totally different
[17:42] <ssweeny> zyga, I meant you can switch ON type like switch foo(type) case bool: <do stuff> case int: <do other stuff>
[17:42] <ssweeny> syntax is probably wrong but that's the idea
[17:42] <zyga> ssweeny: ah, yes you can do that
[17:43] <zyga> ssweeny: switch foo.(type) AFAIR
[17:43] <ssweeny> that's it
[17:44] <ssweeny> but still no way to say "this function takes a plug or a slot and I'll figure out which it is in the body"
[17:44] <ssweeny> I'll go ahead and factor the common stuff out
[17:45] <zyga> ssweeny: well you can have it take an interface{}
[17:45] <zyga> ssweeny: but that's not type safe then
[17:45] <ssweeny> right
[17:45] <zyga> ssweeny: I think that's the best we have for now
[17:45] <zyga> ssweeny: we toyed with an idea to have a private base class for plug and slot but that wouldn't help you much
[17:47] <ssweeny> zyga, I guess I could make an interface that covers the needed fields but by that point I've done more work than just factoring out the common code
[17:48] <tyhicks> zyga: fyi regarding the env var bug> mvo is having trouble with the "... and ubuntu-core-launcher (to actually apply those variables to each started process)" part
[17:48] <zyga> with the "..." and"?
[17:49] <zyga> well, I don't suppose we can assume the env is really inherited
[17:49] <tyhicks> zyga: some variables, such as LD_LIBRARY_PATH are being scrubbed when the launcher execs the app
[17:49] <zyga> because that doesn't work on all the variables
[17:49] <zyga> right
[17:49] <zyga> oh?
[17:49] <zyga> execs?
[17:49] <tyhicks> right
[17:49] <zyga> can we still set it after forking:?
[17:49] <zyga> (I assume we must)
[17:49] <zyga> both do it and must be really able to do it, otherwise shell would break too
[17:49] <tyhicks> some vars are scrubbed because the launcher is setuid root
[17:50] <zyga> right but I'm not talking about inheriting environment
[17:50] <tyhicks> but the launcher should, I think, be able to set those vars itself
[17:50] <zyga> just loading it from a file
[17:50] <zyga> exactly
[17:50] <tyhicks> right now, that's not working
[17:50] <tyhicks> I'm looking at it
[17:51] <tyhicks> zyga: I'll keep you updated when I make progress
[18:10] <oparoz> Is there a kernel for core which include grsecurity or do we have to compile one ourselves?
[18:16] <kyrofa> oparoz, you probably need to build that yourself
[18:16] <oparoz> Thanks kyrofa
[19:13] <jdstrand> morphis, zyga: I responded to the nm PR. I think it is fine pending a comment from zyga
[19:14] <jdstrand> morphis: note that I asked you something as well (but it isn't blocking)
[20:38] <jdstrand> plars: hey, how did you create the snap in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/9 ?
[20:59] <plars> jdstrand: with snapcraft, on a branch I have at https://github.com/plars/snappy-tests
[21:00] <jdstrand> ack, thanks
[21:01] <plars> jdstrand: if you want to build yourself, it may take running it a second time. For some reason it tries to build the go code rather than just the tests. I haven't sorted out why just yet, but rerunning snapcraft does it right if it hits an error the first time
[21:02] <plars> jdstrand: basically it's just a compiled version of the tests in the snappy source tree
[21:08] <jdstrand> ok
[21:09] <jdstrand> I'm having some issues with embedded paths that I think is a snapcraft python issue. I've seen the same thing with hello-unity for example
[21:10] <jdstrand> since I just want the tests to run, I figured if I recreate it locally I could run it locally
[21:31] <plars> jdstrand: I can try to rebuild the snap later too if you like - I'm just tied up trying to get some progress on another thing right now
[21:32] <jdstrand> plars: I have the snap. should snappy-tests -check.f homeInterfaceSuite be run under sudo?
[21:32] <jdstrand> plars: and that is /snap/bin/snappy-tests ?
[21:33] <jdstrand> doesn't look like it on either
[21:34] <plars> jdstrand: no, sudo shouldn't be required
[21:35] <jdstrand> plars: installed with --devmode?
[21:35] <plars> jdstrand: if there's still a problem, we may need to check with elopio and see if they are still having issues - yes, I did install with --devmode
[21:35] <plars> I think it should be require for those tests to have any chance at running
[21:37] <jdstrand> panic: runtime error: invalid memory address or nil pointer dereference
[21:37] <jdstrand> let me try one more time with your snap
[22:06] <jdstrand> plars: fyi https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/11
[22:08] <jdstrand> plars: fyi I'm EOD now so feel free to comment in the bug
[22:08] <jdstrand> jjohansen: fyi, ^
[22:08] <plars> jdstrand: will do, thanks for taking a look. Very possible that snappy and/or the tests have changed since then
[22:08] <plars> elopio: are you hitting errors like that with the tests now? ^
[22:17] <jjohansen> plars: I am building a test kernel, with what I hope is the fix. Is a deb good enough for you to test or do you need it in a ppa?
[22:17] <jjohansen> plars: this is for bug 1579135
[22:18] <plars> jjohansen: well it sounds like something is preventing reproduction of the bug. I would need to test it in snappy, so any chance I could get it as a kernel snap?
[22:18] <jjohansen> plars: uhmm, no :)
[22:18] <plars> jjohansen: but I'll need to try reproducing again first, and check with QA if they are seeing the new problem in their test runs or if it is something unique to running it this way
[22:18] <plars> jjohansen: heh, ok
[22:18] <jjohansen> I'll look into it, I've never done a kernel snap before
[22:19] <plars> jjohansen: me neither, I'm happy to try, just would need to do some rtfm
[22:19] <plars> jjohansen: in any case, no rush... I'm already going to be swamped for most of the night on other problems
[22:19] <jjohansen> right, let rephrase the kernel snap won't happen right away
[22:20] <jdstrand> jjohansen: you'll want to talk to ogasawara for a kernel snap-- I think she can point you to someone. I think there is tooling to convert a deb to a snap, but I might be making that up
[22:21] <jjohansen> jdstrand: ack thanks


[00:31] <bdrung> Laney: not sortable sponsor queue -> adblock plus?
[00:31] <Laney> yeah i do have that on
[00:31] <Laney> seems weird though
[00:33] <bdrung> Laney: whitelist everything on this page
[00:33] <bdrung> micahg: mozilla package set -> ubufox sponsoring (3 bugs)
[00:33] <Laney> that works
[00:33] <Laney> cheers
[00:36] <micahg> bdrung: only 1 I can do
[00:36] <micahg> and it's not really complete
[00:36] <bdrung> micahg: start small
[00:37] <micahg> I'll look at it again
[00:37] <bdrung> tumbleweed: i raised the bar by ~ 5 :)
[00:38] <micahg> bdrung: the script doesn't take into account which series one can upload to
[00:47] <micahg> bdrung: I haven't done it because chrisccoulson is planning an upload of ubufox, so I left it for him
[01:17] <micahg> bdrung: PM?
[02:08] <highvoltage> moo
[02:15] <micahg> highvoltage: builders empty for grazing packages :)
[02:23] <highvoltage> I have some packages to fix but I don't have the energy for them now :)
[02:23] <ajmitch> it's not like it's late there, right?
[02:35] <highvoltage> ajmitch: 21:35, but I have to be up at 4:00 to take someone to the airport
[02:36] <highvoltage> (in eastern canada atm, not south africa :) )
[02:40] <ajmitch> highvoltage: aha :)
[02:48] <zooko> Greetings, people of #ubuntu-motu!
[02:50] <zooko> We Tahoe-LAFS hackers moved up the release date of Tahoe-LAFS v1.8.0 to Wed, Aug 11 in the hopes of getting it included in Maverick.
[02:59] <ajmitch> zooko: still no progress on getting them into debian as well?
[03:10] <zooko> ajmitch: no, no recent progress on getting Tahoe-LAFS into Debian.
[03:20] <zooko> ajmitch: but Tahoe-LAFS v1.8.0 offers some pretty dramatic performance, feature, and bugfix improvements over the v1.6.1 that is currently in Ubuntu.
[03:23] <zooko> ajmitch: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS
[07:20]  * Rhonda cries out loud, https://bugs.launchpad.net/bugs/600100
[07:20] <ajmitch> invalid?
[07:20] <Rhonda> I *explicitly* asked about wether it might go in through a stable release update!
[07:21] <ajmitch> confusion reigns
[07:21] <Rhonda> And was told that there isn't a way. No I receive an invalid for the backports request?!
[07:21] <Rhonda> Sorry, but this is winding me up. :/
[07:21] <ajmitch> bugs aren't serious enough for a SRU, and because they're bugs, no backports
[07:21] <ajmitch> yay for worshipping the process
[07:22] <Rhonda> I would be *more* than happy to have it go in through a SRU, but then, being told that it won't happen I do the other way that makes it possible to offer it, and now this.  :'(
[07:22] <ajmitch> I can understand why you'd be annoyed
[07:23] <Rhonda> And wouldn't a SRU has to go through a bugreport in launchpad, too?
[07:24] <ajmitch> yes
[07:24] <Rhonda> Why not reassign it appropriately instead of marking it invalid, then?
[07:24] <ajmitch> and requires eyballing of the diff
[07:24] <Rhonda> This is so shooting the effort down the drain. :(
[07:24] <ajmitch> because it would still be an invalid task in lucid-backports
[07:24] <Rhonda> Ah, alright.
[07:24] <ajmitch> same bug can be used, just needs a task against wesnoth in ubuntu, targetted to lucid
[07:25] <ajmitch> & why not 1.8.3? :)
[07:30] <Rhonda> Right, should get updated to that. Thanks for the reminder.
[07:31] <Rhonda> Actually I potential would need to bump it to 1.8.4 in a week or two week's time anyway.
[07:31] <Rhonda> And it's definitely not invalid for karmic, there never was a wesnoth-1.8 package in karmic.
[07:32] <Rhonda> The SRU team would only laugh madly at me filing a SRU request for wesnoth-1.8 to karmic.
[07:33] <Rhonda> stalcup: ^^ - can you please take a look, with sugar on top?
[07:57] <dholbach> good morning
[08:04] <ajmitch> morning dholbach
[08:05] <dholbach> hey ajmitch
[08:14] <jdong> stalcup / Rhonda: as a bag of bug fixes new release that was rejected az.
[08:14] <jdong> Err
[08:14] <jdong> as a SRU, I think it's a good backports candidate
[08:15] <jdong> And all those typos means a sleepy jdong
[08:15] <maco> jdong: and no wonder, given the timezone we're in!
[08:15] <jdong> Hey, why are you still up? :)
[08:16] <maco> im up because im a stupid college student who still hasnt gotten it through her head that getting up for work requires going to bed at a decent time
[08:16] <Rhonda> jdong: I still am not clear what you mean. :P  So would you think it does indeed make a good SRU candidate, or not?
[08:17] <jdong> Rhonda: No i mean it's a good backports candidate and was rejected in error
[09:19] <huats> morning
[09:32] <Rhonda> jdong: Can you set it back to new then, I don't want to be involved in status ping-pongs.  %-/
[11:47] <Laney> jdong or ScottK: Could I be added to backporters?
[12:01] <micahg> dholbach: would a bzr merge work better for a new upstream version?
[12:01] <micahg> actually, I'm not sure how to do that
[12:17] <tumbleweed> micahg: bzr merge-upstream? (if you are talking about new upstream versions, not via debian). And yes, that does make for easier reviewing than people attaching tarballs to bugs
[12:17] <micahg> tumbleweed: yeah, idk how to do that yet
[12:18] <tumbleweed> micahg: bzr merge-upstream --version=$VERSON --distribution=maverick $TARBALL
[12:29] <hyperair> debfx: ping
[12:30] <hyperair> debfx: i'm looking at this: https://bugs.launchpad.net/ubuntu/+source/wormux/+bug/541078
[12:30] <hyperair> and i was wondering, why don't you replace the config.guess and config.sub files?
[12:33] <debfx> hyperair: dh_autoreconf replaces them
[12:33] <hyperair> debfx: ah, it does, eh.
[12:33] <hyperair> i'm not familiar with dh-autoreconf, actually.
[12:34] <hyperair> part of the new debhelper, i suppose.
[12:35] <micahg> tumbleweed: k, now do I ask for reviewer from -sponsors?
[12:35] <debfx> it's a fairly new package (dh-autoreconf) but should work with all debhelper/cdbs versions
[12:35] <tumbleweed> micahg: propose it for merging, it'll appear in the sponosr queue
[12:36]  * micahg didn't close the bug right in bzr..trying again
[12:36] <tumbleweed> debcommit should do the right thing
[12:37]  * micahg didn't use debcommit since I already used it for the commit before
[12:38] <micahg> tumbleweed: fixed it, just used debcommit -e :)
[12:39] <hyperair> debfx: yes, i see. okay, let me continue looking.
[12:40] <dholbach> micahg: that'd work too
[12:40] <micahg> dholbach: bzr merge ready :)
[12:41] <micahg> tumbleweed: thanks for your help
[12:41] <dholbach> micahg: I'm going to be a bit busy today, if nobody beats me to it, I'll have a look tomorrow morning
[12:41] <micahg> dholbach: k, thanks
[12:42] <micahg> dholbach: if a bug has a patch and bzr branch, both show up on the sponsoring page
[12:44] <dholbach> micahg: if you do a merge, no need to file a bug
[12:44] <hyperair> debfx: i noticed you dropped README from debian/docs, which looks like it might be useful.
[12:45]  * micahg thought tracking bugs were always a good thing
[13:12] <debfx> hyperair: the README is in wormux.docs
[13:13] <hyperair> debfx: ah, i must have missed it, sorry.
[14:18] <hyperair> debfx: you're missing entries in debian/copyright for vlgothic.
[14:18] <hyperair> debfx: add those and i'll upload
[14:57] <stalcup> 18
[15:07] <debfx> hyperair: done, thanks for reviewing the package :)
[15:07] <hyperair> debfx: sure =)
[16:02] <LucidFox> http://revu.ubuntuwire.com/p/gmail-notifier <-- do we really need *another* gmail notifier for GNOME?
[16:02] <LucidFox> we have like 5 already
[16:45] <directhex> LucidFox, but the other ones are *wrong*!
[17:05] <nigelb> ok, folks! We (Maia and me) need your help.  We're re-branding "Behind MOTU" since everyone in ~ubuntu-dev would be included.  We'd like your suggestions for name!
[17:14] <hyperair> argh.
[17:15] <hyperair> dput finally reached 97343k/97344k of this 90M tarball crawling at 30k/s
[17:15] <hyperair> and then
[17:15] <hyperair> it hung.
[17:15]  * hyperair facepalms
[17:15] <hyperair> whyyyyyyyyyyyyyyyyyy
[17:15] <hyperair> why does this happen to me?
[17:17] <\sh> hyperair: the karma ;)
[17:17]  * hyperair weeps
[17:18] <Laney> hyperair: you should use sftp
[17:18] <Laney> it won't have that problem
[17:18] <hyperair> Laney: eh?
[17:18]  * hyperair tries
[17:20] <Rhonda> stalcup: I should have mentioned that I was guided there after a SRU discussion, right.
[17:26] <stalcup> Rhonda: that would have been helpful :)  although I jumped to conclusions as well
[17:27] <Rhonda> I *think* I did a test in karmic back then as well, but will try so tomorrow again when I am at the place with my chroots.
[17:28] <stalcup> coolio
[17:29] <Rhonda> Given that 1.8 is already in karmic-backports and the development since then is on a stable branch upstream wise so only translation/bugfixes go in, I though don't expect 1.8.3 to be any different here.
[17:29] <Rhonda> But for completeness (and to please my own perfectionist approach) I will give it a shot just to be sure
[17:30] <stalcup> :)
[17:30] <stalcup> excellent
[18:58] <hyperair> debfx: uploaded.
[18:59] <stalcup> Rhonda: ScottK approved your lucid request, care to comment on your package in karmic?
[19:11] <Rhonda> Like said, can do that tomorrow. :)
[19:11] <Rhonda> Two hours doesn't make the day change over here, mind you. :P
[19:14] <stalcup> Rhonda: it's still morning where I am :)
[19:16] <Rhonda> See, day hasn't even changed for you. ;)
[19:17] <ari-tczew> Laney: thanks for sponsoring   ; O
[19:18] <Laney> np
[19:19] <ari-tczew> Laney: just you don't need to set status manually if debian/changelog includes LP: # tag
[19:19] <Laney> I know.
[19:36] <Rhonda> Where are the metting logs again in the wiki?
[19:36] <Rhonda> Ah, I think I just found me a search pattern.
[19:36] <geser> for which meeting?
[19:37] <Rhonda> Found it ^^
[20:17] <fabrice_sp> jtb is waiting in binary new, and this is blocking 4 syncs to get josm at the latest version. Taking into account that FF is around the corner, should I poke an archive admin to get it approved ASAP?
[20:17] <fabrice_sp> or should I request a FFe right now ? :-)
[20:20] <geser> fabrice_sp: if you know that josm will build after the 4 syncs, why not requests sync for all needed packages now? and deal with the build ordering (if necessary) later
[20:21] <fabrice_sp> geser, right. I forgot about that! tbh, I'm releuctant to upload something that will FTBFS. I'll upload it to my ppa before. Thanks!
[20:29] <ari-tczew> tumbleweed: ping
[20:30] <tumbleweed> ari-tczew: pong
[20:31] <ari-tczew> tumbleweed: hello, what's the command for verbose files in .deb (binary)?
[20:32] <tumbleweed> dpkg-deb -c ?
[20:32] <tumbleweed> (or debc for a binary changes file)
[20:32] <ari-tczew> tumbleweed: I'll prepare a patch for ddd package, which misses .xpm install
[20:33] <tumbleweed> cool. please forward to debian (obviously)
[21:34] <ari-tczew> could someone check whether it can be sync'd? the delta for ssl-cert package reffering to jaunty. https://launchpad.net/ubuntu/+source/ssl-cert/+changelog
[21:39] <geser> ari-tczew: what's your opinion?
[21:41] <ari-tczew> geser: the delta is reffering to upgrade packages in jaunty, but jaunty is very old release
[21:41] <ari-tczew> I'd drop the changes, but I'm not 100% sure
[21:42] <geser> because a delta is old, it doesn't automatically mean it can be dropped
[21:42] <ari-tczew> geser: I don't said delta is old, just affected release is old
[21:43] <ari-tczew> geser: what's your opinion?
[21:43] <geser> then I misunderstood you
[21:44] <geser> and I agree that it can be dropped, openssl-blacklist got moved to suggest in the Debian package and the upgrade notice should be a non-issue now
[21:45] <ari-tczew> geser: that's right
[21:57] <Laibsch> Is REVU still the place for sponsorship requests?
[21:57] <Laibsch> it doesn't seem to process my uploads
[21:58] <micahg> Laibsch: REVU doesn't process, people process things in REVU
[21:58] <Laibsch> micahg: not quite correct ;-)
[21:58] <Laibsch> the server needs to process the upload to show it
[21:59] <Laibsch> mine doesn't show up in the list
[21:59] <Laibsch> uploaded it yesterday and today
[21:59] <micahg> Laibsch: are you referring to an existing package or a new package?
[21:59] <Laibsch> new package
[21:59] <Laibsch> natspec
[21:59] <micahg> oh, yeah, well then...
[21:59] <Laibsch> where is the place now?
[21:59] <micahg> Laibsch: same place, just lack of REVUers :)
[22:00] <Laibsch> OK
[22:00] <Laibsch> that's kind of unchanged ;-)
[22:00] <Laibsch> but again, the server doesn't even process my package
[22:00] <Laibsch> it doesn't show up in the list
[22:00] <micahg> Laibsch: is it debian 545151
[22:00] <Laibsch> yes, that's the one
[22:00] <Laibsch> and there is a bug in LP as well
[22:01] <Laibsch> about unzip and encoding issues
[22:01] <micahg> Laibsch: so, getting into debian would be ideal, have you tried that route?
[22:01] <Laibsch> do you remember my nick
[22:01] <Laibsch> ?
[22:01] <Laibsch> no need to always start with the basics ;-)
[22:02] <Laibsch> Yes, I'm maintaining a number of packages in Debian already
[22:02] <Laibsch> and the upload to Debian is in progress
[22:02] <micahg> Laibsch: are you just trying to get in Maverick before FF?
[22:02] <Laibsch> but that won't be in time for maverick (at least most likely it won't)
[22:02] <Laibsch> kind of
[22:02] <Laibsch> DIF
[22:02] <Laibsch> no?
[22:03] <Laibsch> and I think we're already past DIF
[22:03] <micahg> k, I should probably stop now since I'm not helping here...
[22:03]  * micahg will bbiab
[22:03]  * micahg can't REVU anyways
[22:03] <Laibsch> but maybe you can help me find out why the darn server won't process my uploads
[22:04] <Laibsch> :-/
[22:07] <ari-tczew> tumbleweed: ddd patch updated
[22:19] <micahg> Laibsch1: idk, I see the upload, but it says there was an issue and idk who admins REVU
[22:20] <Laibsch1> some special restricted-access area?
[22:20] <Laibsch1> because I don't see anything
[22:20] <Laibsch1> and I did not get a mail about it, eithr
[22:20] <micahg> Laibsch1: http://revu.ubuntuwire.com/details.py?upid=8500
[22:21] <Laibsch1> it's now showing in the list, too
[22:21] <Laibsch> thanks
[23:02] <ari-tczew> bdrung: could you sync this one? bug 614210 it's necessary for some packages to merge
[23:56] <siretart>