[12:08] <airurando> afternoon
[12:08] <zmoylan-pi> o/
[12:09] <airurando> I came across old college floppies and id like to get the data off them.
[12:09] <zmoylan-pi> ooooh a challenge...
[12:09] <airurando> I have a usb floppy drive.
[12:09] <zmoylan-pi> i'm thinking....
[12:09] <zmoylan-pi> ah then you're sorted?
[12:09] <airurando> not sure if the disks are good nor am i sure if the drive is good
[12:10] <zmoylan-pi> ah
[12:10] <zmoylan-pi> no work pc with a floppy drive?
[12:10] <airurando> it doesn't appear to work automagically
[12:10] <airurando> no pc left in house with floppy drive
[12:11] <zmoylan-pi> i could probably rustle up a floppy drive but i have no motherboard it would talk to
[12:12] <airurando> any ideas on how i can check the drive?
[12:12] <airurando> should it just mount when a disk is inserted?
[12:13] <zmoylan-pi> i haven't used a floppy drive with linux since about red hat 5.2 :-)
[12:13] <zmoylan-pi> i would assume on ubuntu it would
[12:14] <airurando> grand
[12:15] <airurando> hope you are keeping well zmoylan-pi
[12:15] <zmoylan-pi> may not be automagic on ubuntu... http://askubuntu.com/questions/168597/how-do-i-use-a-floppy-drive-in-ubuntu
[12:16] <zmoylan-pi> getting by airurando, yourself?
[12:18] <airurando> not to bad here


[14:08] <sillyslux> lol https://www.bug.hr/forum/topic/komentari-clanaka-bughr/prica-o-zivotu-dvojice-vrhunskih-hrvatskih-develop/256883.aspx?page=0&jumpto=5609029&sort=asc&view=flat
[15:02] <jelly> lol -17
[15:02] <jelly> .weather maksimir
[15:03] <datase> jelly: Weather for Maksimir, Croatia | Temperature: 25°F / -4°C; Humidity: 39%; Conditions: Partly cloudy; Wind: Ne, 11mph / 18kph; Updated: 1 hr, 3 mins, 0 secs ago | Forecast for Sunday: Overcast; High of 23°F / -5°C; Low of 9°F / -13°C | Forecast for Monday: Overcast; High of 22°F / -6°C; Low of 12°F / -11°C | Forecast for Tuesday: Overcast; High of 20°F / -7°C; Low of 2°F / -17°C | Forecast for (1 more message)
[15:03] <jelly> .more
[15:03] <datase> jelly: Wednesday: Partly cloudy; High of 23°F / -5°C; Low of 2°F / -17°C | Forecast for Thursday: Mostly cloudy; High of 26°F / -3°C; Low of 20°F / -7°C | Forecast for Friday: Ice pellets; High of 32°F / 0°C; Low of 26°F / -3°C
[15:03] <jelly> > Forecast for Friday: Ice pellets; High of 32°F / 0°C; Low of 26°F / -3°C
[15:03] <jelly> nisam nikad vidio da je tuča prognozirana toliko unaprijed
[15:04] <CrazyLemon> ice pellets == hail ?
[15:08] <jelly> valjda
[15:09] <jelly> zapravo ne, piše da je to kiša koja se smrzne prije pada
[15:09] <CrazyLemon> yup..to je ona kiša koja boli :D
[15:09] <jelly> > Ice pellets are smaller than hailstones
[15:09] <jelly> https://en.wikipedia.org/wiki/Ice_pellets
[15:09] <datase> ^ Ice pellets are a form of precipitation consisting of small, translucent balls of ice. Ice pellets are smaller than hailstones which form in thunderstorms rather than in winter, and are different from graupel which is made of frosty...
[15:10] <jelly> nema stranice na hrvatskom, al na srpskoj wp se zove sugradica https://sr.wikipedia.org/sr-el/%D0%A1%D1%83%D0%B3%D1%80%D0%B0%D0%B4%D0%B8%D1%86%D0%B0
[15:11] <jelly> > prečnik dostiže maksimalno do pet milimetara
[15:11] <CrazyLemon> 'sodra' u sloveniji :)
[15:12] <CrazyLemon> https://en.wikipedia.org/wiki/Graupel
[15:12] <datase> ^ Graupel, also called soft hail or snow pellets, is precipitation that forms when supercooled water droplets are collected and freeze on falling snowflakes, forming 2–5 mm balls of rime. The term graupel comes from the German language.


