[01:38] <duflu> Oh seriously? Same boot bug now affects my second desktop
[03:59]  * duflu suspects grub/EFI boot bugs are due to me having customized /etc/default/grub (which confuses updated)
[03:59] <duflu> It's happened on trusty and wily now
[03:59] <duflu> *confuses updates
[04:01] <RAOF> Huh.
[04:01] <RAOF> I've customised that.
[04:01] <RAOF> And not had anything break :)
[04:01] <duflu> RAOF: Just a theory. I've spent Monday morning reinstalling my wily build machine from scratch
[04:02] <duflu> Also there were slight signs of filesystem corruption in a couple of places
[04:02] <duflu> So start again
[04:02] <duflu> The system was only a week or two old to begin with
[13:04] <miken> kgunn: Hi. I took a look at the kodi/xbmc code over the weekend. It seems they've been moving away from sdl2, using gl/gles/dx for rendering (I'm not certain, still trying to find out on irc). I assume that's narrows my options down for trying to use the mir snap?
[13:07] <davmor2> miken: I believe that gles wouldn't be an issue, not sure about gl but dx I think is microsofts so almost certainly a no go, others might be able to inform you more
[13:08] <miken> davmor2: yes, I assumed I'd be using gles if anything (that's what the kodi rpi deb build uses). But I assumed my snap wouldn't have access to gles. Great if it does.
[13:09] <miken> (heh, and yes, I won't be trying with directx :P)
[13:16] <anpok_> miken: if egl does not work you will have to implement: https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/egl/EGLNativeType.h
[13:17] <anpok_> s/egl/sdl
[13:24] <miken> OK, I'll try a binary using gles and go from there. Thanks anpok_ .
[13:24] <miken> and davmor2 :)
[19:07] <attente> is anyone getting really bad flickering in the demo shell after the kernel update to 4.0?
[19:38] <racarr_> I keep on finding more code to delete in papi :( the delete-deprecations diff is now over
[19:38] <racarr_> 15k lines and I can't
[19:38] <racarr_> keep track of it lol
[20:06] <kgunn> attente: interesting, intel ?
[20:08] <attente> kgunn: yes. it's reminiscent of https://bugs.freedesktop.org/show_bug.cgi?id=88944. but it's slightly different that the flickering only occurs below wherever the cursor is. and the workaround of switching to a vt before switching to the demo server doesn't work
[20:10] <kgunn> attente: so i take it you got the kern update via being on wily ?
[20:11] <attente> kgunn: yes. i switched back to an older one for the mean time
[20:12] <kgunn> yeah, i think everyone's been real hesitant to step off into wily
[20:12] <kgunn> most folks staying on vivid+stable overlay
[20:37] <racarr_> greyback: pushed updates to platform-api delete-deprecations
[20:38] <greyback> racarr_: thanks for that
[20:40] <racarr_> np :D
[20:40] <racarr_> deletedeletedelete
[20:41] <greyback> yummy red
[22:41] <racarr_> omg I didn't realize how much code I was going to get to delete in input/android now that droidinput::InputDispatcher
[22:41] <racarr_> is gone
[22:41] <racarr_> :)
[22:41] <racarr_> death to input registrar, input enumerator, android_input_targeter
[22:41] <racarr_> window handle repository
[22:41] <racarr_> android window handle
[22:41] <racarr_> android application handle
[22:41] <racarr_> and the dispatcher
[23:28] <RAOF> :)


 It is, it is about havign a system that will work forever
[11:07] <bazhang> get snapd on warty!
[11:08] <bazhang> @random ohsnap HURD emacs
[11:08] <bazhang> what!
[11:17] <bazhang> 'crapbuntu'
[11:17] <k1l> its snapbuntu now ;p
[11:17] <bazhang> haha
[11:18] <bazhang> thats only yakkety?
[11:18] <k1l> the base snap is included since 16.04
 OerHeks: try to stop being useless in the channel
[22:59] <elky> dax: what is atomicspark on about?
[23:00] <dax> video games


[19:55] <bpye> If targeting armhf for ubuntu, what's the feature level I can rely on? on clang armv7-linux-armeabihf seems to imply NEON which is above the level of some armhf targets
[20:18] <infinity> bpye: It shouldn't imply it with Ubuntu's clang... Or didn't used to.  Maybe someone dropped that patch.
[20:18] <bpye> That's when i'm setting with -target armv7-linux-armeabihf
[20:18] <infinity> bpye: Anyhow, the minimum ISA for armhf is armv7, thumb2, vfpv3-d16
[20:19] <bpye> Alright, thank you


