[04:37] <biotrox> !banned
[04:37] <ubotu> If you have been banned it is probably because you have not gone along with what is acceptable behaviour. If you're not sure what acceptable behaviour is please see http://www.ubuntu.com/community/conduct/
[04:38] <biotrox> if i'm bein' banned from other channel of ubuntu how to resolve this..?
[04:39] <biotrox> :(
[04:40] <LaserJock> talk to #ubuntu-ops
[04:40] <biotrox> oke thanks
[02:15] <sperotek> I know I can hear sound, like a music file on the computer from my thin clients since sound is set to true, but I can't hear the sound in a youtube video. Is this something I can fix?
[02:22] <ogra> sperotek, https://lists.ubuntu.com/archives/edubuntu-users/2007-June/001253.html
[02:24] <ogra> https://help.ubuntu.com/community/EdubuntuFAQ has it as well :)
[02:51] <sperotek> I only had one other problem other than sound and local devices, I have to make a server with around 500 users (students), is there a tutorial somehow explaining how it can be done so they have the same user privileges, settings, desktop with icons and everything. Some automated way or some easier way?
[02:52] <sperotek> Once I can solve that problem, and I make a presentation to my boss to convince him to convert a lab to an edubuntu lab
[02:53] <sperotek> I have tried finding some guide through Google for a long time, but can't find anything
[03:19] <LaserJock> morning ogra
[03:19] <ogra> heya
[03:19] <LaserJock> ogra: so what do you think about this lang-pack installation from addon CD issue
[03:20] <ogra> well, the language selector should pick it automatically if the CD is mounted
[03:20] <LaserJock> I dug around a little, and if you select "Start Package Manager" when the pop in the CD the CD is added as an apt source
[03:20] <ogra> we should test that, and if it works, probably add a utton to the popup dialog
[03:20] <LaserJock> hmm, yeah
[03:21] <ogra> dunno if thats good UI wise, but that would be an option ...
[03:21] <LaserJock> I think it would be a fairly common use-case
[03:21] <ogra> more tricky will be the gcompris install
[03:21] <ogra> we dont have a package for each language, so we cant bind them directly to the langpacks
[03:22] <LaserJock> well, I was thinking of having a gcompris-addon metapackage in my metapackages
[03:22] <LaserJock> that deps on all gcompris langs
[03:22] <LaserJock> that would at least give an all-or-nothing solution
[03:22] <LaserJock> I think most people won't mind installing all the languages if they are on the CD
[03:23] <ogra> well, thats what we did before
[03:23] <ogra> we could just add a dep to our gcompris package
[03:23] <LaserJock> well, but that would affect people downloading it from the net too
[03:23] <LaserJock> like from Ubuntu
[03:24] <ogra> hmm
[03:31] <LaserJock> that's why I was thinking an edubuntu-addon-gcompris metapack might help
[03:33] <ogra> oh sigh ... pulseaudio uses quilt as patchsystem
[03:33] <ogra> as if two package patch systems wouldnt be enough
[03:33] <ogra> grr
[03:38] <LaserJock> ogra: hehe, just keeps you on your toes
[03:48] <a5benwillis> ogra: Hi there
[03:48] <a5benwillis> I just got home from a huge Ed Tech event in Atlana, GA USA
[03:48] <a5benwillis> Lots of talk about Edubuntu
[03:48] <ogra> cool !
[03:48] <a5benwillis> Mostly good... a fewbad that I didnt agree with.
[03:50] <a5benwillis> One presenter said to a roon of about 300 people that he didnt recomend Edubuntu to the beginner because it still has some issues.
[03:51] <a5benwillis> Like sound issues and that it takes 5 minutes or more for a client to boot which may make a beginner think they've done something wrong.
[03:51] <ogra> he is right, even thouggh his client HW likely doesnt hit the minimal spec :)
[03:52] <ogra> gutsy fixes the slow boots
[03:52] <ogra> there are no sound issues though
[03:52] <ogra> actually what we have in feisty is the best sound support any ltsp ever had
[03:52] <a5benwillis> The other big thing that I heard was people wanting good edubuntu-novell integration.
[03:52] <ogra> what would that mean ?
[03:52] <a5benwillis> A lot of k-12 stilluses netware for user accounts.
[03:53] <ogra> ah, well, we have all clients available for that
[03:53] <a5benwillis> Login authentication from novell e-directory etc...
[03:53] <ogra> just no scripting or setup for it ... ts a bit of manual work
[03:53] <a5benwillis> any guides for it?
[03:53] <ogra> but its not as if you couldnt do it
[03:54] <a5benwillis> I spoke with on IT director from Washington state who has spent lots of time trying to get it to work. His IT department isnt as big as minebut they are more into open source as a district that us.
[03:55] <a5benwillis> He hasnt had any luck so he just uses generic logins to the clint then uses an launcher to the users home directory which then asks for authentication..
[03:56] <ogra> look for docs about the mars_new stuff
[03:56] <ogra> err
[03:56] <ogra> mars_nwe
[03:57] <ogra> ogra@laptop:~/packages/pulseaudio-0.9.6$ apt-cache search netware ncp
[03:57] <ogra> libncp - shared library used by programs that use NetWare Core Protocol
[03:57] <ogra> libpam-mount - PAM module that can mount volumes for a user session
[03:57] <ogra> libpam-ncp - PAM module allowing authentication from a NetWare server
[03:57] <ogra> ncpfs - utilities to use resources from NetWare servers
[03:57] <ogra> all there :)
[03:58] <ogra> i'm sure you will find a howto
[03:58] <a5benwillis> ogra: Ive spent lots of time with those modules. There was a problem using them with ldm
[03:58] <ogra> you just need to make sure the ssh server uses it
[03:58] <ogra> ldm is dumb ...
[03:58] <ogra> the importan part is the pam setup for ssh
[03:59] <a5benwillis> right, tryingto remember here, its been a few months. The problem was really with ssh and the modules..
[03:59] <a5benwillis> Looking through notes now.
[04:00] <a5benwillis> The user had to exist on the local machine for ssh to allow the login.
[05:47] <stgraber> ogra: still the ssh problem even once ltsp-update-sshkeys and ltsp-update-image
[05:47] <ogra> weird
[05:47] <ogra> is the server you try to log in to in the known hosts file ?
[05:48] <stgraber> yes and this Permission denied (publickey,password) looks weird as well
[05:48] <stgraber> yes it's
[05:48] <stgraber> <IP_ADDRESS>
[05:48] <stgraber> dhcp on <IP_ADDRESS> and client <IP_ADDRESS>
[05:48] <stgraber> I don't really see where the problem is
[05:48] <ogra> hmm, me neither
[05:49] <ogra> it worked with a real client ?
[05:49] <stgraber> as when I'm on my laptop on Ubuntu I can ssh<EMAIL_ADDRESS>without any kind of problem
[05:49] <ogra> or did it fail there as well ?
[05:49] <stgraber> well, I'm on a real client
[05:49] <ogra> are you sure its trying to log in to that server ?
[05:49] <ogra> do you see the ip in ldm.log
[05:49] <stgraber> I'm trying ssh<EMAIL_ADDRESS>from a console on the thin client (tty2)
[05:50] <ogra> oh, wait, i dont even know if we write it to the log
[05:50] <ogra> sbalneav, do we ? ^^^
[05:50] <ogra> ssh from commandline doesnt work ...
[05:50] <ogra> i dont know why yet, somehow unionfs related
[05:50] <stgraber> nope : Permission denied (publickey,password).
[05:51] <ogra> yeah, i know
[05:51] <sbalneav> Not doing as much logging as I probably should.
[05:51] <ogra> dont try it :)
[05:51] <ogra> well, you changed a lot the last days
[05:51] <ogra> but that code isnt in tribe2 yet
[05:51] <ogra> yay
[05:54] <stgraber> oh, got something interesting
[05:54] <stgraber> /var/log/ldm.log : ssh: connect to host <IP_ADDRESS> port 22: No route to host
[05:54] <stgraber> so ldm is trying to connect to the wrong host .. :)
[05:55] <ogra> yeah
[05:56] <ogra> you can set LDM_SERVER in the lts.conf (in the tftp tree)
[06:00] <ogra> conmgrats to your MOTUship :)
[06:00] <nixternal> thank you!
[06:00] <sbalneav> nixternal++
[06:01] <nixternal> well, I only got 4 hours of sleep, so nixternal-- ;)
[06:02] <sbalneav> nixternal.sleep()
[06:02] <sbalneav> Hopefully that's a public method I can call :)
[06:02] <nixternal> hehe
[06:03] <nixternal> if not, would be nothing more than a simple class with a default constructor, destructor, and mutators really :)
[06:03] <nixternal> heck, even a namespace would suffice
[06:04] <LaserJock> I'm sure it'd be easy in python ;-)
[06:06] <nixternal> or perl, or bash :)
[06:06] <sbalneav> #!/bin/sh
[06:06] <sbalneav> while nixternal; do
[06:06] <sbalneav>    sleep;
[06:06] <sbalneav> done
[06:06] <nixternal> hehe
[06:06] <nixternal> there you go
[06:06] <nixternal> doesn't get any easier
[06:07] <nixternal> but can you do sleep w/o any input?
[06:07] <nixternal> sleep 8hrs;
[06:07] <nixternal> ;)
[06:33] <ogra> sorry for the noise
[06:40] <LaserJock> nighty night Ollie
[08:38] <a5benwillis> does anyone know if I can boot up a defaultinstall of edubuntu and haveanother dhcp server send the client to boot from the edubuntu server?
[08:46] <vonce8> I need a way to create a large number of users with a standard home folder, theme, and account permissions. I know how to copy a home folder and change the ownership, however I still would need to set the user permissions by hand for each person though the users and accounts tool. Is there a way I can create many accounts (500+) all at once with identical profiles?
[08:46] <sbalneav> a5benwillis: yep, you can do that.
[08:47] <sbalneav> vonce8: shell scripting can be your friend here.
[08:48] <a5benwillis> sbalneav: thanks, figuredit out :-)
[08:48] <a5benwillis> trying fiesty for the firsttime now
[08:51] <vonce8> sbalneav: the problem is though, with the terminal (add user) you dont have as much control over user permissions. aka: ability to use external device
[08:51] <a5benwillis> how can I change the wallpaper that the clients see?
[08:51] <a5benwillis> looking in the wiki but havent found anything
[08:52] <sbalneav> vonce8: Just use the addgroup command to add them to the fuse group
[08:53] <sbalneav> a5benwillis: You could use the gconftool to set the /desktop/gnome/background/picture_filename key to whatever you want.
[08:54] <sbalneav> You've got 3 levels of gconf
[08:54] <a5benwillis> will that effect all users logging into the the ltsp?
[08:54] <sbalneav> depends on how you set it up.
[08:55] <sbalneav> if you set it up as a manditory key, it will affect everyone, and they won't be able to change it.
[08:55] <sbalneav> If you set it up as a default key, new users will get it as the default, but can change it.
[08:55] <a5benwillis> sbalneav: Ok, Im lookig for info on gconftool now
[08:55] <sbalneav> existing users will be left aline.
[08:58] <sbalneav> a5benwillis:  gconftool-2's the program you want to use
[09:00] <LaserJock> vonce8: yeah, the key is just knowing what group the little description in the GUI tool is talking about then you can do it from a script
[09:04] <a5benwillis> sbalneav: Ok, I set the key to the other wallpaper and logged in as a new user but they still have the old wallpaper?
[09:04] <a5benwillis> should this be ran from a client session or the server console?
[09:05] <sbalneav> Well, you'll want to run it as root, and either make it default, or mandatory
[09:07] <vonce8> LaserJock: I don't understand what you mean. I think my real problem for using shell scripting is that from the terminal doesn't have the options for user privileges. I'm sure it exists somewhere but how do I change permissions like the ability to use/not user flash drives or scanners from the terminal?
[09:08] <sbalneav> gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string  --set /desktop/gnome/background/picture_filename /usr/share/pixmaps/wallpaper/desktop.png
[09:08] <sbalneav> substitude /usr/share/pixmaps/wallpaper/desktop.png for the one you want
[09:08] <a5benwillis> wow
[09:08] <a5benwillis> thats diferent from what I ran for sure.
[09:09] <LaserJock> vonce8: that exists from the command line
[09:10] <sbalneav> vonce8: In ubuntu, you add/remove those permissions by adding/removing users from the proper groups.
[09:10] <LaserJock> vonce8: you just have to know what group in /etc/groups controls that "feature"
[09:10] <sbalneav> So, to use localdevs, the user must be in the "fuse" group
[09:10] <sbalneav> To use a scanner, they must be in the "scanner" group, etc.
[09:11] <a5benwillis> sbalneav: worked perfectly. Thanks!
[09:11] <a5benwillis> I need to find a wiki on that tool. it wouldbenice to know all of the things that it can change etc.
[09:12] <sbalneav> a5benwillis: google for "Gnome administrators guide"
[09:12] <sbalneav> http://www.gnome.org/learn/admin-guide/latest/
[09:13] <vonce8> Ok - but wouldn't that also enable file sharing between the users? This solution would be for 500+ students- I cant have them sharing files.
[09:14] <LaserJock> hmm, I don't know exactly
[09:15] <LaserJock> I'm very certain though that the GUI tool doesn't do anything fancy
[09:15] <LaserJock> it just puts users into groups
[09:15] <LaserJock> which you can do from a script just as well
[09:17] <sbalneav> vonce8: define "file sharing".  As in, having a common area they can swap files back and forth in, or file sharing as in bittorrent, emule, etc?
[09:20] <vonce8> sorry - i wasn't clear: I don't want them to be able to communicate at all though the network. Common area, messaging, etc. I can hide bittorrent or make it unusable, but my real issue is students being able to see eachother over the network. On the windows network we already have (hopefully had), students were using netsend. I fear that if the students were in a common group, they would be...
[09:20] <vonce8> ...able to use services like that. Am i dillusional or is that an inherent feature of groups.
[09:23] <LaserJock> vonce8: well, that can be dealt with, but it's really a separate issue
[09:29] <a5benwillis> sbalneav: Does a guide exist for administering the edubuntu server? I need to learn how to uninstall-install applications to the client filesystem and learn how to lock things down etc...
[09:30] <a5benwillis> .
[09:31] <a5benwillis> I know how to install software in ubuntu but doesnt something else have to be done for it to show up on the clients?
[09:33] <vonce8> I'm not going to waist everyones time asking questions of "how" which I can research myself, but this "separate issue" - i'm not trying to limit everyone's freedom on the network over here, but a directory of which all students of the fuse group or scanner group could access with read-write-exicute permissions would be an issue. netsend is trivial and as long as no ip address threatens to...
[09:33] <vonce8> ...kill another one over the network i'm ok with it. I just cant have a public directory with a file posted by a 9th grader containing the answers from a period one test which all students of the "9th grade" group can access before test time. If I dont create any directories for certain groups will they be made automatically?
[09:34] <LaserJock> vonce8: makes sense
[09:34] <LaserJock> but you do need to be in common groups to make things work
[09:35] <LaserJock> like people need to be in the fuse group do access things they do need
[09:38] <sperotek> hmm, i'm curious now...so is adding "student" to the fuse group the same as enabling access to fuse filesystems in the user priviledges teh saem thing?
[09:39] <sbalneav> vonce8: You'll never get around that.
[09:40] <sperotek> if it is that would really help me...
[09:40] <sbalneav> the /tmp directory is, by definition, accessible by everyone.
[09:41] <sbalneav> sperotek: yes it is
[09:42] <sperotek> when you enable the priviledge, that doesn't add you to the group though, does it?
[09:42] <sbalneav> yes it does
[09:42] <vonce8> can i set the tmp as hidden without any ramifications? (if someone accesses it though the terminal then good for them)
[09:43] <cbx33> hey sbalneav
[09:47] <sperotek> vonce8, if we can hide the temp folder that would be perfect
[09:47] <sperotek> I completely missed how we could share files like that
[09:48] <vonce8> hey check it out - the test answers ! lol
[09:49] <sperotek> it says owned by root, so how can we still write stuff to it
[09:49] <sperotek> there must be some way to deny people from making new files on it like I just did
[09:53] <LaserJock> you don't want to prevent access to /tmp
[09:53] <LaserJock> that would led to bad things
[09:54] <vonce8> makes sense - but can we just hide it without leading to any bad things?
[09:54] <LaserJock> kinda
[09:57] <sbalneav> hey cbx33
[10:00] <ctkroeker> anyone else have trouble with thin clients not displaying panels right in gnome, not rebooting, firefox saying its already running, etc.?
[10:03] <sperotek> are you using the same account on multiple clients?
[10:03] <sperotek> at the same time, ctkroeker
[10:03] <ctkroeker> not at the same time
[10:04] <ctkroeker> i did a fresh reinstall acouple of days ago
[10:04] <sperotek> I have the firefox problem when i am logged in to two places
[10:04] <ctkroeker> well this also says a panel is running, etc. and the only fix is rebooting the server
[10:05] <sperotek> I have firefox running on my admin account on the server, and then I try to use firefox on a client with my admin account
[10:06] <ctkroeker> dont do that. have separate accounts, usually only 2 or three seperate ones running at the same time
[10:07] <ctkroeker> I gues I can set up a crontab too reboot the server every couple of days, should be a temporary fix till gutsy comes out which will hopefully fix a bunch of issues
[10:10] <vonce8> ctkroneker "Firefox is already running, but is not responding. To open a new window, you first must close the existing firefox process, or restart your system." ???
[10:10] <vonce8> is that what you get?
[10:12] <ctkroeker> exatly
[10:12] <ctkroeker> although this only happens if the server has been on for quite a while and there have been multiple log/ins/offs
[10:12] <vonce8> if you go to the thin client manager see if there are multiple logins of the same user account
[10:13] <sperotek> yeah there must be a problem with service/programs not ending correctly
[10:13] <ctkroeker> at the moment I have 2 separte users logged in, but no probs
[10:14] <ctkroeker> I mean, this happens not even every week
[10:15] <ctkroeker> How do I view the clients from the thin client manager with vnc? already install x11vnc in the ltsp chroot
[10:18] <vonce8> A better solution than an automatic reboot might be to automatically log someone out if they have been logged in for more than x days, but that's going into an area that I dont know a lot about.
[10:22] <LaserJock> nano*sensors
[10:22] <LaserJock> awesome ;-)
[11:13] <Athanasius> would someone be willing to help me to set the DHCP on edubuntu?


