[00:00] <soren> Try the link from above again.
[00:07] <Goosemoose> works now
[00:19] <soren> Great.
[00:20] <Goosemoose> trying to reinstall now
[00:23]  * soren is going to bed
[00:34] <Goosemoose> good night!
[00:34] <Goosemoose> im taking off for home
[00:34] <Goosemoose> ill check on this tomorrow
[06:27] <CIA-4> ubiquity: superm1 * r2396 ubiquity/ (debian/changelog desktop/ubiquity-mythbuntu.desktop.in): show proper image in ubiquity-mythbuntu.desktop
[09:15] <CIA-4> casper: cjwatson * r455 casper/debian/ (casper.init changelog):
[09:15] <CIA-4> casper: * Avoid ejecting the CD if booting from an ISO image rather than from a
[09:15] <CIA-4> casper:  physical CD (thanks, Agostino Russo; LP: #176014).
[09:20] <CIA-4> casper: cjwatson * r456 casper/debian/changelog: releasing version 1.113
[11:36] <xivulon> cjwatson, I am back, thanks for the thumbs up
[11:37] <xivulon> I have posted a second patch for fstab.d (bug 173659)
[11:37] <ubotu> Launchpad bug 173659 in partman-auto-loop "Add /host/boot to fstab" [Undecided,New] https://launchpad.net/bugs/173659
[11:38] <xivulon> That said I think I have to go through finish.d as well since the mounting scripts there do not seem to like bindmounts
[11:39] <xivulon> did not have time to do it yesterday
[17:48] <Goosemoose> Hey Guys
[17:49] <Goosemoose> Soren, that fix yesterday worked for security, the install went through fine. Only problem now is that I still need to remove 'splash' from grub to get ubuntu to start
[17:57] <Goosemoose> cjwatson, you around?
[18:11] <Goosemoose> hey stgraber, i noticed you don't have any monitor d-i commands in your preseed file, how are you handling that?
[18:17] <Torgoton> Hey all. I know this may be the wrong forum, but I'm having serious trouble with the Mini ISO, and no one in #ubuntu seems to have any clue that the Mini ISO even exists. Would I be way OT here?
[18:19] <Goosemoose> Sorry, I'm not sure what the mini iso is either. That like the usb version?
[18:20] <Torgoton> It's a small ISO (9MB for Gutsy) that is supposed to allow installation over a network. It crashes on my system.
[18:21] <Goosemoose> Ahh, I'm installing over a network using a local server and a tftp server
[18:21] <Goosemoose> that what you're talking about?
[18:22] <Torgoton> Yes, but the Mini ISO is supposed to ... help ... and be a smaller download. I also think it can use ftp or http besides tftp, and it can install from the usual repositories.
[18:25] <Torgoton> I have captured the startup log here, FYI: http://paste.ubuntu-nl.org/48887/
[18:26] <Goosemoose> Sorry, I wouldn't the one to help you there. I'm still trying to get my network install to work properly
[18:27] <Torgoton> Best of luck!
[18:27] <Goosemoose> you too
[18:27] <Goosemoose> when some of the other guys come back around , they are very helpful
[18:46] <Torgoton> Thanks. Any other rooms you might suggest?
[18:46] <Torgoton> #ubuntu-boot maybe?
[18:47] <Torgoton> laptop? server?
[19:36] <Goosemoose> ubuntu-server
[19:48] <xivulon> Goosemoose if you install over a local server you may also use pxe booting without any need for an ISO
[19:48] <xivulon> unknown_bootoption+0x0/0x260 might that be because of bad memory?
[19:49] <xivulon> at least that was what came out on a quick googling
[19:49] <xivulon> http://ubuntuforums.org/showthread.php?t=516953
[19:50] <xivulon> don't think that unknown_bootoption is per se a fatal error though
[19:59] <xivulon> the command line options look strange
[20:00] <xivulon> Here is a guide for pxe installation: http://wiki.koeln.ccc.de/index.php/Ubuntu_PXE_Install
[20:16] <xivulon> Torgoton see if the above helps
[20:18] <xivulon> The dump shows 36MB available, is this what you have?
[20:18] <Torgoton> xivulon, thanks! But I haven't found a PXE guide that works with a laptop. I'm going to try with the alternate CD. Downloading now.
[20:18] <Torgoton> Yes 36MB.
[20:20] <xivulon> Not sure whether that is enough for Ubuntu, https://help.ubuntu.com/community/Installation/SystemRequirements
[20:21] <xivulon> even though I would not think that would trigger a kernel panic
[20:23] <xivulon> for PXE you need to have an ethernet card/bios that supports network booting
[20:23] <Torgoton> A page says the alternate requires 32MB
[20:24] <Torgoton> My laptop does, but the card doesn't. There are boot floppies that then do a PXE, but not for laptops, that I've seen.
[20:25] <Torgoton> here it is: https://help.ubuntu.com/community/Installation/LowMemorySystems
[20:27] <xivulon> 32MB is the absolute minimum, you might also want to consider distros that are designed for low spec such as DSL or PuppyLinux
[20:27] <Torgoton> I tried DSL, but DSL really likes a CD drive, and this machine doesn't have one. Since Ubuntu claims to need 32MB RAM, and run on a 486, I'd really like to give it a good try.
[20:34] <xivulon> did you try different acpi boot options such as acpi=off/acpi=force?
[20:34] <Torgoton> heh. there's no ACPI on this machine. I have tried NOACPI.
[20:34] <xivulon> acpi=off
[20:35] <Torgoton> ok. I'll try that. I'm copying the alternate ISO to the machine now (will take 35 minutes!) and then will extract the files to a partition, then use lilo to start it, like I did the mini ISO.
[20:41] <Goosemoose> xivulon, i am using pxe for my installs
[20:41] <Goosemoose> Torgoton is using the iso
[20:42] <Goosemoose> my problem is the splash line in grub is preventing startup
[20:42] <Goosemoose> i have to manually remove it
[20:43] <xivulon> Torgoton, if you have to go through all that trouble and already have a bootloader capable of launching a kernel (assuming you can also make it work) then you can use a netboot approach
[20:44] <Torgoton> One would think. I tried debootstrap, but since I'm on Woody, it fails because the kernel is too old when it attempts to chroot.
[20:45] <xivulon> you save on HD the netboot kernel/initrd and boot those with whatever bootloader you want, it's still an alternate installer except that deb packages are downloaded on the fly
[20:46] <xivulon> Goosemoose what do you mean that usplash is preventing startup? And why is it difficult to remove?
[20:47] <xivulon> # defoptions=quiet splash
[20:48] <Goosemoose> because im using pxe to install on 500 machines
[20:48] <xivulon> that's the menu.lst line to change then you run update-grub
[20:48] <Goosemoose> yes, in the grub line the command splash is creating a blank screen on boot
[20:48] <Goosemoose> if i remove it , im fine
[20:48] <Torgoton> xivulon, netboot kernel/initrd is exactly what should be on the mini iso. That didn't seem to work, as seen by my debug dump.
[20:49] <xivulon> netboot spares you the trouble to download a full ISO, it does not fix kernel panic.
[20:49] <Torgoton> heh
[20:50] <xivulon> It does not matter what installation method you use since all use the same kernel
[20:50] <Torgoton> well then... what's the issue, might you suppose?
[20:51] <xivulon> I am not a kernel expert by a long stretch, I suppose acpi or memory.
[20:53] <Torgoton> Does the kernel really work on a 486? I mean... do you know what would happen if it were compiled for pentium?
[20:53] <xivulon> Goosemoose, "splash" should be in the kernel options passed to the pxe clients by the server
[20:54] <xivulon> My guess is that the kernel should work on a 486, but do not trust what I say on this topic
[20:56] <Goosemoose> these are P4's
[20:57] <xivulon> P4 will surely work
[20:57] <Goosemoose> only works if i remove splash
[21:00] <xivulon> my bad was thinking you where referring about usplash in the installation initrd as opposed to the installed initrd, of course the first one does not use usplash at all
[21:03] <xivulon> not sure if you can preseed menu.lst defoptions
[21:04] <xivulon> I seem to remember that defoptions is generated also using installation-time boot parameters (cannot look at the code now)
[21:07] <xivulon> In case you can use late_command/success_command to change that
[21:10] <Goosemoose> hmm
[21:16] <xivulon> no framebuffer also has as sideeffect to disable splash in menu.lst
[21:17] <xivulon> debian-installer/framebuffer=false
[21:17] <xivulon> I am sure cjwatson can suggest more elegant ways
[21:22] <xivulon> it's worth trying booting with "nosplash" that might be carried through via grub-installer into menu.lst
[21:48] <Goosemoose> does the framebuffer=false have any other affects?


[01:52] <yuanyou> jamespage: Hi , as we known, neutron-gateway charm have a config "ext-port", and i want get the "ext-port" value in my own charm onos-controller, how should i do ? thanks
[09:31] <deanman> Is it possible to customize the look and feel of juju-gui charm to your needs?
[10:41] <apuimedo> jamespage: you created a new merge proposal for nova-cloud-controller besides https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709?
[10:41] <apuimedo> ?
[10:44] <jamespage> apuimedo, sorry - branch hell
[10:45] <jamespage> deleted not
[10:45] <jamespage> now
[10:45] <apuimedo> ;-)
[10:45] <apuimedo> yes, it's just that I have some extra branches for backports I do
[10:45] <apuimedo> since when somebody wants to try it I usually backport the changes into stable
[10:46] <jamespage> apuimedo, I know we discussed this but I can't remember the rationale for not having the nova-metadata service co-located with the neutron-dhcp and neutron-metadata agents in neutron-agents-midonet like we have in the neutron-gateway charm?
[10:46] <jamespage> rather than using the one provided by the nova-cc service
[10:46] <apuimedo> jamespage: We did :-)
[10:47] <apuimedo> now that neutron-agents-midonet is split from neutron-api I may re-evaluate in a future version
[10:47] <apuimedo> but the deployment recommendation in midonet is usually like that
[10:48] <apuimedo> jamespage: you suggest adding some nova config in neutron-agents-midonet
[10:48] <apuimedo> so that it runs neutron-dhcp neutron-metadata and nova-api-metadata, right?
[10:49] <jamespage> apuimedo, well i have two ideas - one to run the nova-metadata service on neutron-agents-midonet and drop the shared-secret stuff across both charms - each neutron-metadata agents just talks to localhost with a unit local secret
[10:49] <jamespage> so like you say
[10:49] <jamespage> or
[10:50] <apuimedo> well, they wouldn't even need a secret setting then
[10:50] <jamespage> apuimedo, indeed
[10:50] <jamespage> well you do but just for the local neutron-nova comms
[10:50] <jamespage> no configuration at charm level.
[10:50] <jamespage> apuimedo, that's what neutron-gateway does today...
[10:50] <apuimedo> jamespage: IIRC, if you leave it blank it also works :P
[10:50] <jamespage> really?
[10:51] <apuimedo> that's what I saw in some of our cloud configs
[10:51] <jamespage> apuimedo, that sounds like a security vulnerability to me
[10:51] <apuimedo> well, I'd say it is an option to disable the "secure" comm
[10:52] <apuimedo> I opted to keep it in my charms though
[10:52] <jamespage> # If authentication token is set, authenticate
[10:52] <jamespage> ha!
[10:52] <apuimedo> ;-)
[10:52] <apuimedo> precisely
[10:52] <jamespage> so only auth is someone actually set the value
[10:52] <apuimedo> jamespage: do you know how much of a nova.conf chunk I'd have to add if I want to give it a shot?
[10:52] <jamespage> apuimedo, I know exactly
[10:53] <apuimedo> :-)
[10:53] <jamespage> apuimedo, nova needs rabbitmq and the keystone auth data as the neutron agents need - so no new interfaces...
[10:54] <jamespage> apuimedo, something like - http://paste.ubuntu.com/14876487/
[10:54] <jamespage> that's pulled from neutron-gateways kilo template for nova
[10:54] <apuimedo> right
[10:55] <apuimedo> so I'll give it a shot later
[10:55] <apuimedo> I'm now fixing the linting and unit tests of midonet-api
[10:55] <apuimedo> thanks for the template
[10:56] <jamespage> apuimedo, how about I do that for you now? I'd rather work that than have the manual configuration of shared secret in nova-cc
[10:56] <jamespage> apuimedo, I can test locally
[11:02] <jamespage> apuimedo, are you worried about upgrades to charms atm?
[11:05] <apuimedo> well, that would be nice
[11:05] <apuimedo> :-)
[11:37] <jamespage> apuimedo, ok working with kilo ok
[11:37] <jamespage> apuimedo, I'll need to re-deploy to test juno
[11:38] <apuimedo> cool
[11:47] <jamespage> apuimedo, actually
[11:47] <jamespage> juju create-model midonet-juno
[11:47] <jamespage> juju deploy midonet-juno.yaml
[11:48] <jamespage> \o/
[11:48] <jamespage> hurrah for 2.0 models
[11:49]  * apuimedo wants models
[11:49] <apuimedo> why didn't I start working on Juju now instead of before :'(
[11:50] <apuimedo> it's starting to get much easier
[12:04] <jamespage> apuimedo, apparently my laptop is not up for that much stuff grabbing memory...
[12:04] <jamespage> ETOMUCHJAVA
[12:04] <jamespage> lol
[12:04] <apuimedo> jamespage: xD
[12:05] <apuimedo> ETOMUCHJAVAANDPOSSIBLYSCALA
[12:05] <jamespage> lol
[12:05] <apuimedo> you need like 10G for the whole openstack plus zk+cass+midonet agents
[12:05] <jamespage> and maybe a bit of auto config by mysql grabbing anything left..
[12:05] <jamespage> x2
[12:07] <jamespage> apuimedo, OMG that's pretty much the zookeeper charm I wrote many years ago
[12:07] <jamespage> apuimedo, well it still works - nice to know :-)
[12:07] <apuimedo> jamespage: :-)
[12:08] <jamespage> apuimedo, there are more recent choices from the big data team:
[12:08] <jamespage> https://jujucharms.com/apache-zookeeper/trusty/1
[12:08] <apuimedo> jamespage: shouldn't this be promoted to cs:trusty/zookeeper then?
[12:09] <jamespage> apuimedo, tricky
[12:09] <apuimedo> or at least cs:xenial/zookeeper
[12:09] <apuimedo> for backwards compatibility
[12:09] <jamespage> cory_fu, ^^ what do you think
[12:09] <jamespage> I suspect that moving from zookeeper -> apache-zookeeper is not a supported charm upgrade path
[12:45] <apuimedo> jamespage: why did you move the merge proposal from needs review to wip?
[12:45] <apuimedo> without having it run yet, it looks good
[12:45] <jamespage> apuimedo, cause I'm still testing it - I think its ok - just verifying with juno
[12:45] <apuimedo> s/it run/run it/
[12:46] <apuimedo> cool
[12:46] <apuimedo> your RAM will suffer
[12:48] <jamespage> I have some lxd/cloud-init oddisms I have  to deal  with until a bug it resolved
[13:31] <vaewyn> Hey all...  found a bunch of environment variables but have yet to find one with the charms name in it... is there such a beast I can use in the hooks? Wanting one of the hooks to act differently depending on if the charm is directly deployed... or is used as a layer for another charm
[14:18]  * arosales taking a first look at the LTE eNB charms in the review queue
[14:31] <arosales> vaewyn: hello. I may not understand your question, but you can't use a charm as a layer for another charm.  You have to create an explicit layer that is used to build a charm.
[14:33] <arosales> So I can't use https://jujucharms.com/mysql/ as a layer for another charm. If you wanted to build a charm using layers you would need to include a layer from http://interfaces.juju.solutions/
[14:34] <arosales> vaewyn: ^ hth
[14:36] <vaewyn> arosales: I guess maybe I should say more what I am trying to accomplish then...  I have a charm currently that sets up environment and downloads a central codebase... then I have subordinate charms to deploy various apps off it it... was trying to reform all that into layers so I can still reuse the codebase charm in each application but end up with a single charm to deploy made of layers instead
[14:39] <vaewyn> arosales: the codebase charm has no relations or anything really... it's just a "get this crud on the disk" charm
[14:39] <vaewyn> arosales: I'm a very newb to this so I may be totally heading the wrong way but this path looked interesting
[14:51] <vaewyn> arosales: reading more... now I see what you mean :)  Thanks for the direction
[15:02] <arosales> vaewyn: your approach seems very reasonable. It sounds like what we call a "framework" charm, ie rails or java
[15:04] <arosales> but for that "codebase charm" I think you just need to create a layer.
[15:05] <arosales> ref = https://jujucharms.com/docs/devel/developer-layers && https://pythonhosted.org/charms.reactive/
[15:05] <arosales> vaewyn: ^
[15:11] <vaewyn> arosales: It seems kindof inferred...  but are layers always processed/completed in the order of inclusion? ie... are the reactive portions just for interaction with other charms or for internal change events also as each layer gets slapped together?
[15:17] <arosales> vaewyn:  layers give you 2 basic pieces of functionality to build a final charm.
[15:18] <arosales> 1. "layers" give you the ability to react to "states" to model how the service, ie code how the internal events are handled
[15:18] <arosales> 2. "interfaces" give you the ability to easily react to "state" when communicating with other applications (charms)
[15:18] <arosales> vaewyn: ^
[15:22] <arosales> btw, for reference here is the ruby layer http://interfaces.juju.solutions/layer/openjdk/ and the java layer = http://interfaces.juju.solutions/layer/openjdk/
[15:24] <vaewyn> arosales: ahh... those are much cleaner.. the apache-php layer seems to blur those lines you stated a bit... so I was a bit confused
[15:27] <arosales> ya apache-php may blur the lines a little from "run-time" and app
[15:27] <arosales> vaewyn: I hope that helps, let us know how your charming goes
[15:27] <vaewyn> arosales: does yes... thank you! and will do
[15:29] <jamespage> apuimedo, ok so that works on juno as well
[15:29] <apuimedo> great jamespage
[15:29] <jamespage> apuimedo, I love the fact that java is so sensitive for DNS crappy ness
[15:29] <apuimedo> xD
[15:29] <jamespage> apuimedo, https://bugs.launchpad.net/juju-core/+bug/1540061
[15:29] <mup> Bug #1540061: juju 2.0 alpha + local LXD provider: dns hostname inconsistency <juju-release-support> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1540061>
[15:30] <jamespage> apuimedo, until the first dhcp lease renewal everything is called 'ubuntu' in the dnsmasq instance...
[15:30] <apuimedo> jamespage: also, alai reported some lxc containers in maas env not getting "search domainname" in /etc/resolv.conf
[15:30] <apuimedo> which is problematic
[15:31] <apuimedo> jamespage: so I'll merge your proposal
[15:31] <jamespage> apuimedo, that sounds like old MAAS behaviour to me - I'' check
[15:31] <apuimedo> jamespage: I didn't experience it
[15:31] <apuimedo> it was on oil
[15:31] <jamespage> apuimedo, anyway - if you're ok with my changes to neutron-agents-midonet, lets drop https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709
[15:31] <jamespage> its really not needed any longer \o/
[15:32] <alai> jamespage, apuimedo : it's maas 1.9 we are using
[15:34] <apuimedo> jamespage: there's the part of selecting the libvirt vif driver
[15:34] <jamespage> apuimedo, I think that may only be required in the nova-compute units
[15:34] <apuimedo> yeah, I thought so too
[15:34] <jamespage> I've been running with stable n-cc charm and its working fine...
[15:35] <apuimedo> alright, I'll abandon the merge
[15:38] <jamespage> apuimedo, awesome
[15:41] <apuimedo> jamespage: I'll never get used to a brit saying awesome instead of brilliant :-)
[15:44] <apuimedo> jamespage: you had to manually add the compute hosts to the tunnel zone, right?
[15:45] <jamespage> apuimedo, nope - they all got added automatically
[15:45] <jamespage> \o/
[15:46] <jamespage> apuimedo, I had to work around that bug I detailed with a quick dhclient -r && dhclient before stuff got installed but apart from that 0 hacks...
[15:46] <jamespage> apuimedo, instances are getting dhcp IP addresses and can access the metadata service fine
[15:46] <jamespage> apuimedo, still can't get the external network bit going...
[15:46] <apuimedo> ok
[15:47] <jamespage> but that may be my test right
[15:47] <jamespage> rig being a bit bleeding edge...
[15:47] <apuimedo> well, I'm fixing the midonet-api unit tests and changing how the midonet-api registers the hosts into the tunnel zone
[15:47] <apuimedo> to use contrib.network.ip to get the ip of the compute node
[15:48] <apuimedo> and get the uuid from the relation
[15:48] <apuimedo> because otherwise it doesn't work with maas with dns domains :(
[15:52] <jamespage> apuimedo, ack
[15:52] <jamespage> apuimedo, I'll post a summary of TODO to the bug
[15:52] <apuimedo> very well ;-)
[15:52] <apuimedo> I am now removing the split branch
[15:52] <apuimedo> and leaving only /trunk
[16:47] <magicaltrout> alright chaps, charm publish, does that stuff work for us minions if I'm running the PPA?
[16:47] <magicaltrout> or do I have to wait?
[16:48] <jrwren> magicaltrout: it works
[16:48] <magicaltrout> boom!
[16:48] <magicaltrout> cool
[17:13] <jhobbs> is thre some way to tell juju which interfaces to associate with containers it creates?
[17:13] <jhobbs> we're using MAAS 1.9's vlan interface configuration and want containers to be connected to one or more interface
[17:13] <jhobbs> via a bridge
[17:13] <jhobbs> MAAS can't create the bridge - can juju do it?
[17:13] <jhobbs> this is the MAAS bug for creating the bridge https://bugs.launchpad.net/maas/+bug/1512187
[17:14] <mup> Bug #1512187: ability to create bridges on MAAS nodes for use without Juju <MAAS:Triaged> <https://launchpad.net/bugs/1512187>
[18:46] <magicaltrout> in actions, can you set default parameter values?
[18:46] <magicaltrout> of course in the action I can test to see whether its set or not, but if a sensible default was set if it wasn't passed in by the user,it would save me writing check logic
[19:30] <handicraftsman> Hello
[19:31] <handicraftsman> How i can install juju on my debian sid?
[19:32] <handicraftsman> It does not supports ppas
[19:33] <jrwren> handicraftsman: you can use the long form of ppa added to sources.list
[19:37] <handicraftsman> I'll choose xenial version, because it's not finished and ubuntu is always build on debian sid
[19:37] <jrwren> handicraftsman: go here: https://launchpad.net/~juju/+archive/ubuntu/devel/  expand the green "Technical details about this ppa" link and for sid, i'd recommend picking wily, but YMMV.  You'll need to run `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C8068B11 `
[19:38] <handicraftsman> I'll just install it on my linux lite laptop xD
[21:11] <marcoceppi> magicaltrout: yes, you can define a default
[21:15] <magicaltrout> marcoceppi: thanks
[21:15] <magicaltrout> somehow this hotel's wifi is worse than the other one, so testing this stuff is taking time! :P
[21:24] <marcoceppi> magicaltrout: boo
[21:25] <marcoceppi> magicaltrout: now that everyone is gone it's rather peppy here ;)
[21:25] <magicaltrout> hehe
[21:25] <magicaltrout> lack of porn being viewed......
[21:38] <jrwren> i'm roughly following the vanilla layers walkthrough and build says it can't find the layer i'm using.
[21:38] <jrwren> Does the walk through skip a part where I download layers to INTERFACE_PATH and LAYER_PATH?
[21:40] <marcoceppi> jrwren: no, you don't need to download layers
[21:40] <marcoceppi> jrwren: can you pastebin the output
[21:40] <marcoceppi> jrwren: (layers are fetched from the index)
[21:41] <jrwren> http://pastebin.ubuntu.com/14882887/
[21:42] <jrwren> let me check my charmtools version. maybe i didn't re-add ppa after upgrading to wily or something stupid.
[21:42] <marcoceppi> jrwren: yeah, was about to ask
[21:42] <marcoceppi> jrwren: charm version should do it
[21:42] <jrwren> 1.11.1
[21:43] <marcoceppi> that's latest
[21:44] <marcoceppi> jrwren: is your layer somewhere?
[21:44] <jrwren> marcoceppi: no, its brand new.
[21:44] <marcoceppi> jrwren: could you put it somewhere :)
[21:44] <marcoceppi> jrwren: also charm build -l DEBUG will be helpful
[21:45] <jrwren> http://pastebin.ubuntu.com/14882909/
[21:46] <marcoceppi> jrwren: layer.yaml file?
[21:47] <jrwren> includes: ['layer:nodejs', 'interface:mongodb']
[21:47] <jrwren> marcoceppi: https://github.com/jrwren/parse-server-example/tree/no-go-layers
[21:48] <marcoceppi> jrwren: you have a few problems, not related
[21:48] <marcoceppi> I don't think - in reactive file paths will work because of how they're imported
[21:48] <jrwren> marcoceppi: tons, i'm sure :)
[21:50] <marcoceppi> jrwren: works for me. Unset your LAYER_PATH and INTERFACE_PATH
[21:50] <marcoceppi> if there's nothing in there you don't need to set
[21:50] <jrwren> same results.
[21:52] <marcoceppi> http://paste.ubuntu.com/14882948/
[21:52] <jrwren> amazing
[21:55] <marcoceppi> this is what it should do jrwren http://paste.ubuntu.com/14882969/
[21:56] <marcoceppi> jrwren: does http://interfaces.juju.solutions load for you?
[21:56] <jrwren> marcoceppi: yes, i even just used curl to make sure it loads from the remote system on which I'm writing this
[22:01] <jrwren> marcoceppi: i added some debugging, i get 'build: fetch FetchError:No fetcher for url: layer:nodejs'
[22:03] <jrwren> indeed there is no layer fetcher
[22:04] <marcoceppi> jrwren: did you ever pip install charmtools?
[22:05] <jrwren> marcoceppi: not system wide. Maybe in a venv someplace, but that venv isn't active.
[22:05] <marcoceppi> ack
[22:05] <marcoceppi> otp, brb
[23:10] <jrwren> marcoceppi: tried on a different system, can confirm its something wrong with that system.
[23:10] <jrwren> marcoceppi: thanks for walking me through.