[00:11] <marcoceppi> magicaltrout: no worries, you can leave them running for a few weeks before I start to ask questions
[00:11] <marcoceppi> esp since I can see what's running on them and anyting with dcos in it intrigues me
[07:38] <ReSam> how can I use "juju upgrade-juju" to upgrade my machines from beta5 to beta6?
[13:33] <gnuoy> jamespage, thedac, tinwood, beisner, wolsen I've move our layers and interfaces onto https://github.com/openstack-charmers and repointed our entries on http://interfaces.juju.solutions/
[13:40] <gnuoy> s/move/moved/
[13:40] <ReSam> I'm trying to install glance - but it fails at setting up the mysql db with: "Host <IP_ADDRESS>  is not allowed to connect to this MySQL server". But the IP mentioned is exactly the IP of the machine...
[13:52] <ReSam> seems to be this bug: https://bugs.launchpad.net/charms/+source/mysql/+bug/1305582
[13:52] <mup> Bug #1305582: relation with mysql fail when mysql and glance are deployed on the same node <cts> <openstack> <mysql (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1305582>
[14:11] <xnox> jamespage, hypothetically, instead of two network cards, could two different vlans be used on a single network card for openstack deployment?
[14:12] <xnox> aka foo.2001 & foo.2002, instead of two connections?
[14:12]  * xnox ponders how good support for vlans is in juju/lxd/openstack world =)
[14:24] <BlackDex> hello there
[14:25] <BlackDex> i get the following
[14:25] <BlackDex> 2016-04-26 14:24:36 ERROR juju.cmd supercommand.go:429 cannot assign unit "mysql/0" to machine 1: machine is not alive
[14:25] <BlackDex> i installed the machines manually with ubuntu 14.04.4
[14:26] <BlackDex> and after that added them with juju add-machine<EMAIL_ADDRESS>[14:26] <BlackDex> why isn't this working?
[14:27] <aisrael> Is there a workaround for bootstrapping xenial on aws? Bootstrap can't find any xenial images
[14:28] <magicaltrout> aisrael: I asked on the ML, Mark said there will be images later this week hopefully
[14:29] <SaltySolomon> hi
[14:30] <SaltySolomon> Can I ask some support questions here, or is there a differnet channel?
[14:32] <magicaltrout> SaltySolomon: you can try, this is the correct place
[14:33] <SaltySolomon> We are currently trying to setup openstack with maas and juju, we got maas set up and working, but everything else is bugging out when we try to install juju
[14:33] <magicaltrout> you might struggle with openstack questions, I believe most of them are in austin
[14:33] <aisrael> magicaltrout: thanks!
[14:34] <SaltySolomon> Bootstraping Juju takes ages
[14:34] <marcoceppi> SaltySolomon: where's teh bugging start? does bootstrap complete?
[14:35] <SaltySolomon> well, it says bootstraping juju, but it doesn't really finish, does it normally take a long time?
[14:36] <marcoceppi> SaltySolomon: shouldn't be more than 10 mins
[14:36] <marcoceppi> SaltySolomon: can you try to bootstrap again, with the --debug flag, and paste the output in paste.ubuntu.com and link here?
[14:36] <marcoceppi> SaltySolomon: also, what version of juju (juju version)
[14:37] <SaltySolomon> Okay, we got the version that is included with the liberty release on ubuntu server 15.01
[14:44] <mbruzek> marcoceppi: Regarding the new charm push and charm publish commands.
[14:44] <mbruzek> marcoceppi: Is there any special concerns when the charm was in the charm store from the old way and we want to push/publish using the new way?
[14:45] <mbruzek> kwmonroe: ^
[15:05] <lazyPower> mbruzek - just be aware that it disables the VCS ingestion route for that charm. Otherwise nope, it just continues on. You may need to tweak the ACLs on first upload... but thats true with any charm push
[15:06] <mbruzek> lazyPower: I thought there was some caveat with publish. That we could not go back to the old way or something else... Like what if a charm is already in the store and the author pushes to the private namespace. Is there some kind of link problem there?
[15:06] <rcj> aisrael, xenial AMIs should be working now
[15:06] <lazyPower> mbruzek - thats what i was referring to that it disables VCS ingestion
[15:07] <mbruzek> thanks rcj
[15:07] <aisrael> rcj: Is that a recent fix?
[15:07] <lazyPower> mbruzek - once you charm push, you wont be able to go back to pushing to launchpad. You will have to charm push future revisions
[15:07] <mbruzek> lazyPower: ack
[15:15] <aisrael> rcj: bootstrapping xenial working <3
[15:17] <lazyPower> \o/
[15:25] <Odd_Bloke> aisrael: \o/
[15:31] <marcoceppi> SaltySolomon: could you run `juju version` that could be a number of different releases
[15:32] <tinwood> gnuoy, ack. Are we moving to a pull request workflow for them?  e.g. fork, and PR?
[15:33] <SaltySolomon> 1.25.5-wily-amd64
[16:06] <gnuoy> tinwood, moving to openstack gerrit eventually
[16:13] <SaltySolomon> marcoceppi, http://paste.ubuntu.com/16065407/ with version 1.25.5-wily-amd64
[16:14] <marcoceppi> SaltySolomon: ah, this is the openstack installer, not too familiar with this, stokachu ^?
[16:15] <stokachu> SaltySolomon: your maas api key is incorrect
[16:15] <stokachu> SaltySolomon: you copy it from the maas ui under your user's account
[16:15] <SaltySolomon> We tripplechecked it and it is the right one
[16:15] <stokachu> SaltySolomon: did you create your own api key or let maas generate it
[16:15] <SaltySolomon> create our own
[16:15] <stokachu> ah that's why
[16:15] <SaltySolomon> once we had the w
[16:15] <stokachu> we check for ':' in the api key
[16:16] <SaltySolomon> Well, it generated a new one for us
[16:16] <SaltySolomon> It wasn't the default one
[16:16] <SaltySolomon> So we let maas generate it for us
[16:16] <stokachu> so the api key should be 'abcd:abcd:abde'
[16:17] <SaltySolomon> Also once we had a typo in it
[16:17] <SaltySolomon> Then it didn't find any machines, later we used the right key and it even deployed on machine with juju
[16:18] <stokachu> SaltySolomon: ok so does your api key have that format i described? 'aaaa:bbbbb:ccccc'
[16:18] <SaltySolomon> yes it does
[16:19] <stokachu> ok you want to `sudo openstack-install -u` and then remove ~/.cloud-install
[16:19] <stokachu> and start again entering that new api key
[16:24] <SaltySolomon> okay, it finds the maas nodes
[16:24] <tinwood> gnuoy, okay, but for now?
[16:35] <SaltySolomon> Maas webinterface says it is deployed, the node output too,  but the installer, is well stalling
[16:35] <SaltySolomon> stokachu ^
[16:36] <stokachu> SaltySolomon: can you pastebin ~/.cloud-install/commands.log
[16:37] <SaltySolomon> http://paste.ubuntu.com/16065965/
[16:37] <SaltySolomon> Here you go stokachu
[16:38] <stokachu> SaltySolomon: so it's probably still going through the cloud-init stuff with the system
[16:38] <stokachu> has to do apt upgrade etc
[16:38] <SaltySolomon> the client has no connection to the inet
[16:39] <stokachu> do you have a proxy?
[16:40] <SaltySolomon> okay, back it does have internet access, so it is probably the patching
[16:40] <stokachu> ok
[16:40] <stokachu> yea it could take a few minutes to do all that
[16:42] <SaltySolomon> Node is currently just saying "Installation finished"
[16:44] <SaltySolomon> Okay, wrong that was sme old stuff, we got the same error as before, will post you a pastebin in a sec
[16:45] <SaltySolomon> http://paste.ubuntu.com/16066144/ here you go stokachu
[16:46] <stokachu> SaltySolomon: looks like it's failing to upload the juju tools during bootstrap
[16:46] <stokachu> SaltySolomon: you sure those deployed nodes can reach the internet?
[16:57] <cory_fu> tvansteenburgh, kwmonroe: https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pull/4
[17:01] <tvansteenburgh> cory_fu: i'd like to know why it's passing tests before fixing it
[17:01] <cory_fu> tvansteenburgh: Yeah, that's very strange.  I really don't understand it
[17:04] <cory_fu> tvansteenburgh: But it's definitely passing: http://reports.vapour.ws/all-bundle-and-charm-results/charm-bundle-test-parent-6892/charm/aws/16
[17:10] <cory_fu> tvansteenburgh: I'd like to point out that the message the stack trace is waiting for doesn't match the message in the current version of the test
[17:10] <cory_fu> Not that it matters, since the current version of the test also doesn't match what the slave should be setting
[17:24] <aisrael> I published a charm (to my personal namespace), but forgot to change bzr-owner before I published, so now it's showing up in the ~charmers namespace. I've changed bzr-owner now, re-promulgated, but not sure if there's anything else I need to do to fix it.
[17:24] <aisrael> i.e., it's still showing up in the wrong place in the store
[17:27] <SaltySolomon> stokachu, we tried again with packet forwarding activated, this time the error is: http://paste.ubuntu.com/16067371/
[17:28] <stokachu> SaltySolomon: so youre still getting this error iled to connect to streams.canonical.com port 443: Connection timed out\ntools from https://streams.canonical.com/juju/tools/agent/1.25.5/juju-1.25.5-trusty-amd64.tgz d
[17:28] <stokachu> something is still blocking you from accessing streams.canonical.com
[17:37] <cory_fu> aisrael: bzr-owner only affects what Juju Cards show as the source, and is only a stop-gap until they fix Cards.  However, you have to set the bzr-owner for each revision that you push
[17:37] <aisrael> cory_fu: Ok. Any idea why it'd show up in ~charmers vs. my namespace?
[17:38] <cory_fu> Was it previously promulgated in ~charmers?  You may have to unpromulgate it from there
[17:38] <cory_fu> What's the charm ID?
[17:38] <aisrael> I don't think it was promulgated to ~charmers
[17:38] <aisrael> it should be cs:~aisrael/trusty/plex-0
[17:39] <aisrael> but my page in the cs points it to cs:trusty/plex-0
[17:45] <aisrael> ok, I think I unpromulgated it.
[17:45] <cory_fu> aisrael: Yeah, it's not promulgated now but https://jujucharms.com/plex/trusty/0 is still showing up and I don't know why
[17:46] <cory_fu> https://jujucharms.com/plex/ rightly 404s
[17:46] <cory_fu> https://jujucharms.com/u/aisrael/plex/trusty/0 looks right as well
[17:46] <aisrael> but this works: https://jujucharms.com/plex/trusty/0
[17:46] <cory_fu> I have no idea where the first is getting ~charmers.  Only thing I can possibly see is that, in the perms, write is set to charmers instead of you
[17:47] <cory_fu> Yeah.  It shouldn't
[17:47] <aisrael> and https://jujucharms.com/u/aisrael/ shows it's owned by charmers
[17:47] <aisrael> Hmm. write perms..
[17:47] <cory_fu> aisrael: Also note, user pages seem to be a bit out of whack with the new publishing process: https://github.com/CanonicalLtd/jujucharms.com/issues/249
[18:14] <SaltySolomon> @stokachu, thanks a ton, it was exactly that problem, the nodes couldn't reach the internet
[18:15] <stokachu> cool, glad to hear
[18:43] <cory_fu> kwmonroe, kjackal, admcleod1 (if you're around): Does this look ok to you?  https://github.com/juju-solutions/layer-apache-hadoop-namenode/commit/e6ad8fd44f119fdc411c6104498276aa4d2ac1a8
[18:44] <cory_fu> The "update on fencing" sort of worked, but only for the unit that was transitioning.
[18:44] <cory_fu> I could maybe make it work for both but it would be a bit hairy.  But I'm not sure I like the every-minute-cron solution, either
[18:45] <kjackal> lgtm
[18:46] <kjackal> do we have any other option at this time?
[18:46] <kjackal> Lets break it fast :)
[18:47] <cory_fu> I could make the fencing solution more complex (it would require doing a SSH to the other NN to launch juju-run from there to update the status)
[18:47] <cory_fu> Maybe we can do that in the future
[18:48] <kjackal> +1 for pushing this out now and improve it as we go
[18:52] <kwmonroe> yeah cory_fu, cron */1 kinda boo, but i think it's a good stab for now.  also i thought i was reading some hardcore productive code for a minute there.  then i realized that whole nn_status file is just for status.  good grief!  and nice job :)
[19:54] <lazyPower> bdx - MFW i think to myself "Man, why didn't we make a common thing to copy out certificates to path..."
[19:54] <lazyPower> bdx  then i recall doing a review... and find out you contributed this in tlslib :D
[19:54] <lazyPower> high five sir
[19:55] <lazyPower> s/common thing/function/
[20:17] <ReSam> anyone here gonna help with the openstack keystone charm? or should I head over to some openstack channel?
[20:17] <ReSam> keystone fails with "hook failed: config-changed" and in specific the function _ensure_initial_admin seems to fail... (it's tried 3 times until it gives up)
[20:21] <ReSam> and: INFO worker.uniter.jujuc server.go:173 running hook tool "status-set" ["blocked" "Ports which should be open, but are not: 5000, 35357"]
[20:22] <cholcombe> do we have a centos image we can deploy on ec2 with juju?
[20:23] <cholcombe> i want to test some compatibility
[21:51] <a123> I've been trying to run juju bootstrap --config default-series=xenial lxd-test lxd --debug from behind a work proxy which ultimately fails with the message: 2016-04-26 21:13:42 ERROR cmd supercommand.go:448 failed to bootstrap model: cannot start bootstrap instance: can't get info for image 'ubuntu-xenial': not found. This is running inside a fresh Ubuntu 16.06 VM. I have the same setup at home, and all works perfectly. Suggestions?
[21:51] <a123> that's 16.04
[21:51] <magicaltrout> aww a123
[21:51] <magicaltrout> you need to grab an image i suspect
[21:53] <magicaltrout> a123: i'm not sure about the syntax, i think its changed a bit but try something like
[21:53] <magicaltrout> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
[21:53] <magicaltrout> or
[21:53] <magicaltrout> lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
[21:55] <a123> Ah. ok. I'll give that a try. I didn't realize bootstrap would check locally. I'm curious though, why are there 2 different methods of grabbing images? Why doesn't bootstrap use lxd-images...?
[21:59] <magicaltrout> a123: dunno :)
[21:59] <magicaltrout> LXD local does work though i have a bootstrapped setup here
[22:00] <a123> is your bootstrap using the newly release 2.0?
[22:00] <magicaltrout> i just installed a fresh xenial image and did apt-get
[22:01] <magicaltrout> i've been running a self built LXD juju for a while and i did notice a few differences in the bootstrap
[22:01] <magicaltrout> although it could just be me getting old
[22:02] <a123> ok. sounds close enough to what I did. apt-get followed by setting up zfs as a backing store, then juju bootstrap.... As I mentioned, works great w/out being behind a proxy.
[22:02] <magicaltrout> well
[22:02] <a123> The image import syntax has changed a bit, so working on that now.
[22:03] <magicaltrout> also check
[22:03] <magicaltrout> lxc image list
[22:04] <magicaltrout> it will also try and hook up to  streams.canonical.com for the tools
[22:04] <magicaltrout> if that fails i'm pretty sure it will be sad as well
[22:04] <magicaltrout> i'm not sure what error you'd get there
[23:03] <cory_fu> admcleod1: https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pull/5 look ok to you?
[23:04] <cory_fu> admcleod1: Also, if you're ok w/ the HA as it stands now, I'd like to get it merged.  Maybe test it some more today and let me know if you hit anything, and if not I'll merge it tomorrow?
[23:05] <cory_fu> I'm thinking we should  squash the merges, though, because the commit histories are quite loquacious.
[23:06] <magicaltrout> check out the big word!
[23:07] <cory_fu> :)
[23:07] <cory_fu> Alright, well I'm EOD.  Have a good one!
[23:07] <magicaltrout> boooo
[23:08] <cory_fu> :)  Gotta go celebrate a friend's b-day
[23:08] <magicaltrout> i'm too old for those
[23:08] <magicaltrout> have fun!