[01:25] <roaksoax> bigjools: yeah I saw that.. i'm not sure how to fix it because locally it builds just fine
[01:26] <bigjools> roaksoax: oh really? I didn't try I just assumed, how naive. So what's the difference locally?
[01:27] <roaksoax> bigjools: i build locally against a pbuilder
[01:27] <roaksoax> bigjools: so it might be the build environment that's broken.. or maybe the recipe?
[01:28] <roaksoax> bigjools: the reason might be that it is not detecting the source format?
[01:28] <bigjools> roaksoax: I was told that it's bzr's fault
[01:28] <bigjools>  bzr-builder will convert from 3.0 (quilt) to 3.0 (native) if you don't have pristine-tar information
[01:29] <bigjools> and previously dpkg didn't care until a recent trusty upload
[01:29] <roaksoax> bigjools: where is the recipe that builds the package?
[01:30] <rawang> hello, guy, just a quick question, how can i force maas to update the dns record based on the its dhcp lease file?
[01:31] <freeflying> if there is a new record in dhcpd.leases, any reason why hasn't maas has it update into dns? I have restart celery on both region and cluster controller
[01:31] <rawang> in my case , new node added, but failed to add dns record in the zone file
[01:31] <bigjools> is the interface set to manage dhcp/dns?
[01:31] <rawang> bigjools, yes
[01:32] <bigjools> can you see errors in either celery log?
[01:32] <rawang> bigjools, you mean celery logs on region controller?
[01:32] <bigjools> and cluster
[01:34] <roaksoax> bigjools: so maybe bzr is not creating a pristine tarballs then
[01:34] <bigjools> roaksoax: https://code.launchpad.net/~maas-maintainers/+recipe/maas-daily-trusty
[01:34] <bigjools> roaksoax: correct, I think
[01:35] <rawang> bigjools, i don't think i have see the error in  celery logs on both nodes, but i can see 0AuthUnauthorized error in maas.log
[01:35] <bigjools> has this ever worked?
[01:36] <rawang> OAuthUnauthorized
[01:37] <bigjools> have you ever had a DNS entry updated correctly?
[01:38] <rawang> bigjools, yes
[01:38] <bigjools> rawang: ok so what has changed since then?
[01:38] <rawang> bigjools, nothing changes
[01:38] <bigjools> do you keep a log of anything you configure?
[01:38] <roaksoax> bigjools: ok it seems it might be the versioning being used
[01:39] <bigjools> roaksoax: yes, exactly right. it needs a pristine tar for that style
[01:39] <rawang> bigjools, we added a node in maas, enlist, commission, but juju add-unit, when the unit is started, we're trying to ssh ,and the hostname is able to be resolved. that's about it
[01:39] <rawang> s/but/and/
[01:39] <bigjools> rawang: ok one moment
[01:40] <rawang> ok :)
[01:40] <roaksoax> bigjools: nope, I think it might be a bug somewhere..., the error asks for a native package 3.0 (native), when in reality it is a 3.0 (quilt)
[01:40] <roaksoax> it is trying to build the package as native, and antive packages do not have the debian revisions
[01:40] <bigjools> roaksoax: because bzr-builder converts it to native
[01:41] <roaksoax> bigjools: should it do that thoguh? the package is a 3.0 (quilt) not native
[01:41] <roaksoax> the problem might be related to having a debian revision i.e. 1.4-0ubuntu1
[01:41] <roaksoax> the debien revision is '-0'
[01:41] <bigjools> ok
[01:42] <roaksoax> which is intended
[01:42] <bigjools> rawang: ok can you run "maas shell" and then type these lines:
[01:43] <rawang> ok
[01:43] <bigjools> from maasserver.models import DHCPLease
[01:43] <bigjools> DHCPLease.objects.all()
[01:43] <bigjools> and tell me if you see your node's IP
[01:45] <rawang> bigjools, the output is truncated, how do i see the full output?
[01:45] <bigjools> how many nodes do you have?!
[01:46] <rawang> bigjools, currently 33
[01:46] <bigjools> rawang: try:
[01:46] <bigjools> for l in DHCPLease.objects.all():
[01:46] <bigjools>     print l.mac,l.ip
[01:47] <rawang> k
[01:47] <roaksoax> bigjools: can't we tell bzr to not create a native package?
[01:47] <bigjools> roaksoax: no idea!
[01:47] <bigjools> don't think you can
[01:47] <bigjools> roaksoax: go to #launchpad-dev and ask stevek or wgrant
[01:48] <bigjools> stevenk even
[01:48] <rawang> bigjools, well, I don't think I have seen my new node's IP
[01:48] <roaksoax> bigjools: k, i;'ll have to check on tahat tomorrow
[01:48] <roaksoax> i'm off now
[01:48] <roaksoax> ttyl
[01:48] <bigjools> rawang: ok then there is the problem.
[01:48] <bigjools> roaksoax: ok cheers, good night
[01:49] <bigjools> rawang: the celery job on the cluster controller parses the dhcp leases file. Can you check to se if it  threw any errors, and can you manually check the actual leases file for your mac
[01:49] <bigjools> see if there is a host{} entry for it as well
[01:51] <rawang> bigjools, yes, there is a host() entry for new node in /var/lib/maas/dhcp/dhcp.lease file,  this node was added/removed a few days ago
[01:51] <bigjools> rawang: is there a current lease?
[01:51] <wgrant> roaksoax: It will fall back to a native package if thrre's no pristine-tar metadata to allow it to recreate the orig.tar.*. Since you can't really create a non-native package without the orig tarball.
[01:54] <rawang> bigjools, well the node's IP is <IP_ADDRESS> (we can ssh into via this IP), and we have seen this record in dhcp.leases, the only problem is the record  was recorded on 11.20 ->
[01:54] <rawang> https://pastebin.canonical.com/101021/
[01:55] <bigjools> rawang: is that the most recent lease entry?  It has expired, which is why maas is not writing the dns entry.
[01:55] <roaksoax> wgrant: so what's the recommended way to fix this?
[01:56] <rawang> bigjools, that's the most recent lease entry
[01:56] <bigjools> rawang: ok, on the node, can you look at syslog to see if there's any dhclient errors?
[01:56] <bigjools> is dhclient running?
[01:56] <rawang> let me check
[01:58] <rawang> bigjools, seems like there is no error for dhclient on client side.
[01:58] <rawang> Nov 26 10:55:15 74ctp dhclient: DHCPRELEASE on bond0.203 to <IP_ADDRESS> port 67
[01:58] <rawang> <IP_ADDRESS> is the maas cluster controller's ip
[01:59] <rawang> Nov 26 10:55:24 74ctp dhclient: bound to <IP_ADDRESS> -- renewal in 17171 seconds.
[02:00] <rawang> bigjools, more dhclient logs https://pastebin.canonical.com/101022/
[02:01] <rawang> bigjools, so client get the ip, but it does not update the maas lease file with latest date, and maas celery failed to add the new dhcp entry to dns record
[02:01] <rawang> bigjools, is there any command/option to reload maas dns record from dhcp lease
[02:01] <bigjools> rawang: so can you find a matching entry in the maas dhcp server log?
[02:01] <bigjools> is there a rogue dhcp server?
[02:02] <rawang> bigjools, :)   I don't get what do you mean by rogue dhcp server?
[02:02] <wgrant> roaksoax: You need to include pristine-tar metadata in the branch
[02:02] <wgrant> Using 'bzr import-upstream', for example.
[02:02] <roaksoax> wgrant: ok, thanks!
[02:03] <bigjools> rawang: is there another dhcp server apart from the maas-controlled one?
[02:03] <bigjools> you need to find out where the node got that lease from
[02:03] <rawang> bigjools, there are two dhcp services running on maas cluster controller, one for maas managed interface for dns/dhcp , and another dhcpd daemon for the rest of the interfaces.
[02:04] <bigjools> rawang: and they are *definitely* serving different interfaces?
[02:04] <bigjools> can you find the lease in the other dhcp daemon's lease file?
[02:05] <rawang> bigjools, yes, they are definitely server  different interface without any problem for the current nodes
[02:06] <rawang> bigjools, yes, there are two dhcp.lease, one in /var/lib/maas/dhcp/dhcp.lease, the other one is in /var/lib/dhcp/dhcp.leases
[02:06] <bigjools> rawang: ok you need to find that lease in a server daemon log or lease file
[02:06] <bigjools> I need to know where it came from
[02:06] <rawang> bigjools, the one I paste is from /var/lib/maas/dhcp/dhcp.leases
[02:07] <bigjools> ok
[02:13] <bigjools> rawang: so is it in /var/lib/dhcp/dhcp.leases?
[02:13] <rawang> yes
[02:13] <rawang> bigjools, so for short, i think new node entry is in /var/lib/maas/dhcp/dhcp.leases file, but maas didn't update it for dns record :)
[02:13] <bigjools> rawang: wait
[02:13] <bigjools> which leases file is it *current* in?
[02:14] <bigjools> it is not in the maas one AFAICT because it expired
[02:14] <rawang> /var/lib/maas/dhcp/dhcp.leases
[02:14] <bigjools> which is why it's not in DNS
[02:14] <bigjools> rawang: well no, it's not in there
[02:14] <rawang> ok
[02:14] <bigjools> can you grep it in the /var/lib/dhcp/dhcp.leases file?
[02:14] <bigjools> ie the non-maas one
[02:15] <rawang> bigjools, to grep the different mac from same node from /var/lib/dhcp/dhcp.leases?
[02:16] <bigjools> rawang: grep the IP address
[02:16] <rawang> ok
[02:17] <rawang> bigjools, yes i can
[02:19] <bigjools> rawang: and this is the IP for the interface on the maas-dhcp side?
[02:19] <bigjools> you presumably have two IPs
[02:20] <bigjools> rawang: the basic problem is that there is no active lease for the interface that is connected to the maas dhcp. You need to fix this, I don't know why it is not working. There is a dhclient problem or other networking problem you're not telling me about yet.
[02:21] <rawang> bigjools, in short, I can get that node's ip from both dhcp leases files
[02:22] <bigjools> rawang: then you have a fundamental network setup problem
[02:23] <bigjools> somehow your node has got an IP from the wrong dhcp server
[02:23] <bigjools> maas cannot assign a dns entry unless its own dhcp server is used
[02:25] <rawang> sorry, keep busy on looking at other problem, will be back soon
[02:56] <rawang> bigjools, problem solved, it's because we have another workaround for solved dns problem, which leads to this one :(
[02:56] <rawang> bigjools, thanks a lot :)
[02:57] <bigjools> rawang: ok
[04:34] <bigjools> jtv: yo.  So, I need to add something to periodically look for existing dhcp servers.
[04:34] <bigjools> I was thinking of adding it to the lease parser job, what do you think?
[04:34] <jtv> Yes.
[04:34] <jtv> Combining async jobs sounds hazardous.
[04:35] <bigjools> well I thought of doing it in pserv but it's a bit of a job
[04:35] <bigjools> since there's no credential storage there
[04:35] <jtv> Ah.  Credentials.
[04:35] <bigjools> yes credentials
[04:36] <bigjools> but with the leases job I can just call one more api endpoint and we're off
[04:37] <jtv> What if we decoupled the probing and the reporting?
[04:37] <bigjools> in what way?
[04:37] <bigjools> I'm open
[04:37] <jtv> Where one periodic job says "start probing for DHCP servers, boys" and then another (such as the lease-parser job) reports any DHCP servers that have been seen.
[04:37] <jtv> Eliminates the wait, if you see what I mean.
[04:38] <jtv> Although maybe I'm optimising prematurely there.
[04:45] <jtv> bigjools: still here?
[04:45] <bigjools> jtv: sorry, waylaid by something, back a in sec
[04:45] <bigjools> in a*
[04:45] <jtv> ok
[04:59] <bigjools> jtv: so remind me how often we parse leases?
[04:59] <bigjools> 30 seconds wasn't it?
[05:00]  * jtv looks
[05:00] <jtv> bigjools: once a minute
[05:01] <jtv> Guilty thought: "send DHCP probe; parse DHCP leases; send DHCP leases to API; sleep for remainder of DHCP wait period; send DHCP results; done."
[05:11] <bigjools> jtv: that's exactly what I was thinking :)
[05:12] <jtv> Then we're both guilty.
[05:12] <bigjools> jtv: however, we'd need to do non-blocking IO
[05:12] <jtv> Not this way, AFAICT.
[05:12] <bigjools> so I think sequential is fine
[05:12] <jtv> *Sending* the packet should be instantaneous.
[05:12] <jtv> We can start *receiving* once the leases parser is done.
[05:13] <bigjools> we can
[05:13] <jtv> (Never mind the "sleep," I now see: the blocking recv() will do that)
[05:13] <bigjools> in the example code I did I used a settimeout
[05:13] <bigjools> so it waits ~3 seconds and then returns
[05:17] <jtv> Yeah.  For us, the latency of parsing and reporting the DHCP leases would probably hide the latency of probing for a DHCP server, _if_ there is one.
[05:18] <jtv> Otherwise, well, at least we could subtract the elapsed time from the timeout.
[05:19] <bigjools> there's very very little latency.
[05:19] <bigjools> you usually get a response subsecond
[05:31] <jtv> Shouldn't we cater for the situation where there is no DHCP server?
[05:35] <bigjools> of course, we'll update the interface every scan
[05:53] <bigjools> jtv: I'll submit a branch now that has the api side changes so you can see my intended solution to that
[05:58] <bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/dhcp-detect-pserv/+merge/196659
[06:27] <xiaolin> I got an error while PXE booting : http://picpaste.com/20131126_122922-oSwGs8An.jpg
[06:27] <xiaolin> any clue for this?
[06:29] <axw> anyone awake? I'd like to see the agent_name for nodes in my MAAS server; what maas-cli invocation do I need to make?
[06:31] <jam> bigjools, jtv: ^^ is agent_name rendered in output ? I see it in models/node.py and api.py, but not explicitly in any of the templates
[06:31] <bigjools> no it's not part of templates
[06:32] <bigjools> what problem do you have?
[06:32] <axw> jam: your idea works - I can just nodes list agent_name=<UUID>
[06:32] <jam> bigjools: if we acquire using one, we wanted to ensure we did that correctly
[06:32] <axw> bigjools: I started a new instance in MAAS, just wanted to ensure it had the same agent_name as the others
[06:32] <jam> we were hoping to see it in "nodes list" but you just have to guess the agent_name and filter yourself
[06:32] <jam> well "guess" in that we have it written elsewhere
[06:32] <bigjools> yay rushed fixes
[06:33] <bigjools> ok so axw did you answer your own question? :)
[06:33] <axw> bigjools: jam answered it for me, thanks :)
[06:33] <bigjools> ok
[06:34] <axw> may as well stay here while I learn how to use maas ;)
[07:05] <gmb> Morning jtv. In your review here https://code.launchpad.net/~gmb/maas-test/warn-on-virtual-hardware/+merge/196489 you say "we should be okay w.r.t the change..." (unicode vs bytes again). Is "should" indicating an obligation or is it meant to indicate likelihood?
[08:46] <jtv> Hi gmb — I meant likelihood.  My apologies for the ambiguity.
[09:12] <jtv> gmb: about that pidfile...  see the two pastebin links on rvba's MP: https://code.launchpad.net/~gmb/maas-test/accept-proxy-config-option/+merge/196664
[09:14] <gmb> jtv: Yep, looking, thanks.
[09:15] <jtv> Oh wait, it's your MP.  :)
[09:16] <gmb> Yep :)
[09:16] <jtv> On this massive screen I'm in front of, the name at the top is just too far out of the way.  Raphaël's was right in front of me.
[09:19] <bigjools> jtv: did you make any changes to the dhcp detection stuff yet? I need to start doing things with it and we might tread on each other's toes here
[09:21] <jtv> bigjools: yes.  How about I push it now?
[09:21] <bigjools> jtv: sure
[09:21] <jtv> I also have a script that I created for experimentation...  Might as well include that I suppose.
[09:22] <jtv> bigjools: pushing to lp:~jtv/maas/probe-dhcp
[09:22] <jtv> And... done.
[09:23] <bigjools> pwobe
[09:23] <jtv> bigjools: adds a scripts/maas-probe-dhcp.py for easy experimentation.
[09:23] <bigjools> jtv: make a WIP MP so we get a working diff
[09:23] <jtv> OK
[09:52] <gnuoy> Can global kernel options be set through the cli ? maas-cli maas maas get-config 'kernel_opts' is returning "u'kernel_opts' is not a name=value pair"
[09:52] <gnuoy> s/set/displayed/
[09:58] <bigjools> gnuoy: name=kernel_opts IIRC
[09:58] <gnuoy> bigjools, perfect, thank you
[10:39] <jtv> gmb: oops, I just voted Disapprove on your branch but it looks like it's already merged.
[10:39] <gmb> jtv: HOW DARE YOU.
[10:39] <gmb> I mean
[10:39] <gmb> Why, what was wrong with it?
[10:40] <jtv> I am sorry for being so negative, really I am.  Basically, you were trying to stuff two fixtures into one body.
[10:40] <jtv> The thing has become wholly schizophrenic.  Two personalities, no shared code.
[10:40] <gmb> jtv: Nah, it's fine; I'd rather have your negative reviews than most people's positive ones. And you're absolutely right, too. I'll put a branch together to take care of your points now.
[10:43] <jtv> Thanks.  Very sporting of you.
[10:45] <rvba> jtv: since you seems to be in reviewing mode, could you have a look at https://code.launchpad.net/~rvb/maas-test/customize-series-arch/+merge/196685 please?
[10:45] <rvba> seem*
[10:46]  * jtv was trying to get _out_ of reviewer mode for a change
[11:08] <rvba> jtv: all right, no worries, I'll ask someone else to pick it up then.
[11:10] <jtv> Thanks.
[11:11] <rvba> allenap: time for a review? https://code.launchpad.net/~rvb/maas-test/customize-series-arch/+merge/196685
[12:01] <gmb> jtv, rvba: A branch to deal with the concerns about the overloading of ProxyFixture: https://code.launchpad.net/~gmb/maas-test/fix-buggery/+merge/196697
[12:01]  * gmb -> lunch
[12:01] <jtv> Looking.
[12:02] <gmb> jtv: Might want to refresh; just pushed another revision.
[12:03] <jtv> OK
[12:04] <jtv> I was wondering about that class you just removed.  :-)
[12:07] <jtv> gmb: done.
[12:25] <jtv> rvba: I'm beginning to think that we need a separate version of packages.txt for packages that we expect to be installed for development.
[12:29] <allenap> rvba: Sure.
[12:54] <jtv> Does anyone remember what to do about this one?
[12:54] <jtv>   Getting distribution for 'psycopg2>=2.4.4'.
[12:54] <jtv> Error: Picked: psycopg2 = 2.5.1
[12:55] <jtv> allenap..?
[13:00] <allenap> jtv: I tried to help someone with this last week but it was futile. Let me see if I can recreate it.
[13:00] <allenap> jtv: Is this in maas or maas-test?
[13:01] <jtv> allenap: maas
[13:01] <jtv> saucy
[13:01] <rvba> gmb: I'm getting a failing when running the tests on trunk… http://paste.ubuntu.com/6478833/
[13:01] <gmb> rvba: Fuckmonkeys.
[13:01] <rvba> This seems related to landing of your most recent branch.
[13:01] <gmb> Yeah, that was my bad, I've missed a test run.
[13:01] <gmb> Fixing it now.
[13:02] <rvba> I think it's trying to import RemoteProxyFixture which does not seem to exist.
[13:02] <gmb> Yep
[13:03] <allenap> jtv: make install-dependencies?
[13:03] <allenap> jtv: I can reproduce by removing python-psycopg2.
[13:04] <jtv> allenap: I ran that of course.
[13:04] <gmb> rvba: https://code.launchpad.net/~gmb/maas-test/agiantpileofarse/+merge/196709
[13:04] <jtv> I started hitthing the problem without python-psycopg2 installed.  Installing it didn't help.
[13:04] <allenap> jtv: Ah, I can also reproduce now I've installed python-psycopg2! Dammit buildout.
[13:04] <rvba> "can we have CI now? Thanks." says gmb.  Seconded :)
[13:04] <gmb> :)
[13:05] <rvba> allenap might have a secret script to spin up a juju-deployed tarmac.
[13:05] <allenap> jtv: rm -r ~/.buildout/eggs/psycopg2-*.egg
[13:05] <jtv> Actually, without python-psycopg2 it fails even earlier.  :(
[13:05] <jtv> allenap: no ~/.buildout.
[13:05] <allenap> Or wherever your buildout cache is.
[13:06] <jtv> Removing the eg...
[13:06] <jtv> egg...
[13:06] <jtv> Nope, back to the same error.
[13:06] <jtv> This is a freshly installed machine, so no old eggs.
[13:07] <allenap> jtv: After `make distclean`, does `bzr ignored` report anything?
[13:08] <jtv> allenap: bin    ./bin
[13:08] <jtv> etc.
[13:08] <jtv> Same for eggs, develop-eggs, lib, local, and parts.
[13:08] <gmb> rvba: Um, packages.txt seems to be broken: http://paste.ubuntu.com/6478860/
[13:08] <allenap> jtv: It should have reported nothing.
[13:08] <gmb> (Just removing the comment fixes it, but still)
[13:08] <jtv> allenap: what does that mean?
[13:09] <rvba> gmb: uh-oh, my bad
[13:09] <allenap> jtv: make distclean should have removed all non-versioned files from the tree.
[13:09] <rvba> gmb: I'll clean it up…
[13:09] <rvba> I'm still waiting for the diff to show up on your MP…
[13:09] <gmb> rvba: Okay. And another +1 in the CI column...
[13:09] <gmb> rvba: Yeah, LP seems to be on a go-slow today.
[13:10] <jtv> allenap: ah!  "make distclean" fails because "svok" can't be found.
[13:10] <allenap> jtv: Interesting! daemontools is probably missing from the package list.
[13:10] <allenap> Mmm, it's there.
[13:11] <gmb> rvba: To save you waiting: http://paste.ubuntu.com/6478874/
[13:11] <gmb> Woah, hang on
[13:11] <gmb> rvba: Scratch that, I appear to have done something dumb.
[13:11] <gmb> One sec.
[13:11] <jtv> allenap: I also had to install libpq-dev and libpython-dev
[13:12] <allenap> jtv: Something weird is going on: libpq-dev is in required-packages/dev. libpython-dev is missing, granted.
[13:12] <jtv> allenap: make distclean works now, "bzr ignore" says nothing, but still no psycopg2.
[13:12] <jtv> Wha!?  "make install-requirements" gives me some additional packages now!
[13:12] <gmb> rvba: http://paste.ubuntu.com/6478881/
[13:13] <rvba> Ta.
[13:13] <jtv> allenap: whoops...  lots and lots of additional dependencies in fact.
[13:14] <rvba> gmb: approved, and I fixed the packages.txt fuckup.
[13:14] <gmb> Cool.
[13:14] <gmb> rvba: Thanks.
[13:28] <jtv> allenap: success!  Installation must simply have failed somewhere.
[13:30] <rvba> allenap: thanks for the review… I'm afraid my change will add more conflicts to the 2 branches you have in progress but solving them will be mostly mechanical…
[13:32] <allenap> rvba: Don't worry about it.
[13:32] <allenap> jtv: \o/
[13:33] <jtv> That *finally* got to the point where I can test what I wanted to, and the news is bad.  :(
[13:33] <jtv> Can't bind to the dhcp client socket when dhclient is running... even on another interface.
[13:39] <allenap> jtv: http://freeprogrammersblog.vhex.net/post/linux-39-introduced-new-way-of-writing-socket-servers/2 might help.
[13:40] <rvba> gmb: fwiw, MAASFixture.configure_default_series does exactly the sort of config you have to do to make the documentation about --http-proxy be true (i.e. for the proxy to be actually used by the nodes) :).
[13:40] <jtv> Thanks allenap.  Will look at that tomorrow.
[13:43] <rvba> gmb: also, the branch I just landed is the cleanup you and I talked about a few days ago.  The arch and the series for which the images are imported is not hardcoded anymore.
[14:11] <allenap> rvba: Is there any need to keep TestMAAS and TestOneNode separate?
[14:13] <gmb> rvba: Sweeeeeet. Thanks for the tip.
[14:13] <allenap> rvba: I guess TestOneNode has the actual cases, whereas TestMAAS is just utility-like code.
[14:13] <gmb> I'm getting TypeErrors... WTF? I'm going to make tea in anger.
[14:25] <rvba> allenap: yes, something like a mixin… I decided to split them up because at some point, it look as if we were about to have multiple test cases… turns out we only needed one so far.
[14:25] <allenap> rvba: I won't change it, but I will document it.
[14:25] <rvba> Sounds good.
[14:51] <rvba> gmb: I see something fishy in maastest/main.py: we pass cls.proxy to MAASFixture() instead of proxy_url.  Looks like a problem to me…
[14:52] <gmb> rvba: Yeah, that's a bug — we don't actually have tests for the TestCase infrastructure, which doesn't help — I've got a fix for that in a branch now.
[14:52] <rvba> All right.
[14:53] <rvba> Also, I don't see cls.proxy.setUp() being called.
[14:56] <gmb> rvba: Yep
[14:57] <rvba> gmb: where will polipo put its cache?  It's not obvious from the code…
[14:57] <rvba> (I'm asking because I can't have it put large files in ~/, I need to create a symlink to a place where there is space)
[14:58] <gmb> rvba: It goes in /var/cache/polipo by default.
[14:58] <rvba> It can write there even if it's running with my id?
[14:59] <rvba> I doubt it :)
[15:00] <rvba> The log is full of:
[15:00] <rvba> Couldn't create disk file /var/cache/polipo/archive.ubuntu.com/Uh9N+CMWid7p9wF5hBk53Q==: Permission denied
[15:00] <rvba> Couldn't create disk file /var/cache/polipo/archive.ubuntu.com/Q3DSIlpgswiWnUOrv3cdXQ==: Permission denied
[15:00] <gmb> rvba: Hmm, good point, I doubt it too... What an excellent feature!
[15:00] <rvba> :)
[15:00] <gmb> Okay, so we should fix _that_ then.
[15:01] <rvba> gmb: I'll see if I can change the config to cache things in .maas-test/cache
[15:01] <gmb> ok.
[15:01] <rvba> On the bright side, it does not cache anything but it does not break :)
[15:02] <gmb> Yes... that's the kind of failure we like: agreeable uselessness.
[15:03] <gmb> rvba: LP's being slow again; does this look good to you: http://paste.ubuntu.com/6479326/
[15:03] <rvba> gmb: that's precisely what I've done to test this thing.
[15:04] <gmb> Excellent. I'll merge that now.
[15:31] <blueking> any activity here ?
[15:33] <gmb> blueking: Plenty. What kind of activity were you looking for?
[15:36] <blueking> I've tested sphirewall/debian  on new built pc   but seems to be hard to configure  nat not working properly, might be due new nic  I210AT  intel ... so looking into ubuntu server  to be used on router/nat box/firwall and torrent client
[15:36] <blueking> have used ubuntu desktop version before
[15:38] <blueking> hardware on router are
[15:38] <blueking> mobo http://www.supermicro.nl/products/motherboard/Xeon/C220/X10SLM_-F.cfm
[15:38] <gmb> blueking: I suspect  that maas is more than you need for what you're trying to do. You might be better off asking in #ubuntu or #ubuntu-server
[15:39] <blueking> ok
[15:39] <blueking> same irc server ?
[15:40] <gmb> blueking: Yes.
[15:47] <rvba> allenap: would you be available for a review?
[15:52] <rvba> allenap: here is the MP, if you have time: https://code.launchpad.net/~rvb/maas-test/fix-cache-config/+merge/196737
[16:16] <rvba> gmb: did you start working on setting MAAS' proxy?
[16:27] <rvba> gmb: I'll take that as a no :)
[16:27] <rvba> gmb: can you have a look? https://code.launchpad.net/~rvb/maas-test/fix-proxy-usage/+merge/196745
[16:27] <rvba> allenap, maybe ^
[16:46] <allenap> rvba: Sure.


