[07:00] <brobostigon> morning boys and girls.
[11:09] <SebthreeBQM10HD> hi
[11:15] <dataPulverizer> irc://irc.freenode.net/d
[11:31] <benxyzzy> Does the "startup disk creator" make read-only Live USBs? I want to guarantee that no trace of the session booted from the USB stick remains on the stick after shutdown
[13:03] <brmbrmcar> uh oh
[13:03] <brmbrmcar> nae ops
[14:37] <MooDoo> howdy all
[14:39] <penguin42> hey
[15:03] <popey> brmbrmcar: hm?
[18:24] <SebthreeBQM10HD> hi
[18:26] <daftykins> lo
[18:26] <daftykins> new toys \o/ http://imgur.com/a/PojKC
[18:26] <SebthreeBQM10HD> lo
[18:31]  * penguin42 has a new TV due on Tuesday
[18:31] <daftykins> penguin42: ooh anything special?
[18:32] <daftykins> just making the last two ghetto cat6 speaker cables XD
[18:32] <penguin42> daftykins: Curry's bank-holiday special 42" LCD dumb-TV
[18:32] <daftykins> ooh
[18:32] <penguin42> daftykins: JVC Freeview-HD - it's got 3 HDMI, a scary, component, 1 USB, and it does have ether (but I think for only playing local media)
[18:32] <penguin42> scary?! A scart!
[18:33] <daftykins> well it's a French standard so i'd concur ;)
[18:33] <penguin42> daftykins: But more importantly, I paid them the extra £15 to take my 32" widescreen CRT out - given it weighs about 50kg and is upstairs I'm hoping they do it
[18:34] <daftykins> oh excellent! yeah i'd pay to deal with that
[18:34] <daftykins> a Manchester guy actually invented how to recycle CRT glass, i understand
[18:34] <penguin42> really? I wonder where he is....
[18:35] <penguin42> daftykins: I'm not close enough to the Irwell to dump it in there
[18:43] <daftykins> mmm can't seem to find it
[18:44] <penguin42> daftykins: nulifeglass.com seems to be them
[18:44] <daftykins> that's the one :>
[18:48] <penguin42> daftykins: They're under 15 miles away
[18:48] <penguin42> daftykins: Although I bet my TV is on for a much longer journey
[18:48] <daftykins> \o/
[18:49] <daftykins> a gov site almost seemed to hint at pick-up for residents though?
[18:49] <daftykins> council even, i guess
[18:50] <penguin42> daftykins: As far as I could tell the council wanted £30
[18:52] <penguin42> daftykins: They've got quite a blog on the front of nulifeglass.com showing the build out of their New York furnace (and they're now building one in Virginia - I'm not sure they've even still got a UK one)
[18:54] <daftykins> i'd hope so! the original article i read spoke of licensing the process to China
[18:55] <penguin42> daftykins: I wonder what the timescale is; I mean there's only going to be a ~10 year?? window where people are recycling the bunch of them?
[18:55] <zmoylan-pi> there's probably a backlog that would take more than a few decades to recycle
[18:56] <daftykins> yeah
[18:56] <daftykins> 'cause the article spoke of them being gathered but sat around until the process was developed
[18:57] <zmoylan-pi> somewhere there's a field with a big pile of nokia 3310s waiting for scientists of the future to work out how to break them up... :-D
[18:58] <penguin42> daftykins: They might find the mythical Apple Lisa land fill
[19:00] <zmoylan-pi> next to the apple newtown pile i think
[19:01] <daftykins> :>
[19:01] <penguin42> Oh the newtons were both smaller, and I think actually sold fairly well at the time
[19:01] <zmoylan-pi> they started badly but were profitable by the time jobs got back
[19:01] <penguin42> me and a few friends bought a large box of duff ones from a local firm about 20 years ago and made working ones from pairs of duff ones and sold the working one
[19:01] <penguin42> s
[19:01] <zmoylan-pi> but i think he didn't like them as he didn't invent them
[19:02] <zmoylan-pi> i never saw one in wild mind.  this was psion country :-)
[19:02]  * penguin42 has one here but it doesn't work any more
[19:02] <penguin42> zmoylan-pi: Yeh I had the Acorn branded equivalent of the Psion 3a
[19:03] <zmoylan-pi> the school variant. putting computers in school kids hands decades before any one else
[19:04] <penguin42> I was using that during my postgrad; very useful for walking around a library taking notes from papers you had to find and research; back in the day when you had to do most stuff that way
[19:05] <zmoylan-pi> i could walk around with a psion 3a typing at 30wpm.  even standing on bus with arm wrapped around pole as it bounced across dublin
[19:05] <penguin42> nod, very good for thumb typing - was just the right size
[19:05] <daftykins> ah, one network cable left to make up
[19:05] <zmoylan-pi> i typed with 1 thumb and 1 hand using rest of the thumb using hand to grip the battery compartment so it never fell
[19:05] <penguin42> zmoylan-pi: It's a pity no one does a modern Android device in the same format; IMHO it would still work
[19:06] <zmoylan-pi> i've been saying that for a decade...
[19:06] <penguin42> zmoylan-pi: indeed someone now might be able to make more resiliant hinges
[19:06] <zmoylan-pi> even a decent case for the pi zero would do it for a low production variant
[19:07] <penguin42> zmoylan-pi: You'd need the battery/LCD/keyboard stuff
[19:07] <zmoylan-pi> that would be part of the case
[19:07] <penguin42> zmoylan-pi: and you'd have to get lucky for an uSD line up
[19:08] <penguin42> zmoylan-pi: I also have one of the things someone remade the Psion5 after they went under (can't remember the name)
[20:48] <SebthreeBQM10HD> popey, ping
[20:48] <popey> SebthreeBQM10HD: pong
[20:48] <SebthreeBQM10HD> popey, pm ?
[20:48] <popey> ok
[20:49] <SebthreeBQM10HD> popey, can you pm me, on this tablet uhmm...
[20:49] <SebthreeBQM10HD> not so easy
[20:49] <popey> it is
[20:49] <popey>  /msg <person> foo
[21:00] <SebthreeBQM10HD> popey, maybe we could of had that chat here actully oh well, and thanks ;)