[03:00] <thumper> o/ veebers
[03:00] <thumper> veebers: let me guess, you dist upgraded while having a local juju running?
[03:01] <veebers> hey thumper :-) Not sure why this channel isn't in my  autojoin
[03:01] <veebers> thumper: that is exactly what I did
[03:01] <thumper> ok
[03:01] <thumper> the current local provider made some upstart jobs for the database and mongo
[03:02] <thumper> I'm pretty sure that your upgrade brought in systemd
[03:02] <veebers> thumper: I'm currently on vivid
[03:02] <thumper> pretty sure vivid has systemd by default
[03:03] <thumper> is your local stuff important?
[03:03] <thumper> or can we blow it away?
[03:03] <veebers> hmm, no I guess we could just blow it away. I have a backup of the db and can deploy the same revno of the service too
[03:03] <thumper> ok...
[03:03] <thumper> do you have the plugin for nuking a local instance?
[03:04] <thumper> if not, we can do it by hand
[03:04] <veebers> thumper: I don't think I do, at least I don't remember setting anything up
[03:05] <thumper> ok
[03:05] <thumper> first lets clean up the local agents
[03:05] <thumper> look in /etc/init/juju-*
[03:05] <thumper> what do you see?
[03:06] <veebers> thumper: there is no juju-* dir in /etc/init/
[03:06] <thumper> oh?
[03:06] <thumper> curious
[03:06]  * thumper looks locally
 a 'status juju-agent-leecj2-local' shows an error: status: Name "com.ubuntu.Upstart" does not exist
[03:08] <thumper> somewhere there is a file called "juju-agent-leecj2-local.conf"
[03:08] <thumper> perhaps the dist-upgrade moved the config files from /etc/init to somewhere else
[03:09] <veebers> thumper: let me start a find for that file
[03:09] <thomi> veebers: on my system it's a *file* in /etc/init, not a dir.
[03:10] <veebers> thomi: ls /etc/init | grep juju shows nothing
[03:10] <thomi> veebers: ok, sorry - just thought it was worth metnioning :D
[03:11] <veebers> thumper: find didn't find anything
[03:11] <veebers> thomi: oh yeah thanks for the suggestion. Anything helps at this stage :-)
[03:11] <thumper> veebers: did you look all through /etc?
[03:12] <veebers> thumper: used: find / -name "juju-agent-leecj2-local.conf" -print
[03:12] <thumper> hmm...
[03:12] <thumper> just for my peace of mind, look for any jujud processes
[03:13] <veebers> thumper: I do see now "/etc/juju-leecj2-local/"
[03:13] <thumper> ah...
[03:14] <veebers> yep, I see a couple of jujud, i.. "/var/lib/juju/tools/machine-2/jujud machine  . . ."
[03:14] <thumper> those will be from the lxc containers
[03:15] <thumper> it looks like some magic thing converted the upstart script to a systemd start thing...
[03:15] <thumper> I don't know the systemd way to ask if some service is running
[03:15] <thumper> veebers: do 'sudo lxc-ls --fancy'
[03:16] <veebers> thumper: you want me to pastbin the output? I see leecj2-local-machine-{2,3,4} running (3 machines running)
[03:17] <thumper> veebers: and status works?
[03:17] <thumper> veebers: perhaps a hangout with screenshare would be quicker here :)
[03:17] <veebers> thumper: heh, sounds good
[04:32] <jose> marcoceppi: hey, any news on the aws credits?
[09:16] <jamespage> thedac, you have commit access now - gnuoy, arosales and I discussed you membership this week :-)
[09:17] <jamespage> gnuoy, any chance of a quick review for https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/lxd-updates/+merge/273104
[10:41] <jamespage> urulama, rick_h_: any eta on wily support in charmstore?
[10:41] <urulama> jamespage: next week, guys will do the release while we're in seattle
[10:49] <jamespage> urulama, ack - good-oh
[10:49] <jamespage> bundles and charms waiting to injest!
[10:50] <urulama> jamespage: yeah, seen bunch of vivid charms ... sorry, couldn't use staging this week as it was used for the Strata big data demo
[10:50] <urulama> jamespage: i'll try to push it for Monday, it's a small update
[10:50] <jamespage> urulama, awesome
[10:59] <adac> Trying to install openstack, but as soon as I set the openstack password, the installation process is aborting.  Any ideas on how to debug this?
[14:31] <thedac> jamespage: \o/ Thanks. Also, I am going to land your rabbitmq-server branch. And I will continue the race condition hunt.
[14:33] <jamespage> thedac, ta
[14:33] <jamespage> I just noticed a 'update-status' hook running in my 1.26 beta env
[14:33] <jamespage> interesting
[16:15] <faraujo> Hi! Has anybody seem this error before when running ´juju charm proof´ on a local charm? W: no copyright file
[16:15] <faraujo> W: no README file
[16:15] <faraujo> ERROR subprocess encountered error code 100