[09:03] <fossfreedom> hi - the date for beta 1 for community flavours is almost on us.  There are a couple of critical Ubuntu Budgie packages we would like reviewed and incorporated for beta 1 - please can these be reviewed as soon as possible?  TIA  bug 1713071  and bug 1713210
[09:56] <tsimonq2> fossfreedom: asking my sponsor
[09:59] <tsimonq2> FWIW, the debdiffs lgtm, if someone else is faster, please go ahead and upload ^^^^^^
[19:02] <fossfreedom> tsimonq2, cheers for reviewing our packages. I know its a bad day to ask (sunday) ... but is there anyone around who can confirm and upload please?  TIA  bug 1713071  and bug 1713210
[19:03] <Unit193> Finding a MOTU on a weekend is at least easier than core dev, and muuuch easier than Archive Admin. ;)
[19:03] <fossfreedom> :)
[19:44] <tsimonq2> Unit193: True ;)


[00:25] <ThisGuy> anyone on here that can xplain ubuntu thoroughly?
[00:26] <pleia2> ThisGuy: this channel is for scheduled classes, you might want to check out #ubuntu-beginners
[00:26] <ThisGuy> ohhhh. thnks


[04:13] <stochastic> hello, just curious if there's anyone here knowledgeable with connecting a Canon EOS 350D to Ubuntu?