[01:07] <coreycb> jamespage: looks like tempest commit 8d94885df02ea0a4826a1f271f011dfefd2c2ca9 is where the get_domain failure started
[04:17] <jonfatin-> Ubuntu 16.04 netinstalls are broken with archive mirror. here is my kickstart (hasn't changed in a year or so)  https://pastebin.com/raw/3k7STH8M
[04:19] <jonfatin-> https://imgur.com/a/azXDjn9
[04:31] <jonfatin-> Confirmed existing bug yay... https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1820755
[06:07] <jamespage> coreycb: bah - UCA qemu does not have the patch I thought it had - that's my bad
[06:07] <jamespage> it was in ca-patches but that had not refreshed when I ran the backport I think
[07:28] <lordievader> Good morning
[08:43] <blackflow> any suggestions on how to shut up the php-fpm warnings about "server reached max_children setting"? google isn't helpful. Yes, I know what the error means, no I'm not gonna raise the number of PHP procs. The requests should queue up, as is expected, by nginx. Yes, I'm monitoring it and will decide when to upgrade based on too many accepts waiting in the queue. So... there apparently isn't a
[08:43] <blackflow> config to shut that warning up, or I'm missing it from docs, google.
[08:45] <blackflow> other than completely dropping warnings for the pool, with ~E_WARN in error_reporting, which I don't really want to
[09:00] <blackflow> nvm, asking in ##php, thanks.
[09:32] <kstenerud> @cpaelzer if you have time, I'd like your comments on whether I'm on the right track wrt https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1810583
[09:41] <cpaelzer> kstenerud: the bug has no recent updates, where would an update be to think about it?
[09:43] <kstenerud> I'm trying to tackle it, since I'm doing ha stuff now. There's a post here https://chr4.org/blog/2019/01/21/make-keepalived-play-nicely-with-netplan-slash-systemd-network/ which talks about an upstream fix, which is talked about https://github.com/acassen/keepalived/issues/836#issuecomment-382011552
[09:44] <kstenerud> but it's a huge merge: https://github.com/acassen/keepalived/commit/8ecbb591994a567375d78239d075ed032d9f9b07
[09:45] <kstenerud> I can tease out the individual commits, but it will take awhile, so I'm wondering if this is the best way to deal with this issue? The problem is that keepalived doesn't play nice with systemd-networkd. It drops virtual IPs, which renders the entire HA stack useless
[10:05] <cpaelzer> kstenerud: a lot to read ... still reading
[10:06] <kstenerud> yeah, sorry.
[10:07] <kstenerud> From what I've read, the fixes were put in place a year ago, but it's a huge merge, so there's a ton of little commits, most not directly related to the problem. I'm thinking that maybe I can find one or two commits that deal specifically with this problem, or at the least get a list of anyhing that touches vrrp_whatever.c
[10:08] <kstenerud> The only other mitigations people have found so far were to force reload of multiple daemons on a trigger, which can cause other problems...
[10:10] <cpaelzer> kstenerud: lets sort out what these things do please
[10:10] <cpaelzer> kstenerud:  the referenced git entry does a lot of things as it is a whole fixes branch
[10:11] <kstenerud> yes, that's what I'm saying. I'm in the process of sifting through all the little commits to find the ones that are actually relevant
[10:11] <cpaelzer> kstenerud: and eventually all it provides in regard to the issue is that keepalived will realize that it "lost" its VIP to then action on it
[10:11] <kstenerud> I just want to make sure I'm going about this the right way
[10:11] <cpaelzer>  can't promise to know the right way, but I can try to help :-)
[10:11] <cpaelzer> kstenerud: that feature we will get with keepalived 2.0
[10:12] <kstenerud> Yeah that's cool. I just wanted your gut reaction to this, as in "oh god no you're doing this all wrong" :P
[10:12] <cpaelzer> but since we care on this issue on >=Bionic we need a solution for pre keepalived-2.0 anyway
[10:12] <cpaelzer> my gut reaction seems to make what we found in the blog a best practise - if it is seconded by a bunch of people to apply to all their problems
[10:13] <kstenerud> ok, then I'm going to dive deeper into the PR and find the commits that touch the vrrp stuff
[10:13] <cpaelzer> then I'd put it into the Readme file and maybe even a hint to the issue (bug) and recommended solution (ref to the Readme) in a NEWS update
[10:14] <cpaelzer> kstenerud: consider this from the blog (if that is true) "I came to the conclusion that this actually wouldn’t fit the actual problem, as keepalived would just note the removed VIP and failover to another machine. But I wanted to fix the underlying problem itself, instead of just coping with the symptoms"
[10:15] <cpaelzer> considering that, would identifying and backporting the changes (if even possible) help a lot?
[10:15] <kstenerud> It's still not a complete solution, but it does prevent the vrrp from going down and never coming back
[10:15] <cpaelzer> instead - if confirmed really good - we should make the config approach that the blog had best practise
[10:16] <kstenerud> true
[10:16] <kstenerud> we'll probably need both
[10:16] <cpaelzer> kstenerud: I think the two things are not mutually exclusive
[10:16] <cpaelzer> yeah
[10:16] <cpaelzer> identify the changes and evaluate if they are backportable at all
[10:16] <cpaelzer> get in touch with people reporting the bugs if the proposed configuration would work for them
[10:16] <cpaelzer> if backportable it seems a win to do so
[10:17] <kstenerud> yeah
[10:17] <cpaelzer> If not then it is to some extend your call - if keepalived without the fixes it totally broken then we might consider backporting keepalived-2.0 at some point
[10:17] <cpaelzer> but that is a despareate measure that has to be considered only later if needed
[10:17] <cpaelzer> as e.g. upgraders still have ifupdown and are probably happy
[10:18] <cpaelzer> kstenerud: if the config style mentioned in the blog really turns out to be superior that is mostly communication - as I said readme/news also whatever docs that we ahve on the net about it, maybe a blog post on your own
[10:19] <cpaelzer> kstenerud: TL;DR to me it seem the right way is going both ways and decide then
[10:19] <kstenerud> ok sounds good
[10:19] <cpaelzer> and there semes to be a lot of communication involved, so make sure you are in touch with people affected by the issue and also others running keepalived but not being affected
[10:19] <cpaelzer> we don't want to break one of these groups in favor for the other
[10:20] <cpaelzer> kstenerud: there is the sad truth that sometimes a fix has so much regression risk that even thou it would be nice to have we are not doing it and instead have to kindly ask to move to a newer version
[10:21] <cpaelzer> I love to fix issues for our users, but not breaking all other users sometimes wins - so consider "making 19.10/20.04 a great working solution" and then recommending an upgrade an alternative fallback
[10:21] <cpaelzer> and the new recommended config style that avoids the issue could be the documented and recommended solution for 18.04-19.04 then
[10:21] <cpaelzer> kstenerud: ^^
[10:22] <kstenerud> ok
[11:54] <coreycb> jamespage: ohh do you think that explains tobias-urdin's issue?
[12:06] <ahasenack> good morning
[12:16] <rbasak> cpaelzer: in https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/364760
[12:16] <rbasak> rmdir "$NEWCONFFILE" || echo "failed to remove $NEWCONFFILE"
[12:16] <rbasak> If that fails, the preinst will succeed. Is that intentional?
[12:33] <cpaelzer> rbasak: yes
[12:33] <cpaelzer> intentional
[12:33] <cpaelzer> I listed the output in the testcase
[12:33] <cpaelzer> that is when people have made customizations to the extend that we can't cover them all (e.g. placed other things in that dir)
[12:34] <cpaelzer> the intention is there to have the errors shown but NOT fail the package upgrade itself
[12:34] <cpaelzer> rbasak: feel free to convince me otherwise, we could as well make it a "please clean DIR foo to make this upgrade smoothly" + exit 1
[12:34] <cpaelzer> I'd be fine with that as well
[12:35] <rbasak> Ah, I missed your bug comment, sorry. I see it now.
[12:35] <rbasak> There doesn't seem to be an obviously correct answer to what the behaviour should be.
[12:37] <cpaelzer> yeah but are imperfect, but we could come up with "more edgy cases" of something already being a very rare use case all day
[12:37] <cpaelzer> therefore this was the line I decided to draw
[12:37] <rbasak> Yeah
[12:37] <rbasak> I think what you've done is fine.
[12:38] <rbasak> I just wanted to check that the || echo failed was intentional. From your bug comment that I missed it's clear that it was and that you've thought this through.
[12:38] <rbasak> I think what you've done is fine> in intended behaviour I mean. I still need to check again that the code does as intended :)
[12:39] <rbasak> cpaelzer: so is that the last time you'll accidentally put a filename in to the target of a dh_install file? :-)
[12:43] <brektyme> Hi, I'm getting a segfault when pxebooting the installer on 16.04, at the dectect disks step, I'm not really sure what the issue is and I've not seen it before it started yesterday. Does anyone have an idea of what I sould look at or what the issue could be?
[13:09] <cpaelzer> rbasak: no promises
[13:10] <cpaelzer> but it certainly reduces the chances that I'll do so
[13:14] <brektyme> I found a workaround on https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817358, that got me past the segfault but the installer is failing while installing the kernel, looks like a dependancy problem with linux-modules-extra
[13:36] <jamespage> coreycb: might do
[13:37] <jamespage> coreycb: I need to finish off some ceph SRU Testing and I'll take another test run at stein/proposed
[13:39] <coreycb> jamespage: ok. i'm still trying to figure out that tempest domains issue. i narrowed down on the commit. it seems we need to account for the switch of the test class inheritance from base.BaseIdentityV3AdminTest to base.BaseIdentityV3Test.
[13:39] <coreycb> not sure how yet though
[13:39] <jamespage> coreycb: oh I think I know what that is
[13:39] <jamespage> coreycb: obs if you revert the commit its all good
[13:40] <jamespage> I think the problem is the test uses on of the pre-created users todo the get domain call
[13:40] <jamespage> the users are in admin_domain, but the get domain call is for the default domain
[13:41] <coreycb> jamespage: ok, that's along the lines I was thinking as well. switching default_domain_id to admin_domain didn't seem to fix it.
[13:44] <jamespage> coreycb: hmm
[13:56] <kstenerud> cpaelzer: All dependent packages of php7.2 now succeed, except rss-bridge, which failed due to being unable to connect to the deb archive<EMAIL_ADDRESS>[13:56] <kstenerud> I tried restarting the build but I don't have permission
[13:59] <jamespage> coreycb: its working ok for me - using the ID of the admin_domain
[14:00] <coreycb> jamespage: oh great! maybe i've got something residual hanging around in my deployment.
[14:02] <cpaelzer> kstenerud: rsyslog was built just this morning
[14:03] <cpaelzer> kstenerud: maybe there was a problem publishign it in time for armhf
[14:03] <cpaelzer> kstenerud: give it an hour and then run it again
[14:03] <cpaelzer> kstenerud: I'm almost sure it will resolve then
[14:03] <kstenerud> I don't have permission to run it
[14:03] <cpaelzer> ok I can do that for you
[14:03] <kstenerud> ok thanks!
[14:05] <cpaelzer> kstenerud: to me it looks like the metadata in the repo was updated but the ftp not yet fully synced (or something like ti)
[14:05] <cpaelzer> kstenerud: running again http://autopkgtest.ubuntu.com/running#pkg-rss-bridge
[14:05] <cpaelzer> lets see in ~1h
[14:06] <cpaelzer> kstenerud: it passed that step already
[14:07] <jamespage> coreycb: it does indeed work
[14:07] <kstenerud> cool!
[14:08] <jamespage> coreycb: https://github.com/openstack-charmers/openstack-charm-testing/pulls/javacruft if you have cycles
[14:14] <coreycb> jamespage: merged, thanks
[14:21] <coreycb> jamespage: are you ok with releasing keystone LDAP backend fixes early to rocky-updates? they've only been there since last night but testing successful and it's critical.
[14:21] <coreycb> jamespage: fyi bug 1798184 bug 1820333
[14:21] <jamespage> coreycb: +1
[14:22] <jamespage> its basically completely broken right now so a fast-track is appropriate
[14:23] <coreycb> jamespage: alright, i'll go ahead and release that then
[15:02] <jamespage> coreycb: stein-proposed passes our tempest tests!
[15:02] <jamespage> promoting all the things...
[15:33] <coreycb> jamespage: \o/
[17:57] <genewitch> is there any reason to use --user with "pip" command, i'm having issues with certain libraries (libgpuarray specifically) where if the main application is pip installed with --user it can't see a hand compiled libgpuarray
[18:17] <tomreyn> maybe you need to change PATH or LD_LIBRARY_PATH
[18:30] <bin_bash> hello, I want to change the values in /etc/apt/apt.conf.d/20auto-upgrades to be "0" using "echo" how is this possible?
[18:30] <sarnold> it depends what's in that file. best is to just change whatever writes it to write whatever settings you need
[18:31] <bin_bash> well usually i just manually change it, but i'm trying to put it in a quick bash script
[18:31] <sarnold> sed -i is probably the better tool for the job
[18:31] <bin_bash> APT::Periodic::Update-Package-Lists "1";
[18:31] <bin_bash> APT::Periodic::Unattended-Upgrade "1";
[18:31] <bin_bash> this is what the file has by default
[18:31] <bin_bash> i want 1 to become 0
[18:32] <bin_bash> hm sed is a good idea, i didnt consider that
[18:34] <bin_bash> sarnold: im looking at the manpage, not sure i'm seeing how to do this
[18:41] <tomreyn> here's a simple example: sed -i 's/^APT::Periodic::Update-Package-Lists "1";$/APT::Periodic::Update-Package-Lists "0";/'
[18:41] <tomreyn> here's a simple example: sed -i 's/^APT::Periodic::Update-Package-Lists "1";$/APT::Periodic::Update-Package-Lists "0";/' /etc/apt/apt.conf.d/20auto-upgrades
[18:42] <tomreyn> ^ I forgot the file to edit initially
[18:42] <tomreyn> but you'll really need to understand regular expressions, or you won't know what you need to escape.
[18:42] <tomreyn> try #bash
[18:43] <bin_bash> thanks
[18:43] <bin_bash> ideally i'd just replace 1 with 0 in that file
[18:43] <bin_bash> rather than the whole line
[18:44] <tomreyn> if you just want to replace any 1 by one character, that's also possible, but i think that's most likel ynot what you actually want.
[18:45] <tomreyn> *any 1 character by a 0 character
[18:45] <sarnold> you definitely want to make sure you know which exact config settings you're changing
[18:45] <bin_bash> it'd be weird if there was another 1 in the file
[18:46] <sarnold> apt has something like nine thousand config choices
[18:46] <bin_bash> not in this one file
[18:46] <sarnold> and there's no saying what other admins or tools have put in which files
[18:47] <tomreyn> or removed from them, or whether edited to be in a different format, or commented in or out
[18:48] <tomreyn> even regular expressions mey be unsuitable to help you there.
[18:48] <bin_bash> there shouldn't be anything else in this file except these two lines...
[18:48] <sarnold> yeah if the settings are set via the APT { Periodic { Update-Package-Lists } } } style, it'll be harder to edit
[18:49] <sarnold> bin_bash: maybe today .. who knows what'll be there in six months
[18:50] <tomreyn> people like you probably wrote software for boeing 737 max 8
[18:50] <bin_bash> ...
[18:50] <bin_bash> wow
[18:51] <tomreyn> i'm not meaning to blame you there, just pointing out such things can really matter
[18:51] <bin_bash> that's gotta be one of the worst false equivalency attempts i've ever had lobbed against me.
[18:52] <bin_bash> I can't imagine how a single personal-use script is even comparable in your thought process
[18:52] <sarnold> man if you're upgrading your planes in flight .. something is way wrong :)
[18:52] <lordcirth> bin_bash, that was excessive. But if a thing is worth doing, it's worth doing right.
[18:52] <bin_bash> if you're running ubuntu on a plane, there's some serious fucked up shit going on
[18:53] <lordcirth> bin_bash, point is, don't hack something together poorly, do it right the first time
[18:54] <bin_bash> lordcirth: i'm really just trying to reduce having to manually change this in a deployment script for dev usage. i never suggested hacking it together, i'm  simply looking for the easiest implementation for the specific use-case
[18:55] <tomreyn> yes, that was excessive, sorry bin_bash. but you should try to get into this kind of thinking - how risky is it if i do it wrong, and can i actually measure that reliably, or should i just try to make it reliable no matter what.
[18:55] <bin_bash> i'm only ever modifying THIS file. i'm only changing the values from 1 to 0, and was therefore askined the best way to implement this. even if more lines were added i would /still/ want them to change from 1 to 0 because i want to disable any automatic upgrades
[18:55] <sarnold> bin_bash: I still think you'd be better served by figuring out what's putting that file in place and using the correct values from the start
[18:56] <tomreyn> bin_bash: you mention deployment. many deployment frameworks provide a way to edit configuration files in a better way.
[18:57] <sarnold> if it's copying /usr/share/unattended-upgrades/20auto-upgrades into place, it might as easy as asking those scripts to copy /usr/share/unattended-upgrades/20auto-upgrades-disabled instead
[18:57] <bin_bash> sarnold: what?
[18:58] <sarnold> bin_bash: I don't have /etc/apt/apt.conf.d/20auto-upgrades on my systems; there *is* a /usr/share/unattended-upgrades/20auto-upgrades though
[18:58] <sarnold> bin_bash: so I'm curious if your deployment script is copying that file over..
[18:58] <sarnold> bin_bash: in which case it'd be as easy as asking it to copy a *different* file ..
[18:58] <bin_bash> sarnold: which version?
[18:58] <sarnold> bin_bash: which would be way more reliable than copying the wrong file, and then editing it :)
[18:59] <sarnold> ii  unattended-upgrades 1.1ubuntu<IP_ADDRESS> all          automatic installation of security upgrades
[19:00] <bin_bash> sarnold: your setup sounds weird...
[19:00] <tomreyn> i see /etc/apt/apt.conf.d/20auto-upgrades on 14.04, not on anything newer
[19:00] <bin_bash> the unattended upgrades file has always been in etc
[19:00] <bin_bash> this is 18.04
[19:01] <bin_bash> and i found this stack overflow for 16.04, which has a similar sed command to what was suggested above: https://askubuntu.com/questions/1059971/disable-updates-from-command-line-in-ubuntu-16-04
[19:01] <tomreyn> dpkg -S /etc/apt/apt.conf.d/20auto-upgrades
[19:01] <tomreyn> ok, ignore this, that's maybe misleading
[19:02] <bin_bash> this even says the same file too:
[19:02] <bin_bash> https://linuxconfig.org/disable-automatic-updates-on-ubuntu-18-04-bionic-beaver-linux
[19:04] <tomreyn> yes the file is created via postconf apparently
[19:05] <bin_bash> hm interesting
[22:11] <tomreyn> s/postconf/postinstall/ oops


