[08:21] <lordievader> Good morning
[13:27] <coreycb> sahid: I think once we get cinder updated for focal the remaining tempest failures will get resolved
[13:32] <sahid> coreycb: i was not able to fix the issue that you had for merging so i created an other snapshot
[13:32] <sahid> which is comming with some dependencies versions that i need to bump up
[13:33] <coreycb> sahid: ok need a hand with the dependencies?
[13:33] <sahid> thank you that should be fine i will ping you to merge when ready
[13:34] <sahid> can you have a look at python-ironic-lib and python-openstacksdk
[13:34] <sahid> they are ready I guess
[13:34] <coreycb> sahid: yep
[13:35] <sahid> coreycb: also i don't understand the problems with alembic, python-mistral and python-neutron-lib
[13:35] <sahid> if you can have a look
[13:35] <coreycb> sahid: ok I'll take a look
[14:21] <jamespage> sahid, coreycb: https://bugs.launchpad.net/ubuntu/+source/pyrsistent/+bug/1860422 needs a bit of love
[14:22] <coreycb> jamespage, sahid: I'll take a look
[14:23] <sahid> jamespage, coreycb ack
[14:50] <coreycb> sahid: python-ironic-lib and python-openstacksdk uploaded, thanks
[14:51] <sahid> ack
[15:13] <coreycb> sahid: jamespage: everything in ussuri-staging is now promoted to ussuri-proposed. matplotlib and networkx will build successfully once the pandas SRU for bionic is released (tomorrow hopefully).
[15:14] <jamespage> coreycb, sahid - could we take a look at removing python3-keyring from our dependency chain in Openstack? see comments on https://bugs.launchpad.net/ubuntu/+source/jeepney/+bug/1861268
[15:16] <coreycb> jamespage: sure
[15:25] <coreycb> sahid: hmm, python-openstacksdk is hitting some timeouts
[15:57] <coreycb> jamespage: looks like python3-pyrsistent is already in main. updating the bug to say that.
[18:34] <smoser> bryce: if you're around.. https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/378282 is happy now (i think) and the '-B' simplifies things.
[18:35] <bryce> smoser, great, thanks.
[18:37] <smoser> i guess that a nwere version of 3.6 must have come in with the -B flag that you thougt was not available until 3.8
[18:37] <bryce> yeah I was just wondering the same
[19:22] <slimschwifty> Hey all, I'm looking for some advice. I'm upgrading my existing headless ubuntu server and plan to add an RX 580 to help encode my DVR captures. The server doesn't have any GUI as it never needed it, but I believe I need one to utilize the vaapi acceleration with ffmpeg. Is lubuntu-gtk-core my best bet for an absolute minimal GUI for this purpose or is there a better alternative?
[19:24] <bryce> slimschwifty, not really a server question, but I think it might be possible to run pure X.org with no WM.  Depends on what you're trying to maximize/minimize I guess.
[19:25] <bryce> however it seems like there must be a way to run ffmepg even with vaapi, without any X/Wayland at all.  But that may be more a question for ffmpeg folks
[19:26] <slimschwifty> I may be misunderstanding the requirements. I'll try the ffmpeg folks, thanks
[20:01] <Sven_vB> hi! I'm using xinetd on xenial to guard a weak proxy from being overrun. I do this by limiting the number of instances my xinetd proxy service is allowed to have. when apt tries to hammer it, xinetd blocks it. is there a way to have xinetd instead hold up to a few hundred connections in limbo until it's their turn to be served?
[20:02] <Sven_vB> to clarify, "xinetd proxy service" is a xinetd service that netcats to the real proxy.
[20:10] <Sven_vB> wow, even with cps = 512000, "Deactivating service ??? due to excessive incoming connections."
[20:10] <Sven_vB> maybe I underestimated how intense apt update really is
[20:12] <Sven_vB> even if I increase to "instances = 2500" and of course reload xinetd
[20:12] <Sven_vB> I wonder just what is happening
[20:21] <Sven_vB> as a stopgap I'll use a node.js connection limiter in front of xinetd.
[20:21] <Sven_vB> but would be nice to have a more basic solution.
[20:25] <sdeziel> Sven_vB: nowadays, I use systemd-socket-proxyd instead of xinetd
[20:25] <sdeziel> dunno if it's available on Xenial but it is on Bionic
[20:25] <Sven_vB> sdeziel, thanks, I'll try that.
[20:25] <Sven_vB> can it hold connections idle until the service is ready?
[20:26] <Sven_vB> "ready" as in, below limits again
[20:26] <sdeziel> Sven_vB: not that I know. It only lets you set a cap on the number of connections
[20:26] <Sven_vB> yeah I do have that. it's part of the problem.
[20:26] <sdeziel> Sven_vB: if you want something fancy, haproxy does a good job
[20:26] <Sven_vB> I can choose between apt not working because xinetd blocks the rage, or apt not working because the weak proxy breaks down.
[20:27] <sdeziel> Sven_vB: but I'm surprised that you need to proxy to a proxy ;)
[20:27] <Sven_vB> I wouldn't consider "just wait and do nothing" as "fancy"
[20:28] <sdeziel> true but I don't have good alternatives to propose
[20:28] <Sven_vB> yeah I'd prefer all apps I use were kind of friendly, but most of them just don't care about how aggressive they are, because their intended target servers are ready to deal with the assault.
[20:28] <Sven_vB> I mean I kinda accept that lack of respect from overworked people at hipster companies, but now even apt? :<
[20:29] <Sven_vB> well I should study the apt manual again
[20:29] <Sven_vB> maybe it can restrain itself afterall
[20:32] <sdeziel> Sven_vB: there is a Queue-Mode param mentioned in apt.conf man page
[20:32] <sdeziel> can't find what's the default though
[20:35] <tomreyn> there is Acquire::http:Pipeline-Depth also
[20:35] <Sven_vB> https://linux.die.net/man/5/apt.conf covers it, a crude way to limit to 1 connection per criteria
[20:35] <Sven_vB> ah maybe that one will allow a better compromise.
[20:36] <Sven_vB> s:compromise:tradeoff:
[20:38] <tomreyn> see apt-transport-http(1) for details
[20:41] <Sven_vB> thanks!
[21:06] <Sven_vB> strange, it looks like apt only got into that rage because the network interface to the interwebs was down, which I didn't notice at first. now that it's up, it goes way more slowly.