[18:46] <pnarciso> hey
[18:58] <knome> ha! it never occurred to me before that pleia2 is an admin of ~ubuntu-core-doc via ~communitycouncil. she could have given me the power. haha.
[19:00] <elfy> lol
[19:24] <knome> set up https://launchpad.net/xubuntu-docs/saucy for contributions ;)
[19:28] <lderan> ooo
[19:30] <knome> ok, i'm off for now
[19:30] <knome> see you later
[22:23] <knome> micahg, do you have any experiences with mallard?
[23:16] <Noskcaj_school> bug 1177595
[23:39] <Noskcaj_school> can someone confirm?
[23:57] <micahg> knome: nope
[23:58] <knome> okay
[23:58] <knome> i'm looking how to get our docs turn up in yelp


[07:35]  * apw yawns
[08:56] <apw> rtg
[09:06] <apw> heh, that makes so much sense
[12:37] <Marex> Hi
[12:38] <Marex> I'm hitting this issue here http://www.spinics.net/lists/git/msg217736.html when I try to clone from kernel.ubuntu.com GIT repositories
[12:38] <Marex> would it be possible to contact the admins somehow ?
[12:38] <Marex> The patch for the issue has to be applied server-side and is already in upstream GIT repository, see http://www.spinics.net/lists/git/msg217744.html
[13:07] <apw> Marex, is that after a very long wait ?
[13:07] <apw> Marex, and ... does dropping the -q help
[13:07] <apw> was that you who said that ?
[13:08] <Marex> apw: dropping -q fixes it, yes
[13:08] <Marex> apw: it was me who posted to the git@vger ML, yes
[13:08] <apw> so you have a work around at least
[13:09] <Marex> apw: I'm invoking the git from Yocto build and as yocto adds the -q option to the git command line, the workaround is not much of an option
[13:10] <Marex> apw: would it be possible to get a proper fix applied ?
[13:10] <apw> Marex, well yokto isn't being very helpful now is it
[13:11] <apw> Marex, everything is possible, though that machine is on lucid, ick
[13:11] <apw> Marex, so i wouldn't bet my house on it
[13:11] <Marex> can the patch not be backported on that version of git? the patch doesn't seem too big
[13:14] <Marex> apw: the patches are here http://www.spinics.net/lists/git/msg217019.html http://www.spinics.net/lists/git/msg217020.html btw
[13:15] <apw> Marex, in the unlikely event that a patch against tip still applied it might well be possible, though it would have to go thorugh the SRU process so its not going to be less than weeks
[13:16] <apw> Marex, you would need to file a bug against git in the first instance
[13:16] <apw> Marex, though can you not work round this by cloning the tree locally and then just doing the yocto commands against a local mirror?
[13:16] <Marex> apw: it's a server side bug, why would I work around it instead of fixing the server ?
[13:17] <apw> Marex, presumably because you arn't running the command for fun but to get somethign donw
[13:17] <Marex> apw: certainly, but it's not only me running into these issues
[13:18] <Marex> apw: I just so happened to be too annoyed by it to push for a fix
[13:19] <apw> Marex, the backport looks to be non-trivial, so its not going to happen right now
[13:20] <apw> Marex, can you file a bug against git with the relevant info above in the description please, 'ubuntu-bug git' and give me the number, so i can thnk about it
[13:21] <Marex> I dont even have a lunchpad account, would it be too much to ask to leave this in your hands ?
[13:21] <apw> well normally one gets the reporter to test etc
[13:23] <Marex> apw: let me see
[13:27] <Marex> ugh
[13:27] <Marex> apw: where do I need to navigate to file a bugreport for ubuntu kernel git ?
[13:28] <apw> file it against the package git, as that is the issue
[13:28] <Marex> it's rather git-core , no ?
[13:29] <apw> https://bugs.launchpad.net/ubuntu/+source/git/+filebug
[13:29] <apw> old 'git' went away somewhen in the last 2 years, and git-core -> git
[13:49] <Marex> apw: is this the correct bug report https://bugs.launchpad.net/ubuntu/+source/git/+bug/1228148 ?
[13:51] <apw> Marex, yep that lookfs goo thanks
[13:57] <Marex> apw: thanks, I will also update the redhat bugzilla, where this was initially reported and the git mailing list
[14:25] <apw> jsalisbury, yo ... we discussed using aliases for git bisect good/bad to allow reverse bisects to not blowup ones head ...
[14:26] <apw> jsalisbury, if you ended up codifying that, i wonder if it would make sense to update https://wiki.ubuntu.com/Kernel/KernelBisection with that knowledge
[15:01] <jsalisbury> apw, never put anything into code, just been keeping track in my head when I do them
[15:05] <apw> jsalisbury, ok ...
[16:46] <apw> jodh, yo ... i have a couple of boxes which 'recently' are rebooting when i ask for power off ... ie when i say sudo poweroff it doesn't
[18:16]  * apw wanders to another location where there are beverages
[18:18]  * bjf thinks that's a fine idea