[07:01] <dholbach> good morning
[08:16] <iulian> Morning dholbach.
[08:16] <dholbach> hi iulian
[08:29] <dupondje> Could somebody try to create a chroot with pbuilder-dist? It fails here all the time :(
[08:37] <jtaylor> can someone set 791318 to triaged please
[08:40] <iulian> Done.
[08:44] <jtaylor> thx
[08:55] <nigelb> How do I do a += for Cmake's configuration file?
[08:58] <jtaylor> list(APPEND VAR VALUE)
[09:00] <nigelb> I did the CFLAGS change, but I just made it a LIB enry instad of adding it to an existing lib entry
[09:15] <nigelb> bah, doing an append didn't fix it :/
[09:17] <nigelb> This is the CmakeList.txt file http://dpaste.com/563212 and http://dpaste.com/563213 is my patch
[09:17] <nigelb> what am I doing wrong?
[09:25] <jtaylor> shouldn't it go in target_link_libraries?
[09:25] <nigelb> oh.
[09:25] <nigelb> that I didn't know
[09:27] <dupondje> W: Failure trying to run: chroot /var/cache/pbuilder/build/22485/. dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-0ubuntu13_amd64.deb
[09:27] <dupondje> E: debootstrap failed
[09:28] <dupondje> can't even seem to create a natty pbuilder-dist env :(
[09:28] <nigelb> (maybe a dumb question), is your OS is i386 or amd64
[09:28] <nigelb> -is
[09:29] <jtaylor> <amd64
[09:54] <nigelb> This build failure has other problems.
[09:54] <nigelb> I fixed one library call.
[09:54] <nigelb> Seems like more needs fixing
[10:01] <tumbleweed> dupondje: I can create a oneiric pbuilder just fine (on oneiric). What are you running?
[10:08] <nigelb> tumbleweed: heya, you work on ubuntu-dev-tools right?
[10:09] <tumbleweed> nigelb: yip
[10:10] <nigelb> tumbleweed: want to quickly talk about it (5 minutes) during Ubuntu Developer Week lighting talks?
[10:10] <nigelb> (Its mostly project lightning talks, so any interesting package/project gets good visibility)
[10:12] <tumbleweed> nigelb: sure, can do
[10:13] <sagaci> packaging-dev sounds good too
[10:13] <nigelb> tumbleweed: awesome, its at friday 15th at 2000 UTC
[10:14] <nigelb> well, some time between 2000 and 2100 UTC :D
[10:14] <tumbleweed> we are trying to get the interesting bits *out* of ubuntu-dev-tools where possible, but that's no reason not to talk about it :)
[10:14] <nigelb> tumbleweed: heh, was it you that told at the session about someone filing a bug against ubuntu dev tools for a tool that was already in it?
[10:14] <nigelb> *UDs session
[10:14] <nigelb> argh! *UDS
[10:15] <tumbleweed> yeah, this happens :)
[10:15] <nigelb> heh
[10:15] <tumbleweed> (don't know if that was me, though)
[10:15] <nigelb> It was either you or benjamin
[10:16] <nigelb> This is my CMakeList.txt file http://dpaste.com/563236/ (patched), some libs are still not linked, most notably dbus. How do I go about doing that?
[10:18] <nigelb> Do I add openssl and dbus-1 after the ldap entry in TARGET_LINK_LIBRARIES?
[10:22] <tumbleweed> nigelb: don't know what package you rae working on (and I haven't messed with this stuff in cmake), but libldap isn't linked to openssl or dbus
[10:23] <nigelb> tumbleweed: its pathfinder, and I should have been more clearer.
[10:23] <nigelb> One of the .o files depend on libldap, openssl and dbus
[10:23] <nigelb> I got the ldap bit works now after I added it in line 107, but I 'm trying to figure out how to add openssl and dbus
[10:24] <tumbleweed> I don't think order will matter here
[10:24] <nigelb> not order, just what to put there
[10:24] <nigelb> I tried openssl, it failed just now
[10:25] <nigelb> I tried putting ${OPENSSL_LIBDIR} which failed too
[10:25] <tumbleweed> try libcrypto rather than openssl. it's a separate .pc file
[10:26] <nigelb> ah
[10:27] <dupondje> tumbleweed: pbuilder-dist and pbuilder, both are broken here :s
[10:27] <dupondje> debootstrap is mounting /proc in the chroot, but doesn't seem to umount it.
[10:28] <tumbleweed> yeah, I saw you saying that. What Ubuntu release areyou on?
[10:28] <dupondje> Oneiric
[10:28]  * tumbleweed is wondering why I'm not seeing this
[10:29] <dupondje> tried making a oneiric chroot on natty, and that works fine also (other computer)
[10:29] <dupondje> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631087 btw
[10:29] <dupondje> some people in debian have same issue
[10:29] <dupondje> wonder why
[10:30] <tumbleweed> ah well, at least you have a workaround, and we can wait for someone else to get to the bottom of it :)
[10:31] <tumbleweed> nigelb: hrm, the libcrypto.pc is just a subset of openssl. Dunno if that'll help then
[10:32] <nigelb> tumbleweed: I think I'm doing something wrong with linking. I'm just not sure enough
[10:32] <dupondje> well yea :) but can't access the other pc all the time :)
[10:33] <tumbleweed> dupondje: you can copy the base.tgz across, you only need to build it once
[10:34] <dupondje> ah true
[10:35] <dupondje> could do that indeed
[10:35] <dupondje> best thing would be getting it fixed ofc :D
[10:35] <dupondje> but debootstrap got like no debug option :(
[10:37] <jtaylor> please set 803204  to triaged
[10:38] <tumbleweed> thanks
[10:39] <nigelb> tumbleweed: nope, didn't work :)
[10:39] <nigelb> I'm trying some stuff with INCLUDE_DIR
[10:39] <nigelb> It said it can't find that lib the last time
[10:40] <nigelb> the openssl and dbus ones
[10:42] <nigelb> aha
[10:42] <nigelb> How do I fix "/usr/bin/ld: cannot find -lopenssl"?
[10:43] <tumbleweed> that's wrong. It's not called libopenssl
[10:44] <nigelb> so, when I link from the commandline, I do -llibopenssl?
[10:44] <jtaylor> no  -lssl
[10:44] <nigelb> ah
[10:44] <tumbleweed> thanks jtaylor, *not* called libopenssl :)
[10:44] <nigelb> Its probably called libopenssl but not linked that way
[10:45] <nigelb> what's the easiest way to figure that out without installing and doing a dpkg -S?
[10:45] <jtaylor> apt-file
[10:46] <nigelb> thanks jtaylor!
[10:46] <Laney> you have to install it to test build anyway?
[10:46] <nigelb> that's inside the pbuilder
[10:46] <nigelb> I should install the pbuilder hhoks
[10:47] <dupondje> ah well
[10:47] <dupondje> https://bugs.launchpad.net/debian/+source/debootstrap/+bug/805886
[10:47] <dupondje> :)
[10:47] <Laney> I usually log in for non-final builds
[10:47] <Laney> to the chroot
[10:48] <tumbleweed> pbuilder + the C10shell hook is nice for debugging failures
[10:50] <tumbleweed> nigelb: no, it's called libssl (and there's also libcrypto, which is what this build failed on, on the buildd) If a package has a .pc file, you can find out a lot of useful information in it, look at /usr/lib/pkgconfig/openssl.pc
[10:50] <nigelb> tumbleweed: I should have known that. This CMake fle is usint the .pc files
[10:51] <tumbleweed> you sure? I swear I sawe some PKGCONFIG things in the file you pasted
[10:51] <nigelb> tumbleweed: erm *is* using
[11:09] <nigelb> ok, I give up. I thought I fixed this by adding ssl, but that didn't fix it either :/
[11:16] <jtaylor> please set to triaged: 803191
[11:17] <tumbleweed> jtaylor: done. (you can assume I'll notice bugs I filed)
[11:34] <nigelb> Ah, I got confused because this failure is not just an --as-needed failure because of library ordering
[11:35] <nigelb> there is some problem with indiin
[11:35] <nigelb> er, indirect linking
[11:36] <nigelb> oh, well, its the same
[11:43] <nigelb> Ah, quilt. is there a way to un-"add" a file?
[11:45] <tumbleweed> nigelb: that's not something you should need to do. adding a file just means quilt will notice changes when you quilt refresh
[11:45] <tumbleweed> if you haven't made any changes, there's nothing for it to notice
[11:46] <nigelb> tumbleweed: I made a mess, but now undone :P
[11:48] <tumbleweed> well, that's easy, refresh and pop the patch, then edit the patch to remove the changes you don't want and push it again
[11:48] <Laney> there's quilt revert
[11:48] <nigelb> After one scary day playing with the patches themselves, I tend to not edit it directly
[11:48] <nigelb> I forced a push
[11:49] <nigelb> s/push/pop
[11:49] <nigelb> then undid my change
[11:49] <tumbleweed> Laney: ah, even easier
[11:49] <nigelb> forced a push, forced a pop and refreshed
[11:49] <nigelb> Laney: I er accidentally made a change, then added, undid my change and refreshed
[11:50] <nigelb> causing a change opposite of what I wanted to happen
[11:50] <tumbleweed> recountdiff is handy if one does invasive patch etids
[11:51] <nigelb> bah, this still doesn't work :/
[11:51] <Laney> ipatch too for patch editing
[11:51] <nigelb> I did a include <ssl.h> and did -lss
[11:51] <nigelb> *-lssl
[11:51] <nigelb> it is indeed failing at ssl related functions
[11:52] <tumbleweed> Laney: err never heard of that. googling it turns up some OSX thing
[11:53] <tumbleweed> nigelb: if I'm reading it correctly, the failure in the build log from the test rebuild is a missing libcrypto not libssl
[11:54] <tumbleweed> ah, but the cmake file was linking to ssl too. nm
[11:54] <nigelb> isn't crypto provided by ssl?
[11:54] <tumbleweed> yes, but they are separate libraries, dpkg -L libssl1.0.0
[11:55] <Laney> http://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html
[11:55] <nigelb> what does Libs.private mean in the .pc file?
[11:56] <jtaylor> libraries only needed for static builds
[11:56] <jtaylor> no symbols of these libraries are exported
[11:56] <tumbleweed> Laney: oh right, I remember seeing that
[11:56] <nigelb> Now, I'm confused whether to swap -ssl with -crypto because its listed as Libs.private
[11:56] <Laney> useful to have around
[11:57] <tumbleweed> nigelb: Libs.private is not relevant to this problem
[11:57] <nigelb> tumbleweed: oh. swapping.
[12:04] <nigelb> tumbleweed: exact same failure :(
[12:04] <tumbleweed> nigelb: you probably want to turn up the verbosity so you can see what the gcc arguments are
[12:05] <nigelb> Is that a CMake setting?
[12:06] <nigelb> ah, yes
[12:11] <nigelb> My linking is working apparently http://dpaste.com/563276/
[12:12] <nigelb> wait a minute, there are some libs there, where did they come from :|
[12:13] <tumbleweed> nigelb: wrong order, -ssl should be before -crypto
[12:13] <nigelb> tumbleweed: ah
[12:13] <nigelb> tumbleweed: aaaaah, bit by the bug I'm trying to fix. The irony
[12:19] <nigelb> tumbleweed: similar failure again
[12:19] <nigelb> (On another note, I've jut built this package 15 times today now :D)
[12:19] <nigelb> *tried to build
[12:21] <jtaylor> tumbleweed: delay merging gps, I made a typo
[12:25] <jtaylor> stupit bzr ._.
[12:36] <jtaylor> so now its ready
[12:44] <tumbleweed> jtaylor: thanks
[12:54] <nigelb> tumbleweed: I figured out what the problem is and I haev a hacky fix.
[12:54] <nigelb> The CFLAGS are loading a few -l calls.
[12:54] <nigelb> My hacky fix would be to just copy paste them over
[12:54] <nigelb> I don't see an easier solution
[13:05] <tumbleweed> nigelb: can you not fix it to not use CFLAGS for libraries?
[13:06] <nigelb> tumbleweed: I'm not sure how.
[13:08] <tumbleweed> nigelb: debdiff so far?
[13:08] <nigelb> tumbleweed: sec
[13:10] <nigelb> tumbleweed: http://dpaste.com/563289/
[13:30] <jtaylor> gna another libtool package making problems -.-
[13:30] <jtaylor> how I hate that thing
[13:34] <jtaylor> is this wrong? libc_urg_la_LDADD = -lm
[14:00] <debfx> ScottK: could you please ack bug #805962
[14:01] <ScottK> debfx: Done.
[14:01] <debfx> thanks!
[14:06] <jtaylor> while your at it, how about bug 798191?
[14:06] <micahg> jtaylor: that has a lot of rdepends
[14:08] <micahg> jtaylor: http://paste.ubuntu.com/638440/
[14:10] <jtaylor> to my knowledge no package needed changing when it transitioned in debian
[14:10] <micahg> jtaylor: yes, but a requirements for backports is that all rdepends get tested
[14:11] <jtaylor> hm, ok then its hopeless
[14:11] <micahg> jtaylor: why?  there aren't that many on the list...
[14:12] <jtaylor> ~140 rdeps not many?
[14:12] <micahg> jtaylor: there are a lot of dupes in that list :)
[14:12] <jtaylor> I don't care so much for that package that I will test them all ..
[14:12] <micahg> maybe the other person who commented in the request would be willing to
[14:13] <Laney> I do wonder if that requirement is too stringent
[14:14] <Laney> that's no way what happens when updating to a new revision in a developent release, for eample
[14:14] <Laney> (testing all rdeps)
[14:16] <micahg> Laney: yes, but with the dev release, there's an assumption that bugs will be caught, in stable the rules are more stringent, we don't want to break systems
[14:17] <Laney> I know why it's there
[14:34]  * micahg will update the matplotlib backport request
[14:58] <tumbleweed> nigelb: http://code.google.com/p/pathfinder-pki/issues/detail?id=28
[15:07] <jtaylor> that patch will probably not work due to as-needed
[15:07] <tumbleweed> ah, that's true, I only looked on sid
[15:08] <tumbleweed> I gave up trying to understand the right way to solve the problem, their cmake use seems rather icky
[15:08] <jtaylor> hm I'll have a look
[15:10] <tumbleweed> I think I taught myself how to drive cmake, but I started getting semi-colons between gcc parameters (when pkg-config returned two include paths, due to multiarch)
[15:15] <jtaylor> strange it does not want to register the ssl DT_NEEDED entry
[15:16] <nigelb> I just grepped, I rebuild it 40 times today
[15:16] <jtaylor> ah no it needs nss :/
[15:16] <nigelb> but not everywhere
[15:17] <nigelb> I think moving LINK_FLAGS into TARGET_LINK_LIBRARIES might fix --as-needed-linking
[15:18] <nigelb> or something of that effect
[15:18] <jtaylor> so got it to compile
[15:18] <jtaylor> without cmake ^^
[15:18] <nigelb> jtaylor: are you picking this up?
[15:20] <jtaylor> I'll have a look at it if you like
[15:21] <nigelb> jtaylor: I'm trying to figure out how to get things out correctly.
[15:21] <jtaylor> I just quickly compiled it on the command line you need to explicitly link libpathfinder with nss and link nsstest with -lssl3
[15:28] <hrw> why pbuilder needs to be so awkard...
[15:29] <nigelb> pbuilder-dist is slightly more friendlier
[15:29] <Laney> sbuild is love
[15:29] <Laney> (with an apt cacher)
[15:29] <tumbleweed> (or even better, a mirror)
[15:30] <tumbleweed> sbuild doesn't make it quite as easy to dive in and fix problems, though
[15:30] <hrw> Laney: I cant work without apt-cacher-ng ;D
[15:30] <tumbleweed> and doesn't use distcc by default, which can be rather handy when debugging
[15:30] <hrw> --login --save-after-login != --save-after-login --login != --login --save-after-login true
[15:30] <hrw> argh
[15:31] <nigelb> heh
[15:32] <Laney> i just log in, get-build-deps and win
[15:32] <Laney> no need for this fancy hook stuff :P
[15:33]  * tumbleweed tends to fire up a build, then resume the failed session, but that requires copying and pasting, and then working without my preferences (sbuild user doesn't have my rc files)
[15:34] <Laney> ah, that stuff happens in a separate terminal
[15:34] <Laney> the schroot session is just for looping dpkg-buildpackage really
[15:36] <hrw> schroot... I always forget to learn how to use it from other develoeprs at sprints/udses
[15:39] <hrw> ~curse bug 802985 and broken chroots due to this
[15:42] <Laney> heh
[15:42] <Laney> debootsrap should have learned to use multiple suites long ago
[15:43] <hrw> I looked at code of it today - many changes would it take
[15:44] <jtaylor> nigelb: need more help with pathfinder?
[15:45] <nigelb> jtaylor: If you have time, yes!
[15:45] <dupondje> Could somebody take a look at https://bugs.launchpad.net/debian/+source/debootstrap/+bug/805886 ?
[15:46] <nigelb> jtaylor: I think my headache has something to do with cmake's formatting of TARGET_LINK_LIBRARIES
[15:46] <jtaylor> nigelb: this patch builds, but its ugly and it uses ssl and ssl3 which may give conflicts http://paste.ubuntu.com/638463/
[15:47] <nigelb> jtaylor: that's the path I was going through, but it didn't build
[15:47] <jtaylor> did you patch libpathfinder/CMakeLists.txt?
[15:48] <nigelb> jtaylor: yeah, but when I took a similar step, it didn't work for me
[15:48] <nigelb> the $ variables didn't expand for me
[15:48] <jtaylor> strange
[15:49] <nigelb> yup
[16:04] <hrw> I have a package which builds in lucid pbuilder (amd64), lucid chroot but fails on launchpad
[16:05] <tumbleweed> the most common reason for that is internet access
[16:06] <tumbleweed> that and differinc build-dependancy resolution algorithms
[16:07] <Laney> occasionally pkgbinarymangler/pkgstriptranslations too if you don't run those
[16:12] <hrw> anyway time to compile fake-uname.so and get lucid to think that 2.6.32 is kernel
[16:18] <dilruk> Anybody know how i can configure ALPS touchpad correctly?
[16:21] <hrw> dilruk: you run maverick at least?
[16:21] <hrw> ah. no.. it was eten with problem
[16:21] <dilruk> hrw: im on natty...I can get the edge scrolling to work
[16:22] <dilruk> I cant i mean
[16:22] <Pici> dilruk: This isn't a support channel. Please use #ubuntu
[16:23] <dilruk> I tried....but no one seem to care :(
[16:23] <Pici> dilruk: You asked once. Be patient, and repeat your question if no one responds after a few minutes.
[16:24] <dilruk> ok will do that. thank you
[16:25] <hrw> dilruk: it worked in past? is it old laptop or new? tried two-fingers-scrolling?
[16:26] <dilruk> hrw: it never worked...its a VAIO VPCEB intel i3. No special options are working
[16:30] <hrw> dilruk: ouch...
[16:33] <hrw> how to recreate EXACT rootfs used by launchpad while building ppa packages?
[16:39] <Ampelbein> hrw: what for?
[16:40] <tsimpson> just use pbuilder, it's not _exactly_ what LP uses, but it's basically the same
[16:42] <dupondje> bleh, cdebootstrap doesn't even know Oneiric :(
[16:42]  * dupondje sad
[16:42] <hrw> but package builds in pbuilder but not on launchpad
[16:43] <geser> hrw: where does it fail?
[16:43] <hrw> https://launchpadlibrarian.net/74590308/buildlog_ubuntu-lucid-i386.gcc-4.4_4.4.6-3ubuntu1~ppa2_FAILEDTOBUILD.txt.gz
[16:43] <geser> hrw: LP uses a hacked version of sbuild, and you can download the chroot LP uses for building
[16:43] <hrw> geser: url?
[16:44] <geser> hrw: let me search it
[16:45] <hrw> thanks
[16:45] <dupondje> sbuild is better then pbuilder ?
[16:46] <Ampelbein> dupondje: it's different
[16:47] <dupondje> cause pbuilder broke here :(
[16:50] <geser> hrw: you might need to ask wgrant for the magic url which shows you the librarian url for the build chroot
[16:51] <hrw> ok
[16:52] <hrw> +6h - will catch him tomorrow if will not solve
[16:52] <hrw> and time to end work now
[16:52] <hrw> have a nice rest of day
[17:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/courier/+bug/803176 => I attached a fix
[18:32] <tumbleweed> hrw: I know I've found them before by googling
[18:35] <tumbleweed> right: https://launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url
[19:10] <dupondje> ifneq ($(wildcard /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/libcrypt.*),)
[19:10] <dupondje> this should work right ?
[19:18] <tumbleweed> dupondje: I think you'd need to use $(shell ) rather than ``
[19:18]  * micahg is curious as to the use case for the above statement
[19:18] <tumbleweed> yeah, that too :)
[19:19] <dupondje> ifneq ($(wildcard /usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/libcrypt.*),)
[19:19] <dupondje> that should do ?
[19:20] <jtaylor> whats the point of that?
[19:20] <jtaylor> its always false
[19:20] <jtaylor> or true
[19:21] <dupondje> https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/749176
[19:22] <jtaylor> that bug is pending in debian
[19:22] <jtaylor> maybe ask the maintainer for a patch
[19:23] <dupondje> It just has the following now:
[19:23] <dupondje> ifneq ($(wildcard /usr/lib/libcrypt.*),)
[19:23] <dupondje> LIBCRYPT=-lcrypt
[19:23] <dupondje> endif
[19:23] <dupondje> So by adding the one above, it fixes the ftbfs
[19:23] <dupondje> and uses the same way it was done already in the code
[19:23] <dupondje> :)
[19:23]  * micahg wonders why the ifneg is necessary in the first place
[19:23] <jtaylor> just drop the if end endif
[19:24] <dupondje> yea would be the good way indeed ...
[19:25] <dupondje> but just wanted to do it the same way it was done already in the Makefile ...
[19:27]  * micahg would think upstream should switch to a configure flag based detection instead of that
[19:27] <dupondje> well its not a clean way
[19:27] <dupondje> but that shouldnt be changed in a FTBFS patch I think
[19:29] <micahg> well, either way, it's not suitable for upstream, so IMHO I think removing the check is cleaner in this case
[19:30] <micahg> as long as the library in question is in the build-deps
[19:30] <dupondje> libc6-dev is build-dep
[19:30] <dupondje> so yea :)
[19:30] <dupondje> both work.
[19:32] <dupondje> so go for the check removal ? :)
[19:32] <jtaylor> yes
[19:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/749176
[19:35] <dupondje> fix uploaded


[14:18] <newz2000> I'm trying to burn 12.04.2 32b desktop to cd. I remembered hearing rumours that future versions would not fit on a CD so checked the website, no mention, so I tried it.
[14:19] <newz2000> Way way down on this page: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_Requirements
[14:19] <newz2000> there is a note that it can't be burned to a CD
[14:20] <newz2000> This is not a very obvious place to find this info
[14:21] <newz2000> Now that i look, the docs on the website say "burn a dvd"
[14:22] <newz2000> On a side note, did you know that when I burn a dvd at 8x it is far far faster than if I burn a cd at 8x? Apparently 8x != 8x.
[14:59] <nigelb> newz2000: Hrm, when you downloaded it, wasn't the size greater than 700 MB?
[14:59] <nigelb> That should have indicated that you couldn't burn it to a CD.


[08:28] <zch> hi
[08:30] <robertj> is there a list of stuff that needs to be added to EDSAdmin?
[08:45] <robertj> <crickets />
[08:49] <Burgwork> robertj: I have not looked at it, so I cannot comment
[08:50] <Burgwork> rather than figure that out, why not compile a needs list and match it up
[08:57] <robertj> Burgwork: is there such a list?
[08:58] <robertj> Burgwork: I looked at EDSAdmin ~9 months back
[08:58] <robertj> and have since learned something of python
[09:00] <zch> robertj: I miss a "browse view" like lat has it
[09:00] <zch> robertj: do you know lat?
[09:00] <robertj> zch: no, sorry
[09:00] <robertj> zch: I've heard of it
[09:00] <robertj> zch: browse view == tree view?
[09:01] <zch> robertj: perhaps you should look at it, it's not bad, with a nice UI
[09:01] <zch> robertj: yes tree view, with all attributes
[09:03] <zch> I don't know what the scope of edsadmin is
[09:04] <zch> perhaps it shouldn't become yet an other LDAP Browser
[09:04] <robertj> zch: probably not, but I doubt it could be a significant amount of owrk
[09:05] <robertj> well relative to the rest of the task at hand
[09:09] <robertj> EDS had its last commit 23 months ago
[09:11] <zch> robertj: make edsadmin look like lat :)
[09:11] <zch> but much more stable
[09:13] <robertj> edsadmin still depends on howl
[09:13] <Burgwork> yes, lat has stability issues
[09:13] <robertj> it seems like it would be a good ideal to ask nicely if we should fork EDSAdmin
[09:14] <Burgwork> is upstream dead?
[09:14] <robertj> like I said, 23 months
[09:14] <Burgwork> in that case, email the creator asking for you to take it over
[09:14] <robertj> oh no, i'm not falling for that one :)
[09:14] <Burgwork> somebodies got to
[09:15] <robertj> so who's getting paid :)
[09:15] <robertj> but seriously, I don't have the time
[09:20] <robertj> brb
[09:37] <zch> robertj: have a look at this:  https://lists.ubuntu.com/archives/ubuntu-devel/2004-December/002391.html
[09:38] <zch> mark roach (author of edsadmin) wrote:
[09:39] <zch> Hi, Manuel. I want to mention a program I have been working on: EDS
[09:39] <zch> Admin (http://edsadmin.sourceforge.net). It is a gtk + python app for
[09:39] <zch> managing LDAP user directories. Unlike other LDAP programs, it doesn't
[09:39] <zch> try to be a swiss army knife; it tries to manage users and groups well.
[09:39] <zch> The current version auto-detects LDAP servers using either DNS SRV
[09:39] <zch> records or rendezvous. As soon as I can get some strange bugs squashed
[09:39] <zch> in the openldap/kerberos/sasl combo, it will also support auto-login to
[09:39] <zch> the directory server for the domain(realm). It also supports samba
[09:39] <zch> accounts and groups, and I plan to support Lorikeet (Samba + Heimdal +
[09:39] <zch> LDAP SSO solution) as soon as possible.
[09:39] <robertj> thats' check into sf as EDSRealmsAssistant
[09:39] <robertj> .the linked url there seems kaput though
[09:41] <zch> is EDSRealmsAssistant, edsadmin + more? or an own tool?
[09:41] <robertj> I think its a seperate tool, never looked into that htough
[09:43] <zch> hmm, is mark at the moment active in the ubuntu community?
[09:56] <robertj> dunno
[10:00] <robertj> I wonder where it is getting its images module from
[10:00] <robertj> it's not in cvs
[10:00] <robertj> and there is nothing like it in google's code search


[13:58] <The_LoudSpeaker> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036
[13:58] <The_LoudSpeaker> Found this in a focal container so..
[16:42] <OerHeks> hi The_LoudSpeaker
[16:43] <OerHeks> yes, teward found a bug that hits multiple distros
[16:54] <The_LoudSpeaker> Hii OerHeks, I found the bug, teward filed it after he was able to reproduce it.
[16:55] <teward> The_LoudSpeaker found the report on RH’s tracker.  Once I reproduced in a Focal container I simply made the Ubuntu bug for it
[16:56] <teward> So it sounds like the bug is a larger bug than just Ubuntu and RH
[17:00] <OerHeks> indeed, good find!
[17:15] <ChmEarl> the bug is in docker or lxc?
[17:35] <ChmEarl> teward please link your report
[17:36] <teward> ChmEarl: neither the bug is in sudo
[17:36] <teward> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036
[17:36] <teward> Whether its actually contajner specific i haveny tested
[17:36] <teward> Testing in a VM later today
[17:36] <teward> If its not container specific the bug gets amended to be wider
[17:37] <teward> If it is container specifc then it stays as is
[17:37] <teward> Right now, lunch is a rewuisite.


[00:12] <Hanii> When I'm installing kubuntu, can I specify which drive to install grub on so I can install it on the same drive I'm installing linux on? It's trying to install it on my windows partition and failing, I think because it's already there.
 You can choose your partitions custom, you just need to specify your mount points. I for example have a triple boot between w8.1 w10 and kubuntu on my laptop @ hanii
[00:59] <Hanii> Do I get the option to choose a mount point if I do "manual" on the screen that prompts me to choose/format a drive then?
[01:26] <Hanii> Incidentally, at the same time, is there an easy way to remove the grub install on my windows drive that installing before added?
[02:20] <guiverc> Hanii, grub is installed in the /boot/grub/ directory; the MBR is also installed to the selected drive, but the MBR cannot be uninstalled, it's replaced when you want something different (replaced by whatever you want to own the MBR, it's just a sector on the drive)
[02:45] <Hanii> The kubuntu installer installed it on my windows disk instead of the disk I tried to install kubuntu on. Then when I tried to install later, installing grub failed.
[02:47] <Hanii> I currently have no drives with kubuntu installed, but still have a grub install on the windows drive
 Are you trying to restore the windows boot loader to the windows drive?
[11:01] <BluesKaj> 'Morning all
[13:40] <akasic> good day ppl, while trying to ''make'', I get the following error /lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line thnx for the help
 The Ubuntu packages search page is useful: https://packages.ubuntu.com/
 How to install snap-store   … I thried in discover but it stuck in 14%
 Sound like a Discover bug, so sou may need to use the command line.  If the command line works ensure to search for a corresponding Discover bug at bugs.kde.org.  If you cannot find a bug report, please create one.
 I now understand why my system freezes up and that's FF fault
 Firefox
 problem is that the issue is common
 please share
 but I don't know why it's happening. Internet did not give me good resources
 I am getting random system freeze while browsing
 with FF
 I was hoping you found a fix.
 I am asking on the firefox riot chat to see if they can help
 on the internet they say to disable hw acceleration but it's already disabled..
 I would like to find a fix too :P
 I was just not sure why the system was freezing up
 but at least now I am sure that is firefox
 I used FF for a few months and also saw random HW freezes, but it seemed to diminish over time.  But now I am using the "controversial" Brave browser.
 oh. Do you like it?
 I am also looking forward to change browser..
 Yes, it automatically block all the crapware adds without installing any extensions.
 mmm I didn't like the controversy
 because the developer was a little shady.. right?
[14:54] <oerheks> firefox blocks 3rd party cookies, seem many complain, disable ublock might help.
[18:34] <user|28352> How do I use the downloaded iso image to install Kubuntu 20.04 ?
 https://kubuntu.org/getkubuntu/
 (Photo, 957x1280) https://irc-attachments.kde.org/Sm5PH0tQ/file_34311.jpg
 got stuck at black screen with cursor after installation
 try ctrl-alt-t to open a terminal.
 previously i added another user to encrypt my drive then removed new user. can it try to log in deleted user?
 @DarinMiller, didnt worm
 @DarinMiller, do you have another suggestion?
 At the moment, i am not sure what to try.
 @orkhanazarli, try ctrl+alt+F2 to swith the tty, there you might get a console login
 @My1xT, tried ctrl alt f1 and f2
 plugged another keyboard but still no response
 @orkhanazarli, Otherwise you could try recovery mode. … Are you booting via classic bios or uefi?


[07:15] <lukey> How can i download Code from launchpad?
[07:15] <lukey> without bzr
[10:43] <HeOS> Hello! I want to add new comment to the following bug (https://bugs.launchpad.net/fuel/+bug/1584694), but I can't do it, because I see a popup window with the following error: "Timeout error, please try again in a few minutes.".
[10:43] <HeOS> What should I do add my comment?
[10:46] <cjwatson> HeOS: We have some occasional load spikes like that that we haven't fully tracked down yet, but they normally go away fairly quickly.  Wait a bit and try again.
[10:46] <HeOS> cjwatson, great thanks. :)
[10:47] <cjwatson> Yeah, that's the usual thing where an UPDATE of Bug.date_last_updated takes >5 seconds for no good reason
[17:06] <frecel> hello
[17:07] <nacc> frecel: what's your API question? :)
[17:08] <dobey> konnichiwa
[17:09] <frecel> is there a way to get all bugs that are tagged to a specific project through the api?
[17:09] <frecel> I would like to for example get all bugs that are tagged with "xenial"
[17:10] <frecel> nacc: I've been playing with python3-launchpadlib for a couple of hours yesterday and I couldn't figure it out
[17:11] <nacc> frecel: i just wrote / am writing an application to use the same, so let me see if ic an help :)
[17:12] <dobey> sure
[17:13] <nacc> frecel: maybe given a series, you could iterate over its searchTasks results?
[17:13] <dobey> searchTasks(tags=) on a project, project_group, or distribution
[17:15] <frecel> dobey: what's the difference between a bug and a bug task?
[17:15] <sergiusens> wgrant cjwatson hi, question, I can't seem to be able to create a 2.10 milestone, it errors out telling me that 2.1 already exists (notice missing 0 at the end)
[17:15] <dobey> frecel: a bug is a collection of tasks
[17:16] <dobey> a bug can have tasks for multiple projects/distributions for example
[17:17] <sergiusens> hmm, but 2.10 does show up now
[17:17] <frecel> alright I'm going to try that
[17:17] <frecel> thanks guys
[17:18] <frecel> or gals
[17:37] <cjwatson> sergiusens: https://bugs.launchpad.net/lazr.restful/+bug/581748
[17:38] <cjwatson> I tried to fix that a while back and everything was terrible
[17:43] <sergiusens> cjwatson thanks. It was created anyways so not really blocked :-)