[06:45] <jcristau> RAOF: fwiw http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675940
[06:45] <jcristau> from the "how can fglrx be so full of shit" department
[06:46] <RAOF> Hurray!
[06:47] <tjaalton> and the legacy ones are always behind
[06:48] <tjaalton> -96 doesn't support even 1.11
[06:48] <tjaalton> nvidia-96
[06:48] <tjaalton> not sure if -173 has been uploaded yet
[06:48] <tjaalton> so maybe that's in the same boat
[06:50] <mlankhorst> jcristau: It's amazing :)
[07:04] <Sarvatt> that fglrx bug in debian was fixed months ago...
[07:04] <Sarvatt> talk about annoying
[07:05] <mlankhorst> it's revived?
[07:07] <Sarvatt> no it hasnt been released yet
[07:07] <Sarvatt> they fix stuff 3 months before releasing it publicly
[07:08] <mlankhorst> hm, something like http://opensource.apple.com/source/X11libs/X11libs-40.2/cairo/cairo-1.8.6/util/backtrace-symbols.c would be nice to have for X, meaningful backtraces if debug symbols are found (license sadly)
[07:08] <tjaalton> weren't they supposed to change the release policy?
[07:08] <Sarvatt> looks like its in the 12.6 catalyst though
[07:09] <Sarvatt> or 12.7 whenever it actually releases now, 8.98x
[07:10] <Sarvatt> someone from debian reported it on their beta mailing lists
[07:13] <mlankhorst> Sarvatt: Yeah sadly I now believe if they put some more resources into r600 it would work a lot better than fglrx' way of development :(
[07:14] <Sarvatt> it was reported and fixed when debian first went to xserver 1.12, to put it in perspective
[07:15] <mlankhorst> That was how many months ago now?
[07:19] <Sarvatt> march
[07:20] <mlankhorst> so THAT explains why all my crasher bugs overlap rofl
[07:20] <mlankhorst> my biggest issue with ati was that every time it fixes a new issue after 4-5 months it would introduce a new one needing fixes
[07:20] <mlankhorst> so it was guaranteed to never work right
[14:31] <C-Otto> howdy
[14:32] <mlankhorst> well succes-ish, I can sync nouveau with itself using the cpu fallback. :)
[14:32] <C-Otto> i'm here regarding clickpad issues, cf. http://www.theorangenotebook.com/2012/02/call-for-testing-clickpad.html
[14:32] <C-Otto> is it a bug that while doing a two-finger-dragndrop the button holding the key (lower left) can still move the pointer?
[14:33] <C-Otto> i'd like my index finger (in the main part of the clickpad) to move the item and the thumb on the lower part of the touchpad to just click (ignoring any movement)
[14:33] <C-Otto> currently I see that movements of both fingers have an effect
[15:10] <tjaalton> mlankhorst: you seem to be involved with wine.. so on precise 64bit install it complains about DRI being disabled, which is bogus, and I can't run trackmania! :)
[15:10] <tjaalton> err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most likely your OpenGL drivers haven't been installed correctly (using GL renderer "Mesa DRI Intel(R) Ivybridge Desktop ", version "1.4 (2.1 Mesa 8.0.2)").
[15:14] <mlankhorst> tjaalton: glxinfo | head or something
[15:15] <mlankhorst> will probably need mesa-utils:i386 for wine
[15:15] <tjaalton> ok i'll try that. unity et al run just fine
[15:15] <mlankhorst> since it's a 32-bits process
[15:20] <tjaalton> now it crashes with "malloc(): memory corruption: 0x7d7c4308 ***"
[15:21] <tjaalton> i give up, just wanted to see if the wine install worked or not
[15:21] <tjaalton> has been a while since I used it
[15:21] <mlankhorst> heh, are you using the ubuntu wine ppa?
[15:22] <tjaalton> no, stock precise
[15:22] <mlankhorst> been updating that ppa at least
[15:29] <tjaalton> hmm, with 1.5 i get a "GLXBadDrawable"
[15:40] <mlankhorst> funfun
[16:23] <ricotz> mlankhorst, hi
[16:23] <mlankhorst> hey
[16:24] <ricotz> please don't copy the kernel to edgers
[16:24] <mlankhorst> ? I don't usually touch kernels
[16:24] <ricotz> mlankhorst, sorry, i see
[16:24] <ricotz> who did this?
[16:24] <mlankhorst> let me check
[16:25]  * ricotz notes: we want a "full" kernel there with a linux-libc package, and if one copies it at least binary copy it
[16:25] <tjaalton> leann? must be a mistake i guess
[16:26] <mlankhorst> I can cancel the build if you want?
[16:26] <ricotz> mlankhorst,  i can do this too
[16:26] <tjaalton> "Copied from ubuntu quantal in Primary Archive for Ubuntu"
[16:27] <tjaalton> oh the lts backport
[16:27] <ricotz> tjaalton, i mean this one " linux-lts-quantal - 3.5.0-2.2~precise1"
[16:27] <tjaalton> right
[16:27] <ricotz> Copied from ubuntu precise in Q-series LTS Backport
[16:27] <mlankhorst> ricotz: Yeah probably done by mistake :)
[16:28] <mlankhorst> I can't imagine why you want that as part of the edgers ppa
[16:28] <tjaalton> ricotz: best ask on #ubuntu-kernel
[16:28] <ricotz> mlankhorst, it was the same with  3.5.0-1.1~precise1 though
[16:28] <ricotz> tjaalton, i dont think one of the kernel guys put it there
[16:29] <mlankhorst> ricotz: could ask just in case, not sure who manages kernel-ppa
[16:29] <tjaalton> 'kernel-ppa' is some script
[16:29] <tjaalton> and a person wrote it
[16:29] <ricotz> tjaalton, and a person copied it from there
[16:29] <tjaalton> or created the automation
[16:29] <mlankhorst> I would guess automation since 1 time could be done by accident :)
[16:30] <ricotz> i dont think kernel-ppa has the rights to upload to edgers?
[16:33] <mlankhorst> tjaalton: who maintains kernel-ppa script?
[16:34] <tjaalton> mlankhorst: i don't know, guessing it might be timg or leann
[16:35] <ricotz> mlankhorst, fyi, it is in here too https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+packages
[16:35] <tjaalton> that's the correct place
[16:35] <mlankhorst> ricotz: yeah that's the place it ought to be in :)
[16:35] <ricotz> mlankhorst, did you copied it?
[16:35] <mlankhorst> no :s
[16:36] <ricotz> ah, i though this one was copied from somewhere too
[16:36] <ricotz> *thought
[16:36] <ricotz> but this one was actually uploaded
[16:36] <tjaalton> i'd think 'uploader' shows whoever signed the package and uploaded it, not who touched the changelog last
[16:36] <mlankhorst> brb
[16:37] <ricotz> tjaalton, actually any member of edgers can copy a package from somewhere to edgers ppa, but you cant see who
[16:37] <tjaalton> ok
[16:38] <tjaalton> well, then you have a short list of suspects
[16:39] <tjaalton> Sarvatt, bjsnider ^
[16:40] <Sarvatt> ricotz: that was me
[16:40] <tjaalton> :)
[16:40] <ricotz> Sarvatt, uh, i knew! ;)
[16:40] <ricotz> Sarvatt, we want a full kernel in there
[16:41] <Sarvatt> so put it in there too? :P
[16:41] <ricotz> Sarvatt, but if you copy a package, wait for it this be built and binary copy it ;)
[16:41] <ricotz> Sarvatt, i did
[16:41] <ricotz> Sarvatt, the packages arent compatible though
[16:42] <Sarvatt> yeah I use the backports ones
[16:42] <ricotz> meaning the have the same binary package names
[16:42] <Sarvatt> err what?
[16:42] <ricotz> which leads to upload fails
[16:42] <ricotz> i guess that happens last time irc
[16:42] <Sarvatt> no they dont?
[16:43] <ricotz> Sarvatt, mhh, some upload failed, let me see
[16:44] <ricotz> spam ahead
[16:44] <ricotz> * Source Package: linux-lts-quantal
[16:44] <ricotz>  * Version: 3.5.0-1.1~precise1
[16:44] <ricotz>  * Architecture: amd64
[16:44] <ricotz>  * Archive: xorg-edgers PPA
[16:44] <ricotz>  * Component: main
[16:44] <ricotz>  * State: Failed to upload
[16:44] <ricotz>  * Duration: 2 hours 10 minutes
[16:44] <ricotz>  * Build Log: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/3591883/+files/buildlog_ubuntu-precise-amd64.linux-lts-quantal_3.5.0-1.1%7Eprecise1_BUILDING.txt.gz
[16:44] <ricotz>  * Builder: https://launchpad.net/builders/americium
[16:44] <ricotz>  * Source: not available
[16:44] <ricotz> while  "linux - 3.5.0-1.1" was already there
[16:45] <tjaalton> it builds the metapackage too?
[16:46] <ricotz> tjaalton, no
[16:46] <ricotz> that is the source name
[16:46] <tjaalton> ah
[16:46] <Sarvatt> ahh ok my mistake, i thought the packages were namespaced with lts-foo, guess it does conflict
[16:46] <ricotz> the source packages are, but not the binaries
[16:46] <Sarvatt> ricotz: so want to start doing a metapackage then?
[16:47] <ricotz> Sarvatt, no, i thought we dont want this
[16:47]  * Sarvatt is sick of all the emails about linux-image-extra not being installed
[16:47] <ricotz> but copying the meta-package from quantal can be done
[16:48] <ricotz> Sarvatt, sorry, that always you are getting the bad mails :(
[16:48] <Sarvatt> you should have gotten some of them :)
[16:49] <Sarvatt> all the ones about usb and video not working after installing linux-image because they're in -extras now
[16:50] <ricotz> Sarvatt, ah, i guess there is a bug about that since quantal is hit by it
[16:50] <ricotz> Sarvatt, are the metapackages changed in some way for that already?
[16:51] <Sarvatt> yeah in quantal
[16:51] <ricotz> ah right
[16:52] <ricotz> so adding a metapackage will "force" people to upgrade
[16:52] <mlankhorst> Sarvatt: hm was right in my guess then :)
[16:52] <mlankhorst> just don't like to accuse unnecesarily
[16:53] <ricotz> Sarvatt, i will start to copy the metapackages then too
[16:53] <Sarvatt> hmm
[16:54] <Sarvatt> the lts backport meta might actually work
[16:55] <mlankhorst> Sarvatt: well I had to get a whole renamed stack in a ppa as proof of concept :)
[16:55] <Sarvatt> nope it doesn't pull in -extra
[16:56] <Sarvatt> i would argue its the main kernel we don't want, linux-libc-dev stopped being important in edgers once everything started using libdrm headers :P
[16:57] <mlankhorst> pretty much
[16:57] <ricotz> Sarvatt, ok, so if we want to rely on the lts backport kernel there is no need to copy it since it will land in precise automatically
[16:58] <mlankhorst> ricotz: except it's not there yet until <IP_ADDRESS> :)
[16:59] <ricotz> oh, really? i am not speaking of the x-stack
[16:59] <ricotz> the kernels landed pretty fast in lucid irc
[17:00] <Sarvatt> yeah lets just copy the meta, it's pretty much required now with the linux-image-extra junk
[17:00] <mlankhorst> Sarvatt: hm not sure, will 12.04.1 ship with new kernel or is that 12.04.2 too?
[17:01] <Sarvatt> didn't realize the backport one wasn't namespaced and was screwing up the other builds
[17:01] <Sarvatt> mlankhorst: nah 12.04.2
[17:01] <mlankhorst> yeah thought so :)
[17:01] <Sarvatt> i have no clue what the plans are for quantal backports going into precise
[17:01] <Sarvatt> (kernel)
[17:01] <mlankhorst> renamed like that I think
[17:01] <mlankhorst> they're following X since we have more complex requirements
[17:02] <Sarvatt> yeah what ricotz is saying is lts-maverick kernels went into lucid pretty fast but they haven't this time for quantal ones
[17:02] <mlankhorst> final kernel is not even available yet, might need 3.6
[17:03] <ricotz> Sarvatt, alighty then
[17:03] <mlankhorst> in fact the code needed for syncing dma isn't even done yet *sighs*
[18:02] <tjaalton> bryceh: btw, we should wait until the vdpau support lands in debian mesa, since it appears to be not quite finished yet
[18:03] <mlankhorst> tjaalton: at the moment all that vdpau is is a stub :)
[18:03] <bryceh> tjaalton, you mean before doing 1.12?
[18:04] <tjaalton> well i don't mean the upstream code, but packaging
[18:05] <tjaalton> bryceh: no I mean the committed patch was incomplete :)
[18:09] <bryceh> tjaalton, which patch?
[18:10] <tjaalton> bryceh: the one you applied on mesa
[18:10] <tjaalton> bug 1002224
[18:11] <bryceh> tjaalton, then can you comment on the bug?
[18:11] <tjaalton> yes
[18:15] <cnd> mlankhorst: I haven't looked at synaptics yet, still waiting for your confirmation that it is ready
[18:17] <tjaalton> bryceh: done
[18:20] <mlankhorst> cnd: Well 1.6.2 works here :)
[18:20] <cnd> mlankhorst: ok, so do you want me to upload it?
[18:20] <mlankhorst> cnd: It's in the sru queue afaict
[18:20] <cnd> mlankhorst: oh, did someone else upload it for you?
[18:21] <mlankhorst> yeah :)
[18:21] <cnd> I don't see anything here: https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics
[18:22] <cnd> it should be in quantal first
[18:22] <mlankhorst> hm it should be in quantal
[18:35] <mlankhorst> bryceh: did you upload 1.6.2 to quantal?
[18:39] <tjaalton> git shows it unreleased
[18:39] <bryceh> mlankhorst, nope, not me
[18:39] <bryceh> looks like 1.6.1 was the last I uploaded
[18:39] <mlankhorst> ok I don't think it happened yet then, so could you upload it?
[18:39] <bryceh> mlankhorst, certainly
[18:39] <mlankhorst> thanks :)
[18:44] <bryceh> mlankhorst, upload sponsored
[18:49] <bryceh> mlankhorst, hey do you get the Accepted emails from launchpad on uploads?  Or do those go only to the sponsor...
[18:50] <mlankhorst> think only to you
[18:50] <bryceh> ok
[19:06] <stgraber> bryceh: speaking of upload, you're aware that the archive is frozen right? :)
[19:07] <bryceh> stgraber, oh yeah
[19:07] <stgraber> bryceh: because that upload just went to the release pocket even though it was seeded, this might cause alpha-2 images build skew. It should have been going to -proposed instead
[19:07] <bryceh> bother
[19:08] <bryceh> stgraber, feel free to kick it out then
[19:08] <stgraber> bryceh: we can't, it's a soft freeze
[19:09] <bryceh> well it's a fast build at least
[19:09] <stgraber> good, and I believe we haven't started building the next batch of images, so I'll just mention it in #ubuntu-release so that they wait for it before respinning
[22:36] <bjsnider> tjaalton, i definitely did not copy a kernel into edgers