[10:36] <patrick_> hi i am looking for some help configuring my microphone and headphones on my laptop that is running ubuntu 6.10
[10:36] <patrick_> is this the right place?
[10:36] <patrick_> if not, can someone tell me what channel i might be able to get some help?
[10:47] <Nailor> This isn't a help channel, but shoot, I'll try to help you =)
[10:52] <patrick_> hi nailor, i have a laptop that has built in speakers and mic, as well as jacks on the front for headphones and mic. only the main speakers work
[10:52] <patrick_> trying to get mic to work
[10:53] <Nailor> built in mic?
[10:54] <Nailor> Use alsamixer (or some similiar program, like gnome volume controls) to check, that the capture is on for the mic
[10:54] <patrick_> yep
[10:54] <patrick_> thats the problem... limited options and dont allow for mic..
[10:54] <Nailor> What have you tried?
[10:55] <Nailor> the software, i mean
[10:55] <patrick_> alsa drivers
[10:55] <patrick_> and trying to find answers on ubuntu so trying everything i can find. still pretty new to linux
[10:56] <Nailor> Well. Run alsamixer in terminal (type in 'alsamixer' without quotes and hit return)
[10:56] <Nailor> You should get screen with bars for master, pcm, mic etc.
[10:57] <patrick_> yep, i just get master, pcm and capture
[10:57] <patrick_> the mic on capture is unmuted and turned up
[10:57] <patrick_> if i boot the computer with the jacks i, i get a couple more options in alsamixer
[10:58] <patrick_> but shouldnt the options refer to the plugs themselves and not the jacks?
[10:59] <Nailor> Yup
[10:59] <Nailor> On capture page, is there a Capture-slider?
[11:00] <patrick_> there is a slider for the speaker and mic
[11:00] <patrick_> they are both full
[11:02] <Nailor> You're on capture page, so that in the View:-part in upper left corner Capture is hilighted?
[11:02] <patrick_> yep
[11:03] <Nailor> Funny, I wonder why there's a slider for speaker
[11:03] <Nailor> Mic has the "capture" text underneath the bar?
[11:03] <patrick_> yeah i dont know either. seems that a few people have the same issue i have from what i have seen on the net, but noone knows how to fix it
[11:03] <Nailor> Oh
[11:04] <patrick_> what do you mean?
[11:04] <patrick_> i have two tabs
[11:04] <patrick_> playback and capture
[11:04] <Nailor> Yeah
[11:04] <patrick_> on the playback one i have master and pcm
[11:04] <Nailor> And on capture-tab, you have sliders for mic?
[11:04] <patrick_> on the capture i have "capture"
[11:04] <patrick_> there is a dual slider
[11:04] <Nailor> No mic there?
[11:05] <patrick_> with a pic of a speaker on the left bar, and a pic of a mic on the right bar
[11:05] <Nailor> Oh, you're using the gnome volume control?
[11:05] <patrick_> yeah, alsa mixer is exactly the same though.. hold on, will load that now
[11:06] <patrick_> ok, using alsamixer
[11:06] <patrick_> yeah in capture it says capture under the bar
[11:06] <Nailor> But there's no mic in the capture tab of alsamixer?
[11:06] <patrick_> nope
[11:06] <Nailor> Oh.
[11:07] <Nailor> Seems like it doesn't recognize your mic =(
[11:07] <Nailor> What laptop you got?
[11:07] <patrick_> compaq v3118au
[11:07] <patrick_> posted on a few places as ozPATT
[11:07] <patrick_> on the web
[11:07] <patrick_> but noone knows
[11:08] <Nailor> Well, can't really say what kind of magic is preventing the mic to show up
[11:08] <patrick_> ok, well thanks for trying though
[06:18] <xota> hello!
[06:18] <xota> i have a problem with my dv2031
[06:18] <xota> no audio when I connect headphones
[06:19] <xota> anybody can help me?