[12:25] <Kamion> infinity: l-r-m was breaking d-i, so I've uploaded what I think should be a fix for that
[12:25] <Kamion> hard to test without building new images though
[12:25] <Keybuk> heh
[12:28] <Kamion> Keybuk: line 7 of 10-devfs.rules looks suspicious; missing %?
[12:29] <Keybuk> yup
[12:30] <Kamion> Keybuk: could you replace awk '{print $2}' with sed 's/^[^ ] * //; s/ .*//' in /lib/udev/scsi-devfs please? we don't have awk in d-i
[12:31] <Keybuk> can you mail that one to me?
[10:44] <fabbione> cat /proc/cmdline
[10:44] <fabbione> root=/dev/disk/by-uuid/4d216a51-2317-47a4-872f-125a6d035d08 ro quiet splash
[10:44] <fabbione> it seems to work
[10:45] <fabbione> but there is another side effect we didn't think when writing the specs
[10:45] <fabbione> root is not enough
[10:45] <fabbione> we need to possibly detect other partitions and swap
[10:45] <fabbione> otherwise even if we get root, we might miss the rest of the system
[10:45] <fabbione> that defeats the purpose of the spec
[10:46] <fabbione> bah Keybuck isn't here
[10:49] <infinity> But other partitions should be in /etc/fstab...
[10:49] <infinity> (by uuid, perhaps, but they should be there anyway)
[10:54] <fabbione> the problem is that swap doesn't have a uuid
[10:54] <Kamion> fstab supports the UUID= and LABEL= syntaxes
[10:54] <Kamion> you can use LABEL= for swap
[10:54] <fabbione> and the thing is that yes, the other partitions needs to have uuid too
[10:54] <fabbione> fail to do so, we are in trouble
[10:54] <infinity> But multiple swap partitions can have the same label.
[10:54] <Kamion> mm
[10:54] <fabbione> like a / on ext3 = ok, /home on xfs = nok
[10:55] <infinity> I thought uuid-on-swap was something we were fixing?
[10:55] <fabbione> uuid is a property of the fs
[10:55] <infinity> Yes, and?
[10:55] <fabbione> swap isn't exactly a fs
[10:55] <infinity> mkswap could do uuid magic.
[10:55] <infinity> swap isn't an FS, but it still has magic.
[10:55] <infinity> Not much, but some.
[10:56] <infinity> And losing another few bytes for a UUID isn't the end of the world.
[10:57] <fabbione> no, but you would introduce tons of other problems
[10:57] <fabbione> think of the resume from hibernate that clear the swap or so
[10:57] <fabbione> your approach would assume that swap isn't used by anyone else
[10:57] <fabbione> what if the user dual boot breezy/dapper
[10:58] <fabbione> both clean the swaps in 2 different ways
[10:58] <fabbione> bang
[10:58] <infinity> Yeah, ew.
[10:58] <infinity> Hrmph.
[10:58] <infinity> Of course, if this sort of breakage isn't done some day, it can never be done.  Catch-22.
[10:58] <fabbione> yes i agree
[10:58] <infinity> I'd love SOME way to uniquely identify swa ppartitions.
[10:58] <fabbione> there is :)
[10:59] <fabbione> partition IDs
[10:59] <infinity> Har.
[10:59] <fabbione> but still
[10:59] <fabbione> you don't know if that swap is the one you are allowed to use
[10:59] <fabbione> so it still the suck
[10:59] <fabbione> a possible solution would be to generate a uuid
[11:00] <fabbione> and assign it to the swap as LABEL
[11:00] <fabbione> that might do
[11:00] <infinity> Oh wel, for all the noise people make about the dangers of shared swap, using the wrong swap, etc, etc, it seems to be a reasonably uncommonly-tripped bug.
[11:00] <infinity> People THINK about it far more than they actually get bitten by it.
[11:00] <fabbione> i would rather avoid to be the one crossburned for that
[11:00] <infinity> And yes, we could generate a uuid-like label.  Would be ugly in fdisk output, but that's not the end of the world.
[11:01] <fabbione> i think actually.. that going for LABEL=uuid is a much better approach
[11:01] <fabbione> because it might allow us to do it for all kind of FS
[11:01] <fabbione> since LABEL is at partition level
[11:01] <fabbione> and not FS
[11:02] <infinity> Do we ge LABELs on all partition tables, or just MSDOS?
[11:02] <infinity> I get them on PowerPC.  Yay.
[11:02] <fabbione> no idea
[11:02] <infinity> Well, MacPPC anyway.
[11:02] <fabbione> but i guess we do
[11:03] <fabbione> what fs?
[11:03] <infinity>  /dev/hda7         Apple_UNIX_SVR2 Debian             55398400 @ 2098368  ( 26.4G)  Linux native
[11:03] <infinity>  /dev/hda8         Apple_UNIX_SVR2 swap                1136576 @ 57496768 (555.0M)  Linux swap
[11:03] <infinity> Uhh, ext3, not that that matters.
[11:04] <fabbione> no, it shouldn't
[11:04] <fabbione> that's why i was cross checking ;)
[11:04] <infinity> Not sure if all partition tables have label-like metadata that gets translated, but at least the three release arches would be okay.
[11:05] <infinity> I don't recall if BSD disklabels and slices do it.
[11:05] <fabbione> no idea
[11:06] <infinity> (That was one motivation for UUID, though, is that since it's not at the partition table level, we're not subject to weird architectures and their weird partitioning schemes)
[11:06] <fabbione> that's why we can use uuid over label protocols
[11:07] <fabbione> all of this assuming we can stick such a long label
[11:07] <infinity> Look for uuid, fall back to label, if we have neither, cry?
[11:07] <infinity> No, we can't have labels that long they'd need to be a bit less unique.
[11:07] <infinity> DOS labels are... 12 chars?... 16?... I don't recall..  But short.
[11:08] <fabbione> crap
[11:08] <fabbione> i suggest we postpone the spec for dapper+1
[11:08] <fabbione> this is getting already too hairy
[11:16] <fabbione> hey Keybuk
[11:17] <fabbione> Keybuk: in about 10 minutes you want to check the irc log for this chan (last 30 minutes discussion)
[11:17] <fabbione> about probe for root fs
[11:19] <Keybuk> ok
[11:24] <Kamion> infinity: DOS labels are 11 characters, according to 'head debian-installer/installer/build/config/x86.cfg'
[11:40] <Keybuk> *giggle*
[11:40] <Keybuk> for those following the "Dude?  Where's My DMA?" bug
[11:41] <Keybuk> it cleared itself up for mdz all by itsself
[11:41] <Keybuk> with BenC saying the only change to piix was a tweak to the modular IDE driver patch that couldn't POSSIBLY have caused it
[11:41] <Keybuk> upstream IDE subsystem maintainer has identified the patch causes problems for us
[11:41] <Keybuk> it's the (you guessed it) modular IDE driver patch!
[11:58] <Kamion> Keybuk: let me know whenabouts you're uploading udev with the changes I mentioned on IRC last night; I'll need to rebuild d-i with those to get the live CD working
[11:59] <Keybuk> yup
[11:59] <Keybuk> will be this morning
[11:59] <Keybuk> just ploughing through the things everyone sent me overnight for my attention this morning <g>
[11:59] <Kamion> ta
[12:03] <fabbione> i wonder if we have dpkg-query in d-i somewhere...
[12:08] <Kamion> no
[12:08] <Kamion> no plans to add it either
[12:09] <Kamion> you can look through /var/lib/dpkg/status in d-i, but obviously that will only list udebs
[12:09] <Kamion> if you want to inspect /target, chroot to it
[12:09] <Keybuk> infinity: what's the general stance on useful-things-for-debugging in initramfs
[12:09] <Keybuk> like lsmod, udevmonitor, etc.
[12:09] <fabbione> Kamion: yeah the issue is that we can't trust what's in /target ;)
[12:10] <fabbione> Kamion: that's why i am looking at several different options
[12:10] <Kamion> fabbione: then you can't trust /target/var/lib/dpkg/status either ...
[12:10] <fabbione> Kamion: i know. that's why there will be 2 checks available. one that uses status and one that will gather pkgs info from the files installed on the system
[12:11] <fabbione> but the latter is way slower than the former and prone to more false positives
[12:11] <fabbione> as it stands now i am implementing all small shell functions do to almost atomic operations that requires less tools as possible
[12:12] <fabbione> discarding one in favour of another it's easy
[12:13] <Keybuk> fabbione: you asked me to check the irc log, I assume about the /dev/disk stuff?
[12:16] <fabbione> Keybuk: yes
[12:17] <Keybuk> I'm not sure I understand the problem ... the root filesystem knows where the other partitions are
[12:17] <infinity> Keybuk : I wouldn't be against a DEBUG=yes flag in initramfs.conf that optionally copied in some debug stuff, and could be seen by other hooks (like udevs) to copy debug stuff for them...
[12:18] <fabbione> Keybuk: no it doesn't... it does if the disk doesn't change name..
[12:18] <infinity> Keybuk : Not sure we want debug bloat in all initramfs images, hence the flag springs to mind as sane.
[12:18] <Keybuk> fabbione: the disk is named
[12:18] <Keybuk> it has a serial number
[12:18] <fabbione> Keybuk: but we are using uuid exactly because we want to be able to move it around
[12:18] <Keybuk> you could use /dev/disk/by-id/usb-<MODEL NO>_<SERIAL NO>-part2
[12:18] <Keybuk> (inside the root filesystem)
[12:19] <Keybuk> then use root=/dev/disk/by-uuid or whatever to find the root filesystem itself
[12:19] <fabbione> that won't work either..
[12:19] <Keybuk> why not?
[12:19] <fabbione> 0 lrwxrwxrwx 1 root root   9 2005-12-02 09:41 scsi-0ATA_WDC_WD1200JB-00CLinux_ATA-SCSI_simulator -> ../../sda
[12:19] <fabbione>  <-
[12:19] <fabbione> this is an IDE disk in a USB external box
[12:20] <Keybuk> right?
[12:20] <fabbione> i could remove it from there
[12:20] <fabbione> stick it in my desktop
[12:20] <fabbione> that would change to ATA
[12:20] <fabbione> sorry
[12:20] <fabbione> ata-*
[12:20] <Keybuk> use partition labels then
[12:20] <Keybuk> and /dev/disk/by-label
[12:21] <fabbione> Keybuk: label can only be 11 chars
[12:21] <fabbione> there is a high possibility of clashing
[12:21] <fabbione> the reason why we did chose uuid was exactly because of its meaning
[12:21] <Keybuk> pretty low probabibility
[12:21] <Kamion> what's wrong with using /dev/disk/by-uuid/ for the other filesystems too (apart from swap)?
[12:21] <fabbione> Kamion: not all FS support uuid
[12:21] <Kamion> Keybuk: quite high if you have two parallel installations done with the same installer
[12:21] <Keybuk> most the FS we care about support uuid
[12:21] <Keybuk> for those that don't generate a random label
[12:21] <fabbione> root on ext3 and home on fancy fs
[12:21] <fabbione> you are doomed
[12:22] <Keybuk> that gives you a 1 in<PHONE_NUMBER>68963094528 chance of clash
[12:22] <Keybuk> we don't support home on "fancy fs"
[12:22] <fabbione> Keybuk: yes we do. we still provide the option for manual partitioning
[12:22] <fabbione> and iirc not all the selectable FS have uuid
[12:22] <Keybuk> so?  just tell them "uh, no, go back and fix this"
[12:23] <Keybuk> or for those FS that don't support uuid, generate a randomly unique LABEL and force it upon them
[12:24] <fabbione> so you would end up with a fstab that will look like: /dev/disk/by-uuid/$longnumber / etc...
[12:24] <fabbione> and other lines with LABEL=
[12:24] <fabbione> that will be quite inconsistent
[12:24] <Keybuk> just use /dev/disk/by-uuid/$uuid and /dev/disk/by-label/$label
[12:24] <Keybuk> that's not inconsistent
[12:24] <fabbione> Keybuk: what happens if 2 lables are clashing?
[12:25] <fabbione> labels even
[12:25] <fabbione> at udev level.. does it go foobar? or it continues like if nothing happen
[12:26] <Keybuk> just makes a link for one of them
[12:26] <Keybuk> and the changes of two labels clashing is incredibly remote
[12:26] <Keybuk> when we have 250 billion billion installations, we can worry
[12:27] <fabbione> with 11 chars is a bit less than that
[12:27] <Keybuk> and that's just assuming we only stick to alphanumerics
[12:27] <Keybuk> no, that's 11 alpanumeric chars
[12:27] <fabbione> right
[12:27] <Keybuk> DOS is 11 8-bit chars, so it's a number so high my computer can't calculate it
[12:28] <Kamion> in reality people do kinda want labels to be human-readable ;)
[12:28] <Kamion> or at least PRINTABLE
[12:28] <Keybuk> indeed
[12:28] <fabbione> i sort of agree with Kamion
[12:28] <Keybuk> that's why I stuck to alphanumerics
[12:29] <Keybuk> hell, if you just limit yourself to upper case and numbers, you're still over a billion billion possible labels
[12:30] <fabbione> i was wondering if the first 11 digit of md5sum something would do
[12:30] <fabbione> like md5sum the output of the / uuid with the date in nanosecond
[12:30] <fabbione> that would probably be almost unique
[12:31] <Keybuk> why not just pack the / uuid with the partition number or date?
[12:31] <Keybuk> the / uuid is 37 hex characters
[12:32] <Keybuk> actually, 33 and 4 -s
[12:32] <fabbione> yeah
[12:32] <Keybuk> you could certainly use much of that
[12:32] <Keybuk> and there are shorter uuid standards too
[12:32] <infinity> Can we convert base16 to base36? :)
[12:32] <fabbione> the md5 was to scramble numbers completely
[12:33] <Keybuk> anyway, this isn't a SKY FALLING problem
[12:33] <fabbione> no
[12:33] <Keybuk> there's plenty of ways to identify the partition we want to put the swap on
[12:34] <fabbione> Keybuk: other than LABEL no...
[12:34] <Keybuk> there are :p
[12:34] <Keybuk> we could even go as far as tricks
[12:35] <Keybuk> we could improve /dev/disk/by-path to create a tree of directories, and then figure out which one the root filesystem is on, then use ../part2 if we REEEEALLLY wanted
[12:35] <Keybuk> but that's a bit silly
[12:35] <Keybuk> actually, we probably wouldn't need to improve it at all
[12:35] <Keybuk> just figure out which /dev/disk/by-path is the root fs
[12:35] <fabbione> the problem isn't root
[12:35] <Keybuk> that assumes you want swap on the same disk, of course
[12:36] <fabbione> we can't assume :(
[12:36] <fabbione> we would be able to do so only in one condition
[12:36] <fabbione> getting Kamion to kill manual partitioning
[12:36] <fabbione> till users are able to do partitions as they like
[12:37] <fabbione> we are kind of doomed
[12:37] <fabbione> OR
[12:37] <fabbione> the possibility is to add all this chunk of code only if they use our recipe's
[12:37] <fabbione> via guided partitioning
[12:38] <Keybuk> or just make the manual partitioning generate the random label for every new partition
[12:38] <Keybuk> then if the user changes it to something more readable, which might clash (like "SWAP") that's their problem
[12:38] <Keybuk> and the bug can be closed with something like
[12:39] <Keybuk> "This appears to be your foot that you shot, with your gun"
[12:39] <fabbione> LOL
[12:39] <fabbione> no really.. we can do it only if they use our Guided stuff
[12:39] <Keybuk> no, really, we can do it in manual
[12:39] <fabbione> we can't ensure that the user doesn't have 2 disks
[12:39] <fabbione> and stick half system on one
[12:39] <fabbione> and swap on the other
[12:39] <Keybuk> we don't need to
[12:40] <fabbione> ok let me eat and think about it
[12:40] <Keybuk> just use by-uuid for everything that has it, and by-label for things that don't
[12:40] <fabbione> otherwise i will soon be grumpy ;)
[01:20] <Kamion> Keybuk: could you put the /dev/discs/ support back into scsi-devfs, please? d-i needs it
[01:21] <Kamion> and the Debian 076 package has it
[01:24] <Keybuk> "back into" ?
[01:24] <Keybuk> is it not there?
[01:24] <Keybuk> I just used the scsi-devfs script from upstream
[01:27] <fabbione> Kamion: the hooks i need for that md5sum stuff are in the rescue-udeb right?
[01:28] <Kamion> Keybuk: it's not there, no
[01:28] <Kamion> fabbione: rescue-mode
[01:28] <fabbione> Kamion: thanks
[01:28] <Kamion> fabbione: see yaboot-installer for (at present) the only example of another udeb using it
[01:28] <Keybuk> meh, I'll have to see what Debian patches they have for that
[01:28] <Keybuk> *mutters and grumbles about the installer using obsolete, unsupported and broken scripts* :p
[01:29] <Kamion> it's gradually getting fixed, but the live CD doesn't have parted_devices so disk-detect falls over
[01:29] <Kamion> I've got a patch heading into parted upstream (I hope) to avoid some more of the problems
[01:30] <Keybuk> *nods*
[01:31] <Keybuk> getting the installer to eventually search /sys for drives and cds would be much sweeter
[01:31] <Kamion> it'll just use parted to walk drives
[01:32] <Kamion> hmm, scsi-devfs.sh seems to be in extra/ and in the .diff.gz; does it come from upstream anyway?
[01:32] <fabbione> Kamion: it looks pretty simple the README looks clueful
[01:32] <fabbione> "and" the README..
[01:32] <Keybuk> it comes from upstream, I guess Marco's copied it and modified it for his own nefarious purposes
[01:32] <Kamion> oh, meh, it's completely different
[01:33] <Kamion> it's been in Debian since 0.019-3; I imagine it predates upstream's
[01:33] <Kamion> fabbione: thanks, I wrote the README ;)
[01:34] <fabbione> Kamion: that might be why i was able to understand it :)
[01:36] <Kamion> I'll just use a non-SATA/SCSI system for testing for now
[03:11] <Keybuk> *giggle* at kay
[03:12] <Keybuk> after spending most of yesterday evening arguing that there was no reason to run udevd in initramfs, but just place as /sbin/hotplug
[03:12] <Keybuk> he's now decided we were right after all
[03:31] <jbailey> Keybuk: ^5!
[04:05] <Keybuk> hmm
[04:05] <Keybuk> it seems the ide subsystem could be going away :)
[04:05] <Kamion> huh?
[04:05] <HiddenWolf> Huh?
[04:05] <Keybuk> libata has got parallel ide support now
[04:05] <Keybuk> and that seems to be strongly favoured to replace much of the ide subsystem
[04:06] <Keybuk> pretty much how sata is handled
[04:06] <HiddenWolf> s/away/replaced
[04:12] <jbailey> Keybuk: I asked about that the other day, and I thought ben said ide-generic would still be needed for a while.
[04:17] <Keybuk> you didn't dig enough <g>
[06:27] <Keybuk> right, I think that's all the pile-o-udev bugs solved
[06:28] <Keybuk> Kamion: what installer issues do you have (currently) ?
[06:32] <Kamion> Keybuk: scsi-devfs lack of /dev/discs, live filesystem isn't building, casper needs to be updated to do something initramfs-ish instead of pivot_root
[06:32] <Kamion> I've been concentrating on the live CD rather than on the install CD so it's entirely possible that there are install CD bugs I don't know about yet
[06:33] <Kamion> I'm rolling new install CDs now and will test them shortly
[06:33] <Keybuk> I'm looking into the devfs thing now, I think I may just drop that stuff in wholesale from Debian
[06:40] <makx>  Keybuk: could you take a look at debian #342057, BusLogic not loaded because !sysfs (seems needed for vmware testing of initramfs-tools).
[06:40] <jbailey> makx: I think we fixed that in the Ubuntu kernel.
[06:41] <makx> jbailey: you added sysfs hooks? :)
[06:41] <jbailey> Ben or Fabio did, I think.
[06:41] <jbailey> I try to stay on this side of userspace. =)
[06:41] <makx> why's that not upstream :-P
[06:42] <jbailey>     - [scsi/BusLogic]  Add MODULE_DEVICE_TABLE
[06:42] <Keybuk> it probably is upstream by now
[06:42] <jbailey>  -- Ben Collins<EMAIL_ADDRESS>Sat, 12 Nov 2005 23:34:38 -0500
[06:42] <jbailey> From the 12th to now, it's hard to guess.
[06:42] <jbailey> I know there's alot queued to go upstream.
[06:44] <makx> a quick grep in git-commits-head shows it's not yet landed for linus.
[06:45] <makx> jbailey: anyway thanks for the hint, good news. :)
[06:49] <jbailey> makx: Or perhaps check with BenC in #ubuntu-kernel
[06:50] <makx> jbailey: for now i'll include it in d-kernel, but yes.
[07:19] <Keybuk> Kamion: wow, I see what you mean about these scsi-devfs scripts being totally different
[07:19] <Keybuk> they aren't even related
[07:21] <Kamion> right, I don't think they share ancestry
[07:21] <Keybuk> the upstream one looks far more complete
[07:22] <Kamion> it does a lot of stuff I don't care about ;-)
[07:22] <Keybuk> what do you actually care about/
[07:23] <Keybuk> do you need all the /dev/bus/*, /dev/scsi/*, etc.
[07:23] <Keybuk> or do you just want /dev/cdroms and /dev/discs ?
[07:23] <Kamion> /dev/scsi/ is good, I don't especially care about /dev/bus/ personally
[07:23] <Kamion> I don't think I actually NEED /dev/scsi/ though
[07:24] <Keybuk> I'm trying to work out how to make this work
[07:24] <Keybuk> we plug all the disks at once, so get_next_number returns 0 for every single disk
[07:27] <Keybuk> what I'm wondering is ...
[07:27] <Keybuk> if I throw all of this away
[07:27] <Keybuk> and instead replace it with a small "enumerate disc-like objects" helper that just makes /dev/discs and /dev/cdroms
[07:27] <Keybuk> would that be sufficient for the installer?
[07:27] <Keybuk> or does it really need /dev/ide and /dev/scsi ?
[07:30] <Kamion> no, it doesn't need those
[07:30] <Kamion> I use them occasionally but I can easily adjust
[07:30] <Keybuk> so it really just relies on /dev/discs and /dev/cdroms ?
[07:33] <Kamion> yep
[07:34] <Keybuk> how about /dev/floppies?
[07:50] <Kamion> /dev/floppy
[07:50] <Kamion> floppy-retriever looks for /dev/floppy/0
[07:54] <Keybuk> does it matter if there are gaps in the numbering, btw?
[07:54] <Kamion> /dev/floppy/0 has to be thus, for the rest probably not
[07:55] <Keybuk> how about for cdroms and discs?
[07:56] <Kamion> "for the rest probably not"
[07:56] <Keybuk> ah, sorry
[07:58] <dilinger> Kamion: any chance of seeing my parted /sys/block patches making it into parted
[07:58] <dilinger> ?
[07:58] <dilinger> for ubuntu's installer
[07:58] <Kamion> dilinger: have they gone upstream / to Debian?
[07:58] <Kamion> I've got parted back into sync now, would be kind of a shame to branch again
[07:59] <Kamion> I can if need be though, file me a bug
[07:59] <dilinger> Kamion: they have gone upstream; I have no idea debian's status w/ them
[07:59] <Kamion> Debian's tracking upstream pretty closely
[07:59] <dilinger> upstream seems to want me to assign copyright to the FSF, but doesn't seem to be able to put me in contact w/ whomever i need to talk to about that
[07:59] <dilinger> *shrug*
[07:59] <Kamion> file a bug and I can keep an eye on it
[07:59] <Kamion> I've done FSF copyright assignment; you can probably just mail their clerk
[08:00] <dilinger> Kamion: file a bug in which bts?
[08:00] <Kamion> Ubuntu
[08:00] <dilinger> bugzilla?  malone?
[08:01] <Kamion> bugzilla
[08:01] <Kamion> http://www.fsf.org/licensing/assigning.html - the maintainer is supposed to send you the questionnaire though
[08:03] <dilinger> well, it's svenl who's expressed interest in the patch, but i guess he wanted otavio to mail me or something
[08:19] <dilinger> ok, submitted
[08:20] <Kamion> thanks
[08:47] <Keybuk> Kamion: http://people.ubuntu.com/~scott/storage_enum.sh
[08:49] <Kamion> I'll take your word for it on the implementation, but the intent looks plausible
[08:50] <Keybuk> that should actually fix our current problems too, as it should reliably never use the same number twice
[09:33] <Kamion>    * Update installer startup script to use "cp -au" like the init script,
[09:33] <Kamion>      instead of "cp -af".
[09:33] <Kamion> Keybuk: please revert that - busybox cp doesn't have -u
[09:33] <Keybuk> d'oh
[09:33] <Keybuk> tsk
[09:33] <Keybuk> busybox sucks
[09:33] <Keybuk> it has a -f that doesn't behave like the real one
[09:33] <Keybuk> and then doesn't have -u
[09:33] <Kamion> and in any case I'm sure it was the "cannot be opened" trap I hit
[09:40] <Keybuk> reverted that bit