[22:39] <nacc> on3pk: does regular top report the same thing?
[22:40] <on3pk> No.  Top appears to show that I'm using all but 1mb
[22:41] <nacc> on3pk: then i'd suspect a bug in htop ... what version of ubuntu?
[22:42] <puxavida> odd.  When I first start up usb flash live 16.04 touch works at the try ubuntu or install, but then when I go in to try, touch is gone
[22:43] <on3pk> Ubuntu 16.04.3 LTS
[22:45] <puxavida> yes
[22:45] <puxavida> can't get to a terminal from that screen either to check xinput list
[22:46] <nacc> puxavida: 'touch' ?
[22:46] <jrp93> touch the binary file or touch screen?
[22:46] <nacc> on3pk: hrm, seems surprisig, but possible, i guess, for small systems
[22:46] <nacc> on3pk: i'd see if there is a bug already and if not file one
[22:47] <puxavida> touch screen
[22:47] <jrp93> Doesn't surprise me
[22:48] <jrp93> Touch screen being broken I mean
[22:48] <puxavida> is there a way to get to a terminal from the initial installer screen
[22:48] <jrp93> Ctrl + alt + f4 I think
[22:48] <Ben64> if you go to try, you can hit ctrl+alt+t
[22:48] <jrp93> Something like that
[22:48] <jrp93> Ya thats it
[22:48] <puxavida> pressing ctl-alt-# other than f1 only shows a blinking cursor
[22:50] <puxavida> once try is selection, something else happens since the touch is gone at that point
[22:50] <Ben64> it loads the live usb
[22:50] <on3pk> If I file a bug report it'll mean I have to be slightly more professional than claiming to discover a singularity :(
[22:52] <jrp93> I'd see if it's repeatable first
[22:52] <on3pk> I have other VPS's, but all with this same provider
[22:53] <on3pk> If there is something weird that this provider is doing, I wouldn't be able to discount it
[22:53] <nacc> on3pk: just to be sure, `apt-cache policy htop` ?
[22:54] <on3pk> http://paste.ubuntu.com/25928183/
[22:54] <nacc> on3pk: ok, that looks fine
[22:56] <jrp93> I'll spin up a 128MB mem vagrant box
[22:58] <miner8866> Hi, im trying to run a .c file through gcc, but i cannot resolve a number of warnings where the argument is not as expected (int vs int*). should i use another version of gcc in this case, and how can i figure out which, if so?
[22:59] <ikonia> miner8866: you need to talk to C developers to understand the problem
[22:59] <ikonia> randomly swapping compilers is not the answer
[22:59] <nacc> miner8866: you are trying to compile something and it is failing? why are you compiling it?
[23:01] <miner8866> @ikonia okay @nacc trying to install amd-adl-sdk because it is a dependency for amdcovc, which is an overclocking tool
[23:02] <nacc> miner8866: we can't help with random tools, feel free to contact the owner of the tool for help
[23:02] <nacc> miner8866: if it's in the archive, we can help
[23:02] <jrp93> miner8866, I recently installed that actually
[23:02] <miner8866> it is not a specific case of a general 'issue'?
[23:02] <jrp93> miner8866, What cards do you have though?   I rebooted and now touch is working.  Maybe I have to reboot after turning screen keyboard on??
[23:04] <ikonia> you don't run main.c
[23:04] <miner8866> i mean compile
[23:04] <ikonia> miner8866: I suggest you talk to the maintainer
[23:04] <miner8866> ? sorry am new to linux
[23:05] <ikonia> or a programming channel if you feel like you want to work the source code through
[23:05] <nacc> !compile | miner8866
[23:05] <nacc> miner8866: but this channel is not for fixing source code, sorry
[23:05] <miner8866> okay, clear
[23:05] <jrp93> miner8866, I'll help you in PM
[23:06] <ikonia> very kind jrp93
[23:13] <miner8866> i agree irkonia :D
[23:20] <Industrial> Hi. How do I disable a service from starting at boot (redis) ?
[23:20] <nacc> Industrial: what version of ubuntu?
[23:21] <Industrial> How do I check?
[23:21] <nacc> Industrial: lsb_release -a
[23:21] <Industrial> 16.10
[23:21] <nacc> !eol | Industrial
[23:21] <nacc> !yakkety | Industrial
[23:21] <Industrial> ok
[23:21] <nacc> Industrial: you really should upgrade
[23:21] <Sveta> 16.10 was not lts ?
[23:22] <Jordan_U> Sveta: No. Ubuntu 16.04 is an LTS release, 16.10 is not.
[23:22] <Sveta> ok thanks
[23:22] <nacc> Sveta: every two years, in the .04 release only
[23:22] <Industrial> !eolupgrade
[23:22] <Sveta> ok thanks
[23:30] <Mr_H> Hi. I had a RAID5 (4 disks) created with mdadm. After a failure of the motherboard the computer wil not boot anymore. I may have changed the order of SATA ports, but it seems like the problem lies on the disks. Running mdadm --detail /dev/md127 says it's a RAID0 of 2 disks. mdadm -E on all disk shows active decvice 2 and 3 from RAID5, but the two in RAID0 has no superblock. What can I do to get my data back? mdadm --detail --scan also shows the
[23:30] <Mr_H>  RAID0. Running 16.04.02 LTS
[23:31] <oerheks> mobo failure or problem with disks .. are you trying on the problem mobo ?
[23:31] <Mr_H> is there any way to get the headers back from some config or anything?
[23:31] <Mr_H> I had a mobo with the Atom C2000 bug, replaced it with a new mobo of same model after one motnh today
[23:31] <chomwitt> nacc: trying to install hwe kernel i got a 'warning' about missing kernel headers. should i worry?
[23:32] <Mr_H> I was thinking it would be plug and play, but I cant get the disk up. I'm running RAID5 with LUKS on top
[23:32] <nacc> chomwitt: can you pastebin the command and output?
[23:34] <ikonia> with luks.....there we go
[23:35] <chomwitt> ok
[23:35] <Mr_H> ikonia: is that bad? I would think that if I only get the RAID working LUKS would decrypt nicely?
[23:36] <Absolute0> How do I get /lib/modules/4.13.0-16-generic/misc?
[23:36] <Absolute0> I need it for vmware workstation
[23:37] <chomwitt> nacc: https://paste.ubuntu.com/25928435     line 175
[23:37] <jrp93> Mr_H, LUKS won't affect your RAID configuration. Reassembling mdadm is just a pain
[23:37] <nacc> Absolute0: are you sure on that path?
[23:38] <Absolute0> nacc askubuntu.com/questions/966585/ubuntu-17-10-upgrade-broke-vmware-workstation-12-5/968429
[23:38] <jrp93> Mr_H, what are the contents of /etc/mdadm.conf
[23:38] <nacc> chomwitt: you can add that package it recommends to your list, it's goig to be uanble to build your dkms drivers otherwise
[23:38] <nacc> chomwitt: it proably means you are missing similarly named metapcakges for the header files, fwiw
[23:39] <Mr_H> jrp93: that is my thinking also since luks is one layer up. But I need to get mdadm working, all family photos are on that disk set
[23:39] <nacc> Absolute0: if you read the link you just provided, they are creatign that path
[23:39] <nacc> Absolute0: it's not an ubuntu path.
[23:39] <chomwitt> nacc: should i use sudo apt-get install --install-recommends  . i mean i didnt use 'recommends'
[23:39] <jrp93> Mr_H, I have RAID 10 with LUKS. I can share my provisioning script but it's probably different for you
[23:40] <Mr_H> I'm working on getting SSH working now, it only says "system is booting up. See pam nologin(8)"
[23:40] <nacc> chomwitt: headers are a suggests nont a recommends
[23:40] <nacc> chomwitt: do you actually have dkms eanbled drivers?
[23:40] <Absolute0> nacc: I guess they assume you will create it?
[23:40] <nacc> Absolute0: I don't understand what you are asking.
[23:41] <Absolute0> nacc: I created the dir
[23:41] <nacc> Absolute0: ok.
[23:41] <chomwitt> nacc: i dont know many things about that. (dkms enable drivers)
[23:41] <nacc> oerheks: didn't you have a command to check that?
[23:41] <Absolute0> nacc: insmod: ERROR: could not insert module /lib/modules/4.13.0-16-generic/misc/vmmon.o: Invalid module format
[23:41] <nacc> oerheks: if any drivers are using dkms
[23:41] <nacc> Absolute0: i'ts not a ko, dunno
[23:42] <nacc> Absolute0: not really our issue to resolve, i'd ask vmware
[23:44] <nacc> chomwitt: i think you want to install linux-headers-generic-hwe-16.04-edge and linux-headers-generic (corresponds to the binary metapackages you are installing)
[23:44] <nacc> chomwitt: if you do that, it should trigger the dkms builds again (the ones that failed in that log)
[23:44] <oerheks> sudo apt-get install linux-headers-$(uname -r)
[23:44] <nacc> oerheks: i don't recommend that
[23:44] <nacc> well, i mean, it'd work for the current kernels
[23:44] <nacc> *kerenl
[23:45] <nacc> but the point is we're trying to get chomwitt off the install a specific package
[23:45] <nacc> oerheks: the above will also make autoremove not work
[23:45] <oerheks> oh, HWE .. https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[23:46] <nacc> tehre's a corresponding metapacakge for the GA stack, for the HWE stack and for teh HWE-edge stack
[23:46] <nacc> (for both the binary kernel and for the headers)
[23:46] <oerheks> yeah, lets not mix that
[23:47] <Mr_H> jrp93: here is the cointent of mdadm.conf http://paste.ubuntu.com/25928477/
[23:48] <jrp93> Run sudo mdadm --verbose --detail --scan >> /etc/mdadm.conf
[23:49] <jrp93> then show the contents again
[23:51] <Mr_H> jrp93: http://paste.ubuntu.com/25928487/
[23:52] <jrp93> Mr_H, Hmm. Was the array fully functioning before the mobo died?
[23:54] <jrp93> Mr_H, try sudo mdadm --assemble --scan
[23:54] <chomwitt> nacc: packages linux-signed-image-generic-hwe-16.04 and edge dont recommend or depend on linux-headers packages.  (as i checked with apt-cache show) but linux-generic do
[23:54] <chomwitt> nacc: i'll install the headers of the hwe.
[23:57] <Mr_H> jrp93: yes. everything was working, but I had the Intel Atom bug, so I lost contact with the box and after a reboot it never got up again. Replaced mobo with excact same model. wont that destroy the RAID5? I am terrified of losing data