[00:55] <lifeless> slangasek: ok I have a little time
[01:03] <slangasek> lifeless: hey there
[01:04] <lifeless> hey
[01:04] <lifeless> so tell me now, tell me true
[01:04] <slangasek> lifeless: so the process I've been using for package merges is bzr co lp:ubuntu/$package; cd $package; bzr merge-package lp:debian/sid/$package; fwibble-fwibble; bzr commit
[01:05] <slangasek> lifeless: and if I look at my local directory afterwards with 'bzr log -n0' or 'bzr tags', the upstream-$version tag is there
[01:05] <slangasek> lifeless: and if I do a fresh checkout from lp:ubuntu/$package, the tag is *not* there
[01:05] <lifeless> well
[01:05] <lifeless> are you pushing back to lp:ubuntu/$package afterwards ?
[01:05] <lifeless> oh
[01:06] <lifeless> I see
[01:06] <lifeless> uhm
[01:06] <lifeless> workaround - don't checkout.
[01:06] <lifeless> make a branch
[01:06] <lifeless> then do 'bzr push :parent' after committing
[01:06] <slangasek> workaround, yes :)
[01:06] <slangasek> where should I file the bug?
[01:06] <lifeless> please file a bug on bzr saying 'bzr commit in a heavyweight checkout does not propogate new tags'
[01:06] <lifeless> thanks
[01:06] <slangasek> ok
[01:13] <slangasek> lifeless: bug #603395
[01:13] <lifeless> thanks
[01:16] <james_w> thanks slangasek, lifeless
[01:18] <lifeless> de nada
[01:18] <lifeless> its a one liner
[01:18] <lifeless> but I doubt I'll get to it :(
[01:18] <lifeless> EATADBUSY
[01:21] <slangasek> eat a dbus?
[01:21] <lifeless> E a tad busy
[01:21] <slangasek> ohh
[01:22] <slangasek> :-)
[01:22] <lifeless> but I like your parsing too
[01:23] <robertzaccour> I'm using the live cd and installing it. apparently there's a serious kernel problem. i'm gonna let the installer finish and update and find out what happens next
[02:22] <JontheEchidna> I'm having a bit of trouble with DBus. It's spawning a Polkit-1 helper binary as root, but all the locale environment vars end up set as C
[02:22] <JontheEchidna> rather than the system locale
[02:23] <JontheEchidna> whereas starting the helper in a root shell results in the locale environment vars being the system locale
[02:24] <JontheEchidna> Is there anything I can do short of parsing /etc/default/locale to get the system locale?
[04:00] <achiang> if i did a 'bzr add foo' and then decide i don't want to commit foo, how do i remove it from the list of things to be committed?
[04:01] <lifeless> bzr revert foo
[04:02] <achiang> lifeless: yuck. that actually undid my changes to foo. :(
[04:02] <lifeless> achiang: they will be stored in a ~ backup file
[04:02] <achiang> i wanted to do the equivalent of git reset, aka unstage
[04:02] <lifeless> achiang: are you perhaps a git user ?
[04:02] <achiang> lifeless: yes
[04:02] <achiang> struggling with bzr
[04:02] <lifeless> bzr, like *every other VCS on the planet* has no staging area.
[04:03] <lifeless> you might like the 'bzr shelve' and 'bzr unshelve' commands
[04:03] <achiang> lifeless: don't yell at me because git did it correctly
[04:03] <achiang> :P
[04:03] <lifeless> they can take a change that you haven't committed and put it to the side for you
[04:03] <lifeless> and restore it
[04:03] <achiang> lifeless: but thank you for pointing out the ~ backup files, that helped
[04:04] <lifeless> achiang: I'd like you to get the most out of bzr; assuming it works the same way as git won't get you that :(
[04:05] <achiang> lifeless: i mean, point taken re: the tools work differently. i just would have expected that the inverse of 'add' wouldn't actually change the file
[04:06] <lifeless> if the file was added, revert would have unadded it.
[04:06] <achiang> that expectation came from the fact that 'add' and 'commit' are two separate steps
[04:06] <RAOF> Well, “bzr add” doesn't even do what you think it does — bzr commit will commit *all* changes, so you only need to add new files.
[04:06] <lifeless> if the file was previously versioned, revert puts it back to the previously versioned state
[04:07] <RAOF> (ie: the state of the versioned files on disc and the state of the tree that will be recorded by a commit is the same, barring selective commits via “bzr commit $FILE”)
[04:07] <achiang> RAOF: right, i've discovered that bzr commit wants to commit everything, so in my workflow, i've had to manually add the files i changed, and then manually commit them
[04:08] <RAOF> lifeless: Incidentally, I didn't notice any colocated branches NEWS in the bzr 2.2 beta 4 notes - has that slipped from 2.2?
[04:08] <achiang> RAOF: maybe i don't need that separate add step ; i can just say: bzr commit foo bar baz
[04:08] <lifeless> achiang: that doesn't make any sense to me - in git you might say that but in bzr 'bzr add' something that is already added is a no-op.
[04:08] <lifeless> right
[04:08] <lifeless> you just say 'bzr commit foo' if you want to commit just foo.
[04:09] <achiang> lifeless: right, that is just a git-ism. i was assuming that there was an index of some sort in bzr
[04:09]  * achiang stands corrected
[04:09] <RAOF> There is, kinda - “bzr shelve”
[04:09] <FourDollars> achiang: There is no stage concept in bzr.
[04:09] <RAOF> But it works the right way around - ie: by default, you commit your changes :)
[04:10] <achiang> thanks for the education. i appreciate it
[04:11] <RAOF> bzr shelve is well worth exploring.  It's tremendously useful if you want to separate out a bunch of changes into multiple commits.
[04:11] <achiang> do i need a plugin for that, or does it work out of the box?
[04:11] <RAOF> Or just want to keep some debugging kruft uncommitted.
[04:11] <RAOF> Out of the boz.
[04:11] <RAOF> Ahem.  Box.
[04:11] <achiang> cool
[04:12] <achiang> so, in git, i can say, "git show <sha1>" which will show me the changelog and the patch.
[04:12] <achiang> is there an equivalent for bzr? to look at revnos?
[04:13] <lifeless> bzr log -p -r X
[04:14] <RAOF> To expand on lifeless' comment, run “bzr alias show="log -p -n0 "”, then you can “bzr show -r$REVNO”, or just “bzr show” to get the full log.
[04:15] <achiang> yep, i was just about to add an alias
[04:15] <achiang> thanks lifeless, RAOF
[04:15] <achiang> oh! a bzr alias!
[04:15] <achiang> not a bash alias
[04:15] <RAOF> Indeed.
[04:15] <achiang> neat
[04:15] <RAOF> bzr is full of love.
[05:43] <pitti> Good morning
[05:43] <pitti> robbiew: hello
[05:44] <robbiew> pitti: hi
[05:44] <robbiew> pitti: can't remember what I wanted...but I answered it anyway :)
[05:44] <pitti> hehe, the best kind
[06:19] <pitti> uh, what happened to our buildds..
[07:24] <dholbach> good morning
[07:24] <pitti> hey dholbach, wie gehts?
[07:25] <dholbach> pitti: sehr gut - und dir?
[07:25] <pitti> dholbach: prima, danke
[07:26] <dholbach> :-)
[07:28] <maco> is this the part where you three all have a hug and a beer and pout about losing to spain?
[07:28]  * pitti hands dholbach a beer and hugs him over the loss
[07:29] <pitti> maco: great idea!
[07:29] <pitti> maco: although 8:30 in the morning is a little early for the beer part
[07:29] <maco> hmm good point
[07:29]  * maco looks at mvo
[07:29] <maco> a cup of tea?
[07:29]  * dholbach hugs pitti back
[07:29] <dholbach> pitti: give that beer to mvo instead :-P
[08:51] <dupondje> can somebody let rebuild https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 ?
[08:51] <dupondje> it builds fine now :)
[08:52] <hyperair> didrocks: have you seen the banshee bugs regarding the netbook interface?
[08:53] <pitti> ScottK, NCommander: I'd appreciate if you could ack bug 603480 soon, so that we can coordinate the new binarymangler rollout next week; I'll take the responsibility and blame
[08:53] <hyperair> bug #602759 and bug #602760
[08:53] <hyperair> didrocks: ^^
[09:02] <ricotz> can someone look at https://launchpad.net/ubuntu/+source/xine-lib/<IP_ADDRESS>-4ubuntu1 this needs also a rebuild
[09:05] <dupondje> grant dupondje access on 'rebuild button'
[09:05] <dupondje> :)
[09:10] <pitti> ricotz: it'll build now?
[09:11] <ricotz> pitti, there seemed to be a problem with the archive it is building fine in my ppa
[09:11] <ricotz> pitti, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1226883/+listing-archive-extra
[09:11] <pitti> ah, I'll retry
[09:12] <pitti> ricotz: done
[09:19] <dupondje> pitti: https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 => builds also now
[09:29] <psurbhi>  hie! is there a good place to find more information about Ubuntu udev implementation or its variance from Debian?
[09:46]  * psurbhi looking at debian/changelog in ubuntu and debian's udev package.. shall get back if needs more
[09:58] <dupondje> https://launchpad.net/builders => we stop building for sparc ?
[10:04] <pitti> dupondje: do you miss it?
[10:04]  * pitti shakes hand with the new voluntary sparc maintainer
[10:04] <Sarvatt> ack, powerpc too?
[10:05] <dupondje> pitti: don't miss it no :) just wondering :)
[10:05] <pitti> powerpc is still an official port
[10:05] <pitti> sparc and ia64 were about to be removed
[10:06] <Sarvatt> ah phew, just saw the powerpc builders were disabled too
[10:06] <dupondje> that will fix alot of ftbfs ;)
[10:07] <pitti> no, there just seems to be something generally wrong ATM; half of the buildss are broken
[10:13] <wgrant> There was a networking glitch earlier.
[10:13] <wgrant> Probably just needs someone to flip the disabled switch on LP
[10:16] <apw> cjwatson, i seem to remember saying "my machine isn't suspending every time i close the lid" and you mentioned some bug or other with perhaps pmutils, can you remember/point me at it again?
[10:23] <dupondje> https://launchpad.net/ubuntu/+source/openbios-ppc/1.0+svn640-1/+build/1729379/+files/buildlog_ubuntu-maverick-i386.openbios-ppc_1.0+svn640-1_FAILEDTOBUILD.txt.gz => can we force to build it on PPC ? as thats why its ftbfs :)
[10:24] <directhex> dupondje, there's no way to say arch-all packages have specific build-arch requirements. this is a loooong standing issue which only affects, like, 3 packages
[10:25] <dupondje> ok :)
[10:26] <scar_> is there a specific channel for xorg releated questions, something in the line of XorgOnTheEdge? I want to compile/configure/install llvmpipe, preferabley just install.
[10:27] <Sarvatt> #ubuntu-x, llvmpipe is in libgl1-mesa-dri-gallium in xorg-edgers though
[10:28] <scar_> awesome thanks
[10:28] <cjwatson> apw: pm-utils is pretty much the userspace side of power management these days, but I know very little more about it than that
[10:29] <apw> cjwatson, must have been someone else, no worries
[10:32] <apw> cjwatson, so this pretty grub work ... whats the next step.  i am getting close to cleanish set of patches here, not sure if they will ever be acceptible upstream but at least they are small and self contained
[10:33] <apw> i assume we're not ready for them to be in the kernel yet, so perhaps we need a PPA with the bits in?  so people can test ?
[10:40] <cjwatson> apw: can we at least try to get them upstream?  it would make it easier to get the corresponding grub changes upstream
[10:40] <cjwatson> apw: due to an upstream conversation I'm currently working on writing a no-probe simple linear framebuffer device for the kernel
[10:41] <cjwatson> apw: sort of like efifb but guaranteed never to do anything firmware-specific
[10:41] <apw> if i am honest i suspect noone would accept the current approach
[10:41] <cjwatson> apw: I thought it was all nicely tunable now and switched off by default
[10:41] <apw> the "correct" approach probabally is a frame buffer which knows its already filled in like plymouth does
[10:41] <cjwatson> apw: we need both
[10:41] <cjwatson> the framebuffer device can't help when fbcon just goes and clears the screen
[10:41] <apw> which picks up the contents and handles it, and then us not moving over to VT7, ie X on VT1
[10:42] <cjwatson> no no no no nooooo
[10:42] <apw> i am telling you what they are going to say
[10:42] <cjwatson> I don't see why
[10:42] <apw> what we are doing now is just ignoring the kernels desire to clear and update the VT until we switch to VT7
[10:42] <cjwatson> there's no intrinsic reason X needs to move to vt1, and it breaks so much documentation
[10:42] <apw> which is at vest vile
[10:43] <apw> yes its all configurable, but what it does is utterly underhand
[10:43] <cjwatson> so, wait, I didn't ask for no updates
[10:43] <cjwatson> I only asked for no clearing
[10:43] <cjwatson> which I think is much less underhand and much simpler
[10:43] <apw> the only thing that occurs is the clearing though
[10:43] <apw> oh and not turn
[10:43] <apw> and not turning on the cursor
[10:44] <cjwatson> yeah, but that's already upstream
[10:44] <cjwatson> I really don't see that disabling the screen-clear until boot is finished is all that underhand
[10:44] <apw> well except that what you want is not showing the cursor randomly while we are on VT1 the first time, but on for the second time
[10:44] <apw> i am even struggling to put the semantics down in english!
[10:45] <cjwatson> the problem with this not going upstream is that we have no other way to reserve the flags bit
[10:45] <cjwatson> and not having a flags bit for it is really pretty nasty in grub, as I mentioned
[10:45] <apw> in the failure to upstream case we could submit a 'bootloader specific' bit or something
[10:46] <apw> or 'distro specific'
[10:46] <cjwatson> shouldn't be distro-specific
[10:46] <cjwatson> why don't we have the upstream conversation rather than giving up before we start? :)
[10:46] <apw> oh we will, but they won't take sensible patches i suspect they will puke when they see what we have done
[10:47] <cjwatson> this is *neater* than the no-cursor stuff which already went upstream
[10:47] <apw> and they will gladly tell you to confuse all your users to make things clean in the code
[10:47] <cjwatson> (which turns it off permanently, and requires horrible hacks in the login binary to turn it on again per-VT ...)
[10:47] <apw> really?  i don't think it is nice at all, it has horrible semantics
[10:48] <apw> necessary semantics perhaps, well only cause we want to switch VTs
[10:48] <cjwatson> depends on your point of view I suppose
[10:48] <apw> right, i am a sensible person and can see we might need to do it, but that doesn't stop it pegging my vile meter
[10:48] <cjwatson> but I think the fact that the no-cursor patch already went upstream, and the fact that folks were working on plymouth/X framebuffer handover, indicates that it isn't just us interested in this
[10:48] <cjwatson> I don't mind if we end up with something different that meets the same basic requirements
[10:49] <cjwatson> what I don't want is to have to have fundamentally distro-specific code in the linux loader in grub
[10:49] <apw> all understandable
[10:49] <apw> i am just warning you that i think we're on for a beating
[10:49] <cjwatson> because that introduces some real problems - the same linux loader is used for booting Ubuntu and booting other detected OSes
[10:50] <apw> which had better ignore unknown bits me thinks
[10:50]  * mvo hugs dholbach
[10:50] <cjwatson> I'd actually welcome a discussion about the semantics; I agree they're grotty as it stands and perhaps somebody can come up with better ones
[10:51] <cjwatson> I'm hoping that this is an example of "post wrong code on the internet and somebody will suggest right code"
[10:51] <cjwatson> at least get the discussion going ...
[10:51]  * dholbach hugs mvo back
[10:51] <apw> heh indeed.  well it needs some more shining before its ready for that, but its close
[10:52] <cjwatson> actually, surely there's only *one* screen-clear we need to kill
[10:52] <cjwatson> the one when fbcon starts
[10:52] <cjwatson> do we have to care about vt switching or any of that gubbins?  just remember whether it's the first screen-clear or not ...
[10:53] <apw> cjwatson, no cause you don't want the vt switch to smack you either right
[10:53] <cjwatson> which vt switch?
[10:53] <apw> from vt1 to vt7
[10:53] <cjwatson> the one to X is already handled in other ways, or at least it was
[10:53] <cjwatson> X is supposed to snarf the framebuffer contents on its way up
[10:53] <cjwatson> we don't need to solve that problem again
[10:54] <cjwatson> (I think it snarfs the contents before the vt switch)
[10:54] <apw> perhaps this is still doing more than it needs to suceed
[10:54] <apw> will poke some more
[10:54] <tseliot> the switch from vt1 to vt7 takes place when we start plymouth
[10:55] <apw> tseliot, before or after plymouth actually starts
[10:55] <tseliot> therefore when X starts we're already on vt7
[10:55] <apw> that was more my belief too
[10:56] <cjwatson> tseliot: are you certain about that?  I thought we changed that in lucid
[10:56] <apw> so we have VT1 init which clears, VT1 -> VT7 switch which repaints a blank screen too
[10:56] <cjwatson> apw: but again, there's no need to address the latter problem in the kernel
[10:56] <cjwatson> apw: if it exists, plymouth can deal with it the same way X does - snarf the framebuffer contents before the VT switch
[10:57] <apw> hrm
[10:57] <tseliot> cjwatson: yes, I'm pretty sure. X simply doesn't clear the framebuffer when it starts on the same vt as plymouth
[10:58] <cjwatson> tseliot: ok, well in that case do you agree that plymouth can solve this problem?
[10:58] <tseliot> apw: I think we tell plymouth to use vt7, let me check the code
[10:58] <cjwatson> I think you're right, from the changelogs, I'm just misremembering
[10:58] <tseliot> cjwatson: what's the problem again? I think I've missed part of the discussion
[10:59] <cjwatson> tseliot: trying to eliminate black screens between grub and plymouth
[10:59] <apw> cjwatson, the problem then becomes is how does plymouth get the framebuffer contents, when the VT isn't even in framebuffer mode
[10:59] <cjwatson> apw: you mean KD_GRAPHICS?
[10:59] <apw> cjwatson, indeed
[11:00] <apw> now maybe thats what we should be doing, putting VT1 into KD_GRAPHICS instead
[11:00] <tseliot> cjwatson: the problem is that plymouth clears the screen when it starts
[11:00] <apw> tseliot, that is simply a bug though right ?
[11:00] <cjwatson> tseliot: userspace problems are shallow :)
[11:00] <apw> (in this context)
[11:01] <cjwatson> tseliot: I'm trying to figure out exactly what we need to change at the interface between grub and the kernel
[11:01] <cjwatson> tseliot: we know that, at minimum, we need to stop fbcon init from clearing the screen
[11:01] <apw> cjwatson, so now i wonder what would happen if we simply dropped VT1 into graphics mode based on your bit
[11:01] <cjwatson> tseliot: what else do we need to change in the kernel?
[11:01] <tseliot> apw, cjwatson: yes, it's something that can be fixed in plymouth. The only problem is that is that if you copy the fb content from a framebuffer that uses a different resolution, the result is ugly
[11:02] <cjwatson> actually
[11:02] <cjwatson> I'm entirely happy for plymouth to repaint the whole screen, it's going to do that anyway (based on the theme) and there's a possibility of a resolution change here which is something I'm prepared to cope with (one problem at a time!)
[11:03] <cjwatson> all I want is for it to be a clean switch
[11:03] <cjwatson> as in, no flicker to black
[11:03] <apw> tseliot, what interface does X use to read the framebuffer contents
[11:03] <cjwatson> so I guess it doesn't have to read the framebuffer contents
[11:03] <tseliot> well, what I was trying to say is that plymouth clears the screen with a big black rectangle first and then draws the splash
[11:04] <cjwatson> tseliot: ok, does it have to have the foreground vt before it does that?
[11:04] <apw> tseliot, why the HECK would one do that
[11:04] <apw> 'i am going to write over the whole screen with a splash, lets waste my time and make it shiney first' ???
[11:04] <tseliot> apw: in case the resolution doesn't match
[11:05] <cjwatson> as long as it's doing all this to a non-displayed framebuffer, I really don't care if it puts polka-dots on there first
[11:05] <cjwatson> er, a non-displayed buffer
[11:05] <tseliot> cjwatson: would you like to vtswitch only when the splash is ready?
[11:05] <cjwatson> yes
[11:05] <tseliot> I'm not sure it's possible
[11:05] <apw> graphics mode is raw isn't it
[11:06] <apw> ie when a mode is GRAPHICS, then you can't write unless you are the 'current' vt
[11:06] <cjwatson> or, at minimum, at least prepare a suitable buffer and blit it over at once after the vt switch
[11:06] <cjwatson> but then the kernel probably will clear the screen, so still not idea
[11:06] <cjwatson> *ideal
[11:07] <apw> not sure it will from <-> to GRAPHICS
[11:07] <tseliot> apw: yes, something weird would happen
[11:07] <cjwatson> looking at X
[11:07] <cjwatson> as far as I can tell, it actually doesn't read the framebuffer contents at all
[11:07] <apw> cjwatson, why do we need to VT switch?  this is just to make peoples fingers happy that we are on VT7 yes ?
[11:07] <cjwatson> it just refrains from clearing them
[11:08] <apw> cjwatson, what if we just told the kernel that the default VT was 7
[11:08] <tseliot> cjwatson: we can copy the content of fbcon (if the resolution matches)
[11:08] <cjwatson> the web is full of documentation that says "when stuff going wrong, you can get a login prompt with ctrl-alt-f1"
[11:08] <cjwatson> apw: that would break server boots.  I'd really rather not go there
[11:08] <apw> cjwatson, right ... happy with that ... what if we made the default VT-7
[11:08] <apw> why would it break server boots
[11:09] <apw> they get the same graphics poop we do, then they do something to get the login prompt yes?
[11:09] <tseliot> cjwatson: right, X simply creates a root window with no background which makes it possible to see what the framebuffer left
[11:09] <apw> a vt switch to 1 i assume ?
[11:09] <cjwatson> well, not necessarily, a lot of server people disable the splash
[11:09] <apw> right and without splash you'll go back to textual grub and not pass me the bit right ?
[11:09] <cjwatson> no, splash is just a word in the command line
[11:09] <cjwatson> grub refrains from trying to parse that stuff, it isn't generic
[11:10] <apw> cjwatson, can i just say you are making this hard :)
[11:10] <cjwatson> system design back 20 years is making this hard
[11:10] <cjwatson> I'm just trying not to break it
[11:10] <apw> surley we can jsut put a login on VT-7 for server :)
[11:10] <cjwatson> if you think it's hard to get the rest of this upstream, try getting a change of the default VT upstream
[11:11] <apw> cjwatson, i was proposing to make the default change only on a bit asking for it, or a command line option asking for it
[11:11] <cjwatson> can we separate out these two problems?
[11:11] <apw> actually a command line option would work with server well as well
[11:11] <cjwatson> I'm not trying to solve everything at once
[11:11] <cjwatson> avoiding the clear on fbcon init would be brilliant for now
[11:12] <cjwatson> and I don't mind if it takes longer to sort out the rest
[11:12] <apw> indeed, but the point is there are two issues... that init clears stuff is bad, that the VT switch will too is bad
[11:12] <cjwatson> sure, but I think they need different solutions
[11:12] <cjwatson> and the latter is much less intrusive anyway
[11:12] <tseliot> cjwatson: I assume that you want to use the fb that grub provides. Am I right?
[11:12] <cjwatson> init clearing stuff leaves us with a black screen for multiple seconds
[11:12] <cjwatson> the VT switch to plymouth will be at most a flickere
[11:12] <cjwatson> *flicker
[11:13] <apw> well perhaps without some idea of how we are going to resolve it may change how we resolve the other issues
[11:13] <apw> ok
[11:13] <cjwatson> tseliot: well - grub will program an fb in order that we have something, but I expect it to be reprogrammed by the switch to KMS
[11:14] <cjwatson> all I'm really trying to get round here is the several seconds of black screen before plymouth starts
[11:14] <tseliot> cjwatson: right but some flicker would still happen if the resolution changes
[11:14] <cjwatson> papering over the join is tricky, but as long as all of the images are as identical as we can make them (modulo resolution) then it will be an improvement over what we have today
[11:14] <cjwatson> I don't want the perfect to be the enemy of the good here
[11:14] <tseliot> still better thana black screen for sure though
[11:14] <tseliot> than
[11:14] <cjwatson> we can sit here all day saying that we can't make it perfect, but there are definitely improvements we can make
[11:15]  * tseliot nods
[11:15] <cjwatson> and I don't think it can ever be exactly right unless (a) grub gets support for programming native panel resolutions or (b) the native panel resolutions are loaded into the vbe bios
[11:16] <tseliot> the former seems more realistic to me ;)
[11:16] <cjwatson> (whether (b) would result in a flicker is still questionable, apparently the kernel does have to switch off the panel briefly right now but mjg59 doesn't seem to think that's an intrinsic problem)
[11:16] <tseliot> ah
[11:17] <cjwatson> something to do with changing the panel scaler
[11:20] <tseliot> apw, cjwatson: so, to sum up, would it be useful if I made plymouth copy whatever it's in fbcon when it starts?
[11:20] <apw> tseliot, what does 'in fbcon' mean ... and how and where do you get to it
[11:21] <cjwatson> tseliot: is it possible if the vt is in KD_TEXT mode?
[11:21] <cjwatson> tseliot: I actually don't think it would be useful, though, thinking about it
[11:22] <cjwatson> tseliot: we want to inhibit the screen-clear
[11:22] <cjwatson> tseliot: but that may be partly in the kernel and partly in plymouth
[11:22] <apw> cjwatson, as you know what is in there anyhow right, its in /boot/grub/logo.png
[11:22] <cjwatson> right, well ultimately I was going to try to get that dynamically from the plymouth logo
[11:22] <cjwatson> but yes
[11:22] <tseliot> apw: if grub puts something in the framebuffer, I can copy its content by mapping the framebuffer
[11:23] <cjwatson> (the approach I gave you is resolution-specific)
[11:23] <cjwatson> tseliot: is this significantly different from not clearing to black and just drawing it again, though?
[11:23] <tseliot> cjwatson: not much
[11:24] <cjwatson> remind me, when does the switch to kms happen?  it's before plymouth starts, isn't it?
[11:24] <tseliot> but it can take a while before you see the splash
[11:24] <apw> kms happens when the driver loads
[11:24] <cjwatson> or rather, it's before plymouth-splash starts
[11:24] <tseliot> yes, as plymouth's drm plugin requires kms
[11:24] <apw> (kernel driver)
[11:24] <cjwatson> so what happens to existing framebuffer contents when we switch to kms?
[11:24] <tseliot> right
[11:24] <cjwatson> they'll be cleared, won't they?
[11:25] <apw> cjwatson, well they get redrawn, from the VT contents
[11:25] <cjwatson> apw: VT text contents, or the prior framebuffer contents?
[11:25] <cjwatson> apw: if the latter, presumably they aren't rescaled (they couldn't be since there may have been text drawn on top)
[11:25] <apw> if its in text mode the text contents
[11:26] <apw> (i can't see how it could do anytning else)
[11:26] <cjwatson> what if it's in graphics mode?
[11:26] <apw> then i believe the kernel asks the mode owner to redraw it
[11:27] <cjwatson> that's if it's VT_PROCESS too, presumably
[11:27] <cjwatson> you can be KD_GRAPHICS && !VT_PROCESS, IIRC
[11:28] <cjwatson> and indeed if we were doing something where the kernel starts in KD_GRAPHICS, you'd have to be
[11:31] <cjwatson> so I suppose grub does have to be made to know whether there's going to be a splash screen
[11:31] <cjwatson> if there isn't, then it may well want to keep the better mode (people tend to like big framebuffers as long as they aren't too slow), but it shouldn't preserve the screen contents
[11:31] <apw> cjwatson, vt relies on being able to tell someone to redraw on a resize as far as i can see
[11:32] <apw> whether that is fbcon or X
[11:32] <tseliot> oh, and as regards clearing the screen in plymouth, some time ago I spoke with upstream and they told me that:
[11:32] <cjwatson> I can only find the text-mode vt resize code
[11:32] <tseliot> with drm modesetting plymouth gets its own "screen" that it swaps in
[11:32] <tseliot> so it's not really clearing the screen, just detaching it and putting a new on in place
[11:32] <tseliot> but the initial contents of that "screen" is black
[11:33] <cjwatson> tseliot: in that case it should be easy to draw the splash before swapping it in, if it doesn't do so already
[11:34] <tseliot> I guess it's not as fast as ideally it should be then, if we can see the black screen
[11:34] <cjwatson> apw: anyway, when Scott and I tested this a few months back, there seemed to be some plymouth bug that broke things on resize, but aside from that the duration of the flicker on resolution change wasn't particularly long IIRC
[11:35] <apw> cjwatson, and you were testing with the patch i started from ?
[11:35] <cjwatson> IIRC yes
[11:36] <apw> and that patch simply turned off all VT updates in text mode
[11:36] <cjwatson> apw: would setting the vt to KD_GRAPHICS on initialisation be enough to inhibit the screen-clear from fbcon_init?
[11:36] <tseliot> cjwatson: it would take some restructuring but it would definitely be possible to do what you suggest by making plymouth render the 1st frame of the splash so that we could have that instead of the black screen
[11:37] <cjwatson> apw: if KD_GRAPHICS + VT_AUTO works at all, and if it has that effect, I think it might well be what we want
[11:37] <apw> cjwatson, it not clear you have failure tollerance in that case, or indeed if it would survive the KMS mode change
[11:38] <cjwatson> let's ignore the latter, it's not obvious it's soluble at that point
[11:38] <cjwatson> failure tolerance?  you mean things like the ability to display oopses?
[11:38] <apw> or indeed to switch to VT-1 to see the text that the kernel put on it yes
[11:38] <cjwatson> I think the solution for that is "disable splash", isn't it?
[11:39] <tseliot> yes, it's not nice to leave things in KD_GRAPHICS is something goes wrong
[11:39] <tseliot> if
[11:39] <cjwatson> ok, so maybe KD_GRAPHICS won't fly
[11:40] <cjwatson> in that case simply inhibiting the initial clear seems like the only kernel change that's particularly viable right now?
[11:40] <apw>          * Ignore all switches in KD_GRAPHICS+VT_AUTO mode
[11:41] <cjwatson> that's probably not good
[11:41] <apw> cjwatson, our KMS story is going to look bad i suspect if its going to clear when kms loads
[11:41] <cjwatson> apw: it will look better than it does now :-)
[11:41] <apw> we don't start plymouth till after ureadahear on spinning media i think right?
[11:41] <apw> so we'll still get 10s of black
[11:43] <cjwatson> ureadahead is 'start on starting mountall'
[11:43] <cjwatson> plymouth is 'start on (starting mountall or [other stuff])'
[11:43] <cjwatson> plymouth-splash is 'started on started plymouth and [got a graphics device]'
[11:44] <cjwatson> I don't know if there's something that explicitly serialises ureadahead before plymouth, but if there is I can't find it
[11:44] <apw> cjwatson, cirtianly on my machine i have black for most of the time ureadahead is runnign
[11:45] <apw> but its hard to know if thats kms not loaded yet or what
[11:45] <cjwatson> my suspicion is that that is Keybuk's intention but is not guaranteed, but that's just my reading of the job graph
[11:45] <cjwatson> well - udev is 'start on virtual-filesystems'
[11:46] <cjwatson> udevtrigger is 'start on (startup and started udev)'
[11:46] <cjwatson> and virtual-filesystems is emitted by mountall
[11:46] <cjwatson> so you won't get the kms event until ureadahead is done
[11:46] <cjwatson> I mean, userspace won't notice
[11:47] <cjwatson> if it were KD_GRAPHICS + VT_AUTO, then theoretically we could rescale the existing framebuffer contents
[11:47] <apw> cjwatson, who can ?
[11:48] <cjwatson> it would have to be the kernel
[11:48] <apw> deep joy
[11:48] <cjwatson> yeah, I know.  I can't think of any other way to do it
[11:49] <apw> cjwatson, ever played with the fbcon logo ?
[11:49] <cjwatson> no, although it did occur to me just a few minutes ago
[11:49] <cjwatson> is that scalable?
[11:49] <apw> cjwatson, if i am honest i have no idea what it even is
[11:50] <apw> though i have seen a penguin drawn on boot in videos so it could be that
[11:51] <cjwatson> I bet it's not themeable in the ways we'd need
[11:51] <cjwatson> I think I played with it in about 19198
[11:51] <cjwatson> er, 1998
[11:52] <cjwatson> yeah, you compile a logo image into the kernel
[11:52] <cjwatson> (drivers/video/logo/)
[11:53] <apw> a nice purple background perhaps :)
[11:54] <cjwatson> kubuntu's colour scheme is still blue, iirc
[11:54] <cjwatson> anyway, I don't think the fb logo is resolution-scalable
[11:54] <cjwatson> it's just a ppm
[12:04] <tseliot> apw, cjwatson: have you come to a conclusion? (someone shut down my computer here...)
[12:06] <tseliot> i.e. what's the plan?
[12:06] <apw> we're more confused than ever me thinks
[12:13] <tseliot> apw: hehe
[12:15] <cjwatson> apw,tseliot: I guess I'd like to talk about this with Keybuk when he's around.  Maybe we should take this to mail?
[12:15] <apw> cjwatson, sure ok
[12:15] <tseliot> cjwatson: sure
[12:18] <Sarvatt> apw: 10 seconds of black? you mean people actually run KMS without doing a echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash? :)
[12:19] <apw> Sarvatt, what does that do
[12:19] <Sarvatt> loads the drivers and starts plymouth about a second into the boot :)
[12:20] <apw> ahhh
[12:20] <James> Hello
[12:20] <tseliot> Sarvatt: that has drawbacks though
[12:21] <Guest23585> Reading the topic I think im in the wrong place, but, I've just finished porting UBuntu to the iPhone but am having difficulty loading multitouch drivers
[12:21] <tseliot> which is why we don't enable it by default
[12:21] <Sarvatt> yeah it's a  bit racy, about 1/20 boots I get a high res text splash
[12:21] <Guest23585> I've played with xorg.conf but most of the information I've used is fro X86Free
[12:21] <ScottK> pitti: Done.
[12:21] <pitti> ScottK: cheers!
[12:21] <Sarvatt> loads the text splash in plymouth then resizes it to the drmfb
[12:22] <Guest23585> Is there any dependencies fir touchscreen support?>
[12:22] <tseliot> Guest23585: maybe #ubuntu-x is the right chat room
[12:22] <Guest23585> ubuntu-x9;2~?
[12:22] <cjwatson> Sarvatt: it's also a net slowdown
[12:22] <Guest23585> ubuntu-x?
[12:22] <tseliot> Guest23585: yes, the last one
[12:22] <Guest23585> Ok thanks anyway
[12:23] <Sarvatt> weirdly it feels faster because i'm not staring at a ugly screen for 15 seconds on this machine
[12:24] <Sarvatt> i know it sucks because it's shoving the world into the initrd though, just prefer it that way here :)
[12:50] <erle-> hello, guys
[12:50] <erle-> are there any plans to fix the file system layout on amd64 ubuntu
[12:50] <erle-> ?
[12:51] <erle-> it really sucks
[12:51] <erle-> the fedora way is so easy, just let /lib be /lib32, and avery problem of amd64 dissappears
[12:51] <erle-> because you could ad every 32-bit-lib to repo
[12:51] <erle-> without repackaging
[12:51] <cjwatson> https://wiki.ubuntu.com/MultiarchSpec
[12:52] <directhex> erle-, wrong.
[12:52] <erle-> directhex, whats wrong with that?
[12:52] <directhex> erle-, most of it, but in short, it fixes only a tiny tiny number of things, at the cost of patching 18,000 source packages
[12:52] <cjwatson> we've gone over this in a great deal of detail - there's no need to redesign it now.  multiarch just needs to be implemented
[12:53] <erle-> but there is no time to wait
[12:53] <erle-> its a problem to be solved before 32 bit is obsolete
[12:53] <cjwatson> and it will be
[12:53] <erle-> when do you think?
[12:53] <cjwatson> multiarch has been accepted by Debian as the right design as well
[12:54] <erle-> i know that the crappy layout is derived from debian
[12:54] <cjwatson> don't know exactly but we plan to have it before the next LTS
[12:54] <directhex> erle-, lib64 is a leftover from sparc solaris
[12:54] <erle-> hm
[12:54] <erle-> i know
[12:54] <directhex> and until itanium rhel/sles use lib64, i don't take your claims seriously
[12:54] <erle-> thats all obvious
[12:55] <erle-> suse has /lib32 and /lib64 as well
[12:55] <erle-> but /lib points to /lib32
[12:55] <directhex> only on amd64.
[12:55] <directhex> not on all 64-bit arches
[12:55] <erle-> in debian it points to /lib64
[12:55] <directhex> just amd64
[12:55] <erle-> of course
[12:55] <erle-> it only matters, where there are two instructions sets
[12:55] <erle-> in amd64 it really matters
[12:56] <directhex> except itanium can run i386 code too
[12:56] <cjwatson> please read https://wiki.ubuntu.com/MultiarchSpec - it explicitly refutes this
[12:56] <cjwatson> it's tiresome to repeat it
[12:57] <erle-> directhex, but thats software emulated, thats no full support
[12:57] <erle-> and later versions of itanium dont afaik
[12:58] <erle-> cjwatson, i am going to read that
[12:58] <erle-> takes some more time that 1 minute
[12:58] <cjwatson> you could have read it before continuing the conversation; there was no pressure on you to continue it within a minute. :)
[13:01] <erle-> http://www.theregister.co.uk/2001/01/23/benchmarks_itanic_32bit_emulation/
[13:02] <erle-> itanium x86 was dead from the first day
[13:02] <directhex> hands up if you have a production itanium system, and are in a position to comment
[13:03] <ansgar> What are the rdeps of libuuid-perl in Ubuntu? If it includes a standard package, it might be worth syncing the last revision from Debian that replaces the dependency on perl by one on perl-base (see http://bugs.debian.org/588427)
[13:03] <cjwatson> itanium is a bit of a red herring for this anyway.  arm is much more interesting nowadays and there are plenty of specific use cases there for 32-bit-on-32-bit emulation.
[13:03] <cjwatson> ansgar: it's only in desktop, not standard
[13:04] <cjwatson> (and yes, i386-on-arm is software emulation, but so what?  the problems end up being quite similar in practice and they're sufficiently much work to solve each time that we want to solve them once.)
[13:06] <erle-> directhex, does anybody have a itanium system?
[13:06] <erle-> http://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png
[13:07] <cjwatson> forget itanium, it's a bad example for this.
[13:07] <erle-> that what i wanted to point out :D
[13:07] <cjwatson> it doesn't invalidate the design though.
[13:08] <erle-> yeah, i like the design, too
[13:08] <erle-> but thats not my concern here
[13:08] <psurbhi> erle, there is still an existing group doing heavy research on itanium
[13:08] <psurbhi> gelato.org
[13:08] <cjwatson> people have already started work on multiarch; there's a gsoc project in progress at the moment to do the apt side of things
[13:09] <cjwatson> just needs the dpkg side to get done
[13:14] <micahg> does anyone have time to accept a gjs rebuild in lucid-proposed?
[13:17] <cjwatson> persia: any progress on bug 294593?
[13:17] <persia> Uhh, I forgot about it :)  I'll take a look tonight.
[13:18] <cjwatson> thanks
[13:18] <a_ok> can someone help me out with this documentation? https://help.ubuntu.com/community/DisklessUbuntuHowto#Static IP
[13:19] <a_ok> I know I want to configure this but WHERE I might posibly configure this is never mentioned
[13:50] <cjwatson> chrisccoulson: looks like you and Barry were responsible for the libticonv package.  Can you look at the apparently repackaged version now in Debian, and see if we can fakesync it?  (different .orig.tar.gz)
[13:51] <ogra> cjwatson, do you know if foundations currently has a dedicated pulse maintainer now that crimson stopped working on it ?
[13:51] <cjwatson> no
[13:51] <cjwatson> as in, we don't
[13:51] <cjwatson> TheMuso might know
[13:52] <ogra> yeah, got (and expected) that
[14:21] <joaopinto> mvo, do you happen to know if it would be safe to change a  sources.list.d entry on an APT Pre-Invoke Update configuration hook ?
[14:21] <joaopinto> use case: a client side script validating and changing the mirror if required
[14:22] <mvo> joaopinto: that will not work, the sources.list is read/parsed before that hook is called
[14:23] <joaopinto> I was afraid :(
[14:23] <mvo> joaopinto: the mirror method got some improvements recently
[14:23] <mvo> joaopinto: is that not something you could use?
[14:23] <joaopinto> I have played with mirror: a long time ago, need to revisit it
[14:24] <joaopinto> mirror: fetches the archive just once and uses it for all the subsequent transactions, right ?
[14:24] <joaopinto> I mean, the archive url
[14:28] <mvo> joaopinto: yeah, it updates the mirror file on each apt-get update
[14:28] <mvo> joaopinto: and then uses the mirror it gets from that
[14:28] <joaopinto> ok so it's probably the best option
[14:33] <joaopinto> mvo, the mirror list gets cached and will be used if the mirror mehtod url is unavailable during a future cache update ?
[14:35] <joaopinto> just to make sure we don't keep a single point of failure :)
[14:37] <mvo> joaopinto: the mirror list gets cached, yes
[14:38] <chrisccoulson> cjwatson - yeah, i can look at that at some point next week. i'm not working today though
[14:38] <joaopinto> ok, tks :)
[14:40] <ScottK> Urgh.
[14:40] <cjwatson> chrisccoulson: thanks
[14:40] <ScottK> NCommander: mainwindow.cpp:109: internal compiler error: output_operand: invalid expression as operand <-- qt4-x11 on armel.
[14:41] <NCommander> ScottK: ICEs go to doko :-)
[14:41] <ScottK> NCommander: He's not here, so I pass it to you to pass to him.
[14:44] <evdvelde> hi all, i am currently an archlinux user, but thinking to switch to ubuntu. However i love to have the newest software possible, so i was wondering... is ubuntu development version stable enough to use daily?
[14:46] <persia> evdvelde: Depends on the day: the place to ask is #ubuntu+1
[14:47] <kenvandine> cjwatson, we have a rather urgent upload waiting in the unapproved queue for lucid-proposed
[14:47] <kenvandine> cjwatson, think you can take a look at it? it's gwibber
[14:47] <evdvelde> ok thx persia
[14:48] <kenvandine> cjwatson, facebook is throttling all gwibber users, and this fix will greatly reduce the amount of load we put on facebook, so the sooner people start to upgrade it the sooner everyone will start to be able to use facebook again
[14:53] <cjwatson> kenvandine: ouch.  accepted
[14:53] <kenvandine> thank you very much :)
[14:54] <kenvandine> cjwatson, it has been a very painful bug... it is annoying that facebook throttles all gwibber users, not just the ones that are heavy users
[15:35] <zul> cjwatson: i just uploaded a bunch of new landscape-client can we get this accepted into proposed plesae?
[15:36] <cjwatson> zul: not now, have to prepare for the release meeting
[15:36] <cjwatson> sorry
[15:36] <zul> cjwatson: k
[15:36] <cjwatson> pitti: can you look at bug 595650 please?  it's a regression from your libusb upload
[16:00] <cjwatson> seb128: can your team take bug 600194?  it's on our list for the release meeting, but seems desktopish
[16:00] <seb128> cjwatson, yes
[16:00] <seb128> cjwatson, I wanted to work on it anyway since I need to do a gir update for other changes
[16:01] <cjwatson> thanks
[16:01]  * MattJ frowns at dput... it tells me I just uploaded to upload.ubuntu.com successfully
[16:01] <seb128> cjwatson, np
[16:01]  * cjwatson adjusts the agenda
[16:02] <cjwatson> MattJ: the upload will succeed but if you don't have upload permissions then it'll be rejected when the queue runner gets to it
[16:02] <MattJ> Excellent, thanks
[16:02] <ScottK> seb128: What's the url for the desktop team report?  I'll add the Kubuntu stuff to it (Riddell is not available today)
[16:02] <MattJ> I'm kind of surprised that's there's a default upload destination
[16:03] <seb128> ScottK, https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:03] <seb128> ScottK, thanks
[16:03] <ScottK> seb128: Thanks.
[16:27] <ScottK> seb128: What do I need to do to get gtk stuff to use the menubar?  For Qt/KDE stuff it just does.
[16:28] <seb128> ScottK, install appmenu-gtk
[16:28] <seb128> and restart your session
[16:28] <ScottK> seb128: OK.  Thanks.
[16:28]  * ScottK wonders if plasma-widget-menubar should recommend that then...
[16:32] <lag> tkamppeter: ping
[16:33] <smoser> just curious, anyone know why memtest86 would be part of ubuntu-standard ?
[16:34] <lag> pitti: ping
[16:42] <tkamppeter> lag, hi
[16:42] <lag> Oh you are there :)
[16:43] <lag> I wanted to ask you about cups
[16:43] <tkamppeter> lag, then simply ask.
[16:43] <lag> Specifically: modprobe -q -b parport_pc || true
[16:44] <lag> I'm not sure it's such a good idea to be doing modprobes from your scripts
[16:45] <lag> If you modprobe a module for a device which does not exist, it could have dire consequences
[16:45] <tkamppeter> lag, this loads the parport_pc kernel module if it is available and if its requirements (I do not know whether a parport must be actually present) are fulfilled. The " || true" takes care that the script is not aborted if the parport_pc module is not loadable.
[16:46] <tkamppeter> lag, the module is needed to print on parallel printers.
[16:46] <lag> And if a parallel port doesn't exist?
[16:49] <maxb> A package I got a sponsored upload for (subversion in maverick) FTBFS on armel and sparc. What should I do about it? I don't have access to those architectures.
[16:50] <lag> tkamppeter: ?
[16:50] <cjwatson> lag: what dire consequences?  the kernel will give you ENODEV
[16:51] <cjwatson> lag: the kernel isn't that stupid :)
[16:51] <ogra> cjwatson, sadly it is (atm)
[16:51] <cjwatson> not for established devices like parallel ports
[16:51] <ogra> https://bugs.launchpad.net/bugs/601226
[16:51] <ogra> same for parport_pc
[16:52] <ogra> and same for the omap3 kernel
[16:52] <cjwatson> I'm not surprised about problems on arm, but we don't generally have that kind of problem on x86
[16:52] <ion> Thats a bug in the kernel, not in anything that modprobes stuff.
[16:52] <cjwatson> and it's unambiguously a kernel bug, not a cups bug
[16:52] <ogra> agreed
[16:53] <lag> http://paste.ubuntu.com/461186/
[16:53] <ogra> but it doesnt seem so clever to actually hardcode modprobe in the initscript, could that be solved more dynamically
[16:53] <lag> cjwatson: I am in the process of fixing the bug in the kernel
[16:53] <lag> But there are bound to be other problems if modules are loaded willy nilly
[16:53] <lag> Udev should be used instead
[16:54] <lag> Only only loaded if the hardware exists
[16:54] <lag> This will become a problem for x86 also, when they start to remove parallel ports
[16:54] <lag> And only*
[16:54] <ion> They’ve been leaving parallel ports out for a long time from PCs.
[16:55] <ion> s/from/in/
[16:55] <lag> So this will kill every PM without a parallel port running the Maverick rootfs
[16:55] <lag> PC*
[16:56] <lag> There must be a way for you to check if the hardware exists before loading the module (i.e. udev)
[16:57] <cjwatson> lag: loading modules for non-existent devices doesn't usually cause null dereferences in the kernel, and I've never before heard somebody suggest that
[16:57] <cjwatson> parallel ports are often hung off legacy busses that can't be so easily detected
[16:58] <lag> cjwatson: I accept that this is also a kernel failing (as I say, I am in the process of fixing that)
[16:58] <cjwatson> parport_pc is one of those devices we tend to just load because detection is often weak
[16:59] <lag> I still think these scripts should use the functionality provided for extra security
[16:59] <cjwatson> that's the problem, my understanding is that the functionality is not always provided
[17:00] <cjwatson> sure, modern PCI devices and such, that's easy
[17:00] <lag> udev?
[17:00] <lag> Well it must in this case
[17:00] <cjwatson> udev only gets uevents from the kernel if the bus can actually tell you that the device is there
[17:00] <hallyn> cody-somerville: hey, kirkland` suggested you knew a lot about live-helper.  I'm jsut curious what I did wrong:  I did 'lh clean --binary; lh build'.  That ended up trying to rebuild chroot/ (which i didn't think it would), where i had made some customizations, and then failed anyway, trying to stat chroot/boot/vmlinuz-
[17:00] <lag> Correct
[17:01] <hallyn> (now i'm just re-doing a full lh_build, with lh_build hacked to pause while i make my changes between stages :)
[17:01] <hallyn> what was the right way to make a change?  (I wanted to drop in my own initrd.img into chroot/)
[17:01] <cjwatson> but, as far as I can see, only the parport_pc module itself knows how to probe for a PC parallel port
[17:02] <lag> cjwatson: A uevent is not sent in this case
[17:02] <lag> but it is on my PC
[17:02] <lag> Thus, it must be detectable
[17:02] <cjwatson> that depends on how the parallel port is hooked in
[17:02] <lag> Ture
[17:02] <lag> True*
[17:03] <cjwatson> the IRQ probing stuff is not hooked into a MODULE_DEVICE_TABLE
[17:03] <cjwatson> I don't see how uevents for that would ever arrive
[17:03] <cjwatson> sure, if it's on PCI then fine
[17:06] <kees> pitti: sourceful retracing is not working right now?
[17:06] <lag> cjwatson: So your final word is that directly modprobing the module is the best solution
[17:07] <lag> and just hope that it fails sensibly
[17:07] <cjwatson> insofar as I'm authoritative on this, that is my understanding yes
[17:07] <lag> Okay
[17:07] <lag> I'll just fix it :)
[17:08] <ScottK> seb128: Does appmenu-gtk set some magic config option to prevent menus from hiding?  It worked before on my system with the Qt/KDE stuff and now it doesn't.
[17:08] <lag> tkamppeter - cjwatson: Thanks for your time
[17:09] <smoser> cjwatson, how is it that update-grub gets run on kernel installation or removal ? does one have to have that in kernel-img.conf ?
[17:09] <ScottK> jcastro: ^^^ re my question for seb.  Do you know?
[17:09] <seb128> ScottK, yes, it installs a Xsession.d script
[17:09] <seb128> ScottK, edit it and change the 1 to 0
[17:09] <ScottK> seb128: Thanks.
[17:09] <seb128> 80appmenu
[17:09] <seb128> export APPMENU_DISPLAY_BOTH=1
[17:09] <seb128> change that one to 0
[17:10] <seb128> we will turn it to 0 next week probably by default
[17:10] <cjwatson> smoser: yes, right now - there's a Debian bug to use /etc/kernel/postinst.d/ for that instead
[17:11] <smoser> and is that option in kernel-img.conf just written by the installer then ?
[17:13] <jcastro> ScottK: we're shutting that off to be "normal" next week
[17:13] <ogra> smoser, the bootloader part in the installer sets it (based on the bootloader the system uses)
[17:14] <cjwatson> smoser: yes
[17:14] <smoser> ogra, thanks.
[17:14] <ogra> which reminds me i need to remove that stuff for armel
[17:14] <ScottK> jcastro: OK.  It's just a bit unfortunate that it affects the Qt/KDE stuff too, so by intalling the gtk bits, the Qt/KDE bits stop working right.
[17:14] <ogra> since debian moved everything flash-kernel related into update-initramfs
[17:15] <smoser> cjwatson, you did get a mail from me wednesday/thursday, right ? not pestering, just wanted to verify receipt.
[17:15] <jcastro> ScottK: I wasn't aware of that
[17:15] <ScottK> jcastro: Me neither until a few minutes ago.
[17:16] <cjwatson> smoser: yes, sorry, haven't got to it yet
[17:16] <smoser> no problem.
[17:47] <cody-somerville> hallyn, it doesn't actualy rebuild the chroot/ - all the helpers run though but they skip doing anything.
[17:48] <cody-somerville> hallyn, as for the stat chroot/boot/vmlinuz-, thats unfortunately a bug I've ran into as well.
[17:48] <cody-somerville> hallyn, if you have a lot of ram, I suggest doing the build on tmpfs. with a local mirror you can do an entire build of ubuntu-desktop in 10 minutes.
[17:49] <hallyn> cody-somerville: hm, great idea :)  yeah plenty of ram here
[17:49] <hallyn> but the time wasn't the point - i wanted to drop in my own hand-built initrd
[17:49] <hallyn> (to hack up the casper-helper function)
[17:50] <hallyn> but...  it *did* rebuild the chroot/.  it removed it, and rebuilt it.
[17:50] <cody-somerville> the .stage/ files must have been deleted then
[17:51] <cody-somerville> are you sure the entire chroot was rebuilt or are you just guessing?
[17:52] <cody-somerville> cause the stat error only happens when you do lh clean --binary;lh build
[17:52] <ricotz> cjwatson, hi, do you mind increasing the priority a bit for https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9.2/<IP_ADDRESS>+build1+nobinonly-0ubuntu1/+build/1861827 ?
[17:55] <cjwatson> ricotz: done
[17:56] <ricotz> cjwatson, thanks
[17:56] <hallyn> cody-somerville: yeah, after i started 'lh build', chroot/initrd.img was gone (as were most dirs at first)
[17:57] <cody-somerville> hallyn, oh, it stores things in .cache
[17:57] <cody-somerville> hallyn, it goes through the entire process but if something is cached then it uses it instead of doing it
[17:58] <cody-somerville> somethings get done no matter
[17:58] <cody-somerville> like probably rebuilding initrd
[17:59] <dupondje> What do we do with packages that are (wrongly) named in ubuntu and needs to be synced ? Example xfsprogs (3.1.2-1)  => debian, 3.1.2ubuntu1  in ubuntu ...
[18:00] <hallyn> cody-somerville: drat, i was hoping chroot/ got built during 'lh chroot', and 'lh binary' woudl jsut package up the binary from chroot/
[18:00] <BlackZ> dupondje: you should check why there's that number in debian/changelog
[18:00] <hallyn> cody-somerville: ok, thanks, just having lh_build pause between steps is working for me so i'll stick with that - and start using a tmpfs like you suggested
[18:00] <BlackZ> err, version
[18:01] <dupondje> BlackZ: how you mean ? the ubuntu package should be named 3.1.2-0ubuntu1 no ?
[18:01] <BlackZ> dupondje: however if the ubuntu changes are no longer relevant the version number doesn't matter
[18:01] <cjwatson> dupondje: nothing much you can do except make it 3.1.2ubuntu2 in Ubuntu and wait for the next sync
[18:01] <cjwatson> er, the next upstream
[18:01] <dupondje> k :)
[18:01] <cjwatson> BlackZ: you don't understand ...
[18:01] <cjwatson> BlackZ: 3.1.2ubuntu1 > 3.1.2-1, so you can't sync
[18:03] <BlackZ> cjwatson: ah, yeah
[18:03] <cjwatson> it was 3.1.2ubuntu1 because at the time the Debian version was 3.1.2
[18:03] <cjwatson> and 3.1.2-0ubuntu1 would have meant doing a native -> non-native transition in Ubuntu which has its own problems
[18:04] <cjwatson> no good answers when a package is wrongly native in Debian really
[18:09] <dupondje> What group you need to be in launchpad exactly to change bug importance ?
[18:09] <BlackZ> dupondje: for ubuntu bugs, bug control
[18:14] <dupondje> cjwatson: couldn't it be changed that 3.1.2-1 > 3.1.2ubuntu1 ?
[18:15] <cjwatson> dupondje: no
[18:15] <cjwatson> dupondje: do not muck with the versioning algorithm. :)
[18:15] <dupondje> :P
[18:16] <dupondje> better spank the debian maintainter :)
[18:18] <cody-somerville> hallyn, why do you need to do that? live-helper has a mechanism to install files into the chroot and/or binary.
[18:19] <smoser> i'm wanting to have a package install a file in /etc/kernel/postinst.d/ .  As it is, it gets marked as a config file, and left if the package is removed.  As the postinst.d script invokes something from the package, that seems wrong.
[18:20] <smoser> how should I ensure that the file is removed on package uninstall ?
[18:20] <hallyn> cody-somerville: jinkeys, that WAS fast
[18:21] <hallyn> cody-somerville: oh, through lh_config arguments?
[18:21] <hallyn> i'll have to take a look, thanks for the hint
[18:21] <cjwatson> smoser: conffiles are removed on purge rather than on remove; the standard is that they must check whether any file they refer to outside /etc exists.
[18:21] <cjwatson> smoser: you're not allowed to have files in /etc that aren't configuration files
[18:21] <smoser> well, it would seem to me that /etc/kernel/postinst.d goes against that principal
[18:22] <cody-somerville> hallyn, no, you can drop files into chroot_local-includes or binary_local-includes after running lh config
[18:23] <hallyn> cody-somerville: thanks!
[18:23] <cjwatson> smoser: same principle as init scripts
[18:23] <smoser> so you're suggesting '[ -x /path/of/script ] || exit 0' ? I was using initramfs tools as an example, which puts files into the postinst.d, and invokes update-initramfs. it doesn't check, so that would be a bug, right ?
[18:24] <cjwatson> minor bug in the case of initramfs-tools because the kernel depends on initramfs-tools so it's impossible for it not to be installed while running postinst.d
[18:25] <cjwatson> /etc/kernel/postinst.d/dkms checks -x
[18:25] <smoser> thanks cjwatson
[18:33] <cjwatson> top tip: it helps if you install the version of the package you're trying to test
[18:33] <Luke> does anyone know the difference between the indicate and appindicator modules in python for the indicator-applet stuff?
[18:34] <Luke> oh i see i'm in the wrong channel
[18:40] <ricotz> chrisccoulson, hello, will there be thunderbird "3.1.1 build1" in maverick? that would be nice
[18:41] <cjwatson> SpamapS: any reason you reopened bug 603363?
[18:46] <cjwatson> SpamapS: I've reclosed it
[18:46] <SpamapS> cjwatson: doh, I didn't refresh ;)
[18:47] <SpamapS> cjwatson: the ajax code should flag any clicks that come from a page generated more than 2 hours ago. ;)
[18:47] <SpamapS> cjwatson: apologies for the confusion. Thanks for fixing that. ;)
[18:49] <cjwatson> ideally the ajax code should have some kind of way to spot mid-air collisions in general
[18:49] <cjwatson> it's doing a transaction with the server, after all
[18:53] <SpamapS> cjwatson: couchdb does this brilliantly, by assigning every record a generation, allowing developers to simply include that in all communications to the backend, and tell the user "you changed a document that has changed since you read it"
[18:53] <cjwatson> indeed
[19:07] <ScottK> jcastro: What's a gtk app the works the the appmenu stuff?
[19:08] <jcastro> gimp
[19:08] <jcastro> rhythmbox
[19:08] <ScottK> jcastro: Thanks.
[19:09] <jcastro> ScottK: anything but FF/ooo/chromium should work
[19:09] <ScottK> jcastro: Guess which gtk apps I regularly use?
[19:09] <jcastro> 0?
[19:09] <ScottK> FF, OOo, and Chromium.
[19:09] <ScottK> I'll try gimp.  I at least have that installed.
[19:10] <jcastro> I just triggered a crash with it in gimp fyi, apported it
[19:10] <njin> Hello, everybody
[19:11] <ScottK> jcastro: Doesn't seem to work with the Qt/KDE appmenu.  I did install the packages seb said I needed.
[19:11] <jcastro> that should work
[19:12] <ScottK> It may be my fault.
[19:12] <njin> I'm installing today's build Alternate amd64 but it failed cause unmert dependencies of imagemagick, it' a work in progres ?
[19:12] <ScottK> jcastro: The Qt/KDE thing didn't work at all with the Xsession script, not even with  APPMENU_DISPLAY_BOTH=0, so I removed the script.  That was probably overkill.
[19:13] <ScottK> I'll play with it some more over the weekend.
[19:13] <jcastro> ScottK: I'll have agateau and ted/cody in the same room in 2 weeks
[19:13] <ScottK> Excellent.
[19:14] <jcastro> ScottK: if you file bugs just toss the "app-menu" tag on em
[19:14] <ScottK> I will.  jcastro: You might want to subscribe to bugs for the plasma-widget-appmenu package as it's ALL appmenu stuff by defintion.
[19:15] <jcastro> good idea
[19:34] <jussi> cjwatson: you about?
[19:35]  * jussi forgets cjwatson's tz.
[19:35] <jussi> anyway, anyone who knows, its rather frustrating that both the kubuntu and ubuntu maverick images are named exactly the same.
[19:35] <jussi> perhaps we could get that changed??
[19:40] <SpamapS> So ideally /win 10
[19:40] <SpamapS> dooh
[19:46] <zul> SpamapS: dude....hah
[19:51] <ScottK> jcastro: I got it working in both.  In gtk it wants export APPMENU_DISPLAY_BOTH=0 to not double the menus.   If that environment variable exists at all, then the Qt/KDE version will show double menus.  To get it working for both, you need to just remove that line from the script.
[19:52] <ScottK> seb128: ^^^ - When you get rid of the double windows, would you please just remove export APPMENU_DISPLAY_BOTH=1 from the Xsession script instead of setting it to zero?
[20:39] <ScottK> jcastro: http://skitterman.wordpress.com/2010/07/09/menubar-for-gtk-and-qtkde-apps-on-kubuntu/
[21:02] <tumbleweed> what's the development process for ubuntu-dev-tools? commit to trunk or merge review?
[21:06] <ScottK> tumbleweed: Commit to trunk if you're an ubuntu-dev.  Merge review otherwise.
[21:06] <tumbleweed> ScottK: cool. I have some ack-sync fixes
[22:51] <jazzanova> hi
[22:51] <jazzanova> I plug in usb headset, and the machine freezes:  10.4
[22:54] <ScottK> jazzanova: #ubuntu.
[22:54] <jazzanova> too busy there, those guy are not helpful
[23:11] <veleno> hello. i'm following this guide http://blog.petersen.vg/post/237815372/debfile to build a deb. How do I do to install some files in the home directory of the user, instead of putting them in /usr/lib ?
[23:12] <soren> Wow. There are so many things wrong with that article.
[23:12] <veleno> soren: please point me to a more correct one
[23:13] <siretart> veleno: don't. you cannot rely that a home is writeable or even existant at all.
[23:13] <siretart> +on
[23:15] <soren> veleno: All I know is the Ubuntu packaging guide, but that's probably not what you need.


[05:52] <rick_h__> morning
[06:07] <huwshimi> rick_h__: Morning
[06:14] <rick_h__> huwshimi: hey, funny running into you there
[06:14] <huwshimi> rick_h__: Yeah, strange to see you at this time :)
[06:14] <huwshimi> rick_h__: How was the travel?
[06:17] <rick_h__> huwshimi: you know, time in a tin can flying through the sky
[06:17] <huwshimi> hehe
[06:17] <rick_h__> working on catching up on sleep
[07:10] <rogpeppe> mornin' all
[07:14] <huwshimi> Morning
[07:21] <urulama> morning all
[07:35] <rogpeppe> urulama: hiya
[13:19] <rogpeppe>  anyone with good http-fu know what's going on at line 1503 here? http://golang.org/src/pkg/net/http/server.go#L1503
[14:45] <jcsackett> Makyo: do you know if a unit would ever *not* have a state outside of being uncommitted?
[14:46] <Makyo> jcsackett, units should always have a state, I believe.  Is something going wrong?
[14:46] <jcsackett> Makyo: no, not at all. that's a good answer. :)
[14:46] <jcsackett> uncommitted units don't have agent_state, which makes sense.
[14:46] <rogpeppe> urulama, jrwren: https://github.com/juju/charmstore/pull/52
[14:47] <jcsackett> the QA issue you found was b/c the condition for identifying uncommitted units isn't correct once the service is deployed.
[14:47] <rogpeppe> anyone know if frankban is around today?
[14:47] <jcsackett> but since they don't have state, we can use that.
[14:47] <jcsackett> and that's always accurate.
[14:47] <rogpeppe> or bac
[14:47] <Makyo> rogpeppe, frankban is out today on swap.
[14:47] <rogpeppe> Makyo: ah, thanks
[14:47] <Makyo> jcsackett, ah, yeah, that makes sense
[14:48] <jcsackett> rogpeppe: bac is in nuremburg.
[14:48] <Makyo> Boo, forgot about that.,
[14:48] <Makyo> CI doesn't seem to be working for me.
[14:48] <rogpeppe> jcsackett: ah, i'd forgotten about that
[14:48] <Makyo> Maybe jenkins needs a kick in the pants
[14:49] <rogpeppe> i guess i'm just not gonna land anything today
[14:49]  * rogpeppe goes to the pub :-)
[14:50]  * jcsackett laughs
[14:50] <jcsackett> rogpeppe: starved for reviews, or jenkins issues?
[14:50] <rogpeppe> jcsackett: reviews
[14:51] <rogpeppe> jcsackett: i think there's only one person around ( jrwren ) that can review the code, but i need two reviews for landing
[14:52] <jcsackett> rogpeppe: can Makyo or hatch sub in for today, or do you need deep knowledge of the code base? they're both go-literate, if memory serves.
[14:52] <jcsackett> (it's not ideal, but better than blocking)
[14:54] <Makyo> jujugui call in 6
[14:55] <urulama> rogpeppe: i'll try to do it
[14:55] <urulama> rogpeppe: but it's a huge one and with interruptions, it might take a while :)
[14:55] <rogpeppe> urulama: if you could, that would be great. unfortunately, it's a bit of a bad of bits.
[14:56] <rogpeppe> perhaps i should try to split it up
[14:56] <rogpeppe> anyone know of a good tool for splitting up branches?
[14:57]  * urulama suggests an axe
[14:57] <rogpeppe> lol
[15:00] <Makyo> jujugui call now.
[15:18] <jrwren> http://ci.jujugui.org:8080 its up
[15:18] <jrwren> I have no answers for why it wasn't up.
[15:19] <Makyo> jrwren, awesome, thanks
[15:34] <kadams54> jcsackett: finished QAing your PR
[15:35] <kadams54> Makyo: you mentioned running debug logging while setting the juju-gui-source… how do I do that?
[15:35] <Makyo> juju debug-log
[15:38] <kadams54> This is what I get: http://pastie.org/private/8kodvcgaorziu7fq9evxa
[15:39] <kadams54> Seems to be an error right off the bat, maybe in fetching the new source from git?
[15:44] <kadams54> guihelp: ^
[15:45] <jcsackett> kadams54: thanks.
[16:08] <rick_h__> hey all, anyone know what's the status of hatch's card and potential gui release?
[16:09] <rick_h__> jujugui ^
[16:14] <Makyo> rick_h__, working on QAing now, then checking on some problems with the charm, then I'll see about starting release prep.
[16:14] <rick_h__> Makyo: awesome thanks.
[16:14] <rick_h__> Makyo: what's up with the charm?
[16:15] <urulama> rogpeppe: i've looked your PR ... it's huge, for last parts /v4/stats.go and stats_test.go i need more time ...
[16:16] <Makyo> rick_h__, some folks are having trouble setting juju-gui-source - looks like it fails to start back up.
[16:16] <Makyo> Going to research that.
[16:16] <rogpeppe> urulama: yes, i'm sorry about that
[16:16] <rogpeppe> urulama: i fixed lots of things in an organic way when trying to make the tests pass
[16:16] <rick_h__> Makyo: note that only works in trusty and not precise due to git changes
[16:16] <urulama> rogpeppe: yes, that's what i'm worried about
[16:17] <urulama> need to go to dinner
[16:17] <rogpeppe> urulama: i could spend a few hours splitting it up
[16:18] <Makyo> rick_h__, Aha! Good to note.  kadams54 ^
[16:19] <rick_h__> Makyo: yea, would love to get details on the series and the string used for that field to make sure it's supposed to work
[16:19] <rick_h__> Makyo: so trusty + 'develop' should be trunk and be good to test with
[16:19] <rick_h__> and should come up, if not there's a log file to check in /var/log/juju/all-?
[17:16] <kadams54> rick_h__, Makyo: alas, I'm in trusty.
[17:16] <kadams54> I didn't see anything obvious in the all-machines.log file, but I'm going to give it another go, this time tailing both that and running debug-log
[17:20]  * rogpeppe is done for the day
[17:20] <rogpeppe> g'night all
[17:38] <Makyo> Can't seem to deploy the charm at all, hmm.
[17:40] <kadams54> rick_h__, Makyo: And of course, this time, it appears to have worked for me. FWIW, I confirmed that my card, bug #1341653, seems to be fixed.
[17:40] <Makyo> kadams54, Woo!
[17:40] <Makyo> I might be running into a juju bug, not sure.  Trying on other computer.
[17:42] <kadams54> I'm going to see if I can clear a few more cards out of the QA queue.
[17:51] <Makyo> Yeah, seems to be something weird going on in tip, up and QAing juju-gui-source now.
[18:09] <hatch> Makyo juju-core is failing CI atm so you'd best to use a stable release
[18:09] <Makyo> hatch, so I found.
[18:09] <Makyo> Now go back to not working.
[18:10] <Makyo> It's a holiday :)
[18:10] <hatch> haha I am not working :) I have to do html's and css's for my dads website....bleh, I wonder if I could convince huw to do this for me lol
[18:10] <hatch> right Monday Holiday
[18:10] <kadams54> Provincial Day!
[18:10] <tvansteenburgh> anyone in here familiar with the charmhelpers.contrib.jujugui python module?
[18:11] <hatch> jujugui https://twitter.com/FromAnEgg/status/496158671710466049 hahaha
[18:11] <tvansteenburgh> i have a MR to remove it, wondering if anyone here cares
[18:11] <hatch> tvansteenburgh I've never even heard of it :) what does it do?
[18:12] <tvansteenburgh> nothing any more! muwhahaha
[18:12] <hatch> lol w00t
[21:09] <urulama> hi there, jujugui
[21:10]  * urulama hears pings go all over the world ;)
[21:10] <hatch> haha hey urulama how goes ze Germans?
[21:10] <hatch> (little Top Gear reference there)
[21:11] <urulama> ze Germanz are fine ... at least their bear and pork products are ;)
[21:11] <urulama> s/bear/beer
[21:12]  * urulama now wonders what a bear tastes like
[21:12] <hatch> haha
[21:12] <hatch> tastes pretty gamey
[21:12] <urulama> you had one?
[21:12] <hatch> of course
[21:12] <hatch> elk deer, etc etc
[21:13] <hatch> I live in the North remember
[21:13] <hatch> north of the wall ;)
[21:13] <urulama> survival of the fittest :)
[21:14] <urulama> i had deer and boar and whatnot, but not bears ... and we have a lot of them, just not allowed to eat them
[21:14] <urulama> so how's it going? CI working now?
[21:15] <hatch> no idea, I'm off today
[21:15]  * kadams54 is going to start referring to hatch at "that wilder".
[21:16] <rick_h__> howdy all
[21:16] <kadams54> urulama: I just landed a branch for juju-gui, so that CI seems to be working
[21:16] <kadams54> rick_h__: hey there
[21:17] <urulama> hatch: remember the talk about being away from computer ... now's probably the time then :)
[21:18] <urulama> kadams54: ok, good news
[21:19] <rick_h__> Makyo: issues? no release it sounds like?
[21:20] <hatch> hey rick_h__
[21:21] <hatch> urulama haha, I'm sitting in the back yard on the swingy chair with a beer working on my dads website.....it's pretty day-ofish :)
[21:21] <rick_h__> hey hatch
[21:35] <Makyo> rick_h__, I think release is a go, pulling together changelog now.  May actually go out tomorrow.
[21:35] <Makyo> (was on the patio, sorry)
[22:15] <hatch> to submit forms on this vps I have to write a PHP script....
[22:16] <hatch> I don't even think I remember how to write a form submission script in PHP any longer lol
[22:17] <hatch> I can't even write it in python....
[22:17] <hatch> what kind of vps restricts to ONLY php
[22:17] <hatch> haha
[22:38] <Makyo> Someone landed a branch while I was writing the change log and now there's a conflict >:/
[23:02] <huwshimi> Morning
[23:24] <huwshimi> hatch: Morning, in a test I have a beforeEach that sets "placeUnit: utils.makeStubFunction()". How would I go about having one test that has the real function there?
[23:24] <Makyo> jujugui GUI release is done.  Going to get dinner prepped, then work on charm release.
[23:24] <huwshimi> Makyo: Yay!
[23:25] <Makyo> On going through the change log, decided on 1.1.1, since much of our work was done behind a feature flag meant for a larger release.
[23:25] <hatch> huwshimi have a code sample? From that one there it looks like you're just passing in a fake stub not the actual ecs object?
[23:25] <hatch> Makyo +1 Thanks for doing the release!
[23:26] <huwshimi> hatch: Yeah, so it's stubbed out for all the tests, but it one test I don't want to stub it out...
[23:26] <hatch> huwshimi well it looks like your not stubbing it out but passing a mock ecs in?
[23:27] <huwshimi> hatch: https://github.com/juju/juju-gui/blob/develop/test/test_machine_view_panel.js#L223
[23:28] <hatch> huwshimi ok yeah you're passing a mock in, you'll need to set the ecs to a real ecs object if you want to use the real placeUnit
[23:28] <huwshimi> hatch: Ah ok, so any ideas on how to do that?
[23:28] <huwshimi> Do we do this anywhere else?
[23:28] <hatch> you can't really 'just' use placeUnit because it relies on the ecs instance in a lot of places
[23:28] <hatch> well what are you testing?
[23:29] <huwshimi> hatch: OK, so I'm trying to test that a container token is created when placeUnit occurs
[23:30] <huwshimi> I'll push up my code
[23:31] <hatch> well you don't really need to do that
[23:31] <hatch> you just need to test that placeUnit is called with the proper data
[23:31] <hatch> then there should be a test which takes said data and makes sure placeUnit does the proper stuff with it
[23:31] <hatch> ^ huwshimi