[12:23] <petan> hi is there any problem with package uploading?
[12:23] <petan> I uploaded 1 like 10 minutes ago and no response anywhere
[12:27] <wgrant> petan: Which package?
[12:28] <wgrant> Ah, I see it.
[12:28] <wgrant> petan: The key you signed it with isn't registered with your Launchpad account.
[12:32] <petan> oh, you are correct I am an idiot...
[16:08] <Fly-Man-> What is the average time it takes the code puller to wake up and start pulling code ?
[16:11] <cjwatson> For a branch pushed directly to LP, or for some kind of import?
[16:19] <Fly-Man-> import
[16:19] <Fly-Man-> Ahh, it went through ..


[05:25] <Mirv> ScottK: my best estimate would be in 2.5 weeks from now, with the new 5.2.1 fixing some remaining issues and QA team coming up to speed in testing with 5.2.1 appearing in PPA soon. there'll be a bit of new extra work also because mkspecs location changed in Debian recently and that wasn't reflected in our packaging before now.
[05:59] <Noskcaj> Can someone please upload lp:~noskcaj/+junk/gnome-weather to trusty? debian won't upload it in time and ubuntu-gnome needs it
[06:00] <Noskcaj> oops, lp:~noskcaj/+junk/gnome-photos actually
[06:05] <RAOF> pitti: Yo!
[06:39] <pitti> Good morning
[06:39] <pitti> RAOF: hey
[06:39] <RAOF> pitti: Good morning!
[06:40] <RAOF> I've got two questions - how soon will those umockdev commits land in trusty, and how would you like the load_ioctl(testbed, NULL, "foo.ioctl") thing implemented?
[06:41] <RAOF> Hm. But first I apparently need to get some mushrooms, so I'll ping you again later :)
[06:46] <pitti> RAOF: if you want those commits, I'll do a microrelease/upload today
[06:50] <pitti> RAOF: ioctl_record_open() needs to write $UMOCKDEV_IOCTL_RECORD_DEV (major/minor) as the first line into the .ioctl file; or if that's impractical/ugly, umockdev-record needs to pass the original device name in addition (perhaps UMOCKDEV_IOCTL_RECORD_DEVNAME)
[06:52] <pitti> RAOF: then ioctl_tree_new_from_text() needs to be able to load that
[06:52] <pitti> RAOF: perhaps "@DEV /dev/...." (@ to make it an invalid ioctl name)
[06:55] <pitti> RAOF: hm, actually evaluating it in ioctl_tree_new_from_text() is a bit impractical, as you'd need to pass it upwards and back in time
[06:56] <pitti> RAOF: so I guess ioctl_tree_new_from_text() should just ignore it, and load_ioctl() itself needs to open it once, read the first lines, and evaluate the @ commands
[06:56] <pitti> RAOF: you need to make "string dev" to "string? dev", check it for null, and if it is, open the file, read the devname, and use that instead of "dev"
[06:57] <RAOF> pitti: Ah, good. That was roughly what I was thinking, except using # instead of @.
[06:57] <pitti> RAOF: # is an usual comment character, though
[06:57] <pitti> RAOF: we support # in .script files; not sure that it already does in .ioctl files, but it should
[06:58] <pitti> (particularly when you hand-edit them)
[06:58] <RAOF> Right; I was going to have ioctl_record_open write something like "# originally recorded from: /dev/baz"; “@ DEV /dev/...” seems better, though.
[06:59] <RAOF> pitti: So, I notice that ioctl_record_open supports appending to existing .ioctl files. How would you want that handled?
[07:00] <pitti> RAOF: right, if the file already has non-zero length you shouldn't write it again
[07:00] <pitti> syntactically it should be ok (ioctl_tree_* should just ignore @DEV entirely), but it would look confusing
[07:00] <RAOF> Or we could support loading for multiple things, with a little bit of extra effort in umockdev.vala
[07:01] <RAOF> If you don't think loading for multiple things is likely to be valuable (it's not something I want at the moment), just suppressing it for non-zero file lengths is fine.
[07:01] <pitti> hm, I wouldn't want to stuff traces from multiple different devices into one .ioctl file TBH
[07:01] <pitti> the format and its traversing is complicated enough as it is
[07:01] <RAOF> Sweet.
[07:02] <RAOF> So, should umockdev-record error out if it tries to append something from a different device node?
[07:02] <pitti> there should be an assertion
[07:02] <pitti> it Should Not Happen™, so it doesn't need to be a fancy error message
[07:02] <pitti> oh wait
[07:03] <pitti> if one umockdev-record sessio opens the device multiple times, it can't happen
[07:03] <pitti> but you can record into the same file multiple times, indeed
[07:03] <pitti> RAOF: so yes, then umockdev-record should error out
[07:03] <RAOF> Good.
[07:03] <pitti> if we want to support that at some point, we can do that without breaking compatibility
[07:04] <RAOF> Indeed. It wouldn't be _super_ hard to do (read in the file in umockdev.vala, split it out into the apropriate ioctl files), but I don't know if it's _useful_ :)
[07:05] <pitti> *nod*
[07:05] <pitti> RAOF: yeah, I'm more concerned about user confusion than implementation
[07:21] <pitti> mlankhorst: tested ppa7, I followed up to bug 1278737
[08:33] <mlankhorst> pitti: well it seems that multi-arch: no is required on newer ubuntu, but precise used multi-arch: none..
[08:34] <mlankhorst> I'll just skip that field altogether
[08:34] <pitti> if it's not there, it should be similar to M-A: same, right?
[08:35] <mlankhorst> no it skips to multi-arch: none I guess
[08:35] <mlankhorst> which is what's needed
[08:41] <dholbach> good morning
[09:15] <mlankhorst> pitti: yeah I fixed m-a none, can you still hit the geode issue?
[09:16]  * pitti boots the precise live system
[09:25] <pitti> mlankhorst: confirmed, no held back packages any more; great!
[09:26] <mlankhorst> good
[09:26] <pitti> mlankhorst: want to upload? I can do the NEWing, and then re-run the full upgrade tests
[09:26] <mlankhorst> I can't upload, tjaalton? :P
[09:27] <tjaalton> push it to git
[09:27] <pitti> mlankhorst: I can sponsor it, if you want
[09:27] <pitti> mlankhorst: (with dropping the ~ppa suffix)
[09:27] <tjaalton> hm can't use git since it had the merge from debian already staged
[09:28] <pitti> it's a new source package
[09:28] <tjaalton> ah
[09:28] <tjaalton> ok then :)
[09:28] <pitti> and it'll get removed in trusty+1 again
[09:28] <mlankhorst> https://mblankhorst.nl/etc/ xorg-lts-transitional*
[09:28] <pitti> so probably not worth the trouble
[09:28] <tjaalton> I thought it was xorg source modified
[09:28] <tjaalton> sure
[09:28] <mlankhorst> tjaalton: no way I want to have this hit version control
[09:28] <mlankhorst> :P
[09:28] <tjaalton> hehehe
[09:28] <tjaalton> no complaints there
[09:30] <mlankhorst> pitti: at one point you need to upgrade and confirm whether /usr/lib/xorg/protocol.txt still exists
[09:31] <pitti> mlankhorst: *nod*; is its existance enough, or should we assert some contents?
[09:31] <pitti> mlankhorst: I can add that as a post-upgrade test
[09:31] <mlankhorst> no, existence is enough
[09:32] <pitti> mlankhorst: and protocol-{precise,*}.txt should not exist any more?
[09:32] <mlankhorst> I'm also curious about "update-alternatives --config x86_64-linux-gnu_gl_conf" after upgrade
[09:32] <mlankhorst> pitti: just protocol-precise.txt that exists
[09:32] <mlankhorst> it's overridden by xserver-common
[09:32] <pitti> mlankhorst: I mean after the upgrade
[09:32] <mlankhorst> yeah protocol-precise.txt should be gone
[09:32] <pitti> in trusty we certainly don't expect protocol-precise.txt any more, or do you?
[09:33] <mlankhorst> it was a diversion added by xserver-common-lts-w/e
[09:33] <pitti> *nod*
[09:37] <pitti> mlankhorst: hm, no copyright file, I'll add a simple one
[09:37] <mlankhorst> 'not eligible for copyright' really!
[09:37] <mlankhorst> there are no contents either! :-)
[09:39] <seb128> slangasek, infinity, cjwatson: does any of you have a strong objection to restrict the list of archs for firefox to amd64/armhf/i386? (same as chromium) It fails to build on arm64/ppc/ppc64 and noboby seems to have available slots to work on those issues, meanwhile that blocks migration to trusty and means we are 3 versions behind (we never had a version built on the trusty toolchain yet)
[09:39] <seb128> chrisccoulson, ^
[09:41] <doko> seb128, there are patches for arm64, which were once overwritten by chrisccoulson
[09:41] <seb128> doko, those patches were not upstreamed and we don't have the resources to distro maintain them and rebase on new versions by ourself
[09:41] <doko> jamespage, 1268915 is still incomplete. could you subscribe?
[09:42] <chrisccoulson> indeed, and they only make it build. without a jit compiler for arm64, it would be even more unusable than the current arm build
[09:42] <chrisccoulson> which is already terrible
[09:43] <jamespage> doko: done
[09:44] <chrisccoulson> it looks like ppc actually builds, but then crashes when creating the startup cache. that needs someone with real hardware to debug that really
[09:45] <seb128> not having a porting box for ppc doesn't help there
[09:51] <pitti> @pilot in
[09:58] <seb128> ups, pitti went offroad
[09:59] <seb128> pitti, easy on the piloting ;-)
[09:59]  * seb128 hugs pitti (just saw the ibus-pinyin sync)
[09:59] <pitti> seb128: yeah, sorry about taht; already undid my damage
[09:59] <seb128> no worry
[10:01] <seb128> happyaron filed the libpyzy MIR and mterry already did a first review, good
[10:03] <Guest3895> seb128: hey
[10:03] <happyaron> seb128: hey
[10:03] <seb128> happyaron, hey
[10:04] <seb128> lol, I was looking for you, I even looking in the calendar to see if you were off
[10:04] <happyaron> seb128: shall I subscribe desktop team for libpyzy?
[10:04] <happyaron> :)
[10:04] <seb128> happyaron, "desktop-bugs" is our bugs team
[10:04] <seb128> so yes
[10:04] <seb128> or let me know if you don't the rights to do that
[10:05] <happyaron> seb128: I can't subscribe it on LP, :(
[10:06] <darkxst> pitti, pilot, can you take a look at the gnome-ey stuff in the queue
[10:07] <seb128> darkxst, from #ubuntu-desktop backlog, seems he's already doing
[10:08] <darkxst> seb128, boom :( gdm still restarting ;(
[10:08] <seb128> darkxst, did you try twice?
[10:08] <seb128> darkxst, it's the prerm from the installed version that stops it
[10:09] <pitti> darkxst: I'm at gnome-menus ATM
[10:09] <seb128> darkxst, so when installing the new fixed deb it's going to restart, because of the prerm of the installed version, then it should work
[10:09] <darkxst> seb128, yes, right, it worked second time
[10:11] <Laney> you should sed the prerm of the old one ;-)
[10:11]  * Laney RUNS
[10:11] <darkxst> pitti, there is also lp:~noskcaj/+junk/gnome-photos, I told Noskcaj to file a bug but he didnt ;(
[10:12] <Laney> oh actually I don't think you can
[10:12] <Laney> https://wiki.debian.org/MaintainerScripts?action=AttachFile&do=get&target=upgrade.png
[10:15] <pitti> darkxst: bug 1279201
[10:18] <darkxst> pitti, ah, ok
[10:19] <pitti> darkxst: ah, gnome-photos landed in the NEW queue 23 mins ago
[10:20] <darkxst> yes, I see that now
[10:20] <tjaalton> hum, trusty doesn't seem to recognize win 8.1 at all.. the partitioner says the disk is empty
[10:24] <RAOF> tjaalton: And yet grub finds it just fine!
[10:24] <tjaalton> RAOF: didn't go that far yet, this is still the installer
[10:28] <tjaalton> and I'd like to keep win8.1 there, if only just for civV which just crashes here on wine :)
[10:29] <RAOF> Oh, indeed.
[10:29] <RAOF> You should probably also want to keep XCOM:EW :P
[10:32] <tjaalton> don't have that one, yet anyway :)
[10:34] <cjwatson> seb128: there are a *lot* of rdepends on firefox - for instance packagekit's arch-specific build-depends would need to be tweaked if we were removing firefox/powerpc.  I can see your point but it needs actual thought and hard work following the rdepends stack and thinking about it rather than just restricting the arch set
[10:35] <cjwatson> it's probably tractable, but please make sure that that work is done rather than just left to +1 maint or something
[10:35] <seb128> cjwatson, thanks for pointing that out. What would be the right place to have that discussion? ubuntu-devel@?
[10:35] <cjwatson> Seems reasonable, yeah
[10:39] <seb128> thanks
[10:39] <spineau> doko: hello, could it be possible to move to main the following checkbox dependencies? bug 1277408 and bug 1278822. So that our next upload of checkbox can have all its dep in main
[10:40] <pitti> RAOF: oh, to clarify: (1) do you want to work on the load_ioctl(NULL) thingy, and (2) do you want a release now or wait on (1)?
[10:41] <RAOF> pitti: (1) yes, and (2) yes, please wait.
[10:41] <tseliot> cjwatson: QA caught an issue with Jockey in 12.04.3 (hybrid graphics won't work with the new X stack). I've filed bug #1279229 and uploaded a fix in precise-proposed
[10:42] <pitti> RAOF: ack, thanks
[10:42] <RAOF> pitti: Also - do we get DEP-8 tests run on syncs from Debian? I added some to fsharp, but they don't seem to have been run.
[10:42] <pitti> RAOF: we generally do, yes
[10:42] <Laney> They get missed on the first upload AFAIK
[10:42] <pitti> that was fixed
[10:43] <pitti> RAOF: très interessant, I'll have a look at that later
[10:43] <Laney> Well then, :)
[10:43] <RAOF> Just to check - they should show up on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ if they get run, right?
[10:43] <pitti> correct
[10:43] <pitti> Testsuite: autopkgtest
[10:43] <pitti> that looks fine to me, too
[10:45] <pitti> cjwatson: is https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64/+merge/199972 something you'd rather handle yourself, or should I sponsor this?
[10:46] <cjwatson> I'll take care of it, I did most of the rest of that stuff at the core sprint
[10:46] <pitti> cjwatson: ack
[10:46] <cjwatson> just ran out of time there
[10:47] <pitti> https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64+calxeda-subarches/+merge/199977 as well then, I assume
[10:47] <pitti> (which includes the previous MP)
[10:48] <cjwatson> yeah
[10:49] <seb128> happyaron, desktop-bugs subscribed to libpyzy now
[10:49] <happyaron> seb128: great
[10:56] <tjaalton> my partman bug was already reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731736
[11:08] <tjaalton> huh, why are we still on parted 2.3?
[11:10] <tjaalton> found debian #646130
[11:33] <tseliot> cjwatson: did you get my message?
[11:35] <cjwatson> tseliot: probably best not to rely on just me for all things precise since I need a break from it after 12.04.4, but I'll have a look at this SRU I guess
[11:36] <pitti> mlankhorst: oh, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[11:36] <pitti> mlankhorst: xserver-xorg-video-geode-lts-* mustn't be built on amd64
[11:37] <Laney> bdrung: Is there a way to use ubuntu-distro-info to get the full name (-r) of the current release?
[11:37] <cjwatson> tseliot: ok, looks reasonable
[11:38] <bdrung_work> Laney, current release = the latest stable release?
[11:38] <Laney> bdrung_work: the one you're running it on
[11:39] <pitti> mlankhorst: fixing..
[11:39] <Laney> or maybe going from codename to release would be okay
[11:39] <Laney> trusty → 14.04 LTS for example
[11:39] <cjwatson> tseliot: (accepted)
[11:39] <bdrung_work> Laney, no. distro-info has no info what release you are running on
[11:40] <bdrung_work> currently it does not support a codename -> fullname/release mapping
[11:40] <tseliot> cjwatson: ok, thanks a lot
[11:41] <seb128> bdrung_work, hey, did you get my email about Sweetshark's libroffice's ppu application?
[11:41] <Laney> xnox: ^
[11:41] <Laney> I read that as 'patches welcome'
[11:42] <bdrung_work> seb128, probably. i'll hope to find time to process my mail backlog at the weekend
[11:42] <seb128> bdrung_work, good ... is that application still blocked on anything?
[11:42] <pitti> mlankhorst: http://paste.ubuntu.com/6919521/
[11:43] <xnox> bdrung_work: Laney: thanks.
[11:43] <bdrung_work> seb128, i have to look into the mail and look at the progress of the last month
[11:44] <bdrung_work> xnox, yes, patches are welcome
[11:44] <seb128> bdrung_work, do you think you are going to have slots to do that soon? if not can you delegate to other ppu members?
[11:45] <seb128> bdrung_work, that application is ongoing for ages and we feel like we addressed all the initial concerns, it would be nice to see things moving or have an update on what more should be done
[11:45] <bdrung_work> seb128, i'll try to do it on the weekend. otherwise i have to delegate it.
[11:45] <seb128> thanks
[11:46] <bdrung_work> since i have a job, my free time is heavily reduced
[11:51] <xnox> bdrung_work: may i upload https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1012439 ?
[11:52] <Laney> that's a long week :P
[11:52] <bdrung_work> xnox, you may :)
[11:53] <bdrung_work> i think there was an objection against this patch
[11:53] <denisw> hi
[11:53] <xnox> Laney: like my accidental 6 month holliday?! =)
[11:53] <Laney> accidents happen right
[11:54] <Laney> anyway I heard we know one of the debootstrap maintainers ;-)
[11:54] <denisw> was it a deliberate decision to have the desktop web apps integration use the touch-optimized webbrowser-app in trusty? will that app be made more desktop friendly before the trusty relase?
[11:55] <bdrung_work> xnox, bonus: get the patch into debian
[11:57] <xnox> Laney: debootstrap maintainers? who is that? =)
[11:57] <bdrung_work> http://packages.qa.debian.org/d/debootstrap.html
[12:01] <cjwatson> xnox: please don't diverge debootstrap in Ubuntu, it's hassle
[12:02] <xnox> cjwatson: ok.
[12:03] <cjwatson> xnox: that latest version of the debootstrap patch is probably ok, but if we use it it should be in Debian
[12:03] <cjwatson> (case in point, I just synced debootstrap)
[12:04] <cjwatson> xnox: but hey, you're in the d-i team these days
[12:10] <mardy> cjwatson: hi! I updated https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674
[12:18] <cjwatson> mardy: ack, will look later today, trying to finish something else off
[12:20] <doko> bdmurray, did you find out anything about the php issues?
[12:21] <shadeslayer> so if I run : grep-dctrl -P kde4libs -F Build-Depends /var/lib/apt/lists/es.archive.ubuntu.com_ubuntu_dists_trusty_main_source_Sources   : it seems to give me the entire kde4libs source information, but I explicitly told it to give me the Build Depends field, any ideas what I'm doing wrong?
[12:22] <cjwatson> -F is "search by this field"; if you want "show this field" you need -s instead
[12:23] <shadeslayer> ahh
[12:25] <mlankhorst> pitti: can you make xserver-common* architecture: all ? and I want to point out that you matched with *geode** :P
[12:27] <apachelogger> pitti: any objections to modifying the apport cleanup cronjob to also clean the drkonqi files we create through kdelibs?
[12:28] <pitti> apachelogger: fine for me
[12:38] <doko> jamespage, why did you drop the juju gccgo binaries for x86? are these builds still being tested?
[12:39] <jamespage> doko, not any longer
[12:40] <doko> jamespage, are any gccgo binaries being tested?
[12:40] <jamespage> doko, on ppc64el and arm64 yes
[12:40] <doko> ok
[12:41] <jamespage> doko, oh - and upstream will be checking with gccgo still so we don't regress those platforms
[12:41] <doko> upstream?
[12:41] <jamespage> doko, juju team
[12:41] <doko> ahh
[12:49] <apachelogger> hm
[12:50] <apachelogger> pitti: apport's cron actually excepts whoopsie's .upload*, do you simply leave them around since they are 0byte anyway?
[12:51] <pitti> apachelogger: they are cleaned up after 7 days
[12:51] <pitti> apachelogger: I guess ev did it that way to avoid cleaning up crahses which have an .upload but not an .uploaded yet, or so (but I'm not sure, it woudln't work that way)
[12:52] <apachelogger> mh
[12:52] <apachelogger> pitti: ok, going hold on to that then since the drkonqi stuff is related ^^
[12:53] <pitti> mlankhorst: WDYT? http://paste.ubuntu.com/6919792/
[12:54] <mlankhorst> pitti: looks good!
[12:54] <pitti> uploaded
[12:54] <mlankhorst> maybe that will fix the weird issue
[13:00] <rbasak> tjaalton: just looking at bug 1278898. The server team aren't actively looking after cobbler now, since the MAAS team stopped depending on it. I also note that there's no Debian package for this now. Are you happy to continue caring for the package in universe, or should we drop it?
[13:00] <tjaalton> rbasak: there's a new upstream bugfix release to address that, I'll push that to trusty soon
[13:01] <tjaalton> packaging has been in collab-maint git, but guess there's no itp for it yet
[13:01] <rbasak> Ah, OK. Thanks!
[13:01] <apachelogger> pitti: https://code.launchpad.net/~apachelogger/apport/cleanup-drkonqi-files/+merge/205955
[14:03] <pitti> apachelogger: bah, this is rather hard to read :)
[14:04] <pitti> apachelogger: i. e. this cron job does *not* remove drkonqui files after 7 days, while current apport does?
[14:05] <apachelogger> pitti: what, for me the find returned the drkonqi files with mtime >7days
[14:06] <apachelogger> alas, the find syntax is nigh unparsable to my puny mind
[14:07] <pitti> apachelogger: oh of course, I missed the -o
[14:07] <apachelogger> pitti: ^^
[14:08] <pitti> apachelogger: merged, danke; how soon do you want/need this in trusty?
[14:08] <pitti> (probably not that urgent, right?)
[14:09] <apachelogger> pitti: not urgent
[14:09] <apachelogger> thanks for merging :)
[14:48] <seb128> hum, what's the best way to run checkrdepends nowadays?
[14:48]  * seb128 is reading https://wiki.ubuntu.com/ArchiveAdministration#NBS
[14:49] <pitti> seb128: reverse-depends from ubuntu-dev-tools AFAIK
[14:49] <pitti> it's fast, and reasonably correct
[14:49] <seb128> that needs a local mirror right? do we have an archive admin available box recommended for that?
[14:49] <pitti> no, it reads from LP or UDD or something like that
[14:49] <rbasak> Ah, handy. Thanks!
[14:50] <seb128> pitti, I was speaking about checkrdepends
[14:50] <pitti> a local mirror is an incredibly heavy beast, I doubt that many people have one
[14:50] <pitti> seb128: so was I
[14:50] <seb128>  reverse-depends gnome-control-center-signon-autopilot
[14:50] <seb128> No reverse dependencies found
[14:51] <seb128> pitti, it errors out out on
[14:51] <seb128> IOError: [Errno 2] No such file or directory: '/home/ubuntu-archive/mirror/ubuntu/dists/trusty/main/source/Sources.gz'
[14:51] <seb128> for me
[14:51] <seb128>   -B ARCHIVE_BASE, --archive-base=ARCHIVE_BASE
[14:51] <seb128>                         archive base directory (default: /home/ubuntu-
[14:51] <seb128>                         archive/mirror/ubuntu)
[14:51] <seb128> or is archive base dir /var/lib/apt/lists?
[14:51]  * seb128 tries
[14:51] <pitti> reverse-depends src:gnome-control-center-signon
[14:51] <pitti> you might want that?
[14:52] <pitti> reverse-depends -b src:gnome-control-center-signon
[14:52] <pitti> and that for reverse build deps
[14:52] <pitti> (account-plugins and empathy in that case)
[14:53] <seb128> pitti, seems fine to delete the gnome-control-center-signon and gnome-control-center-signon-autopilot binaries then, right?
[14:53] <seb128> or am I overlooking something
[14:54] <pitti> seb128: gnome-control-center-signon has reverse depends
[14:54] <seb128> pitti, which one?
[14:54] <pitti> seb128: http://paste.ubuntu.com/6920308/
[14:54] <pitti> does that look any different for you?
[14:54] <seb128> pitti, those all have a "unity-control-center-signon | gnome-control-center-signon"
[14:54] <pitti> aah
[14:55] <seb128> if I didn't overlook things
[14:55] <pitti> fine then
[14:59] <seb128> pitti, should we change https://wiki.ubuntu.com/ArchiveAdministration#NBS to recommends using reverse-depends over  "checkrdepends -b"?
[15:00] <pitti> seb128: yes, sounds good; shell login is generally disabled now
[15:00] <seb128> cjwatson, infinity: ^
[15:00] <seb128> pitti, danke
[15:02] <geser> pitti, seb128: reverse-depends queries a webservice on qa.ubuntuwire.org
[15:02] <cjwatson> ok
[15:02] <cjwatson> Let's still keep checkrdepends around though; for those with access to it it has stronger guarantees of being current
[15:03] <seb128> on what box can that be run? pepo?
[15:03] <seb128> (seems I don't have ssh to that one)
[15:03] <cjwatson> ubuntu-archive@snakefruit
[15:04] <seb128> cjwatson, thanks
[15:04] <bdmurray> doko: no, not yet
[15:12] <doko> pitti, does dbus in trusty diverge that much from unstable? https://launchpadlibrarian.net/164705202/buildlog_ubuntu-trusty-i386.python-notify2_0.3-2_FAILEDTOBUILD.txt.gz
[15:12] <seb128> doko, ** (notification-daemon:2593): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
[15:12] <seb128> doko, seems like you are missing a depends on at-spi or something
[15:13] <seb128> or at-spi2-core rather to be exact
[15:13] <doko> seb128, it did build before ...
[15:15] <pitti> doko: it's not dbus itself, something in gtk/whatever now requires at-spi2-core
[15:15] <mitya57> I think rather notification-daemon should depend on that
[15:16] <pitti> mitya57: agreed
[15:16] <seb128> speaking of notification-daemon, if anyone still uses it/cares about it, it needs to be fixed for incorrect g_source_remove use
[15:17] <seb128> that's an issue with new glib and is ranked high enough on the trusty reports
[15:17] <seb128> on e.u.c
[15:17] <mitya57> Hm, no, neither notification-daemon nor python-notify2 reference a11y in the code
[15:18] <pitti> I've seen this quite often recently
[15:18] <pitti> my suspicion is that it's something in GTK, and that gtk itself should depend on it
[15:19] <seb128> pitti, libgail-3-0 depends on at-spi2-core
[15:20]  * seb128 doesn't understand the a11y stack enough to figure what's the right thing to do there
[15:20] <seb128> I though libgail was needed for a11y?
[15:20] <pitti> that build log doesn't install gail, though
[15:20] <seb128> pitti, https://launchpad.net/ubuntu/+source/gtk+3.0/3.5.8-0ubuntu1
[15:21] <seb128> that's where it got added
[15:21] <seb128> I think GTK upstream has been working on dropping gail and moving a11y directly in gtk
[15:22] <seb128> so yeah, maybe having libgtk-3-0 depending on it would make sense
[15:22] <seb128> would be useful to get a bt of those warnings
[15:22] <seb128> to see what is the caller
[15:25] <pitti> G_DEBUG=fatal-warnings?
[15:26] <mitya57> G_DEBUG=fatal_warnings (with underscore)
[15:26] <mitya57> or maybe dbus-monitor
[15:27] <seb128> thanks guys, I know how to get one
[15:27] <seb128> I'm just dealing with 5 stuff already so I was hinting in case somebody has the setup to trigger the warning
[15:27] <seb128> I can try in a bit otherwise
[15:27] <seb128> ;-)
[15:28]  * seb128 usually do "b g_log" instead
[15:28] <seb128> so you can go pass the first warning
[15:28]  * mitya57 is in battle with mathjax packaging, so not now
[15:30] <dobey> cjwatson: can we install a hook or something from the click scope, that gets run whenever a click package is installed (like a dpkg trigger but for click)?
[15:31] <cjwatson> click packages can attach to hooks; there's no way to write a hook that will run for *any* click package installation right now
[15:31] <cjwatson> that's possible, would need to be specced with some thought
[15:32] <dobey> cjwatson: oh ok. i was just thinking that it would be nice for the click scope to be refreshed when i adb shell and install a click package that way (or do it from qtcreator or whatever)
[15:32] <cjwatson> I suppose the simplest way would be to make the Pattern field (https://click.readthedocs.org/en/latest/hooks.html) optional, in which case no symlink would be created and we'd just run whatever Exec says
[15:33] <cjwatson> would that work for you?
[15:34] <cjwatson> (if so, please file a bug, I'm not going to get to it this week)
[15:34] <dobey> i'm not sure, but probably.
[15:34] <dobey> right, we're in a bit of rush on scope development right now as well. so if we can't do it right now, it'll have to wait a bit anyway
[15:35] <dobey> but i'll read the hooks doc and let you know
[15:36] <cjwatson> well.  I could maybe do it on Thu/Fri if it's a simple enough approach, but it'd be my first proper release under the ci train stuff so I can't guarantee it
[15:45] <dobey> cjwatson: yeah, no worries. i don't want to block the scope work on it so we're going to have to do the results invalidation call a different way for now. but i'll see if your suggestion makes sense (or if i think of something better while reading the docs), and file a bug
[15:51] <caribou> pitti: I see that you have merged my clamav MP, though I thought it was still waiting for a fix
[15:51] <caribou> pitti: I just updated the MP with a potential modification
[15:52] <pitti> caribou: I posted the modification I did to the MP and to the bug
[15:53] <caribou> pitti: yeah, just seeing the emails
[15:53] <caribou> pitti: my suggestion was to replace the [[:space:]] with \b as the reasoning behind that is to be able to discriminate on word boundary
[15:54] <pitti> caribou: \b looks fine as well, but [[:space:]] should work equally well
[15:54] <caribou> pitti: I do think so. So let keep it as it is then
[15:54] <pitti> after all, you could potentially have a variable Logfile-Destination /dev/null
[15:54] <pitti> and \b would match after LogFile
[15:54] <pitti> (perhaps)
[15:54] <caribou> pitti: I'll fix the debdiffs in the bug
[15:54] <pitti> I mean, I don't know whether clamav allows that
[15:55] <pitti> but [[:space:]] seems fine
[15:55] <caribou> pitti: dunno. I'll open a bug on this on Debian
[15:55] <pitti> caribou: thanks, appreciated
[15:55] <caribou> pitti: thanks for the merge, I'll get the SRU fixed
[15:56] <pitti> caribou: I already fixed the precise SRU
[15:56] <caribou> pitti: ah, ok then I won't bother
[15:56] <caribou> pitti: such a small fix
[15:56] <psusi> how can I get an rdepends on udebs?  possibly using the package cache within a d-i build tree?
[15:57] <caribou> pitti: btw, I had the same issue with UDD and the time it took to check it out
[15:57] <roadmr> Hello! My source package stopped building some now-deprecated binaries, so the new upload is in -proposed with a series of "out-of-date" on the deprecated binaries. How can I fix this? do the old binaries need to be removed?
[15:58] <seb128> roadmr, you need an archive admin to delete the NBS binaries I think
[15:59] <stgraber> roadmr: what source package is that and what binaries did you drop?
[15:59] <psusi> ahh, figured it out...
[16:01] <roadmr> stgraber: source: checkbox, dropped binaries: checkbox-gtk, checkbox-urwid
[16:01] <stgraber> roadmr: ok, taking a look now
[16:01] <cjwatson> FWIW this only happens if the binaries were dropped in a subsequent upload when there was already an unmigrated upload in -proposed
[16:01] <cjwatson> it's a corner case due to -proposed being a partial suite
[16:02] <roadmr> stgraber: also, my source package was building python3-checkbox-support which exists only in -proposed, but that overlaps the same package (version 0.1 I think) from debian. I fixed this but I guess the stale binary stayed in proposed and is also considered out-of-date
[16:02] <psusi> wait... maybe not... those are non udeb rdepends somehow...
[16:02] <stgraber> roadmr: you actually have a bigger problem, you regressed architecture support
[16:02] <pitti> @pilot out
[16:02] <stgraber> roadmr: checkbox used to build on all architectures, now it fails on arm64, powerpc and ppc64el
[16:03] <roadmr> stgraber: I saw it failing due to lack of some qt5-sensors dependency, but it's not actually needed, my latest upload should have fixed that. I can double-check that too
[16:04] <stgraber> roadmr: I'm looking at https://launchpad.net/ubuntu/+source/checkbox/0.17.4ubuntu3
[16:05] <roadmr> stgraber: oh, I removed the qtsensors5-dev dep but now it's stuck on qtmultimedia5-dev
[16:06] <stgraber> roadmr: so I resolved the pytohn3-checkbox-support bit for now, I'll let you upload something which fixes those 3 arches then we can see what britney thinks about migrating those
[16:06] <stgraber> cjwatson: right, python3-checkbox-support was in that case (introduced in ubuntu2, dropped in ubuntu3, never migrated)
[16:07] <roadmr> stgraber: cool, thanks so much! I'll fix that asap
[16:15] <alow> infinity: Would like to chat about PPC64el and libv8
[16:17] <infinity> alow: Perhaps when I'm out of this current meeting/call.
[16:17] <infinity> alow: I meant to follow up to your email, but I've been headless chickening the last day or two.
[16:18] <alow> infinity: no problem. I've been hacking away to create minimal diffs between the v8 levels. I've created a unique branch for libv8 https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[16:19] <infinity> alow: Awesome.  And, as an added bonus (not a requirement, but a bonus), I understand this works on big-endian as well?
[16:19] <alow> infinity: It should - I haven't tested that specifically. I'd be happy to hit both BE / LE
[16:20] <alow> infinity: I'm off on vacation soon for a bit, so it'd be good to get this working for others soon
[16:20] <infinity> alow: Righto.  I will probably end up testing on ppc32be by accident, since that's my primary development workstation in my house. :P
[16:20] <infinity> alow: I'll try to find some time to poke at it today, after I throw some time at glibc stuff this morning.
[16:21] <alow> so my repo https://github.com/andrewlow/v8ppc/tree/libv8-3.14 doesn't include the debian/ directory in it (yet) - would that be preferred?
[16:21] <infinity> alow: No, no.  A simple branch of upstream is much easier to work with, importing debian directories and spec files tends to end in tears when they diverge from the distros anyway.
[16:22] <alow> infinity: oh good. so.. from here http://packages.ubuntu.com/source/trusty/libv8-3.14 I took the repository git://anonscm.debian.org/collab-maint/libv8.git and used that as a comparison base for  https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[16:23] <alow> when I mix in a slightly hacked debian directory to support ppc64el -- I get .deb files out the other side
[16:23] <infinity> A positive result. ;)
[16:24] <infinity> Does it run a testsuite at build time?  I haven't looked at v8 packaging.
[16:24] <alow> infinity: one caveat - I don't understand how the debian/patches directory gets applied. So I run the makefile / gyp patch manually
[16:24] <alow> infinity: yes - testsuite gets run
[16:25] <alow> infinity: >>> Running tests for ppc64.release
[16:25] <alow> Converting status file.
[16:25] <alow> Converting status file.
[16:25] <alow> Converting status file.
[16:26] <alow> No connection to distribution server; running tests locally.
[16:26] <alow> [01:28|% 100|+ 6093|-   0]: Done
[16:26] <infinity> alow: Kay, cool.  As for patches, that depends on the source format, but if it's 3.0(quilt), the patches are applied at source unpack by dpkg.
[16:26] <infinity> alow: Based on the debian/patches/series file.
[16:27] <alow> infinity: Ok - I'm not sure I've setup things correctly in my builds then. I'll poke at that. I start with the source tree in place and use 'fakeroot debian/rules binary' to build
[16:27] <alow> infinity: but I'm fairly confident my code in the repo is suitable for the build at this point
[16:28] <alow> infinity: patches may not all apply clean - I'll try to validate that
[16:29] <infinity> alow: Kay.  Will you be around in ~30m, when I'm not multitasking too much here? :)
[16:29] <pitti> mlankhorst: success!
[16:29] <alow> infinity: yes
[16:30] <pitti> mlankhorst: I'll add the protocol.txt post-upgrade test tomorrow; we don't keep around the container after upgrade, so I can't check right now
[16:33] <pitti> mlankhorst: I filed bug 1279411 as a reminder, does that sound right?
[16:33] <mlankhorst> pitti: thanks
[16:46] <infinity> alow: Alright, grabbing the Debian source and cloning your git repo and having a morning smoke.  I'll be with you shortly. :P
[16:46] <alow> infinity: cool - I'm around
[16:49] <pitti> mlankhorst: http://bazaar.launchpad.net/~auto-upgrade-testing-dev/auto-upgrade-testing/trunk/revision/90 (tested locally)
[16:50] <infinity> Gah, only 250KB/s from github?  Internets, why do you hate me this morning?
[16:51] <pitti> mlankhorst: rolled out, I'll check the results tomorrow
[16:59] <pitti> mlankhorst: you are right: http://d-jenkins.ubuntu-ci:8080/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/13/artifact/results/bootstrap.log
[16:59] <pitti> - ['/usr/lib/xorg/protocol-precise.txt', '/usr/lib/xorg/protocol.txt']
[16:59] <pitti> mlankhorst: that's what's left after the lts-raring → trusty upgrade
[17:00] <pitti> mlankhorst: so the diversions should be cleaned up
[17:02] <pitti> mlankhorst: I filed bug 1279424
[17:03] <pitti> jibel: ^ FYI (in case you wonder why green tests go back to yellow)
[17:03] <jibel> pitti, thanks for adding new tests. I'm pretty sure you can find tests that will make it red :)
[17:05] <pitti> at most yellow, I hope
[17:08] <tester56> will vlc 2.2 land in trusty?
[17:10] <Logan_> tester56: does it even have an ETA?
[17:13] <tester56> Logan: oh damn ... I do not know, sorry for that. As I have it running here, I supposed it was released already, my mistake sorry for the inconvenience. It has been in development for quite some time now if I am not mistaken
[17:13] <Logan_> haha, no need to apologize
[17:13] <Logan_> if it lands before Feature Freeze, we can likely maneuver it into trusty, but I'd rather go with Debian's releases
[17:14] <Logan_> and Feature Freeze is in eight days, so it doesn't look like that'll be happening :P
[17:15] <Logan_> unless there's a good reason to merge it in
[17:21] <cjwatson> Coo, ci.debian.net exists
[17:21] <cjwatson> Just noticed it from my qa.debian.org/developer.php page
[17:28] <roadmr> stgraber: We introduced a few new build-deps (and dependencies) for checkbox, and some aren't available for those archs (arm64 and ppc). That's where my arch support regression comes from.
[17:29] <stgraber> roadmr: does checkbox absolutely need those or could you have ti build on those arches without those build-deps?
[17:29] <stgraber> roadmr: (making those arch-specific build-deps and deps and have checkbox do the right thing at build time)
[17:30] <mpt> bdmurray, I see the new color for 14.04 is on <https://errors.ubuntu.com/>, but the milestone lines aren’t. Does that mean there’s something wrong with the milestone line code, or is it just that the rollout included the former but not the latter?
[17:30] <roadmr> stgraber: they're actually for a new checkbox-gui binary, maybe we could do what you say and then checkbox-gui would just be unavailable for those archs
[17:32] <mpt> bdmurray, or a simpler way of asking the question: What revision is the current rollout? :)
[17:34] <stgraber> roadmr: I guess that'd be reasonable, yes, make checkbox-gui arch:any and only building on the arches that have those bits, changed your build depends to also be arch-specific and change your build process so that it only attempts to build the GUI bits if those build-deps are present.
[17:34] <bdmurray> mpt: rhe rollout included the milestone colors, so it may be something with the graph code
[17:34] <mpt> ok, thanks
[17:35] <roadmr> stgraber: ok, sounds good, I'll get working on this. Thanks so much for your help and guidance!
[17:36] <stgraber> np
[17:47] <Logan_> does anyone else run trusty in a VirtualBox VM? I'm having screen resize issues with the latest update
[17:49] <Logan_> debfx: ^
[18:01] <seb128> do we have arm64 porter boxes?
[18:01] <seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has
[18:01] <seb128> skipped: gnome-control-center-signon (52 <- 1)
[18:01] <seb128>     * arm64: unity-control-center-signon
[18:01] <seb128> not sure how to debug that
[18:04] <infinity> seb128: It means unity-control-center-signon is uninstallable on arm64...
[18:04] <seb128> infinity, yeah, which would be easier to figure out why if I had access to an arm64 chroot/porter box ;-)
[18:04] <infinity> So, there isn't a porter box right now due to lack of hardware to go around.
[18:05] <seb128> how would you recommend trying to debug that?
[18:05] <infinity> seb128: Check your channel invites. :P
[18:06] <seb128> infinity, and why is unity-control-center-signon being uninstallable blocks migration when it's a new binary and has never been installable?
[18:24] <alow> BenC: infinity pointed me your way in regards to e500 v2 hardware. Today my v8 port doesn't work on e500 https://github.com/andrewlow/v8ppc/issues/100 - I'd like to fix, but need ready access to hardware
[18:25] <BenC> alow: I can get you access to e500mc, but I don't have anything for e500v2 (which, you probably shouldn't care about anyway)
[18:26] <BenC> alow: I can try a build on e500mc and let you know if that works or not...
[18:26] <alow> BenC: I know it won't work - check the data in the github issue I linked
[18:27] <BenC> alow: That data shows e500v2, which is not entirely the same as e500mc, so let me check
[18:27] <alow> BenC: if the basic floating point hasn't changed between e500mc and e500v2 - then either should work
[18:28] <BenC> alow: But it has...e500mc has hardware floating point and e500v2 uses softfloat (or mathemu in the kernel)
[18:28] <alow> BenC: the reason the code doesn't work is that we are generating FPU instructions - and the encoding is entirely different on e500 (mc / v2)
[18:32] <BenC> alow: I've cloned and started a build. In the meantime can you email me<EMAIL_ADDRESS>and I'll get you ssh access to our RPLE server, which is e500mc/P4080 based.
[18:43] <BenC> ACTION tools_gyp_v8_gyp_v8_snapshot_target_run_mksnapshot /home/svy/v8ppc/out/ppc.release/obj.target/v8_snapshot/geni/snapshot.cc
[18:43] <BenC> Illegal instruction
[18:44] <alow> BenC: yes - expected
[18:45] <alow> BenC: if you build with "make ppc snapshot=off" it will complete the build.. but crash on startup when it tries to generate FPU instructions into memory and run them (V8 is a JIT)
[18:45] <BenC> alow: I can give you access to the hardware if you email me an SSH pub key and username
[18:46] <alow> BenC: drat.. just hit send -- will follow up now with key & name
[18:46] <BenC> Ah, thanks
[18:47] <BenC> alow: So the system has chroots. Probably makes no difference which one you use, but we want people to create a schroot env for their builds so we can easily isolate having to install build-deps if needed
[18:47] <BenC> alow: Instructions on how to use the setup is in the motd when you login
[18:47] <alow> k - will be a good citizen in that regard
[19:08] <dobey> kenvandine, robru: is there a way to make friends-service update from twitter more often? also, it seems to never actually pop up notifications on my workstation, but every time i boot my laptop, i get a bunch of notifications from it. :-/
[19:28] <kenvandine> dobey, you can change the interval in gsettings
[19:28] <kenvandine> and there is also a setting for notifications
[19:29] <dobey> kenvandine: yes, notifications is set to "mentions-only"
[19:29] <dobey> kenvandine: which is what i want, but i don't seem to be getting them.
[19:29] <dobey> i do on my laptop though of course
[19:30] <slangasek> seb128: firefox ppc> I have no opinion on this, other than to reiterate that if there are issues with packages on the ports, this needs to be brought to the attention of the porters prior to give them a chance to respond /before/ it becomes a blocking issue for the desktop
[19:42] <seb128> slangasek, hey, how do I brought attention to the porters? trusty has a firefox which is outdated by 3 versions (and outdated compared to security pockets from other series by almost as much)
[19:42] <slangasek> seb128: for powerpc, I would say the first stop is to ping infinity about it :)
[19:43] <seb128> slangasek, it's not like the issue was not visible, it's just that nobody is stepping up to do anything about it, we are past mid-cycle and we got 0 firefox build with the trusty toolchain reaching the release pocket
[19:43] <seb128> infinity, ping :p
[19:43] <seb128> slangasek, done ;-)
[19:44] <seb128> infinity, slangasek: note that firefox "builds", the build fails on a cache generation error after the actual build is done, seeing that the same version works on other series it looks like a toolchain issue (due to the toolchain or to firefox doing wrong thing)
[19:45] <slangasek> seb128: it's visible /to you/ because you're paying attention to the package; build failure reports from launchpad go to the uploader, not to the porters
[19:46] <slangasek> so no, it's not fair to assume that a package build failure is "visible" to the porters unless someone lets them know it's blocking them
[19:46] <seb128> slangasek, right, I'm not especially paying attention, out of the fact that my firefox is outdated by 3 versions
[19:47] <seb128> slangasek, I wish we had a better way to flag such issues :/
[19:48] <infinity> seb128: Right, the toolchain pointer is an interesting hint.  It might be a workable workaround to build with an older GCC on ppc for now, though the actual problem should be hunted down.
[19:49] <infinity> seb128: It might also be an acceptable workaround to drop ffox and its rdeps from PPC for now, but I want to look into the impact of that before I go on a deletion spree.
[19:49] <seb128> infinity, I've said that before, and thanks for stepping up to provide us solution when that happened, but not having a porter box available doesn't help there
[19:49] <seb128> how the heck can we support an arch without having access to one box to debug issues?
[19:49] <infinity> seb128: A porter box is on my Very Soon TODO.  It got pushed back by an externally-imposed ABI break on ppc64el that I have to deal with this week.
[19:49] <seb128> infinity, that's good news ;-)
[19:50] <seb128> infinity, anyway, help on the firefox issue is welcome, we don't have a firefox maintainer anymore atm
[19:50] <seb128> chrisccoulson does what he can on his extra-work-hours time to keep it going
[19:51] <seb128> but he said several times that he doesn't have the free slots/motivations to deal with "exotic" archs (that includes ppc)
[19:51] <infinity> Pretty sure, to most people, "exotic" is everything that their home computer isn't. :P
[19:51] <seb128> lol
[19:51] <infinity> (It just so happens that my home contains a lot of computers...)
[19:51] <chrisccoulson> my home computer isn't i386 or arm, but i'm happy to deal with those ;)
[19:52] <seb128> infinity, it's rather than we have to be given proof that anyone uses firefox on ppc and it's usable there
[19:53] <infinity> seb128: To be fair, I don't use a desktop on PPC either, mine are all servers.  So, yeah, I'm happy to examine the "just drop the binaries" option, but I want to poke the "why is it broken?" bit first.
[19:53] <seb128> infinity, thanks
[19:53] <seb128> infinity, I got that you are busy this week, do you think you can have a look before the end of the month?
[19:54] <seb128> infinity, I would like to see us publishing a firefox update in trusty before beta time
[19:55] <infinity> seb128: Yeah, I can commit to having a fix, one way or the other, before beta.
[19:56] <psusi> cjwatson: quick question... partman-ufs is broken on linux so I got the monolithic image to build once after removing it from pkg-lists/standard-udebs... but this file seems to be auto generated somehow so it keeps getting put back.  how is this?
[19:57] <infinity> seb128: Although, I'm not seeing the toolchain change argument here, with rmadison output.  Looks like powerpc is missing for precise-updates too.
[19:57] <infinity> The last version that built on ppc on any series was 25.
[19:57] <seb128> shrug
[19:57] <infinity> So, 25->26 deltas and looking for stupid would be my first pass.
[19:58] <seb128> infinity, sorry, I saw the security/updates going through on other series, I assumed that's because they didn't regresses on archs
[19:58] <infinity> seb128: Nah, the security team will happily regress unsupported arches if they can't immediately sort out the breakage.
[19:58] <seb128> I didn't think we pushed through updates that don't build on all supported arches
[19:59] <seb128> k
[19:59] <seb128> I learnt something there
[19:59] <seb128> infinity, anyway, if you can help getting that resolved one way or another that would be appreciated ;-)
[19:59]  * infinity nods.
[19:59] <seb128> I'm just chrisccoulson would join in buying you drinks at the next event
[20:00] <infinity> This whole work-for-drinks thing needs to stop before my liver falls out.
[20:00] <infinity> I'm staring at a bottle of gin from Carlos, and wondering if it's going to kill me.
[20:01] <seb128> infinity, can buy you some vegetables if you prefer!
[20:01] <sarnold> chrisccoulson also runs on steak, would that work? hehe
[20:01] <infinity> seb128: Steak? :)
[20:01] <seb128> oh, you said you want french cheese if I remember
[20:01] <infinity> Steak!
[20:01] <seb128> that works too ;-)
[20:01] <infinity> A few kilos of d'Affinois cheese wouldn't go amiss either.
[20:01] <seb128> hehe
[20:02] <infinity> In fact, it's nice melted on top of a filet mignon.  Two for one.
[20:02] <seb128> lol, I see where you a going ;-)
[20:02]  * seb128 starts wanting some steak
[20:12] <seb128> infinity, ok, gnome-control-center-signon built, I just deleted the arm64 debs from trusty/trusy-proposed since he can't work there (lack of qt5) and is depwaiting in the current upload
[20:12] <seb128> infinity, if there is still work needed, after the next run, please do your magic if you can ;-)
[20:12] <infinity> seb128: Alrighty.
[20:12] <seb128> thanks
[20:12] <infinity> seb128: That should have been all the magic required.   :P
[20:13]  * seb128 hides
[20:13] <seb128> let's see, I'm confident I'm not going to screw twice in a day ;-)
[20:13] <infinity> That sentence really needs another word to be significantly less embarassing.
[20:15] <seb128> screw -> screw up an Ubuntu upload? ;-)
[20:15] <seb128> see why french should be default, it would be easier!
[20:17] <stgraber> it'd be a lot less fun ;)
[20:19] <infinity> seb128: "up" was indeed the missing word. :)
[20:19] <infinity> seb128: Entirely different meaning without it. :P
[20:21] <seb128> ;-)
[20:21] <seb128> I was going for fun, stgraber got it :p
[20:21] <seb128> anyway, let's see if britney is happy once the arm64 binaries are gone
[20:22] <infinity> Should be.
[20:22] <seb128> great
[20:22] <infinity> Unless something depends on the now-missing binaries.
[20:22] <infinity> But if so, we should sort that anyway, not ignore it.
[20:22] <seb128> things depends on those yes
[20:23] <seb128> but those have never been installable
[20:23] <infinity> I'm going to go pizza hunting.
[20:23] <seb128> since they depended on qtdeclarative
[20:23] <seb128> infinity, if you have internet, or a phone, you can get pizza delivered ... rather than having to hunt for it. Just saying...
[20:24] <seb128> infinity, enjoy ;-)
[20:24] <ogra_> seb128, he probably likes the guns ;)
[20:24] <seb128> ogra_, did he move to Texas? ;-)
[20:25] <ogra_> maple syrup guns ;)
[20:25] <jdstrand> seb128: powerpc isn't 'supported' by us in that sense. amd64, i386 and armhf get security support. the other archs are along for the ride (https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures)
[20:26] <seb128> jdstrand, yeah, sorry I use "supported" for "existing"
[20:27] <infinity> jdstrand: Time to update the table for a new release and a new arch. :)
[20:29] <jdstrand> infinity: yes, a couple of them :)
[20:29] <jdstrand> oh no, arm64 is already there
[20:29] <jdstrand> infinity: and thank you for looking into ff/powerpc
[20:32] <seb128> infinity, \o/ that worked, g-c-c-signon migrated to trusty
[20:33] <dobey> is it impossible to disable ctrl+super+left/right keybindings?
[20:34] <seb128> dobey, you tried ccsm?
[20:35] <dobey> seb128: no, but tried dconf-editor, and don't see them in there. and setting them to a different action didn't help
[20:45] <seb128> dobey, I'm not sure, I think that's the grid plugin but you might want to ask Townsend when he's online, I think he cleaned that code previous cycle
[22:19] <infinity> jdstrand: You might want to split that table in two, for historical and current, too.  Then the current one would have fewer arches, and fewer still next year.
[22:34] <jdstrand> yeah
[22:34] <jdstrand> I was thinking about that
[23:38] <miseria> "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*