[00:26] <dandel> rtg, i see that they are ready, i'll boot those 2 kernels up asap.
[02:18] <dandel> rtg, it seems that the mainline 2.6.25 kernel is unbootable for me.
[02:21] <dandel> it gets stuck at boot, but is not a kernel panic ( flashing capslock key )
[02:24] <JanC> they key flashes?   :P
[02:37] <dandel> hmm... might be wrong on that one... either way, waited until just now to reboot after trying 2.6.25 again.
[02:38] <dandel> !bug 338701
[02:38] <ubot3> Factoid bug 338701 not found
[02:38] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
[02:39] <dandel> either way, i've limited the bug down to an acpi patch in 2.6.26.
[03:01] <dandel> Ncommander, can you look over bug #338701 and tell me what else i should probably submit to that?
[03:01] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
[10:31] <Mez> Hey. my kernel seems to be crashing aon a t1500 celeron dual core, last message is marking tsc unstable due to tsc halts in idle
[10:31] <Mez> I can get it working with "apci=ht noapic"
[10:31] <Mez> but that's exactly the best solution, seeing as it's a laptop
[10:31] <Mez> any suggestions?
[10:31] <aboSamoor> I filed this bug 341625 , what is the info needed ?
[10:31] <ubot3> Malone bug 341625 in linux "Hard disk I/O operation freezes the system" [Undecided,New] https://launchpad.net/bugs/341625
[10:37] <aboSamoor> any ideas ?
[10:53] <ia> hello. I have a kernel config, which i use for compilation each new jaunty linux kernel. On previous versions (before 8.27) cpu freqency scaling works fine, but at later kernels this feature unavailable (i use asus eeepc 901). But at generic kernel scaling still works fine; so, looks like that for enabling this feature in my custom kernel i should enable some other (new?) option in config, but what exactly option? I will be very appreciate for any clues.
[11:00] <ia> or, in any words, i would like to know, which exactly config option/module enables in latest kernels cpu frequency scaling feature for eee pc 901 hardware?
[11:06] <amitk> ia: What processor does the eeepc have?
[11:06] <ia> amitk: intel atom n270
[11:07] <amitk> ia: do you need the custom config for other reasons or only for cpufreq?
[11:08] <ia> amitk: for other also :-)
[11:08] <amitk> ia: there were some changes made in cpufreq configs between -8.27 and the current -9. We are reviewing those changes now
[11:13] <amitk> ia: what is the current governor set to?
[11:14] <amitk> and the current driver to?
[11:14] <amitk> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
[11:27] <ia> amitk: >what is the current governor set to? // "performance" ; >scaling_driver // "acpi-cpufreq" ; and here section from my config with cpufreq related info - http://paste.ubuntu.com/130113 ; i've looked into generic config - there CONFIG_X86_ACPI_CPUFREQ have set as "Y"; so, maybe in this problem - i should try to change m to y in my config, but in my "make gconfig" configuration ACPI_CPUFREQ available only as module - y unavailable (maybe because some r
[11:27] <ia> elated for y-option modules disabled)
[11:30] <Mez> Question: if I put in nolapic, my system only shows 1 cpu, but i have dual core. Does this mean I'm only using one core??
[11:38] <amitk> ia: could you boot with -8.27 and check the values of scaling driver and scaling governor?
[11:52] <ia> amitk: well, i've just run sudo modprobe acpi-cpufreq, and scaling started working. I've added acpi-cpufreq in /etc/modules, reboot system, and frequency just works now. It's strange, that at previous versions scaling works without adding module in /etc/modules. However, sorry for worrying and thanks you very much for help :-)
[12:02] <ia> amitk: and another small question about this topic - so, if system uses acpi-cpufreq module, so can i safely remove from config X86_SPEEDSTEP_* modules?
[12:04] <amitk> ia: that is what is done in the -9 kernels. acpi-cpufreq is built-in (not a module) and given more precedence over SPEEDSTEP
[12:04] <amitk> check commit 495f78bd6d8f7a5e35dd962031eb6e639d83e438 in the git tree
[12:10] <lod_> hi, i've just noticed that there's no more /etc/modprobe.d/aliases
[12:11] <lod_> in jaunty devel
[12:11] <lod_> is there any replacement?
[12:12] <lod_> is it safe to rename aliases.dpkg-bak to aliases.conf ?
[12:12] <IntuitiveNipple> /etc/modprobe.d/arch/ ?
[12:12] <lod_> no arch
[12:12] <lod_> only .conf 's
[12:12] <IntuitiveNipple> oh yeah - that's in the initrd :)
[12:13] <lod_> i've got basic info on initrd
[12:14] <lod_> no knolege to mess with it
[12:16] <lod_> also another Q.
[12:16] <lod_> i've noticed that upon reboot, the system only reload fresh kernel
[12:16] <lod_> no BIOS or hardware reboot
[12:43] <lod_> please, how to use full reboot, not only kernel reloading
[15:44] <lesshaste> hi all
[16:52] <kees> apw: is there a specific bug for tracking the issue you brought up here: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027366.html
[16:53] <smb_tp> kees, apw won't listen today
[16:53] <kees> smb_tp: ah, dang.  does anyone else know?  ogasawara maybe?
[16:54] <smb_tp> kees, maybe. not sure
[16:54] <ogasawara> kees: I think there exists a bug for it, lemme search around and get back to you
[16:56] <kees> ogasawara: cool, thanks
[17:15] <dandel> ogasawara, ya still there?
[17:16] <dandel> you said you'd help a bit with describing how to do a git cross-section examination done, right... it's pertaining to bug #338701
[17:16] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
[17:28] <IntuitiveNipple> bug #292381
[17:28] <ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381
[17:55] <kees> IntuitiveNipple: ah! thanks
[18:02] <IntuitiveNipple> oh - was that OK? I thought you'd only just asked then after posting the link realised my IRC client had been disconnected for 1/2 hour :)
[19:19] <sashimi> Hello guys. I hope my question is not to much out of scope of the topic : does the ubuntu kernel (does the vanilla kernel) have eSata hot plug capability ?
[19:52] <VaSavoir> Hello, is there a place to discuss about event and so on on ubuntu, i want to catch event to detect partition changed, mount change, i already detect disk connection/deconnection, thank for your help
[23:13] <lesshaste> hi
[23:21] <Kano> hi, i have got a major issue with that ignore-hpa preset in -9 kernel
[23:22] <Kano> my raid does not work when this is default
[23:22] <Kano> on reboot without poweroff it even shows offline members
[23:23] <Kano> and what is also critical: ignore_hpa=0 does not work to set the default behaviour, at least it did not for me, maybe i missed some prefix.
[23:24] <Kano> please tell the users who currently need that hack to set the jumpers correctly - in many cases they are just set wrong
[23:24] <Kano> with 32 gbyte limit
[23:24] <Kano> and revert the change
[23:25] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=0d3c04214230d4340345a7a5d5353883b3299d9f
[23:25] <Kano> this is critical