[01:55]  * xnox ponders if fsharp is what i think it is
[14:08] <Mirv> ok click is published to xenial which should make ubuntu-app-launch installable on s390x which should fix xenial finally for good
[14:08] <Mirv> xnox: ^
[16:48] <slangasek> cjwatson, infinity: what am I missing that pushing to lp:~ubuntu-cdimage/debian-cd/ubuntu fails for me with a 'readonly transport' error?
[16:52] <ogra_> slangasek, did you follow https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ?
[16:55] <slangasek> ogra_: ...no, why would I push to nusakan before pushing to LP and why would anything described there prevent me from pushing to LP?
[16:55] <ogra_> well, thats a cjwatson question then :)
[16:56] <ogra_> there is some binding magic going on
[17:02] <xnox> slangasek, lp is a mirror from people.canonical.com =)
[17:02] <xnox> This branch is an import of the Bazaar branch at http://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu.
[17:03] <slangasek> xnox: hmm ok
[17:03] <slangasek> in that case it sounds like I do need to push straight to nusakan
[18:09] <xnox> please remove mono/powerpc binaries from xenial-release
[18:09] <xnox> slangasek, ^
[18:11] <doko> xnox, doesn't it build anymore?
[18:27] <xnox> doko, debian maintainer remove powerpc architecture...
[18:27] <doko> xnox, debian *never* had powerpc binaries
[18:27] <xnox> also, please build <IP_ADDRESS>+dfsg2-4ubuntu1 on z13-008 builder with a fixed kernel.
[18:27] <xnox> doko, i believe it was enabled in experimental for a while for 4.x series
[18:29] <xnox> slangasek, wgrant, cjwatson - mono <IP_ADDRESS>+dfsg2-4ubuntu1 did build correctly on a "good" kernel, could you please retry it on z13-008?
[18:29]  * xnox ponders if -no-pie is not needed at all, just a fixed kernel needed.
[18:30]  * xnox rebuilds
[18:33] <slangasek> xnox: surely all of the lp builders have "good" kernels at this point, don't they?
[18:33] <xnox> slangasek, nope.
[18:34] <slangasek> what's the difference between them?
[18:34] <xnox> Kernel version: Linux z13-009 4.3.0-0-generic #9 SMP Tue Dec 1 18:12:15 CET 2015 s390x
[18:34] <xnox> bad
[18:34] <slangasek> they must all have the basic PIE fixes
[18:34] <xnox> Kernel version: Linux z13-008 4.3.0-1-generic #10+wgrant+s390x.1-Ubuntu SMP Thu Dec 3 23:39:27 UTC 2015 s390x
[18:34] <xnox> good
[18:37] <xnox> slangasek, https://launchpad.net/ubuntu/+source/linux/4.3.0-2.11 is the first good one or better. wgrant prebuilt the cherrypick and deployed it to z13-008.
[18:39] <slangasek> xnox: non-trivial arch-dep reverse-dependencies of mono on powerpc; please iterate through these for a clean removal before we drop mono itself:
[18:39] <slangasek> $ reverse-depends -a powerpc src:mono | awk '{ print $2 }' | sort -u | xargs apt-cache show | grep-dctrl -FArchitecture amd64 -sPackage | wc -l
[18:39] <slangasek> 44
[18:40]  * xnox hands over `--list' to slangasek, and takes away | awk '{ print $2 }'
[18:42] <slangasek> useful, thanks ;)
[18:42] <slangasek> (also makes the sort -u go away)
[18:44] <xnox> right so -fno-pie upload is not needed at all. as building on a good kernel is sufficient.
[19:32] <xnox> oh
[19:32] <xnox> my build on ibm vpn was done noopt, rather than just on a fixed kernel.
[19:32] <xnox> sigh.
[19:59] <xnox> mono is crazy and kernel has nothing to do with it.
[20:20] <infinity> doko: Eh?  Debian definitely used to have powerpc mono with 3.x, it was dropped with 4.x
[20:21] <doko> infinity, hmm, I thought we were patching that ...
[20:21] <infinity> doko: No, we patched for ppc64el.
[20:26] <doko> right, I remember, the suse patches ...
[20:30] <infinity> doko: Speaking of compilers, have you managed to hunt down why arm64 suddenly hates the kernel source?
[20:31] <doko> infinity, yes it succeeds with an assembler test testing ARMv8.1 instructions and succeeds, while the compiler doesn't yet support them
[20:32] <infinity> Ahh, so it was actually the new binutils that upset it slightly?
[20:32] <doko> that's what will appear with the Linaro branch in Jan/Feb
[20:32] <infinity> Okay, we can't wait until January to have a buildable kernel.  So, where do you proposed we fix this for now?
[20:32] <doko> told apw to disable these checks for now
[20:32] <infinity> Kay.
[20:33] <infinity> (Normally wouldn't care, but we still have linux/meta skew issues on s390x until this is all resolved, and we need to have sane s390x kernels for the upcoming milestone)
[20:34] <doko> and ubuntu-toolchain-r/test now has the first gcc-6 packages ...
[20:34] <infinity> I saw that, yeah.
[20:34] <infinity> I assume that's for xenial+1?
[20:34] <doko> yes, and for test rebuilds over the holidays
[20:35] <doko> infinity, can you prepare gibc 2.22 for the end of next for the test rebuilds? or is it to busy?
[20:36] <doko> infinity, how many cpu's have the s390x buildds?
[20:36] <infinity> doko: It's the top of my list to get done before holidays.  Should be there before the 17th.
[20:37] <infinity> @z13-001:~$ nproc
[20:37] <infinity> 4
[20:37] <infinity> doko: 4 cores, 8G, 2G/core.
[20:37] <doko> 1h 10 is not bad for the gcc-6 build on s390x
[20:37] <doko> (with tests)
[20:37] <doko> out
[20:38] <infinity> s390x is pretty speedy.
[20:38] <infinity> It better be for the price. :P
[20:38] <infinity> And it screams at pure integer stuff, since the clock speeds are insanely high.
[20:40] <doko> I thought it would scream at decimal stuff ...
[20:41] <infinity> Float performance is good too, don't get me wrong, but float insns imply pipe bubbles, generally, so you don't see the same pure linear increase from clock speeds going up.
[20:41] <infinity> Pure integer == full pipes == "whoah, dude".
[20:46] <slangasek> xnox: s390x debian-cd branch merged and deployed on nusakan
[20:47] <slangasek> kicking off an extra ubuntu-server daily build to see what explodes
[20:48] <infinity> It'll be less than ideal while the kernel/meta situation is still borked.
[20:48] <infinity> But it still might build, just won't install.
[20:48] <slangasek> last time it failed at "can I make it bootable"
[20:49] <slangasek> let's see if we cleanly get past that now
[20:49] <slangasek> if we do, we can always kick off an s390x-only build with -proposed enabled
[20:50] <infinity> We can, yeah.  But I intend to get with the kernel team to sort the kernels ASAP.
[21:27] <slangasek> genisoimage: No such file or directory. cannot read from MD5 list file '/srv/cdimage.ubuntu.com/scratch/ubuntu-server/xenial/daily/tmp/xenial-s390x/md5-check'
[21:27] <slangasek> also, /srv/cdimage.ubuntu.com/debian-cd/tools/boot/xenial/common.sh: line 88: MANIFEST.udebs: No such file or directory
[21:34] <slangasek> infinity: any idea about bug #1525393? xnox was mentioning a similar thing this morning
[21:34] <slangasek> not sure at what point this may have regressed
[21:35] <infinity> slangasek: No idea.  I guess we'd need to trace where that comes from.
[21:35]  * infinity hunts a bit.
[21:35] <slangasek> I would have assumed debian-cd was to blame, but no recent changes there
[21:37] <slangasek> ah... one thing that changed was that cjwatson un-stuck the ftp mirror, I wonder if that would be related
[21:40] <slangasek> 20151209 image was grub +2.02~beta2-31, which dated from 19Nov.  20151210 image is grub +2.02~beta2-32ubuntu1
[21:43] <infinity> I'm not entirely convinced I understand where efi.img comes from in the first place...
[21:43] <slangasek> yeah
[21:43] <slangasek> also, old logs: touch /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/.disk/base_installable
[21:43] <slangasek> new logs: Linking /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/./.disk/base_installable to /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/./EFI/BOOT/grubx64.efi
[21:46] <infinity> Yeah, grubx64.efi being 0 length doesn't inspire confidence.
[21:47] <infinity> I suspect this is one of those things Colin would give us on answer on in 2 minutes. :P
[21:49] <slangasek> right the 'Linking' is because they're both empty files and so their md5sums match; not the root cause
[21:50] <infinity> *nod*
[21:50] <slangasek> efi.img isn't the issue, either; it's wherever it's getting bootx64.efi and grubx64.efi
[21:57] <infinity> So, bootx64.efi comes from d-i.
[22:08] <slangasek> ah. who broke d-i?
[22:08] <infinity> Nobody...
[22:09] <slangasek> infinity: ok.  where does it copy it out of d-i?
[22:10] <infinity> Trying to figure that out.
[22:10] <slangasek> (and how do you know it's from d-i? I don't see this in the build log)
[22:10] <infinity> Oh.  Maybe it doesn't come from d-i.  That might just be for mini.iso
[22:11] <slangasek> right, the bootx64.efi file is supposed to be a copy of what's in the shim-signed package
[22:11] <slangasek> and grubx64.efi from grub-efi-amd64-signed
[22:11] <slangasek> it's the how-they-get-there that's opaque
[22:12] <slangasek> what happens if we nuke scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64 and rebuild...
[22:13] <infinity> Nuking it should happen before every build anyway.
[22:14] <xnox> slangasek, i suspect that i didn't git something right. MANIFEST.udebs should have been retrievied among the d-i kernel/initramfs/paramfile not sure what md5-check is. Thanks for this, will toy with it. I wonder if I can run debian-cd stage locally myself...
[22:14] <slangasek> tools/boot/xenial/boot-amd64:
[22:14] <slangasek> mcopy -i boot$N/isolinux/grub/efi.img ::EFI/BOOT/BOOTx64.EFI $CDDIR/EFI/BOOT/BOOTx64.EFI
[22:14] <slangasek> mcopy -i boot$N/isolinux/grub/efi.img ::EFI/BOOT/grubx64.efi $CDDIR/EFI/BOOT/grubx64.efi
[22:14] <slangasek> so that is actually coming from grub/efi.img
[22:15] <xnox> boot-* scripts usually do the "find latest d-i and download/copy things from it"
[22:19] <slangasek> infinity: so that file is scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/boot/grub/efi.img, which is extracted from scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/cdrom/debian-cd_info.tar.gz
[22:19] <infinity> Yeahp, found it.
[22:20] <infinity> http://paste.ubuntu.com/13944778/
[22:20] <infinity> Certainly seems a bit suspect. :P
[22:20] <slangasek> what are "new" and "old" here?
[22:21] <infinity> 404 and 402
[22:23] <infinity> new/grub/mount/efi/boot:
[22:23] <infinity> total 384
[22:23] <infinity> -rwxr-xr-x 1 root root 391680 Dec  5 00:51 bootx64.efi
[22:23] <infinity> -rwxr-xr-x 1 root root      0 Dec  5 00:51 grubx64.efi
[22:23] <infinity> old/grub/mount/efi/boot:
[22:23] <infinity> total 2230
[22:23] <infinity> -rwxr-xr-x 1 root root 1289424 Nov 24 07:00 bootx64.efi
[22:23] <infinity> -rwxr-xr-x 1 root root  991608 Nov 24 07:00 grubx64.efi
[22:23] <xnox> make[1]: Leaving directory `/srv/cdimage.ubuntu.com/debian-cd'
[22:23] <xnox>  ... checking your mirror
[22:23] <xnox> rm -f /srv/cdimage.ubuntu.com/scratch/ubuntu-server/xenial/daily/tmp/xenial-s390x/md5-check
[22:23] <xnox> Unknown arch/source s390x!
[22:23] <xnox> make: *** [mirrorcheck-binary] Error 1
[22:24] <xnox> hm.
[22:24] <infinity> slangasek: It's possible a rebuild of d-i would "fix" it, but I'd kinda like to know why it exploded...
[22:26] <slangasek> yep
[22:26] <xnox> slangasek, https://code.launchpad.net/~xnox/debian-cd/s390x/+merge/280369
[22:27] <slangasek> xnox: looking.  btw, did you catch the fix-up commits I did to make bzr-builddeb plugin not fall over on dpkg-parsechangelog?
[22:28] <infinity> Oh, bah.
[22:28] <xnox> slangasek, hm?
[22:28] <slangasek> xnox: looks like the answer to this is 'no' ;) please merge from trunk
[22:28] <slangasek> xnox: the branch has debian packaging in it, the debian/changelog has garbage at the top that makes it unparseable; if bzr-builddeb is installed you can't merge
[22:29] <slangasek> infinity: ?
[22:29] <xnox> slangasek, done.
[22:30]  * xnox goes back to adult size LEGO, IKEA series...
[22:30] <infinity> slangasek: The code in d-i kinda relies on wget actually working.  A network blip would have caused this mess.
[22:30] <infinity> slangasek: So, yeah, a rebuild will fix it.
[22:30] <slangasek> sigh
[22:30] <slangasek> ok
[22:31] <infinity> I'll just release cyphermox's findutils fix for now, and build against the old kernel ABI so it doesn't get stuck.
[22:33] <slangasek> xnox: merged, pushed, retrying build
[22:34] <infinity> slangasek: Hah, you added that d-i task half a second before I tried. :P
[22:34] <slangasek> :-)
[22:38] <infinity> slangasek: Alright, tiny brain dump done in the bug.
[22:38] <slangasek> excellent, thanks
[22:42] <infinity> FFS.
[22:43] <infinity> That build also broke.
[22:43]  * infinity investigates harder.
[22:49] <infinity> And, of course, it works from home.  Grr.
[23:08] <infinity> slangasek: Okay, no, there's a real bug here.  Sorting it out now.
[23:17] <xnox> oh.
[23:17] <xnox> stgraber, we need Ubuntu Server s390x product in the iso tracker?
[23:18] <stgraber> probably
[23:19] <xnox> stgraber, can you create s390x server image there and mark me as the "manager for it" i guess i will be doing qa for it, at least for the initial few milestones
[23:19] <xnox>     raise KeyError("Product '%s' not found" % product)
[23:19] <xnox> KeyError: "Product 'Ubuntu Server s390x' not found"
[23:19] <xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151211.2.log
[23:22] <stgraber> xnox: done
[23:22] <xnox> stgraber, merci beaucoup
[23:24] <xnox> later we will add testcase specific to that image, but the defaults look good for now.
[23:49] <cyphermox> how do the sections work in our archive? would it be very complicated to add a Section: tasks ?
[23:50] <infinity> cyphermox: Err, why?
[23:51] <cyphermox> looking at tasksel merge, seems like the source in there in Debian
[23:52] <infinity> cyphermox: We don't do tasks as metapackages.
[23:53] <cyphermox> so you think I should just revert that section change for us?
[23:53] <infinity> I think there's probably more to it than that.
[23:53] <infinity> And it's entirely possible we don't want to merge at all.
[23:54] <infinity> tasksel 3.00 is when metapackage tasks happened, which is why we're forked from 2.88
[23:55] <cyphermox> I'd be tempted to think it just happens that the timing fits, other things haven't been merged in a while.
[23:55] <infinity> That one's quite deliberate.
[23:56] <infinity> Tasks in Ubuntu come from the Task: header in Packages, which comes from seeds.
[23:56] <cyphermox> oh, I know
[23:56] <infinity> Which is entirely different from what tasksel >= 3.0 expects.
[23:56] <cyphermox> we have delta to handle this
[23:56] <cyphermox> I'm not saying you're wrong, just trying to get a clear picture of things
[23:57] <cyphermox> and I feel like it probably wouldn't hurt to merge anyway, provided it's done correctly
[23:58] <infinity> It's possibly mergable, by dropping all the debian metapackages, keeping our update magic, etc.
[23:59] <infinity> And yes, keeping our Sections.
[23:59] <cyphermox> yeah