[03:25] <lotuspsychje> good morning
[04:09] <NewtonTrendy> hopefully not offtopic, but a dontations platform where you can donate to anything happening and anyone that can prove necessity has a chance of claiming the money
[04:10] <lotuspsychje> we try to keep discussions around ubuntu topics here NewtonTrendy is yours a bit related or?
[04:12] <oerheks> how is donating/reclaiming ubuntu related? reclaiming part i understand...
[04:33] <leftyfb> NewtonTrendy: https://itsfoss.com/open-source-funding-platforms/
[04:33] <leftyfb> and the linux foundation


It migrated now. (re @RikMills: @mitya57 are you bothered that this is not migrating? https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src-gles/5.15.2+dfsg-3)


[22:09] <yano> https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers
[22:09] <jenni> [ visual c++ - Why is this program erroneously rejected by three C++ compilers? - Stack Overflow ] - https://j.mp/1HLRSMY


[06:11] <rbasak> Eickmeyer: FWIW, you're not supposed to be able to push directly to git-ubuntu repositories. They're read-only.
[06:11] <rbasak> The staging branches are supposed to be the exception but they're not live yet (waiting on a Launchpad feature request).
[06:12] <rbasak> Eickmeyer: https://canonical-git-ubuntu.readthedocs-hosted.com/en/latest/howto/upload.html for how to "push" rich history with git-ubuntu
[14:14] <Eickmeyer> rbasak: Ah. Makes sense. Still came in handy as I did a `pull-lp-source` and `git ubuntu` for the merge and then built the package as normal and uploaded that way. Worked like a charm.
[14:32] <arif-ali> athos, thanks for your comments on the sosreport LP, I've got to the point of using debdiff-apply, and get the issue on "don't know how to rebase version-change", is that normal
[14:40] <Eickmeyer> arif-ali: debdiff-apply isn't really for you to use, but for the sponsor to use. :)
[14:41] <arif-ali> Eickmeyer: sure, wanted to make sure it would apply cleanly as per the issues with symbolic links yesterday. So wanted to see if that was something I need to worry about
[14:43] <LocutusOfBorg> ahasenack, LP: #2063841 has a new comment
[14:43] -ubottu:#ubuntu-devel- Launchpad bug 2063841 in virtualbox-hwe (Ubuntu) "[SRU] virtualbox crash on network traffic" [Critical, Confirmed] https://launchpad.net/bugs/2063841
[14:43] <LocutusOfBorg> please tell me if something is still missing, or you want something changed
[14:43] <ahasenack_> k
[14:43] <LocutusOfBorg> I'm a little bit afk but will answer eventually :D
[14:44] <athos> arif-ali: if that is the only issue you are  facing, it is fine. I will deal with it before uploading :) Thanks for addressing it.
[14:45] <arif-ali> ack, thanks
[15:25] <john-cabaj> Not sure anyone is around, but I'm hoping to get sponsorship on some new packages for LTS releases pre-Noble (Jammy, Focal, Bionic) - https://bugs.launchpad.net/bugs/2063362
[15:26] -ubottu:#ubuntu-devel- Launchpad bug 2063362 in involflt (Ubuntu Jammy) "Backport for 22.04, 20.04, and 18.04" [Undecided, In Progress]
[15:45] <tsimonq2> @pilot in
[15:45] <tsimonq2> o/
[16:00] <tsimonq2> liushuyu needs a bouncer ;P
[16:05] <john-cabaj> tsimonq2: Are you able to have a look at the LP bug above?
[16:06] <tsimonq2> john-cabaj: Sure :)
[16:09] <john-cabaj> tsimonq2: Thanks!
[16:11] <tsimonq2> john-cabaj: I'm a community member, so I don't have as much insight on this package's purpose as you probably do... that being said, if you need this in Bionic, that has passed the standard 5 year support cycle. I'd talk to the ESM team.
[16:11] <tsimonq2> john-cabaj: For Focal and Jammy, I'll do a full source NEW review (the works), but from an SRU team perspective my gut tells me they'll want more information.
[16:12] <john-cabaj> tsimonq2: Noted. Priority is Jammy and Focal
[16:16] <tsimonq2> john-cabaj: `lintian -EvIL +pedantic` throws me these two, I would be mindful of them for future uploads but I won't block on them: executable-not-elf-or-script (probably comes from upstream?), wrong-section-according-to-package-name (can be done via an Archive Admin override)
[16:19] <tsimonq2> Oh, on the source build itself I'm getting missing-build-dependency-for-dh-addon and missing-build-dependency-for-dh_-command ... should be a fairly simple fix
[16:19] <john-cabaj> tsimonq2: Interesting. The packages did build fine in my PPA
[16:21] <tsimonq2> Yeah, that is somewhat confusing, hm
[16:23]  * tsimonq2 sees if it builds any different with dh-dkms as a build dep
[16:27] <tsimonq2> john-cabaj: Is this intended to ship the *built* kernel module or just the source files under /usr/src/involflt-0.1.0/ ?
[16:30] <john-cabaj> tsimonq2: It's intended to ultimately build the module with the kernel. The kernel build pulls in DKMS, builds it, and packages the module
[16:31] <john-cabaj> So the former, I believe
[16:31] <tsimonq2> I ask because as-is, it only ships the source under /usr/src/involflt-0.1.0/
[16:32] <tsimonq2> I'm also not very familiar with DKMS packages :)
[16:32] <john-cabaj> tsimonq2: Right, I think if you were to install the DKMS package standalone, it would go there.
[16:33] <john-cabaj> But this should be part of the kernel build eventually (similar to zfs-linux, v4l2loopback, etc...)
[16:37] <tsimonq2> john-cabaj: Okay, I'm mostly satisfied here - the only thing that caught my eye besides the aforementioned Lintian flags is that src/md5.c is public domain. I'll add the debian/copyright entry and get these in the queue for you; that being said, I'd still suggest making the SRU bug report more detailed :)
[16:38] <tsimonq2> ( licensecheck --copyright -r . )
[16:38] <john-cabaj> tsimonq2: Thanks for giving it a look!
[16:39] <tsimonq2> No problem :)
[17:45] <tsimonq2> @pilot out
[18:11] <arraybolt3> tsimonq2: ok so what am I doing wrong here
[18:11] <arraybolt3> first I downloaded the build logs of all the failed qcoro builds and stuck them in a directory.
[18:11] <arraybolt3> Made sure they were unzipped and named differently, so they're all there.
[18:12] <arraybolt3> Then I went into the root of the qcoro source package tree, and did pkgkde-symbolshelper batchpatch -v 0.10.0 ../qcoro-symbols/*
[18:12] <arraybolt3> this spits out a ton of output and it does indeed change the symbols, but then when I build qcoro again locally, it has a bunch more added and removed symbols that almost seem to have been "missed".
[18:12] <arraybolt3> Any clue what happened there?
[18:13] <arraybolt3> (part of me is tempted to just surgically convert each build log into a diff file and then `patch` it manually)
[18:43] <RikMills> arraybolt3: pkgkde-symbolshelper batchpatch -v 0.10.0 -c amd64,arm64,armhf,ppc64el,riscv64,s390x../qcoro-symbols/* is what I would have done at 1st
[18:45] <tsimonq2> arraybolt3: try piping it into the command?
[18:46] <tsimonq2> I'd have to clone it myself, but if you're stuck I can do that
[18:47] <arraybolt3> I'll give it a shot later on, thanks!
[18:48] <tsimonq2> yw :)
[19:06] <liushuyu> tsimonq2: Thanks for looking through all the merge proposals!
[19:07] <liushuyu> tsimonq2: liushuyu needs a bouncer ;P > I did not use a bouncer because I know where to find the scroll back
[19:37] <RikMills> arraybolt3: do you mean your local qcoro build failed again on symbols, or it succeeded but with messy symbols output?
[19:38] <tsimonq2> liushuyu: hahahaha fair enough ;)
[19:38] <tsimonq2> liushuyu: Also, I didn't look through *all* of them, I left a few of the complicated ones ;P
[19:39] <arraybolt3> RikMills: It succeeded but with messy symbols output.
[19:39] <arraybolt3> And I'm unsure if it would have succeeded had I pushed to the archive.
[19:39] <RikMills> arraybolt3: arraybolt3 the current symbols file have a lot of MISSING entries commented out with a #
[19:40] <RikMills> is that perhaps what you are seeing?
[19:40] <arraybolt3> maybe, but it wasn't just that, there were symbols that were shown as needing to be added too
[19:41] <arraybolt3> so both new symbols and MISSING symbols together in the build log of the "working" build.
[19:41] <RikMills> arraybolt3: so I just did this: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3997/+sourcepub/16128654/+listing-archive-extra
[19:41] <RikMills> which might be more helpful than a local build
[19:42] <arraybolt3> hmm, yours looks substantially nicer than mine
[19:43] <RikMills> yeah, I don't seem to have any added. just missing optional, which is to be expected and allowed
[19:43] <arraybolt3> mine was this mess: https://termbin.com/wa1c
[19:44] <arraybolt3> and this is *after* pkgkde-symbolshelper
[19:44] <arraybolt3> what was the exact command you used to do it?
[19:44] <RikMills> the one I posted earlier
[19:45] <RikMills> arraybolt3: your above paste seems truncated
[19:45] <liushuyu> Hi there, can someone with permissions to retry https://launchpad.net/ubuntu/+source/gammaray/2.11.3-4ubuntu1/+build/28434638? It should succeed according to my PPA build https://launchpad.net/~liushuyu-011/+archive/ubuntu/misc/+build/28425081
[19:46] <liushuyu> (This is an universe package, so I suppose any MOTU or CoreDev should be able to do it)
[19:46] <RikMills>  pkgkde-symbolshelper batchpatch -v 0.10.0 -c amd64,arm64,armhf,ppc64el,riscv64,s390x ../buildlog_ubuntu-oracular-*
[19:47] <tsimonq2> liushuyu: .
[19:47] <RikMills> liushuyu: just did it. or collided with tsimonq2
[19:47] <RikMills> :P
[19:48] <arraybolt3> so yeah, the only thing I missed was the "-c" in there. OK, noted.
[19:49] <arraybolt3> I vaguely remember needing to do something like that now.
[19:50] <liushuyu> RikMills, tsimonq2: Thanks! (Although I am bit nervous because the build job got assigned to the slower ARM worker)
[20:12] <sudip> I need to request no-change rebuild of two packages for oracular. Is there any special process to request rebuild or do I just do the usual process of opening new bug, add debdiff and assign to sponsors?
[20:17] <arraybolt3> sudip: Easier yet still, say something here and someone who has access can do it.
[20:17] <arraybolt3> What two packages, and what are they being rebuilt for so I know what to put in the changelog?
[20:17]  * sudip knows arraybolt3 has access ;-)
[20:18] <sudip> diagnostics and ivtools please. "no-change rebuild for libace-7.1.3"
[20:19] <arraybolt3> on it
[20:19] <sudip> thanks arraybolt3
[20:24] <arraybolt3> sudip: done
[20:25] <arraybolt3> marked them both as being from you and sponsored them
[20:25] <sudip> thanks arraybolt3 :)
[20:26] <sudip> now I know whom to ping next time I upload a new version of libace in Debian  :D
[20:29] <arraybolt3> hmm, I have some time to burn, might not do a whole lot but why not...
[20:29] <arraybolt3> @pilot in
[20:34] <arraybolt3> Currently looking at fstransform.
[20:35] <arraybolt3> Patch looks great, building.
[20:35] <RikMills> arraybolt3: do you want me to upload qcoro or leave you another try?
[20:36] <arraybolt3> RikMills: If you could, that would be great, it takes a while to build here and if you have the magic words figured out, I'd not introduce another point of potential failure by passing it back to me.
[20:36] <arraybolt3> I'm sure I'll get a chance to patch the symbols right again :)
[20:36] <RikMills> ack, will do
[20:37] <RikMills> arraybolt3: done
[20:38] <arraybolt3> sudip: fstransform patch for Oracular sponsored (bug https://bugs.launchpad.net/ubuntu/+source/fstransform/+bug/2060740).
[20:38] -ubottu:#ubuntu-devel- Launchpad bug 2060740 in fstransform (Ubuntu Oracular) "fsattr fails to run" [Undecided, Confirmed]
[20:39] <sudip> arraybolt3: can you please add release targets for fstransform, Focal, Jammy and Mantic please
[20:39] <arraybolt3> sure
[20:39] <sudip> thanks :)
[20:40] <arraybolt3> done
[20:40] <arraybolt3> for https://bugs.launchpad.net/ubuntu/+source/bcftools/+bug/2062071, the fix looks like it should be applicable to Oracular too. Do you want to update the patch for that, or would you like me to do it so it can be uploaded and thus become SRU-ready for Noble?
[20:40] -ubottu:#ubuntu-devel- Launchpad bug 2062071 in bcftools (Ubuntu) "gff2gff.py crashed with ModuleNotFoundError in Noble" [Medium, Confirmed]
[20:42] <sudip> arraybolt3: will be great, if you can do it please. I think I missed it when I was updating all the others to Oracular
[20:42] <arraybolt3> kk, doing
[20:43] <sudip> thanks a lot
[20:45] <arraybolt3> oh, actually, it looks like Debian already has the fix and it's been pulled into Oracular.
[20:45] <arraybolt3> So in that instance, the Noble patch is SRU-ready.
[20:47] <sudip> I will need to add the SRU information first. removing sponsors for now, will add the info tomorrow and put it to sponsors list again
[20:47] <arraybolt3> sounds good
[21:05] <sudip> arraybolt3: I can see the no-change upload in diagnostics, but cant see it for ivtools.
[21:12] <sudip> dont worry, I can see it now. thanks again :)
[21:14] <arraybolt3> Wrote some guidance for the libfilezilla SRU patch here: https://bugs.launchpad.net/ubuntu/+source/libfilezilla/+bug/2061954
[21:14] -ubottu:#ubuntu-devel- Launchpad bug 2061954 in libfilezilla (Ubuntu) "filezilla crashed with SIGABRT in start_thread()" [Undecided, In Progress]
[21:14] <arraybolt3> and with that, my patch piloting time is out.
[21:14] <arraybolt3> @pilot off
[21:14] <arraybolt3> @pilot disable
[21:14] <arraybolt3> @pilot out
[22:05] <ahasenack_> LocutusOfBorg: I couldn't get to virtualbox, the containerstack sru was huge and was ahead
[22:05] <ahasenack_> blackboxsw: ^likewise for cloud-init
[22:06] <blackboxsw> thanks ahasenack_ for the note. we appreciate the effort


[02:50] <elkbuntu> darkmatter, well you already put suse on it...
[02:50]  * elkbuntu runs and hides
[03:56] <darkmatter> heh. actually. suse doesnt have nearly as many err... shall we call them "features".. as ubuntu :P
[03:58] <nothlit> yes, our beloved ubuntu "features"
[04:04] <troy_s> darkmatter: Swoopy curvey sh*te for all!  Yay!
[04:04] <darkmatter> lol
[04:23] <elkbuntu> bah.. he's gone... i cant go on about rpms now :(
[04:31] <troy_s> elkbuntu: No, but we have swoopy swirly curvey windows 95 stuff!
[15:51] <kwwii> lassegul: ping?


[03:16] <mwhudson> what is the expected time between verification being done on an sru bug and it hitting -updates?
[03:16] <mwhudson> it's only been 3-4 days for the ones i care about but i want to calibrate my expectations :-)
[03:34] <stgraber> mwhudson: it's usually at least 7 days after the package was accepted in -proposed
[03:34] <mwhudson> stgraber: ah ok
[03:34] <mwhudson> i had a memory of something like that but i couldn't find it written down anywhere
[04:55] <pitti> Good morning
[04:56] <pitti> infinity: yeah, it was on Friday; we are still missing lcy01, and I had about 500 kernel tests queued up
[04:57] <pitti> infinity: it seems ppc64el has a problem (lots of in progress), looking
[06:24] <pitti> infinity: nodejs built everywhere and all of its tests pass (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nodejs)
[06:24] <pitti> infinity: ok to remove block-proposed, or do you want to do some manual testing too?
[07:14] <seb128> cyphermox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1482851 ?
[08:57] <cjwatson> pitti: Could you please chase webops about that (lcy01)?  https://rt.admin.canonical.com/Ticket/Display.html?id=84603 has been resolved since Thursday, so if your stuff still doesn't have access to it then that shouldn't be very hard to fix now.
[08:57] <pitti> cjwatson: oh, I will, thanks
[08:58] <pitti> cjwatson: webops> that's filing an RT? or the IS IRC channeL?
[08:58] <cjwatson> pitti: I was thinking #webops, but indeed you'll probably want to file an RT
[08:59] <pitti> cjwatson: /me files, thanks
[09:11] <pitti> cjwatson: btw, all bos* builders having this "permission denied (public key)" / Cleaning error is known?
[09:11] <cjwatson> wgrant: ^-
[09:19] <cjwatson> pitti: Oh, I think IS are just in the middle of moving that over to a different firewall
[09:20] <cjwatson> wgrant: ignore
[09:23] <cjwatson> pitti: happier now
[09:23] <pitti> yay
[10:11] <Odd_Bloke> cjwatson: Did you have a chance to play with that build I pasted to you on Friday?
[10:12] <cjwatson> Odd_Bloke: Oh, not yet, let me finish up my current branch and then try that.
[10:13] <Odd_Bloke> cjwatson: Cheers. :)
[12:06] <cjwatson> Odd_Bloke: Sigh, I need to bite the bullet and set up a VM buildd rather than relying on lxc
[12:07] <Odd_Bloke> cjwatson: :(
[12:42] <pitti> stgraber: FYI, i386 regression on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lxd
[12:43] <pitti> stgraber: I tried to run this locally in a VM, but there it doesn't even succeed on amd64 (http://paste.ubuntu.com/12514056/)
[12:55] <pitti> PSA: I need to take down and rebuild autopkgtest.ubuntu.com (just the debci web UI, not the machiner)
[12:55] <pitti> machinery
[14:50] <ogra_> woah ...
[14:51] <stgraber> pitti: I saw that failure but it confused me a bit, the testsuite never succeeded on i386 (except locally where it passes fine) and the web UI wasn't showing me the actual failure for 0.18-0ubuntu2
[14:51]  * ogra_ just accidentially typed "ssh cdimage" instead of "ssh nusakan" ... and i noticed that the cdimage entry in my known_hosts not only predates nusakan but also encryption of known_hosts entries
[14:51]  * ogra_ feels old
[14:51] <pitti> stgraber: yeah, that's the reason why I had to rebuild autopkgtest.u.c., it ran out of space
[14:52] <seb128> cyphermox, hey, did you see my os-propber ping earlier?
[14:52] <cyphermox> seb128: I did, I just committed this in Debian
[14:52] <cyphermox> I'm about to apply the changes here now
[14:52] <cyphermox> just doing a few things at a time :)
[14:53] <seb128> cyphermox, that's ok, you didn't pong so I was unsure, thanks!
[14:53] <cyphermox> yeah, sorry :)
[14:54]  * pitti needs to run, cu tomorrow
[15:13] <Saviq> pitti, hey, if I wanted to test adt-run on packages as built in a silo/PPA, is something like the following correct?
[15:13] <Saviq> adt-run --no-built-binaries --binary *.deb --source unity8_*.dsc --- schroot wily-amd64-shm
[15:13] <Saviq> it does complain about broken deps :/
[15:33] <tdaitx> infinity, pitti, bdmurray squid3 depends on libecap2, but the build fails because libecap2 is using the old gcc abi while squid3 current build is using the new one, I can get squid3 to build with -D_GLIBCXX_USE_CXX11_ABI=0 but I'm not sure if that is the right approach
[15:35] <rbasak> tdaitx: thank you for looking at it and sorry for the mess, I intended to merge squid3 before feature freeze but ran out of time. Let me know if I can help with anything. I'm not sure of the answer to that question.
[15:35] <rbasak> I wonder if we should migrate libecap2 to the new ABI?
[15:35] <rbasak> IIRC the only libecap2 consumer is squid3.
[15:39] <tdaitx> rbasak, you are right, reverse-depends (-b) list only squid3 as a dependency, so rebuilding it should work
[15:39] <tdaitx> rbasak, are you able to trigger a rebuild?
[15:44] <tdaitx> rbasak, and thanks, I was wondering why we were still at 3.3.8 while debian is at 3.5.7 =)
[15:45] <tdaitx> anyway, I have been able to fix squid3 FTBFS locally
[15:47] <sil2100> cjwatson: I'll be doing a bzr pull of my latest changes to cdimage on nusakan - in case it breaks something, feel free to revert ;)
[15:48] <infinity> rbasak: I wouldn't be against you merging squid3 to be up to date with Debian, if we can test it in any reasonable way.
[15:48] <infinity> rbasak: We're behind by years.
[15:49] <cjwatson> sil2100: jfdi, I expect it's just your change
[15:49] <cjwatson> sil2100: I normally pull immediately
[15:53] <rbasak> infinity: the merge will take me at least a day, maybe two, to clean it all up. I think that by the time I get round to it we'll be too close to release :(
[15:53] <seb128> cyphermox, is there any chance you could review https://code.launchpad.net/~binli/ubuntu/wily/modemmanager/lp1441095/+merge/271088 ?
[15:53] <rbasak> tdaitx: I can upload a no-change rebuild, but I'd prefer to have an uploader more familiar with the GCC 5 ABI transition ack it first since I'm not sure I fully understand the consequences.
[15:55] <infinity> rbasak: Well, we definitely should get caught up for 16.04, if you'd rather merge first thing in 16.04, that's fine too, but merging now would get rid of that one old library.
[15:56] <cyphermox> seb128: yes, it's on my list for today
[15:56] <seb128> cyphermox, excellent, thanks ;-)
[15:58] <hallyn> pitti: do you have a candidate pkg source for systemd 226 for ubuntu?  should i just use the debian pkg verbatim?
[16:04] <tdaitx> rbasak, oh, btw, I said libecap2 only required a rebuild, but since a few symbols will change, debian/libecap2.symbols does require a few changes
[16:17] <tdaitx> infinity, if we rebuild libecap2 and that changes the symbols, would we need to update its version as well? (libecap3, which, btw, is already being used by ecap 1.0)
[16:23] <infinity> tdaitx: It would need the package name changed, per the C++ transition.
[16:24] <tdaitx> infinity, thought so... alright, is it ok to build squid3 with -D_GLIBCXX_USE_CXX11_ABI=0 then? at least until we get the merge in?
[16:24] <infinity> tdaitx: Does it link to any other C++ libraries?
[16:26] <infinity> tdaitx: Links to libicuuc.so.55, that looks C++ish as well, and I assume has transitioned.
[16:26] <infinity> tdaitx: So you'd be mixing ABIs.
[16:27] <infinity> tdaitx: Well, except that ICU probably didn't actually change.  Most libraries didn't.
[16:27] <infinity> tdaitx: Anyhow, if libecap *does* change on rebuild, it should be transitioned, IMO.
[16:27] <infinity> tdaitx: Cause a security update would cause a post-release explosion.
[16:28] <tdaitx> ouch, indeed
[16:30] <Laney> xnox: I'm going to upload what we have there, can tweak later on
[16:30] <infinity> tdaitx: When you speak of libecap3, is that only in Debian?
[16:31] <tdaitx> it seems to be better to get the squid3 merge in and avoid all that
[16:31] <tdaitx> infinity, no, it is in wily-proposed as well
[16:31] <infinity> tdaitx: Oh. So.  From the same source package.  That *completely* changes this conversation.
[16:31] <infinity> tdaitx: Because we're also talking about removing libecap from proposed, and any rdeps (does it have any?)
[16:32] <infinity> Oh, it really is *just* squid. :P
[16:33] <infinity> tdaitx: So, either remove libecap from proposed and rename/transition libecap2.  Or work with rbasak to get a merged squid in and give it a bit of testing.
[16:33] <infinity> tdaitx: I'm really more in favour of the latter, but either workd.
[16:33] <infinity> s/workd/works/
[16:35] <tdaitx> right, I also believe getting squid up to date is better
[16:36] <infinity> tdaitx: Well, and I assume this is why libecap2 never transitioned, because the new version is already "transitioned".
[16:37] <rbasak> tdaitx: I have some pieces of a merge from a previous merging tutorial I can use. Let me take a look tomorrow.
[16:38] <tdaitx> rbasak, would you mind if I give that merge a try?
[16:41] <infinity> Willing to bet most of our delta goes away on a merge anyway.
[16:41] <infinity> Security updates, etc.
[16:45] <rbasak> tdaitx: IIRC it's a complex and messy merge, with tons of delta that needs rationalising and IIRC quite a bit of it needs modifying or dropping. I think quite a bit of it needs to remain, too. I've already done half the work.
[16:46] <rbasak> tdaitx: I use http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html
[16:46] <tdaitx> rbasak, in that case, keep up the good work =)
[16:46] <rbasak> tdaitx: you can take it if you really want it, but it'd be duplicating some effort I think.
[16:46] <tdaitx> yeah, agreed
[16:46] <rbasak> tdaitx: OK. OTOH if I don't get to it tomorrow then I don't want to block anyone.
[16:56] <tdaitx> rbasak, don't worry about that, if we can't get a newer squid in, then we only have to transition the current libecap2 and apply a few patches to the current squid3 source package
[16:58] <tdaitx> rbasak, and thanks for that link ;-)
[17:11] <ScottK> FYI, it looks like Ben needs a kick since there's several listings in http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4-5.html that are long out of date.
[17:57] <hjd> How does virtual packages work, or rather, how are they created? libjpeg9 fails to build (https://launchpadlibrarian.net/217954976/buildlog_ubuntu-wily-amd64.libjpeg9_1%3A9a-2_BUILDING.txt.gz) because it is missing automake-1.14. This seems to be a virtual package which is in Debian (https://packages.debian.org/unstable/automake-1.14), but I can't find a trace of it in Ubuntu...
[18:00] <sarnold> hjd: it does look like it exists... https://launchpad.net/ubuntu/+source/automake-1.14
[18:03] <hjd> When I try to look up the package name I find http://packages.ubuntu.com/wily/automake, which is built from automake-1.15, but has the same binary package name. Perhaps that is confusing it somehow?
[18:15] <xclaesse> mardy, signond not giving token to apps happens again
[18:15] <xclaesse> mardy, sending you syslog in mp (redacted tokens, but in case it still contains something sensing better not post in public chan)
[18:18] <xclaesse> mardy, what I see the first time evo asks for the token signond says "Stored token is expired", then all subsequent retries it says "One request is already active"
[18:20] <xclaesse> mardy, if I kill signond it works again
[18:20] <xclaesse> mardy, my understanding is that it tries to refresh the token, for some reason that operation never completes, then it's stuck forever waiting for that operation to finish before giving a token to any app
[18:31] <TJ-> hjd it looks like the source claims to be in 'universe' but the copy-from-Utopic applies to 'main' (the .debs are in pool/main/ too)
[18:31] <pitti> Saviq: this looks ok in principle, but you should add a -B before the dsc, otherwise it'll build the .dsc again
[18:32] <Saviq> pitti, --no-built-binaries is there
[18:32] <pitti> Saviq: does wily satisfy all of its dependencies?
[18:32] <Saviq> pitti, no, the --binaries do
[18:32] <pitti> Saviq: perhaps you rather want to add the PPA?
[18:32] <pitti> hallyn: yes, you can use https://launchpad.net/~pitti/+archive/ubuntu/systemd
[18:33] <Saviq> pitti, that's what I was thinking if I fail to run from dir, just add the PPA to the chroot and run as if it worked from the archive
[18:33] <pitti> hallyn: this contains the output of the "trunk CI" builds, I regularly run them and they get uploaded if they pass all tests
[18:33] <Saviq> pitti, but thought it's possible to do locally
[18:33] <pitti> hallyn: you can poke me if you want/need a new trunk build; it's just calling a single script, but I need to remember doing it often enough
[18:34] <pitti> Saviq: yes, I often run it like that (adt-run *.deb -B foo.dsc), works fine in general; do you have a log of the error?
[18:34] <Saviq> pitti, just a sec
[18:34] <hallyn> pitti: thx, i'll use that.  i just want to build a 226 with some debug added so i can test why sid containers are regressing with journald
[18:35] <Saviq> pitti, ah, I think I found my issue... my *.deb included armhf and i386 packages...
[18:36] <Saviq> doh
[18:37] <pitti> Saviq: :)
[18:58] <stgraber> pitti: that MAC address test failure is really odd. I'm currently working on our testsuite and I've run it probably about 50 times over this weekend and never saw that one, yet it seems to be easy enough to reproduce in the adt environment
[18:58] <stgraber> pitti: I'm assuming it's some kind of race, possibly happening on slow storage (all my systems are on SSD)
[18:59] <stgraber> pitti: I pushed a force-skiptest for LXD since it's clearly not a regression and I'll add a bit more context to that test for the next release, so hopefully I can see whether it's an actual race (no MAC at that point or something) or something's actually messing up the MAC address somehow
[19:00] <stgraber> (we also run the testsuite on every commit and have never seen that particular failure outside of adt)
[19:12] <cjwatson> hjd: Virtual packages are things which appear in the Provides field of another package.
[19:15] <cjwatson> hjd: wily has automake-1.15, not automake-1.14.  libjpeg9 should really not be build-depending on automake-1.14, but rather on automake (>= 1:1.14) - assuming that it works with 1.15, that is.
[19:16] <cjwatson> (If it's even a sensible thing to have in the archive at all, given that I thought libjpeg-turbo was consciously preferred.  Not sure why doko synced it.)
[19:21] <sarnold> cjwatson: why do you say that automake-1.14 isn't in wily? https://launchpad.net/ubuntu/+source/automake-1.14 shows that it is published for wily, expanding the little triangle shows an _all.deb file for it that's just about the same size as the 1.15 _all.deb; I just don't see how it's "not in wily"
[19:22] <sarnold> I mean, the error from the builder looks like it agrees with you :) but I just odn't know how the builder came to the same conclusion you did
[19:23] <cjwatson> sarnold: the automake-1.14 source produced exactly one binary, "automake", which is superseded in the archive by a binary of the same name built by automake-1.15
[19:23] <cjwatson> So the fact that the automake-1.14 source is still present is cruft, but essentially irrelevant
[19:23] <cjwatson> We don't have good reports for that kind of thing so they sometimes aren't cleared up very promptly
[19:24] <cjwatson> In this case, probably partly because the source doesn't seem to have been removed from Debian unstable yet
[19:24] <sarnold> cjwatson: aha, thanks for the explanation
[19:27] <hjd> cjwatson: sarnold: Ok, I see.
[19:27] <hjd> Btw, what's the story on libjpeg vs libjpeg-turbo?
[19:28] <cjwatson> The TB decided to go for libjpeg-turbo some time ago
[19:28] <cjwatson> The Debian technical committee agreed, more recently
[19:28] <cjwatson> I have absolutely no idea why libjpeg9 is being introduced into wily now
[19:33] <hjd> cjwatson: Ok, thanks.
[21:07] <mterry> ogra_, do you know much about system loggers?  Like how one registers as one?  And how /dev/log connects to it?
[21:09] <mterry> Or anyone else, if anyone knows.  :)
[21:11] <mterry> slangasek, maybe you know?  ^
[21:13] <cyphermox> mterry: slangasek is on vacation
[21:13]  * cyphermox looks
[21:15] <sarnold> mterry: iirc /dev/log is a unix domain socket with a name in the filesystem; it is probably created by a socket(AF_UNIX), bind(s...) series of system calls
[21:16] <cyphermox> yep
[21:17] <sarnold> mterry: if you want to handle some log entries but not others, you probably have to write an rsyslog module; you might also configure rsyslog to forward all entries to a specific tcp or udp port, ip..
[21:17] <cyphermox> mterry: my reaction was to dig in src/journal in systemd source
[21:19] <mterry> cyphermox, sarnold: I'm trying to debug a case where syslog() freezes.  Trying to figure out where it's dying before it hits rsyslog.  And there's some evidence that rsyslog isn't correctly being "registered" as the system logger, however that's done (is that simply creating /dev/log?)
[21:19] <mterry> This is on the phone, so no systemd.  But true that it may be instructive
[21:19] <sarnold> mterry: syslog() _freezes_? that's odd. can you reproduce it with e.g. logger(1)?
[21:20] <mterry> sarnold, yes.  I can reproduce it with a one-line main() call to syslog
[21:20] <mterry> (and logger(1))
[21:21] <mterry> If I 'restart rsyslog', it no longer freezes
[21:21] <mterry> But it also doesn't write to syslog
[21:21] <mterry> So I think rsyslog is having troubles 'registering' as the logger?  first time it gets broken.  and can't do it subsequent times
[21:22] <mterry> If I gdb into rsyslog, it's waiting on a select, which would seem to be normal rsyslog behavior
[21:22] <cyphermox> mterry: maybe you're running in a case where some other android thing is picking things up when it shouldn't, if it's some new device
[21:22] <sarnold> mterry: I think if the file exists, rsyslog ought to be running; if writes into the socket are blocking, that might mean that rsyslog isn't consuming data quickly enough.
[21:22] <mterry> cyphermox, that's possible
[21:23] <cyphermox> mterry: unlikely though :)
[21:23] <cjwatson> it'll be openLogSocket in rsyslog, I expect
[21:23] <sarnold> mterry: odd that it would be just sitting in select(); I'd expect rsyslog to really be free of select() bugs by now
[21:23] <mterry> cjwatson, it seemed to be the same place a well-behaved rsyslog was waiting, but I don't recall at the moment.  let me check
[21:23] <cjwatson> you might want to arrange for rsyslog debugging output to go somewhere useful, since I expect it'll at least issue a debug message if it fails to bind /dev/log
[21:23] <cjwatson> (I don't know how to do that OTTOMH)
[21:24] <cjwatson> the process of opening the log is basically socket+bind
[21:24] <cjwatson> see createLogSocket
[21:24] <mterry> Yeah, rsyslog is selecting inside of realMain.  Presumably doing its normal looping?
[21:24] <cjwatson> and bind(2) + unix(7)
[21:24] <mterry> cjwatson, ok
[21:25] <mterry> cjwatson, I remember it being awkward to get debug info out of rsyslog...  will see what I can do
[21:25] <cjwatson> bind() can fail if something else is already bound to the same filesystem socket object
[21:25] <cjwatson> if I were investigating this I would probably just hack it to spew debug to some hardcoded file under /run
[21:26] <cjwatson> debugging early boot stuff got a lot easier when /run was devised :)
[21:26] <mterry> cjwatson, heh
[21:26] <cjwatson> alternatively you could just hack the upstart job to run it under strace
[21:26] <cjwatson> and likewise dump the trace to /run
[21:27] <cjwatson> that would probably be my first resort
[21:27] <cjwatson> then you can look for it trying to bind to /dev/log, which should be pretty early, and see if it worked
[21:28] <mterry> cjwatson, great points, thank you.  I'm about to go EOD; I'll try them tomorrow
[21:29] <mterry> Rsyslog may have won the battle, but it will not win the war  :)
[21:32] <hallyn> pitti: oh, nm, i see it must be in your bzr or git tree - sorry for the noise
[21:32] <sarnold> mterry: one possibility is that the /dev/log might have changed underneath you somewhere; I think all it would take to seriously confuse things is for one program to unlink(/dev/log), then create its own socket or fifo
[21:33] <sarnold> mterry: check lsof for inode numbers for both the hanging client and the running rsyslog; perhaps the /dev/log is a holdover from an android logging daemon? (seems unlikely, but worth mentioning, the situation you've got now is confusing)
[21:35] <mterry> sarnold, agreed  :)   thanks
[21:39] <mterry> sarnold, lsof only shows rsyslog on the broken device
[21:40] <sarnold> mterry: does it have the same inode number as e.g. the blocking logger() or one-liner syslog() program?
[21:41] <mterry> sarnold, oh, right.  I had run it without the syslog program up  :-/
[21:41] <mterry> sarnold, with that up, I see:
[21:41] <mterry> dpmd     2197   root   12u  unix 0xffffffc0675ba000      0t0 19440 /dev/socket/qmux_radio/qmux_client_socket
[21:42] <mterry> which is unexpected by me
[21:43] <mterry> Which is some android thing
[21:43] <mterry> I think I need to talk to the android-side people
[21:43] <sarnold> qmux radio? o_O
[21:44]  * mterry shrugs
[21:44] <mterry> sarnold et al: thanks for the help.  I'm going to knock off soon, but will try digging further with your awesome suggestions tomorrow
[21:45] <sarnold> have a good evening :)


[17:20] <yano> https://forecast.weather.gov/showsigwx.php?warnzone=OHZ055&warncounty=OHC049&firewxzone=OHZ055&local_place1=2%20Miles%20WNW%20Columbus%20OH&product1=Tornado+Watch&lat=39.9993&lon=-83.0149
[17:21] <yano> .nws 43210
[17:21] <jenni> !!!TORNADO!!! *WATCH* issued April 03 at 1:13PM EDT until April 03 at 8:00PM EDT by NWS
[17:21] <jenni> Special Weather Statement issued April 03 at 12:59PM EDT by NWS
[17:21] <jenni> Flood Advisory issued April 03 at 11:06AM EDT until April 03 at 8:00PM EDT by NWS
[17:21] <jenni> Flash Flood *WATCH* issued April 03 at 10:23AM EDT until April 04 at 2:00AM EDT by NWS
[17:21] <jenni> [ National Weather Service Watch Warning Advisory Summary ] - https://bit.ly/2Eg1Kxe
[17:21] <jenni> Complete weather watches, warnings, and advisories for Columbus, OH, available here: https://alerts.weather.gov/cap/wwaatmget.php?x=OHC049 -- You may also PM me to get more details.


[00:10] <lifeless> cjwatson: for when you get up - if I read things right, grub is trying to decide if my .../ARRAY0 device is a partition or a whole disk
[00:10] <lifeless> cjwatson: and failing because its not linear so not easy
[00:10] <lifeless> cjwatson: but this seems bogus: its a bios drive even though linux considers it a devmapper device
[00:11] <lifeless> cjwatson: shouldn't we treat it as a whole disk ?
[00:12] <lifeless> put another way, we seem to be poking under an abstraction that we shouldn't, in this case.
[00:14] <lifeless> e.g. devmapper for a linear ICH10R mirror drive can determine we start at offset 128 (or whatever), but at boot time we have an offset of 0, because we're talking to the array not the components
[01:27] <lifeless> \o/ I win.
[01:27] <lifeless> up-and-running
[10:04] <CIA-37> debian-installer: cjwatson * r1480 ubuntu/ (build/config/armel/linaro-vexpress.cfg debian/changelog): Move armel/linaro-vexpress to 2.6.39-1001 kernels.