[07:28] <dpm> hi wgrant, is there a way we can remove old merge proposals from https://code.launchpad.net/developer-ubuntu-com/+activereviews? I don't seem to be able to edit https://code.launchpad.net/~mpt/developer-ubuntu-com/bug-861031/+merge/77395 in any way.
[07:29] <dpm> it's not applicable any more, but its status has been "Approved" forever and I cannot change
[07:31] <wgrant> dpm: The branch owner on either end can set it to rejected.
[07:31] <dpm> wgrant, yeah, but he no longer works for Canonical or is part of the Ubuntu community
[07:32] <dpm> oh, on either end
[07:34] <dpm> mpt, could you set the status of https://code.launchpad.net/~mpt/developer-ubuntu-com/bug-861031 to "Rejected"? It would help us cleaning it up from the +activereviews view on the developer site code reviews
[08:09] <mpt> dpm, no, I don’t seem to have permission to change the status (and I wouldn’t want to even if I could)
[08:09] <wgrant> It's an MP into an abandoned non-trunk branch.
[08:09] <wgrant> I think you'd probably want to.
[08:10] <wgrant> (or delete it entirely)
[08:12] <mpt> It was trunk at the time I submitted it! (though I remember thinking at the time that it was a dodgy project structure)
[08:13] <dpm> mpt, in that case, setting it to Merged should probably do. Is that correct, wgrant?
[08:13] <dpm> I mean the status of the branch, not the MP
[08:13] <wgrant> The branch and MP statuses are unrelated.
[08:13] <mpt> I think I’ll resubmit it against the current trunk. The current page has pretty much exactly the same problem I was trying to fix three years ago.
[08:13] <wgrant> I'd suggest deleting the MP; it doesn't make sense against a non-trunk.
[08:14] <dpm> mpt, we're moving to django, that won't apply anymore
[08:18] <mpt> Okay. But regardless, if you find yourself itching to change the status of a three-year-old MP against a branch that you don’t even own, this suggests the problem is with Launchpad :-)
[08:19] <mpt> Specifically, that “Active reviews” is an interesting collection for a branch (e.g. trunk), but not so interesting for a project as a whole
[08:19] <wgrant> Sure. But the problem comes up infrequently and I can't fix that tonight.
[08:20] <mpt> naturally
[08:21] <dpm> mpt, we can only agree, but beyond that, and the fact that all three of us have enough on our plates, it'd be good to see if we could set the branch to a status where it no longer appears in active reviews. I'm happy to review a new branch that's against the current django trunk afterwards
[08:23] <mpt> dpm, understood. As I say, I don’t seem to have permission to change the merge proposal, and as far as I know, changing the status of the branch wouldn’t change the merge proposal either. I wouldn’t want to delete the branch outright, because I’ll want to use it as a reference when I make the new one.
[08:23] <wgrant> mpt: I'd suggest deleting the MP.
[08:23] <wgrant> That you can certainly do.
[08:23] <mpt> Oh! I was looking at the wrong page
[08:24] <mpt> done
[08:24] <dpm> great, thanks mpt!
[08:46] <mpt> Reported bug 1402973
[09:26] <apw> wgrant, i am looking at the +upcomingwork support in LP and wondering how that interacts with milestones without any dates, specifically i note that things against say precise-updates do not appear to show up; that has to be a bug right ?
[09:31] <wgrant> apw: IIRC it shows items for milestones in the next 90 days.
[09:32] <wgrant> It would be rather unmanageable if it showed all undated milestones too.
[09:33] <apw> wgrant, well, perhaps not if they were "unexpanded" for ones out further?
[09:33] <apw> wgrant, is there an unfiltered view as well?  as the other issue is if things are not done by the deadline, they just dissappear too
[09:34] <wgrant> apw: I don't believe so. IIRC Linaro implemented that view for their own purposes.
[09:35] <wgrant> I'm not quite sure why it's hardcoded, but that's unfortunately the way it is.
[09:35] <apw> damn, so nearly useful
[16:56] <legalize> I need some help deleting a bogus launchpad account, can anyone help me with that?
[17:01] <legalize> ugh, what a piece of crap
[17:01] <teward> legalize: probably posting a question against Launchpad Itself and getting help is a little more expedient
[17:01] <teward> i'm guessing people don't read the topics and see the "Support" section :p
[17:14] <dobey> how rude
[17:14] <teward> dobey: indeed!
[17:15] <teward> dobey: if everyone read the topics in a channel this world might be better.  *shrugs*
[17:15] <dobey> well even just ignoring the topic
[17:16] <dobey> rage-quitting isn't going to solve the problem
[17:16] <teward> true statement
[17:16] <dobey> i don't read the topic
[17:16] <dobey> they're usually way too long and a bunch of urls
[17:17] <dobey> they've become a description of where to go information elsewhere, and not a topic for the channel itself
[17:17] <teward> well, true, but in this case the topic links to answers.launchpad.net/launchpad so... *shrugs*
[17:17] <dobey> and i'm in way too many channels
[17:18] <dobey> teward: not in the ~160 chars that my irc client shows at the top of the screen
[17:18] <dobey> and this is the support irc channel for launchpad
[17:19] <dobey> so it's perfectly acceptable to ask support questions in it
[17:19] <teward> dobey: true, I ignore topics in most chanels as well :)
[17:19] <dobey> as you've done many times instead of posting quetions on answers.lp.net :)
[17:19] <teward> dobey: except ragequitting doesn't help, of course
[17:19] <teward> dobey: indeed!
[17:19] <teward> (although i have patience, and a lot of times my questions aren't admin-attention-required)
[17:21] <dobey> well, i don't know if his issue was or not either
[17:22] <dobey> it seemed like he was perhaps asking how to delete an account he had access to
[20:43] <sidi> teward, dobey you mean if Launchpad gave users a means to delete their account you wouldn't get those questions ;-)
[20:44] <teward> yes, but then we'd ahve the 'recover the account' problem if someone deleted their account or a mailicious hijacker did that
[20:44] <cjwatson> https://help.launchpad.net/YourAccount/Closing?action=show&redirect=DeactivatingYourAccount
[20:44] <cjwatson> er, indeed https://help.launchpad.net/YourAccount/Closing with less cruft
[20:45] <sidi> tbh if someone actively sabotages an account they can already do a lot of harm
[20:45] <cjwatson> but that's not actually quite what was asked
[20:45] <cjwatson> the original question appears (it's unclear) to be about deleting a different account
[20:50] <dobey> sidi: no, i'm sure we would
[20:51] <dobey> cjwatson: well, he just said "bogus" so it's not entirely clear to me what he was asking
[20:59] <cjwatson> dobey: Sure, it indeed wasn't clear, but sidi said "if Launchpad gave users a means to delete their account", and to most intents and purposes it does.
[20:59] <cjwatson> Anyway this is out of proportion to the actual support load caused; it's not a very common question here.
[20:59] <dobey> yes indeed


[07:31] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF added no-merge to [pull request #2731](https://github.com/MirServer/mir/pull/2731): Test review
[07:31] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2731](https://github.com/MirServer/mir/pull/2731): Test review
[07:31] -GitHub[m]:#mir-server-
[07:31] -GitHub[m]:#mir-server- > Temporary, for a technical interview
[07:31] -GitHub[m]:#mir-server- no-merge
[08:55] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF closed [pull request #2731](https://github.com/MirServer/mir/pull/2731): Test review
[14:28] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths assigned  to [pull request #2730](https://github.com/MirServer/mir/pull/2730): Sphinx integration


[00:04] <tjaalton> could debhelper 10 be backported to xenial?
[00:16] -queuebot:#ubuntu-release- New binary: ubiquity-slideshow-ubuntu [amd64] (zesty-proposed/main) [119] (kubuntu, ubuntu-desktop)
[00:19] <jbicha> tjaalton: it's in xenial-backports: https://launchpad.net/ubuntu/+source/debhelper
[01:13] -queuebot:#ubuntu-release- Unapproved: gnome-keyring (yakkety-proposed/main) [3.20.0-2ubuntu4 => 3.20.0-2ubuntu4.1] (ubuntu-desktop)
[01:18] -queuebot:#ubuntu-release- Unapproved: gnome-keyring (xenial-proposed/main) [3.18.3-0ubuntu2 => 3.18.3-0ubuntu2.1] (ubuntu-desktop)
[03:01] <tsimonq2> New fancy debhelper? :O
[05:14] -queuebot:#ubuntu-release- New binary: fifechan [i386] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: fifechan [ppc64el] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: fifechan [amd64] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: fifechan [arm64] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: fifechan [armhf] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: fifechan [powerpc] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: fifechan [s390x] (zesty-proposed/universe) [0.1.3-2] (no packageset)
[05:18] <tjaalton> jbicha: oh.. thx
[05:27] <valorie> weee, it's so good to see some of our KDE packages appear
[05:30] <tsimonq2> tjaalton: But the work there might not be done, actually.
[05:30] <tsimonq2> tjaalton: https://nthykier.wordpress.com/2016/09/11/debhelper-10-is-now-available/ - seems it doesn't recognize 10 as a stable release yet.
[05:30] <tjaalton> tsimonq2: yeah and I'd need it in -updates but doubt that'll happen.. best to just modify pkgs to not need 10
[05:37] <tsimonq2> tjaalton: Hmm, why is that?
[05:37] <tjaalton> mesa migrated to it
[05:37] <tsimonq2> tjaalton: Why can't mp up one? Just curious what breaks...
[05:37] <tsimonq2> *we bump
[05:37] <tjaalton> dunno, just not gonna happen anytime soon
[05:38] <tsimonq2> O_o
[05:39] <tjaalton> actually, since backports has it it's good enough for me for now
[06:45] -queuebot:#ubuntu-release- New: accepted dropwizard-metrics [amd64] (zesty-proposed) [3.1.2-1]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [arm64] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [i386] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [ppc64el] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [amd64] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [s390x] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [armhf] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [powerpc] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [s390x] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [amd64] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [powerpc] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [powerpc] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [i386] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [armhf] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [arm64] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted fifechan [s390x] (zesty-proposed) [0.1.3-2]
[06:45] -queuebot:#ubuntu-release- New: accepted simgrid [ppc64el] (zesty-proposed) [3.14.159-1]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [arm64] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [i386] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [armhf] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[06:45] -queuebot:#ubuntu-release- New: accepted seafile [ppc64el] (zesty-proposed) [6.0.1+git20161227.5f030ac-1]
[07:53] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.7]
[09:35] <xnox> mwhudson, the updated runc in 1.12.3 docker.io appears to be no worky on s390x at all.
[10:12] <apw> xnox, you are sure it is the runc which causes the issue here ?  the delta from what was there before is very small
[10:17] <xnox> apw, pretty sure.
[10:17] <xnox> apw, will test in a bit. Let me show the pastebin.
[10:19] <apw> xnox, i am saying that downgrading docker.io itself and leaving runc upgraded is also a fail
[10:20] <xnox> correct
[10:20] <xnox> docker.io is irrelevant, as it execs containerd, which execs runc, which bubbles up the error
[10:20] <xnox> apw, http://paste.ubuntu.com/23832610/
[10:20] <apw> xnox, most unexpected, what version of runc works ?
[10:20] <xnox> is the update to libseccomp which is present in docker.io & containerd, but not in runc.
[10:21] <xnox> runc from zesty-proposed is all good
[10:21] <xnox> currently triggered ADT tests to get that to migrate.
[10:21] <xnox> after that will take this seccomp_internal.go vendorized update, rebuild runc with just that, and hopefully push that out as SRU to yakkety & xenial asap.
[10:21] <apw> xnox, that does seem like a good idea, if we can get that migrated, we can get it backported :)
[10:22] <xnox> yeap =) backporting everything may be easier ;-)
[10:22] <apw> xnox, as the versio in zesty release and those are the same
[10:22] <apw> currently, so it seems reasonable to continue to do that
[10:26] <xnox> apw, however docker-in-lxd is failing
[10:26] <xnox> adt test (did rerun now) maybe i need to add "&trigger=lxd" or some such.
[10:27] <xnox> nope, there is no new lxd..... i wonder if lxd does not let the new docker do seccomp =(
[10:33] <xnox> apw, if the ADT fails for zesty, i'll start a silo with SRU for seccomp via bileto - such that we have a PPA for yakkety/xenial and can see ADT test results before shoving it in.....
[11:01] <apw> xnox, sounds plausible, and the plan too
[11:04] <xnox> ticket for yakkety https://bileto.ubuntu.com/#/ticket/2388
[11:04] <xnox> ticket for xenial https://bileto.ubuntu.com/#/ticket/2389
[11:04] <xnox> apw, cherrypick of the seccomp patch, upgrading runc on yakkety results in container to start, when previously it did not.
[11:05] <xnox> no need to restart docker.service or anything like that. Will upload things into tickets shortly.
[11:15] <apw> xnox, ack
[11:35] <xnox> https://bileto.ubuntu.com/#/ticket/2388 built and validated on yakkety that it is all good; adt tests / automated signoff is now pending
[11:35] <xnox> for the 2389 waiting for packages to be published
[11:36] <xnox> actually they look to be published too
[11:59] -queuebot:#ubuntu-release- New source: xf86-input-mtrack-hwe-16.04 (xenial-proposed/primary) [0.3.1-1build1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-evdev-hwe-16.04 (xenial-proposed/primary) [1:2.10.2-1ubuntu1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-libinput-hwe-16.04 (xenial-proposed/primary) [0.19.0-1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-vmmouse-hwe-16.04 (xenial-proposed/primary) [1:13.1.0-1ubuntu2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-amdgpu-hwe-16.04 (xenial-proposed/primary) [1.1.2-1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-cirrus-hwe-16.04 (xenial-proposed/primary) [1:1.5.3-1ubuntu3~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-fbdev-hwe-16.04 (xenial-proposed/primary) [1:0.4.4-1build5~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-geode-hwe-16.04 (xenial-proposed/primary) [2.11.18-2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-mach64-hwe-16.04 (xenial-proposed/primary) [6.9.5-1build2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xf86-input-wacom-hwe-16.04 (xenial-proposed/primary) [1:0.33.0-0ubuntu1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-synaptics-hwe-16.04 (xenial-proposed/primary) [1.8.3-1ubuntu1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-ati-hwe-16.04 (xenial-proposed/primary) [1:7.7.1-1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-freedreno-hwe-16.04 (xenial-proposed/primary) [1.4.0-1build1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-mga-hwe-16.04 (xenial-proposed/primary) [1:1.6.4-1build2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-joystick-hwe-16.04 (xenial-proposed/primary) [1:1.6.2-1build4~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-dummy-hwe-16.04 (xenial-proposed/primary) [1:0.3.7-1build5~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-input-void-hwe-16.04 (xenial-proposed/primary) [1:1.4.1-1build2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-intel-hwe-16.04 (xenial-proposed/primary) [2:2.99.917+git20160706-1ubuntu1~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-neomagic-hwe-16.04 (xenial-proposed/primary) [1:1.2.9-1build2~16.04.1]
[11:59] -queuebot:#ubuntu-release- New source: xserver-xorg-video-openchrome-hwe-16.04 (xenial-proposed/primary) [1:0.3.3+git20160310-1~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-r128-hwe-16.04 (xenial-proposed/primary) [6.10.1-1~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-siliconmotion-hwe-16.04 (xenial-proposed/primary) [1:1.7.8-1ubuntu6~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-tdfx-hwe-16.04 (xenial-proposed/primary) [1:1.4.6-1build2~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-vesa-hwe-16.04 (xenial-proposed/primary) [1:2.3.4-1build2~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-nouveau-hwe-16.04 (xenial-proposed/primary) [1:1.0.12-2~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-savage-hwe-16.04 (xenial-proposed/primary) [1:2.3.8-1ubuntu3~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-trident-hwe-16.04 (xenial-proposed/primary) [1:1.3.7-1build2~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-qxl-hwe-16.04 (xenial-proposed/primary) [0.1.4-3ubuntu3~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-vmware-hwe-16.04 (xenial-proposed/primary) [1:13.1.0-2ubuntu3~16.04.1]
[12:00] -queuebot:#ubuntu-release- New source: xserver-xorg-video-sisusb-hwe-16.04 (xenial-proposed/primary) [1:0.9.6-2build5~16.04.1]
[12:14] -queuebot:#ubuntu-release- New source: xorg-server-hwe-16.04 (xenial-proposed/primary) [2:1.18.4-1ubuntu6.1~16.04.1]
[12:21] -queuebot:#ubuntu-release- New source: xorg-hwe-16.04 (xenial-proposed/primary) [1:7.7+13ubuntu4~16.04.1]
[12:35] -queuebot:#ubuntu-release- Unapproved: vulkan (xenial-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1 => <IP_ADDRESS>+dfsg1-1~16.04.1] (no packageset)
[14:10] <slangasek> tseliot: I can cover the nusakan side next week if alpha2 is happening
[14:11] <slangasek> er, sorry
[14:11] <slangasek> tsimonq2: I can cover the nusakan side next week if alpha2 is happening
[14:24] <clivejo> for security updates to xenial and yakkety, is it only the security team can do that?
[14:25] <acheronuk> upload?
[14:25] <clivejo> yes, upload
[14:39] <apw> clivejo, normally they are built in the security PPA so they are only built against that pocket
[14:39] <apw> tyhicks, ^ i assume they need to come through one of your sponsors
[14:51] <tyhicks> apw: that's correct
[14:51] <tyhicks> clivejo: hey - is there something you need the security team to sponsor?
[14:52] <tyhicks> clivejo: my spidey sense tells me that you may be asking about sponsoring the ark upload - is that right?
[14:52] <clivejo> yes
[14:53] <tyhicks> clivejo: it is in our sponsoring queue and we'll get to it soon
[14:53] <clivejo> https://bugs.launchpad.net/ubuntu/+source/ark/+bug/1655507
[14:53] <tyhicks> clivejo: I'll see if we can bump it up in the queue
[14:54] <clivejo> can you backport the same patch to xenial?
[14:54] <clivejo> can I upload those packages or does it have to go via your team?
[15:03] <tyhicks> clivejo: it has to go via our team
[15:04] <tyhicks> clivejo: we won't be able to do the xenial backport - can you provide a debdiff in the bug?
[15:05] <tyhicks> clivejo: hmm, now I'm confused because you already attached a xenial debdiff in the bug (https://bugs.launchpad.net/ubuntu/+source/ark/+bug/1655507/comments/2)
[15:06] <clivejo> mine hasnt got a compliant changelog entry
[15:07] <clivejo> and I'm just about to go out the door
[15:07] -queuebot:#ubuntu-release- Unapproved: sosreport (yakkety-proposed/main) [3.3-1 => 3.3+git50-g3c0349b-2~ubuntu16.10.1] (ubuntu-desktop, ubuntu-server)
[15:08] <tyhicks> clivejo: ratliff can probably fix up the changelog entry when sponsoring
[15:09] <tyhicks> ratliff: it looks like you can steal the changelog from the yakkety debdiff
[15:09] <tyhicks> clivejo: going forward, please make sure that the debdiffs are ready to be sponsored when attaching them to the bug
[15:10] <xnox> apw, automated testing passed (docker.io tests) and manual looks good too. I will sync runc into yakkety-proposed and xenial-proposed unaproved queues.
[15:10] <xnox> the bug template should be correct, please accept them =)
[15:11] <xnox> the diff will not be in the queue, but one can access the content.diff at https://bileto.ubuntu.com/#/ticket/2388 and https://bileto.ubuntu.com/#/ticket/2389
[15:11] <xnox> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2389/2017-01-20_11:36:03/xenial_runc_content.diff
[15:11] <xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2388/2017-01-20_11:31:44/yakkety_runc_content.diff
[15:15] -queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc1-0ubuntu2~16.04.1 => 1.0.0~rc1-0ubuntu2~<IP_ADDRESS>] (no packageset) (sync)
[15:15] -queuebot:#ubuntu-release- Unapproved: runc (yakkety-proposed/universe) [1.0.0~rc1-0ubuntu2~16.10.1 => 1.0.0~rc1-0ubuntu2~<IP_ADDRESS>] (no packageset) (sync)
[15:16]  * apw will review those ^
[15:17] <apw> and hate on launchpad for a bit because diffs
[15:19] <xnox> tah.
[15:20] <apw> your versions are a bit odd, 1.1 rather than .2, but meh
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted runc [sync] (yakkety-proposed) [1.0.0~rc1-0ubuntu2~<IP_ADDRESS>]
[15:28] <ratliff> tyhicks, clivejo: ack, will start work on ark sponsorship in about an hour
[15:28] <tyhicks> thank you!
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted runc [sync] (xenial-proposed) [1.0.0~rc1-0ubuntu2~<IP_ADDRESS>]
[15:33] -queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.12+16.04ubuntu1 => 0.14+16.04ubuntu2] (no packageset)
[15:33] -queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.12+16.10ubuntu1 => 0.14+16.10ubuntu2] (no packageset)
[15:49] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-49-g9e904bb-0ubuntu1~16.04.4 => 0.7.9-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (xenial-proposed) [1.8.16-0ubuntu1.3]
[15:55] <sil2100> barry: hey! You could have re-uploaded as ubuntu1 again, since I'm just rejecting the previous upload anyway - but ubuntu2 is fine as well
[15:55] <sil2100> Handling it now ;)
[15:55] <barry> sil2100: yep, but i like moving forward.  better for tagging and tracking.  thanks for approving!
[15:55] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (xenial-proposed) [0.14+16.04ubuntu1]
[15:56] <sil2100> (rejecting the old ones first)
[15:56] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (yakkety-proposed) [0.14+16.10ubuntu1]
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.14+16.04ubuntu2]
[16:03] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.14+16.10ubuntu2]
[16:36] <tsimonq2> slangasek: Ok, could you please put your name on the wiki if you haven't already?
[16:43] <acheronuk> hi release team. could you please force-badtest baloo-widgets5/4:16.12.1-0ubuntu1 please?
[16:44] <acheronuk> upstream KDE developers are telling us that is safe to ignore
[16:48] -queuebot:#ubuntu-release- Unapproved: rejected crash [source] (xenial-proposed) [7.1.4-1ubuntu5]
[16:50] <apw> acheronuk, looking
[16:56] <apw> acheronuk, done
[16:56] <acheronuk> apw: thank you :)
[17:03] <slangasek> tsimonq2: I haven't done so yet and my browser is somewhat occupied at the moment, feel free to put my name in for me :)
[17:09] -queuebot:#ubuntu-release- Unapproved: crash (xenial-proposed/main) [7.1.4-1ubuntu4 => 7.1.4-1ubuntu4.1] (core)
[17:11] <xnox> internet on diamond is so slow......
[17:14] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (xenial-proposed) [7.1.4-1ubuntu4.1]
[17:15] -queuebot:#ubuntu-release- New binary: golang-glide [ppc64el] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: instant [amd64] (zesty-proposed/universe) [2016.2.0-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: golang-glide [armhf] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: golang-glide [i386] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: fiat [amd64] (zesty-proposed/universe) [2016.2.0-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: golang-glide [amd64] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: git-annex-el [amd64] (zesty-proposed/none) [1.0+git20160215.e61ef24-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: php-geos [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: php-geos [i386] (zesty-proposed/none) [1.0.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: ufl [amd64] (zesty-proposed/universe) [2016.2.0-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: golang-glide [arm64] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: golang-glide [s390x] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:23] <xnox> slangasek, we have a regression-updates and a fix in -proposed. https://bugs.launchpad.net/ubuntu/+source/runc/+bug/1658009 could you please consider releasing it into -updates expedited? e.g. today or on monday?
[17:23] -queuebot:#ubuntu-release- New binary: golang-glide [powerpc] (zesty-proposed/universe) [0.12.3-2] (no packageset)
[17:27] <slangasek> xnox: targeted fix? +1; looking now
[17:33] <xnox> slangasek, an update to a vendorised library that did not include if nativearch=s390x return s390x.
[17:33] <xnox> slangasek, in normal world we would have updated golang-libseccomp once, instead of have that update in docker.io; in containerd; and missed in runc.
[17:34] <xnox> slangasek, also I have not yet investigated how did runc sru got published in yakkety and xenial; when it did not at all was capable to launch any container.
[17:34] <xnox> this has been fixed in runc rc2 in zesty-proposed; stuck because docker-in-lxd test is currently failing in zesty at the moment.
[17:35] <slangasek> xnox: not capable on any architecture, or on !x86?
[17:36] <xnox> not capable on s390x
[17:36] <xnox> it was fine on amd64
[17:36] <slangasek> ok
[17:37] <slangasek> I don't imagine cross-arch testing is part of the SRU test plan
[17:37] <xnox> not sure if somebody else !x86 is also bad, as ppc64el appears to be working.
[17:37] <slangasek> did it fail autopkgtests?
[17:38] <bdmurray> cjwatson: Could you set a driver or bug supervisor for ubuntu-archive-tools?
[17:38] <xnox> based on http://autopkgtest.ubuntu.com/packages/docker.io/yakkety/s390x the docker.io test, with bad runc as a trigger passed on s390x
[17:38] <xnox> slangasek, ^ clearly adt test is insufficient then; opening a bug for me to look at in two weeks time after vac.
[17:39] <slangasek> xnox: ack
[17:40] <xnox> https://bugs.launchpad.net/ubuntu/+source/runc/+bug/1658150
[17:40] <xnox> 17.02
[17:49] -queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (yakkety-proposed) [2.2.4-4ubuntu<IP_ADDRESS>]
[17:50] -queuebot:#ubuntu-release- Unapproved: vlc (yakkety-proposed/universe) [2.2.4-4 => 2.2.4-4ubuntu<IP_ADDRESS>] (mozilla, mythbuntu)
[17:50] <cjwatson> bdmurray: I've just changed the maintainer to ~ubuntu-archive
[17:53] -queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (yakkety-proposed) [2.2.4-4ubuntu<IP_ADDRESS>]
[18:48] <slangasek> xnox: oh right, the autopkgtest passing for docker is because s390x is autopkgtest in lxd
[19:05] <rtg> can someone tell me why linux 4.9.0-12.16 isn't promoting ? I'm not getting much out of brittny update excuses
[19:07] <rtg> or linux-meta 4.9.0-12.16, rather
[19:26] <infinity> rtg: Because of 3 blocking bugs.
[19:26] <infinity> apw: ^-- Who's currently on the hook for checking your autopkgtest matrix and then clearing blocking bugs?
[19:27] <rtg> those are just tracking bugs
[19:28] <rtg> do I have to clear the block-proposed tag on all of them ?
[19:29] <infinity> rtg: Yes, but we don't generally do that until we're happy with the testing matrix (which is a manual review process, since britney's view of kernel testing is wrong).
[19:30] <rtg> infinity, the ADT test matrix, or the bjf SRU tests ?
[19:30] <infinity> rtg: The adt matrix, ie: http://people.canonical.com/~kernel/status/adt-matrix/zesty-linux-meta.html
[19:32] <rtg> infinity, I'm mostly happy with the ADT test matrix (if you ignore systemd and glibc test failures)
[19:39] <infinity> rtg: The glibc one is a false negative.
[19:44] <rtg> infinity, last time you checked you said the same thing about systemd
[19:48] <infinity> rtg: I'm not sure I was ever convinced that the systemd failure isn't the kernel's fault, but I think by the time I looked, it was no longer a regression between release and proposed. :P
[19:48] <infinity> rtg: And it needs Real Debugging to figure out WTF is actually wrong.
[19:48] <infinity> Which none of us have done.
[19:49] <infinity> (By that same metric, it's still not a regression, but I do think we need to understand it before release)
[19:50] <apw> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1658178
[19:50] <apw> i've filed a bug ...
[19:50] <rtg> infinity, so, should it hold up this promotion ? I'm not seeing any problems that look like systemd with the previous release
[19:50] <infinity> apw: Last I looked, it was a bit of a weird one.  It didn't seem like tests were failing, but that the mid-test reboot was failing.
[19:50] <rtg> previous release of the Zesty 4.9 kernel
[19:50] <infinity> apw: Which is... Special.
[19:51] <apw> infinity, whats special ?
[19:51] <infinity> rtg: This looks fine to release from the "not regressed from previous zesty" POV.  Just saying we want to double back on any red in that matrix between now and final release (by feature freeze would be better).
[19:51] <infinity> apw: The line above? :P
[19:52] <rtg> infinity, ok
[19:52] <apw> infinity, i'll get some bugs filed for all the red and get them on our lists
[19:52] <rtg> apw, is it just the block-proposed tags holding up brittny ?
[19:53] <infinity> rtg: And I realise it'll all go topsy-turby again when 4.10 lands (when is that?), but yeah.  We need to drive that matrix to green by release, so it's useful for SRUs (and so we don't have obvious regressions from the previous release).
[19:53] <infinity> rtg: block-proposed is what's causing it to hate you right now.
[19:53] <infinity> rtg: Then it'll be d-i, which I'll fix right now.
[19:55] <acheronuk> release team: could you please force-badtest another for us? libkdegames/4:16.12.1-0ubuntu1
[19:55] <rtg> infinity, 4.10 is a couple weeks out yet.
[19:56] <acheronuk> this one has been failing in debian since august, and on ours for some time as well I believe
[19:57] <rtg> infinity, alright, tags are cleared
[19:57] <acheronuk> I plan to either try and fix it with debian by the time we have a 16.12.2 to upload, or disable the test if it is not actually useful or fixable
[20:00] <infinity> rtg: You'll want to add it back for the unreleased kernel once it happens.
[20:01] <infinity> Err, once this migrates.
[20:01] <rtg> infinity, not sure what you mean. I'm creating new tracking bugs for each upload.
[20:02] <infinity> rtg: I assume you cleared the tag from all the bugs that britney was referencing?
[20:02] <infinity> rtg: If so, some of those bugs are for future kernels you haven't uploaded yet. :P
[20:02] <rtg> infinity, I did, and now see that -15.16 was one of those.
[20:02] <apw> rtg, you have bugs for the ones in CKT PPA which are also incorrectly blocking britney, once that migrates you need to put it back before it gets out to -proposed
[20:03] <rtg> apw, will do.
[20:03] <rtg> I'm surprised that brittny pays attention to the ckt PPA
[20:03] <infinity> It doesn't.
[20:03] <infinity> It pays attention to bugs.
[20:04] <infinity> And LP bugs don't have version info.
[20:04] <rtg> makes sense
[20:04] <infinity> So, it pays attention to *all* open bugs against "linux" in "zesty" with the block tags.
[20:07] <infinity> rtg: d-i uploaded, once that's built, it should all sail through.
[20:07] <rtg> infinity, cool, thanks for your help.
[20:26] <tsimonq2> slangasek: Ok.
[20:31] <tsimonq2> infinity: Just out of curiosity, is there a page explaining why we have a 493 long delta on debian-installer?
[20:31] <tsimonq2> I'm curious. :P
[20:35] -queuebot:#ubuntu-release- Unapproved: indicator-application (xenial-proposed/main) [12.10.1+15.04.20150128-0ubuntu1 => 12.10.1+16.04.20170120-0ubuntu1] (ubuntu-desktop) (sync)
[20:58] <infinity> tsimonq2: Nope.
[21:02] <tsimonq2> infinity: So then why? :) *puppy eyes*
[21:20] -queuebot:#ubuntu-release- Unapproved: indicator-application (yakkety-proposed/main) [12.10.1+15.04.20150128-0ubuntu1 => 12.10.1+16.10.20170120-0ubuntu1] (ubuntu-desktop) (sync)
[23:05] <clivejo> how long does it usually take to get NEW packages processed?
[23:05] <clivejo> new binary I mean
[23:12] -queuebot:#ubuntu-release- New: accepted fiat [amd64] (zesty-proposed) [2016.2.0-2]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [amd64] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [armhf] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [powerpc] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [s390x] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted php-geos [amd64] (zesty-proposed) [1.0.0-1]
[23:12] -queuebot:#ubuntu-release- New: accepted ufl [amd64] (zesty-proposed) [2016.2.0-2]
[23:12] -queuebot:#ubuntu-release- New: accepted git-annex-el [amd64] (zesty-proposed) [1.0+git20160215.e61ef24-1]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [i386] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted instant [amd64] (zesty-proposed) [2016.2.0-2]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [arm64] (zesty-proposed) [0.12.3-2]
[23:12] -queuebot:#ubuntu-release- New: accepted php-geos [i386] (zesty-proposed) [1.0.0-1]
[23:12] -queuebot:#ubuntu-release- New: accepted golang-glide [ppc64el] (zesty-proposed) [0.12.3-2]
[23:48] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-80.88~14.04.1]
[23:48] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-62.83~14.04.1]


[19:11] <lazarus_> hi 4
[19:11] <lazarus_> hi*
[19:18] <lazarus_> i've been looking to optimise some code that i put together since i know there are like 100 ways to write shell scripts http://pastebin.com/1wsBDd8d