[16:55] <EvilResistance> can someone answer a question for me?
[16:56] <EvilResistance> when one reports in one of the #ubuntu-* channels that they've added something to [Arbitrary Site or Wiki Here] that is obvious vandalism, does that constitute a violation of the U. CoC?
[16:56] <Myrtti> depends
[16:57] <EvilResistance> on what?
[16:58] <EvilResistance> the individual channel operator who witnessed the situation?
[17:04] <EvilResistance> as well, does this include #ubuntu-offtopic?
[17:04] <EvilResistance> (since the issue occurred there)
[17:05] <EvilResistance> (approx. 20 minutes ago, _Marcus stated spam that he subsequently added to a Wikipedia article on Acer Inc., which is blatant vandalism)
[17:05] <EvilResistance> wondering whether that alone constitutes a violation
[17:06] <AlanBell> I would not think of the code of conduct in terms of violations
[17:06] <Pici> We use the CoC as a set of guidelines for our channels, even if the person in question has not signed it.
[17:06] <EvilResistance> i see.
[17:07] <EvilResistance> then in this case, does it count as a violation of any channel policies?
[17:07] <AlanBell> it is a.set of principles of guidelines
[17:07] <zykotick9> seems there is an issue with !text factoid, it doesn't actually contain instructions for "text" anymore...
[17:07] <AlanBell> !text
[17:12] <bazhang> https://help.ubuntu.com/community/BootOptions#Changing_boot_options_Temporarily_for_an_Existing_Installation
[17:12] <bazhang> that?^


[16:22] <infinity> cjwatson: So... This armhf linker mess leaves me with another interesting mess to sort out.
[16:22] <infinity> cjwatson: In the short term, we technically have two linkers (both symlinks to the same one, but two canonical locations)
[16:22] <infinity> cjwatson: mklibs can't handle that situation AT ALL, and I don't want to make it.
[16:23] <infinity> cjwatson: So, I'm thinking a bit of hackery in d-i/Makefile around where there's already some fudging of the Hurd linker.
[16:23] <infinity> cjwatson: The real kicker is that what gets done by mklibs is non-deterministic (or, rather, hard to guess, because it'll pick the first PI from the first binary that claims to have one)
[16:24] <cjwatson> I'm OK with that kind of hackery for now
[16:24] <infinity> So, I guess I just test for both, and whichever one exists, link the other two it.  Or something.
[16:24] <infinity> s/two/to/
[16:24] <infinity> I'll experiment locally once I have glibc built in the archive.
[16:24] <infinity> But yeah.  Something like that will happen soon. :P
[16:25] <infinity> Just a heads-up, if you'd prefer to ignore it and not vomit.
[16:25] <cjwatson> mklibs is pretty awful, but nothing else does the job ...
[16:25] <cjwatson> happy to ignore it :-)
[16:25] <infinity> Teaching mklibs to deal with multiple PIs seems pointless, unless we ever intend to have multi-arch d-i initrds (oh god, say no).
[16:25] <infinity> So, yeah, the Makefile hack seems saner anyway.
[16:25] <infinity> FSVO "sane".
[16:26] <cjwatson> I see no point in multiarch for d-i :-)
[16:26] <infinity> Also, if you're in the mood to vomit, check out the last patch on the end of http://lucifer.0c3.net/~adconrad/eglibc.debdiff
[16:26] <infinity> This is the madness that distro consensus has driven me to.
[16:27] <cjwatson> Ew
[16:27] <cjwatson> Wait, aren't those strcmps backwards?
[16:27] <cjwatson> Shouldn't it be strcmp() == 0?
[16:27] <infinity> Nope.
[16:28] <cjwatson> Oh, double negatives
[16:28] <infinity> Yeah.
[16:28] <infinity> When using strcmp, get into POSIX shell mode.
[16:28] <infinity> Confuses me every damned time.
[16:28] <infinity> "Wait, this is the one time when C is shell?"
[16:29] <cjwatson> No, it's not that that confused me, it's that the entire test is negated
[16:29] <cjwatson> (effectively, by way of continue)
[16:29] <infinity> Oh, that too, yeah.
[16:29] <infinity> It's all confusing. :P
[16:29] <infinity> But anything in C returning 0 for "a-ok" just fucks with me.
[16:29] <cjwatson> Er.  Like every system call?
[16:30] <infinity> Yes, anything. :P
[16:30] <infinity> I'm easily confused.
[16:30]  * cjwatson passes infinity libdbus
[16:31]  * infinity sidesteps.
[16:33]  * cjwatson considers fixing usb-creator for syslinux-legacy to get it off ev's plate, since I don't see a branch for it
[16:34] <cjwatson> need to move some code around a bit, though
[16:38] <infinity> Say, you speak fluent dpkg, right?
[16:38] <infinity> How many beers would it take to convince you to waste a half hour fixing http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588077 for me? ;)
[16:38] <ubot2> Debian bug 588077 in dpkg "/usr/bin/dpkg-divert: --add --rename should not rename a file currently owned by --package" [Important,Open]
[16:42] <cjwatson> Er.  Need to be critical-path on slightly fewer things before promising anything.
[16:43] <infinity> Sounds familiar.
[16:43] <cjwatson> Probably not horribly painful though.
[16:43] <infinity> It even has a patch!
[16:43] <infinity> ... if only it wasn't in Perl, and dpkg-divert is now in C.
[16:43] <infinity> *cough*
[16:44] <cjwatson> And dpkg-divert has a test suite now, which should help.
[16:44] <cjwatson> Ask me after our rls-p-tracking >=High queue's at zero, and you can pay me a beer at UDS.
[16:44] <cjwatson> (Which I'm hoping will be no later than Tuesday)
[23:16] <cjwatson> ev: considering http://paste.ubuntu.com/931825/ - still need to test, but comments welcome, including "hands off, I'm working on it already"
[23:16] <cjwatson> ev: (I'm off tomorrow)


[23:46] <tiwake> WoodyPC: hey
[23:47] <Ardonel> hey WoodyPC and tiwake
[23:47] <tiwake> and Ardonel
[23:48] <WoodyPC> hey yall
[23:48] <WoodyPC> yall ever use a program called "mono complete"
[23:48] <WoodyPC> ?
[23:48] <Ardonel> How is/was your day tiwake ? and WoodyPC ?
[23:49] <Ardonel> no
[23:49] <tiwake> heh, alright
[23:49] <WoodyPC> uneventful....rained all day here.
[23:49] <tiwake> WoodyPC: hey, that guy never did call me :P
[23:49] <WoodyPC> whatchall up too?
[23:50] <WoodyPC> hang in there...I'll find out what's up with that.
[23:51] <Ardonel> auditing mod code for minetest... and trying to find info on a nick who has been bouncing all over freenode...
[23:51] <WoodyPC> ;0
[23:51] <WoodyPC> ;o
[23:51] <WoodyPC> :0
[23:52] <WoodyPC> ardonel: maybe I can help. what is the nick:?
[23:54] <Ardonel> xenthree3<EMAIL_ADDRESS>[23:54] <tiwake> am at work still... almost 5pm
[23:55] <Ardonel> tolna is in Hungary
[23:55] <Ardonel> account is fairly new <-- from a friend
[23:55] <WoodyPC> what is this person doing? bad things?
[23:56] <Ardonel> not sure how many channels were joined and parted, but wondering if someone is trying to hack freenode
[23:59] <WoodyPC> ah, ok... I'll what I can dig up.
[23:59] <WoodyPC> see
[23:59] <Ardonel> -NickServ- Information on xenthree3 (account xenthree3):
[23:59] <Ardonel> -NickServ- Registered : May 19 14:50:30 2016 (9h 8m 28s ago)
[23:59] <Ardonel> -NickServ- Last addr<EMAIL_ADDRESS>[23:59] <Ardonel> -NickServ- Last seen  : May 19 20:59:39 2016 (2h 59m 19s ago)
[23:59] <Ardonel> -NickServ- Flags      : HideMail
[23:59] <Ardonel> -NickServ- *** End of Info ***