[01:53] <TheMuso> dtchen: given the upstart stuff you tried to sort out for alsa-utils, do youf irstly mind if I do that merge, and secondly, do you want me to include those upstart changes you made in the update?
[02:19] <slangasek> pitti, cjwatson: a little present for you in the -proposed queue (gdm+xorg)
[02:26]  * cjwatson looks
[02:27] <cjwatson> slangasek: could you look at lilo-installer in hardy-proposed for me, in return? :)
[02:28] <cjwatson> slangasek: we don't want to use a respawn limit instead? I thought historically we made the sketchy assumption that gdm might do better a second time, or something
[02:30] <cjwatson> oh, it respawns itself on a crashing X server
[02:32] <cjwatson> slangasek: where does EXIT_STATUS come from?
[02:33] <cjwatson> ha, undocumented upstart feature
[02:33] <cjwatson> oh, just not documented in init(5), but stopped(7)
[02:33] <cjwatson> slangasek: what if gdm was killed by a signal (other than the usual termination signals - e.g. SEGV)?
[02:58] <m4t> i was wondering earlier, where the .04 and .10 versioning scheme comes from?
[02:58] <lifeless> months of the year
[02:58] <m4t> oh ;-)
[02:58] <wgrant> 9.04 == April 2009
[02:58] <m4t> thanks
[03:27] <slangasek> cjwatson: lilo-installer> ack, looking :)
[03:29] <slangasek> cjwatson: haven't looked in detail at signal handling; I can dig into that further if you wish, but the major problem is gdm exiting on its own, and I think this upload is a marked improvement regardless of how it handles signals
[03:29] <slangasek> cjwatson: btw, I noticed after upload that bryce also had a 7.1 upload to -updates, so I rejected my own ubuntu8 - bryce has merged the two and uploaded ubuntu9
[03:34] <dtchen> TheMuso: I don't mind, and I would like that bit merged, yes.
[03:36] <TheMuso> dtchen: ok will do, thanks.
[03:38] <dtchen> TheMuso: great, thanks
[03:39] <ebroder> dtchen: Can you take a look at bug #330766?
[05:03] <cjwatson> slangasek: I think it would be worth checking into signal handling some more, yes, but I agree that it makes sense to accept this in the meantime, and have done so
[05:03] <cjwatson> slangasek: are any corresponding changes needed to kdm?
[05:05] <slangasek> cjwatson: bulletproof-x only ever hooked into gdm... we could do kdm as well, but that would involve quite a bit of fiddling and is probably not a good idea for SRU
[05:05] <slangasek> thanks for the accept :)
[05:42] <m4t> anyone familiar with getting grub2 to boot openbsd and the like?
[05:42] <m4t> i thought a simple chainloader +1 should suffice
[06:16] <cjwatson> slangasek: ok, I wasn't sure if kdm had hooks or not
[06:17] <cjwatson> m4t: not familiar with BSD, but I know that GRUB2 has explicit commands for it, which rather suggests to me that chainloader is not sufficient
[06:19] <cjwatson> m4t: you might try 'help openbsd' in the GRUB shell
[06:20] <cjwatson> (it'll change to 'kopenbsd' in the future to denote that it's for the openbsd kernel specifically
[06:20] <lifeless> cjwatson: is grub2 nice?
[06:21] <cjwatson> ask a more meaningful question :) I like it, personally
[06:21] <cjwatson> much nicer to hack on than grub legacy was
[06:22] <slangasek> and some day it will free us from menu.lst
[06:22] <lifeless> cjwatson: I considered the question carefully :) - and cool
[06:22] <lifeless> slangasek: orly? speaking of menu.lst...
[06:22] <lifeless> do we know the cause of the missing entries yet?
[06:22] <cjwatson> some day> I believe the only remaining blocker is sorting out reliable disk identification
[06:22] <cjwatson> which I've asked Robbie to allocate me a work item for for lucid
[06:23] <cjwatson> (have already designed it, but regrettably ran out of time in karmic)
[06:24] <slangasek> lifeless: I'm attributing it to the unexplained causality bubble that follows you around
[06:24] <slangasek> because nobody could reproduce it on a fresh install
[06:24] <lifeless> slangasek: and yet, many folk have this problem :)
[06:24] <lifeless> slangasek: did the testers try manual partitioning?
[06:25] <cjwatson> many folk have a problem with the same symptom
[06:25] <slangasek> really?  you're the only one who's been confirmed to have /this/ problem
[06:25] <lifeless> cjwatson: true
[06:25] <cjwatson> lifeless: did you already attach your installer syslog to a bug?
[06:25] <lifeless> cjwatson: yes
[06:25] <cjwatson> oh yes, I think I looked at it and it was inconclusive
[06:25] <slangasek> long term, though, grub2 ought to hook into /etc/kernel/p*.d/ and sidestep this
[06:25] <cjwatson> I know for a fact that manual partitioning is not fucked in this way, in general
[06:25] <slangasek> (there's a bug just opened on the Debian package about that, in fact)
[06:26] <cjwatson> this is not to say that there are not specific problems
[06:26] <cjwatson> but it doesn't pay to overgeneralise
[06:26] <cjwatson> the only cause I can think of for update-grub not getting hooked properly would be the installer crashing before it gets to the end of grub-installer
[06:27] <cjwatson> sometimes people miss the fact that the installer crashed, assisted by the installer not always being terribly clear about the fact that it crashed
[06:27] <cjwatson> so they end up continuing to run semi-busted systems
[06:27] <lifeless> cjwatson: thats entirely possible
[06:27] <lifeless> ok, so I generalised too early I think.
[06:27] <cjwatson> you might be able to notice this by the fact that, in this scenario, the ubiquity package would be installed on the installed system
[06:27] <cjwatson> is/was this the case?
[06:28] <lifeless> dpkg -l ubiquity -> <none>
[06:28] <lifeless> I haven't been on a cleanup crusade that I remember
[06:28] <cjwatson> the weird bit was that I didn't see any definite indication in your log that grub-installer *had* run properly
[06:29] <cjwatson> but I'm travelling this week so only had about 30 seconds for analysis
[06:29] <lifeless> its : purge ok not-installed in initital-status.gz
[06:29] <cjwatson> that's fairly indicative
[06:29] <cjwatson> indeed the fact that you have initial-status.gz at all is a good indication that installation completed successfully
[06:30] <lifeless> so, other than I had to manual partition (dmraid system) I don't recall any oddities about the install
[06:30] <cjwatson> I wonder if something broke kernel-img.conf later, then
[06:30] <lifeless> and by manual partition I mean configure dmraid, then run ubiquity and clicky-clicky config the partitions on the dmraid device
[06:31] <cjwatson> sure
[06:31] <cjwatson> (no longer necessary in karmic)
[06:31] <lifeless> cjwatson: datestamp on kernel-img.conf is 2009-04-21 00:01
[06:31] <lifeless> which is, I think the cd timestamp - there are other directories and stuff in /etc with the same
[06:32] <cjwatson> it ought to be installation timestamp not cd timestamp
[06:32] <cjwatson> what's your bug unumber?
[06:32] <lifeless> I installed the machine fresh with jaunty
[06:32] <lifeless> one sec
[06:34] <lifeless> bug 470265
[06:38] <cjwatson> I don't see it running grub-installer at all there
[06:39] <lifeless> that would explain the hook not being present
[06:39] <lifeless> OTOH
[06:39] <lifeless> how come I can boot?
[06:40] <cjwatson> you clearly have a bootloader installed, but that doesn't necessarily mean your new installation put it there
[06:40] <cjwatson> new> the jaunty one I mean
[06:40] <lifeless> thats true
[06:40] <lifeless> so I bought the machine new
[06:41] <cjwatson> did you do anything in the advanced dialog in ubiquity, like uncheck the "install grub" box?
[06:41] <cjwatson> and install a bootloader by hand?
[06:41] <lifeless> I don't recall going into the advanced dialog
[06:41] <cjwatson> that's the only way I can see how this log could have happened
[06:41] <lifeless> does ubiquity journal the options?
[06:42] <lifeless> if install-grub is off, is the grub package still installed ?
[06:42] <cjwatson> unfortunately not
[06:42] <lifeless> cool
[06:42] <cjwatson> quite possibly, copied from the live filesystem
[06:42] <lifeless> so if I have grub, and didn't manually install it?
[06:43] <cjwatson> the reason I think you unchecked the option is that the characteristic mount pattern in configure_bootloader is missing
[06:43] <cjwatson> grub is unconditionally kept installed regardless of that option, but it isn't necessarily installed *as a bootloader*
[06:43] <lifeless> right
[06:44] <lifeless> I grok the difference :)
[06:44] <cjwatson> in jaunty, you may well have had to do something like this to make things work with dmraid
[06:44] <lifeless> I don't trust my memory of an install 4 months back :(
[06:44] <lifeless> ok, so we should close this bug - its not representative I guess?
[06:45] <cjwatson> please don't close it
[06:45] <cjwatson> I'm attempting to analyse the cause, not apportioning blame
[06:45] <cjwatson> even unrepresentative bugs shouldn't necessarily be closed :)
[06:46] <lifeless> cjwatson: I get that, but if the cause is 'the user chose not to have grub installed' ? :)
[06:46] <cjwatson> but then you chose to use it later, and that wasn't handled correctly
[06:46] <lifeless> cjwatson: and as grub2 will be less fragile in having the right setting in the hook
[06:46] <cjwatson> it's still a bug
[06:46] <lifeless> k
[06:46] <lifeless> I apply a similar analysis to bzr bugs, was really just asking what you wanted
[06:46] <cjwatson> I don't think that grub2 is less fragile in this particular way (kernel-img.conf), although it is less fragile than others
[06:47] <m4t> cjwatson thanks, uhm, grub shell...is there a grub shell with grub2?
[06:47] <cjwatson> s/than/in/
[06:47] <cjwatson> m4t: the command line when you boot
[06:47] <m4t> ah yea.
[06:47] <cjwatson> press c at thee menu
[06:47] <cjwatson> slangasek: is lifeless about the only person who has update-grub just plain missing from kernel-img.conf?
[06:48] <m4t> ehm maybe i am just silly
[06:48] <m4t> # For booting OpenBSD
[06:48] <m4t> menuentry "OpenBSD" {
[06:48] <m4t>         set root=(hd0,1,a)
[06:48] <m4t>         openbsd /bsd
[06:48] <m4t> }
[06:48] <m4t> from docs/grub.cfg in the latest grub2 source
[06:48] <cjwatson> I'm wondering if a useful workaround would be to have the kernel packaging explicitly call update-grub if it notices /boot/grub/{menu.lst,grub.cfg} and update-grub isn't in postinst_hook
[06:48] <m4t> what gets me, though...
[06:48] <m4t> is why openbsd refuses to install its second stage loader in the openbsd partition
[06:48] <m4t> slight off-topic but #openbsd doesnt seem very responsive
[06:48] <m4t> let me try with this
[06:48] <cjwatson> afraid I don't know
[06:48] <m4t> (did grep  -ri on the grub2 source)
[06:49] <m4t> er
[06:49] <m4t> grub -ri openbsd
[06:49] <m4t> heh
[06:49] <cjwatson> please don't use the enter key as punctuation. :)
[06:50] <lifeless> cjwatson: so, perhaps fixing the postinst_hook if the grub package is installed and /boot/grub/menu,cfg are  present ?
[06:50] <cjwatson> your menuentry stanza matches the one in up-to-date grub trunk, so I'm afraid I don't know more ...
[06:50] <cjwatson> lifeless: or just doing the right thing regardless of the dodgy hook thing
[06:50] <cjwatson> which was (frankly) never a particularly sane design
[06:50] <lifeless> cjwatson: or using a dpkg trigger and doing the right thing?
[06:51] <cjwatson> I don't know whether triggers are the right thing long-term, but I would rather not introduce them in an SRU
[06:51] <lifeless> calling update-grub from a new spot might be a problem too
[06:52] <cjwatson> this wouldn't be a new spot, really - just do it alongside where it already processes postinst_hook
[06:52] <cjwatson> it's new code, but fewer moving parts
[06:52] <cjwatson> triggers are cool but they can have some slightly weird consequences sometimes :)
[07:08] <Vkontakte> A lot of free mp3 and video clips. Other pages in social networks "Vkontakte" www.vk.com/reg4286668 and invite your friends!
[07:29] <NCommander> superm1, yay for IRC ping-pong :-/. I completely missed your earlier ping
[07:34] <AnAnt> Hello, will Source format "3.0 (quilt)" be allowed in lucid ?
[07:37] <cjwatson> AnAnt: probably, but not for a little while yet
[07:46] <hyperair> hello. who handles hal here?
[07:47] <dholbach> good morning
[07:49] <hyperair> hal stops and doesn't restart when udev is restarted.. hmm
[07:52] <hyperair> how does upstart handle "and" and "or" for events?
[07:52] <hyperair> does it remember when one event is fired, or what?
[07:53] <AnAnt> ok
[07:54] <mdke> we've had a lot of bugs lately being filed on ubuntu-docs which are nothing to do with documentation. I'd like to understand why they end up there instead of just without a package allocated. They all say "Binary package hint: ubuntu-docs" at the beginning - does that suggest any explanation to anyone?
[07:54] <hyperair> ubuntu-bug ubuntu-docs, perhaps?
[07:56] <mdke> hyperair: I suppose it could be, but I don't see why a user would type that if they have a problem which is nothing to do with docs
[07:56] <mdke> I'm wondering if Launchpad is suggesting the package or something
[07:57] <hyperair> agreed =\
[08:00] <cjwatson> they type 'ubuntu' and it's early in the list?
[08:03] <hyperair> heh
[08:04] <hyperair> does launchpad understand the concept of binary packages when it comes to bugs?
[08:04] <hyperair> i mean you don't see a launchpad.net/ubuntu/+binary/<pkg> do you?
[08:04] <cjwatson> only in that it can map binary to source when you type a binary package name in the "affected package box
[08:05] <soren> If you just type "ubuntu" in the search field, it'll tell you there's too many matches.
[08:08] <hyperair> ah
[08:11] <mdke> hmm
[08:13] <mdke> a mystery I guess
[08:15] <hyperair> you could ask one of the bug reporters how they reported it
[08:15] <hyperair> =p
[08:19] <mdke> hyperair: occasionally we do but it's never yielded any results
[08:19] <hyperair> heh
[08:19] <hyperair> another one of those kinds of mysteries eh
[08:19] <hyperair> at one point of time, #ubuntu-sg was getting a lot of people connecting to it from US, UK among other faraway places
[08:20] <hyperair> they'd connect when everyone was sleeping, start kicking up a big fuss about how nobody's around to help them and leave before anyone woke up =.=
[08:29] <pitti> Good morning
[08:29] <pitti> kirkland: hi
[08:30] <pitti> kirkland: will process SRUs this morning (as every morning, afternoon, and evening nowadays :) )
[08:38] <pitti> ttx: any chance to give euca some testing with the packages in -proposed? (see bug 461090)
[08:38] <pitti> ttx: I'll also do a binary debdiff to ensure that the only thing that changed is the added .pom files; but better be double-sure..
[08:39] <ttx> pitti: sure
[08:39] <ttx> pitti: I need to purge my inbox first, but i'll update my setup to -proposed and run a few tests soon
[08:40] <pitti> ttx: merci beaucoup!
[08:40] <ttx> pitti: bitte
[08:51] <slangasek> cjwatson: lifeless is the only one w/ a botched kernel-img.conf missing that I've run across /so far/.
[09:14] <pitti> argh, LP offline
[09:15] <seb128> pitti, hey, same here
[09:15] <seb128> I could have slept an extra hour ;-)
[09:18] <seb128> weird, I didn't read any mailing list announce about it
[09:20] <pitti> seb128: there was one yesterday
[09:20] <pitti> wgrant: FYI, something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538679#10 is now sent to quite a lot of packages, so I think we won't get around having dpkg-3.0 in lucid :-(
[09:21] <wgrant> pitti: We certainly won't get around it for Lucid.
[09:22] <wgrant> pitti: The thing in question is whether we can get away without it until 2009-12-05.
[09:22]  * wgrant checks the rate of 3.0 migration.
[09:22] <seb128> wgrant, what is special at this date?
[09:23] <siretart`> next scheduled lp rollout?
[09:23] <wgrant> seb128: LP 3.1.11.
[09:24] <seb128> oh ok
[09:24] <wgrant> We have the option of cherrypicking before then though, since the DB changes slipped into 3.1.10.
[09:52] <Phurl> hi all, I would like to help with these new problems of the upgrade
[09:52] <Phurl> I am a developer, and can do all types of things.
[09:53] <Phurl> right now I have upgraded my ubuntu from 8.4 over the months
[09:53] <Phurl> and the sound and netowork stopped working
[09:53] <Phurl> is there anything that I can do to fix this?
[10:03] <Phurl> ok well i will file a bug report
[10:25] <AnAnt> Hello, is it possible to build a Source format "3.0 (quilt)" package on my karmic installation ?
[10:25] <AnAnt> using pbuilder that is
[10:30] <slangasek> AnAnt: the dpkg in karmic supports it if you pass some magic options (which I don't know offhand); Launchpad won't currently accept any such packages though, FWIW
[10:30] <slangasek> Phurl: filing a bug report sounds like a good idea there
[10:31] <Phurl> ok
[10:32] <wgrant> It shouldn't need magic options besides the existence of debian/source/format.
[10:33] <slangasek> oh, well, that's magic enough :)
[10:35] <AnAnt> wgrant: so, does one still need to put quilt in build-deps ?
[10:35] <AnAnt> if he is using quilt patch system that is
[10:44]  * StevenK blinks at why his shiny new Dell doesn't want to talk via Ethernet
[11:06] <StevenK> pitti: Oh, I wanted to talk to you about one of your specs?
[11:06] <pitti> StevenK: please do :)
[11:07] <StevenK> pitti: You subscribed me to the UNR session one so that desktop people could try it?
[11:07] <StevenK> pitti: I was wondering if we could also do it the other way -- if the UNR session was the default for UNR images, but people could choose a desktop session too
[11:16] <StevenK> Oh, duh. Don't play with Jockey when apitude is installing stuff
[11:16] <StevenK> pitti: But Jockey could give a better error than "installArchives() failed"
[11:18] <pitti> StevenK: that should be easy as well
[11:18] <StevenK> pitti: If you're happy to cover that in the spec, then that is one less I have to write :-)
[11:18] <pitti> StevenK: sorry, had a DSL reconnect; I got your "Oh, duh...", but not anything before that
[11:18] <StevenK> [22:07] < StevenK> pitti: You subscribed me to the UNR session one so that desktop people could try it?
[11:18] <pitti> StevenK: it'd be a separate package though, I guess
[11:19] <StevenK> [22:07] < StevenK> pitti: I was wondering if we could also do it the other way  if the UNR session was the default for UNR images, but people could choose a desktop session too
[11:19] <pitti> [12:11]     pitti| StevenK: that should be easy as well
[11:19] <StevenK> pitti: Right, then you were answering what I thought you were. :-)
[11:20] <pitti> StevenK: can be covered in the same spec; it's the same scheme, just a different package and session name
[11:20] <StevenK> pitti: Can you also subscribe davidm to the spec?
[11:20]  * StevenK digs for it
[11:21] <pitti> StevenK: done
[11:21] <pitti> StevenK: please change the summary accordingly (how you want it to look in UNR, since you don't have gdm visible)
[11:23] <StevenK> pitti: We still use gdm, so it could be hand waved, I guess
[12:26] <mvo> amitk: if you have a moment I would like to ask about bug #453444 - is the kernel in karmic-final fixed or is this a fix that is commited and will be part of a commin update?
[12:26] <mvo> amitk: I ask because I got reports (eg. from YokoZar) that this is still a problem with karmic-final
[12:39] <mvo> pitti: hm, there is a discussion on flag-restart-required *before* actually doing the upgrade in update-manager. what do you think about "XB-Restart-Required: [system, session, app]" in debian/control ?
[12:40] <pitti> mvo: oh, instead of having to change the postinst? sounds nice
[12:40] <mvo> yeah
[12:41] <mvo> nice and simple, I'm trying to think of downsides, but I can't see any
[12:41] <pitti> mvo: before the upgrade> so that the user can choose not to do it right now?
[12:41] <mvo> yes
[12:41] <pitti> mvo: which bit would check that flag and call restart-required? dpkg?
[12:41] <mvo> showing in u-m "this update requires a restart"
[12:41] <mvo> well, I was not thinking that far :)
[12:42] <mvo> we could have a debhelper thing that generates a postinst just like we have now
[12:42] <pitti> or that
[12:42] <mvo> or modify dpkg/apt/apt-listchanges
[12:42] <seb128> mvo, what do you want to do from this info?
[12:43] <james_w> mvo: would it be able to specify versions as well?
[12:43] <mvo> seb128: showing in update-manager "2 updates that require a restart"
[12:43] <james_w> XB-Restart-Required: system (<= 0.1-1)
[12:43] <seb128> mvo, is that a "you need to restart to be able to use the upgrade" or a "you should restart because you don't get the security fix until then"?
[12:43] <mvo> james_w: sweet, that is a nice idea
[12:44] <james_w> some packages do dpkg --compare-versions currently in the postinst?
[12:44] <soren> james_w: Meaning "if you're upgrading from a version of this package earlier than 0.1-1, you need to reboot"?
[12:44] <mvo> seb128: I'm not sure I understand the difference, but it would be purely to show the user in advance that this update will require some sort of restart (e.g. fireofx)
[12:44] <james_w> soren: exactly
[12:44] <soren> james_w: Ok.
[12:45] <james_w> for those packages that don't require a restart every time they are upgraded
[12:45] <seb128> mvo, the difference: is it to point cases where the upgrade will break what you do and force you to restart?
[12:45] <seb128> mvo, or is that for things like dbus or you are suggested to restart
[12:45] <mvo> james_w: I wonder if there are any currently (but its good to have the feature)
[12:45] <james_w> of course, it can always be more complex, like "restart if this other package is installed", but you can always suggest restarting too much
[12:46] <james_w> mvo: what would signal update-notifier?
[12:46] <mvo> seb128: currently its mixed together, it might make sense to have a different one. like restart-suggested, restarted-required
[12:46] <james_w> mvo: would dpkg now write the /var/run/ file based on XB-Restart-Required?
[12:46] <mvo> james_w: not sure yet, it could either be the currently mechanism and debehlper would do some magic
[12:46] <pitti> well, it's not really "suggested"
[12:46] <james_w> ok
[12:46] <mvo> james_w: or we move it to dpkg or we add a pre-run hook
[12:46] <pitti> the difference is just that ffox breaks after the upgrade, while dbus doesn't
[12:47] <mvo> (like apt-listchanges, just for this)
[12:47] <seb128> pitti, well I think the user is rather interested to know about things which will break
[12:47] <mvo> pitti: yeah, for the "it-breaks" it would be a "restart-required: app"
[12:47] <pitti> seb128: exactly
[12:48] <mvo> restart-requires: [system, session, app, app-breaks] ;)
[12:48] <seb128> app and app-breaks is the same
[12:48] <seb128> you only want to notice about breakages
[12:48] <seb128> you can assume than in any case you need to restart an app to get the change anyway there
[12:49] <mvo> good point
[12:49] <seb128> in any case seems fine to me
[12:49] <seb128> +1
[12:49] <seb128> we can figure what we do from the info later
[12:49] <soren> How about something like this: We add the field (as an XB-Restart-Required), and add a debhelper script that detects it and adds a handler to postinst. The handler will dump the information in a state directory somewhere, and call "dpkg-trigger restart-required".
[12:49] <soren> Packages like update-notifier can add a handler for that trigger and do somethign useful with it.
[12:50] <mvo> soren: that sounds like a good plan, I think we have just create a mini-spec :)
[12:50] <superm1> NCommander, if we are on different time zones right now, email might be better then
[12:50] <soren> That way, we don't need extra magic in dpkg at all, and we have flexibility in adding multiple handlers.
[12:50] <mvo> thanks seb128, pitti, soren, james_w
[12:51] <mvo> soren: yeah
[12:52] <pitti> soren, mvo: right now the script/inotify ensure that dpkg is completely done; with a trigger, the user might click "reboot" too early (e. g. when a later trigger is still doing stuff)?
[12:53] <NCommander> superm1, we're in relatively close timezones. The problem is my internal body clock thinks its in Japan at the moment
[12:53] <soren> pitti: Depends.
[12:53] <soren> pitti: Whatever is triggered can check if the package db is still locked.
[12:53] <soren> Or whatever.
[12:53] <soren> pitti: It's definitely solvable.
[12:53] <pitti> ah, fork & poll FTW :)
[12:53] <soren> Well, in the case of update-notifier, doesn't it just send a dbus event that something else will handle?
[12:54] <pitti> soren: solvable> agreed, just needs to be kept in mind
[12:54]  * soren hasn't really looked closely at that stuff.
[12:54] <soren> pitti: Sure. Good point.
[12:54]  * mvo nods
[12:54] <pitti> soren: no, u-n inotifies a flag file that /usr/share/reboot-required script sets
[12:54] <pitti> and then waits on apt to finish
[12:54] <soren> The thing that actually suggests to the user to reboot should be smart enough to not do this if e.g. the package db is locked.
[12:55] <soren> pitti: Ah, ok.
[12:55] <pitti> soren: but you are right; we clearly need to involve d-bus here! :-)
[12:55] <soren> So if someone starts apt again in the mean time, what happens?
[12:55] <pitti> soren: after the upgrade? you lose
[12:55] <superm1> NCommander, okay well what's up?
[12:55] <soren> does the restart dialog disappear..
[12:55] <soren> oh.
[12:55] <pitti> i. e. if you start another install and click reboot
[12:55] <soren> well, that should probably be fixed, too :)
[12:55] <NCommander> superm1, mind if I PM you?
[12:55] <superm1> sure
[12:56] <mvo> I think what we want is a more general "if you reboot while dpkg is running, give it a bit extra time to finish". but that becomes tricky when the user is e.g. in a hurry
[12:56] <mvo> its also a problem in how to represent it
[13:00] <soren> mvo: As a first step, how about just having the UI not offer the option to reboot if dpkg is running?
[13:01]  * soren runs an errand
[13:02] <mvo> soren: that should already be the case, but it should also auto-vanish if dpkg gets started again after the dialog was shown
[13:03] <soren> mvo: ..and turn up again when dpkg is done, surely?
[13:03] <mvo> yes
[13:03] <soren> Ok.
[13:03] <soren> Great :)
[13:03] <mvo> :)
[13:03] <james_w> mvo: one thought
[13:03] <mvo> just the vanish-again part needs to get done, then its cool
[13:04] <james_w> does "XB-Restart-Required: package" depend on whether it is an upgrade or install?
[13:04] <james_w> would we have anything that needs to trigger a restart when installed for the first time?
[13:04] <mvo> hm, in the case of an app not, but in the case of a kernel it might be I think
[13:05] <james_w> because you could force only-on-upgrade with "XB-Restart-Required: package (>= 0)"
[13:05] <mvo> or of e.g. a nvidia driver, a session restart is suggested then
[13:05] <mvo> right
[13:05] <james_w> but it may not be possible to force only on install
[13:05] <james_w> so "XB-Restart-Required: package (install)"
[13:05] <james_w> could be supported or something
[13:05] <james_w> depending on what "XB-Restart-Required: package" alone means
[13:06] <mvo> I think its something to keep in mind
[13:06] <james_w> I don't mean "package" do I? I mean "system"
[13:21] <mantiena> dholbach: hi, I've noticed, that you fixed some bugs in msttcorefonts package few years ago, now this package has very big problems, which doesn't allow smootly upgrade to Ubuntu 9.10 (Karmic) :(
[13:21] <mantiena> Look at bug #464422 - about 60 duplicates already, about 10 duplicates are reported every day since release of Karmic :(
[13:24] <mantiena> I think Ubuntu developers should release a fixed version of ttf-mscorefonts-installer ASAP, it's not hard to fix this bug - ttf-mscorefonts-installer shouldn't return an error if there are no access to corefonts download servers, AFAIK a dialog with buttons "Try again" and "Download later" (run dpkg-reconfigure ttf-mscorefonts-installer when you will have internet connection) should be displayed instead
[13:25] <slangasek> "download later" shouldn't result in the package being configured
[13:25] <slangasek> the flash installer did that for the longest time, and people ended up with no flash plugin on their systems and no idea why
[13:26] <mok0> Should multiverse be enabled during install???
[13:26] <mok0> Like slangasek says, there are other packages downloading non-free stuff and that is bound to screw up
[13:28] <mok0> Perhaps downloading packages should be moved to a different component alltogether
[13:28] <slangasek> not really
[13:28] <mok0> slangasek: not really what? :)
[13:28] <slangasek> they shouldn't be moved to a different component
[13:29] <slangasek> making new buckets doesn't change the underlying problem
[13:29] <mok0> slangasek: it does, because you can disable the bucket during upgrade
[13:30] <slangasek> but we don't want people not upgrade parts of their system. :)
[13:30] <slangasek> +to
[13:30] <mantiena> slangasek: in any case - user should get interactive dialog instead of canceled Ubuntu upgrade procedure. Please read the description of bug 464422 - there are lots of situations, when internet connection is lost after packages are downloaded (in configuration stage), so, ttf-mscorefonts-installer shouldn't fail silently if there are no access to download servers
[13:30] <mok0> slangasek: that's what's happening anyway, in these bugs
[13:31] <mok0> slangasek: besides, when the bucket is disabled, the system doesn't know that it's supposed to upgrade something :)
[13:31] <slangasek> mok0: giving them a button to click that lets them defer the upgrade indefinitely isn't a good solution, though.
[13:31] <mok0> slangasek: I agree
[13:32] <seb128> jdstrand, hi, if you do a sru on a desktop package where the karmic and lucid version are the same please commit to bzr too
[13:33] <slangasek> mantiena: right, the package should at least make it clear why it's failing
[13:33] <seb128> jdstrand, not sure if you forgot for evince or if the policy was not clear about where the store sru changes
[13:33] <mantiena> slangasek: what about moving fonts download to preinst script?
[13:33] <slangasek> that would only change the type of error you get
[13:33] <seb128> jdstrand, I've fixed it in bzr now so no need to look at this one btw ;-)
[13:34] <mantiena> slangasek: but if preinst will fail, then ttf-mscorefonts-installer will be left in older version and upgrade procedure will continue, right?
[13:35] <mok0> preinst script could check that the box is connected to the internet
[13:35] <mantiena> because currently ttf-mscorefonts-installer is updraded and status is partially installed if there are no access to download servers
[13:35] <slangasek> mantiena: I'm not sure how far it will continue, mvo would know better.  In both cases, apt will see an error, and eventually report it to the user
[13:35] <slangasek> mok0: why?  that doesn't change anything about what the script needs to do
[13:35] <mok0> slangasek: ... you're right
[13:35] <slangasek> can't download --> failure
[13:36] <mok0> slangasek: it just seems wrong to me somehow to download in preinst
[13:37] <slangasek> well, I tend to agree; but for ephemeral, aesthetic reasons - whatever works best must be the right thing to do ;)
[13:37] <mok0> heh, yes
[13:37] <slangasek> but if you mean checking for internet connection in the preinst, so we can abort early; but only download in the postinst - this is obviously not atomic, so the preinst check would then be redundant
[13:37] <mantiena> slangasek: AFAIK the best situation would be: if there are no access to corefonts download servers, then ttf-mscorefonts-package should be not installed (or not upgraded) and don't return a critical error (distribution upgrading should continue)
[13:38] <mok0> Sort-of when the upgrade of a package requires the installation of a new package, it's left un-installed
[13:38] <slangasek> distribution upgrading should continue anyway; if it doesn't, I think this is an issue with package manager error handling, TBH
[13:40] <mantiena> checking internet connection in preinst isn't good decision, because there are plenty of cases, when internet connection is ok, but fonts can't be downloaded from some download servers (for example because of timeouts of lots internet connection during download)
[13:40] <mok0> In any case, this package should have no reverse dependencies, and should have the lowest priority of all -> installed at the very end
[13:41] <mantiena> slangasek, mok0: in reality updrading ttf-mscorefonts-installer shouldn't download any files from internet, because fonts files are already installed in user's system ;)
[13:42] <slangasek> heh, I think that's a separate bug from what we've been talking about so far, then. :)
[13:42] <mok0> mantiena: Indeed
[13:43] <mok0> Why hasn't this been a problem with earlier releases?
[13:45] <jdstrand> seb128: ack. I was thinking lucid was different now, so didn't commit to bzr. your policy makes sense and I'll keep that in mind going forward. thanks for taking care of the commit, and sorry for not committing
[13:45] <seb128> jdstrand, thanks ;-)
[13:53] <mantiena> mok0: Few years ago msttcorefonts package always informed user before download, that he needs internet connection and users can type "none" if  they do not wish to download these fonts now or do not have internet access, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549882#25
[13:54] <mantiena> This text was displayed before download: If you have already downloaded Microsoft's TrueType Core Fonts for the web,  type the name of the directory which contains them. Those files are in the  Microsoft Windows self-installing format, and are named andale32.exe,  arial32.exe, arialb32.exe, comic32.exe, courie32.exe, georgi32.exe,  impact32.exe, times32.exe, trebuc32.exe, verdan32.exe and webdin32.exe.   If you haven't yet downloaded these fonts, leav
[13:55] <mok0> mantiena: hm, perhaps that was changed in connection with the switch to kpackagekit
[13:56] <mantiena> mok0: no, that was changed earlier, maybe in 8.10 (Intrepid)
[13:56] <mok0> mantiena: I see
[13:59] <mantiena> Bug #464422 still isn't assigned to Ubuntu developer, I'm talking here because I hope to find a developer for fixing this bug :)  About 60 duplicates already, about 10 duplicates are reported every day since release of Karmic, AFAIK it's big problem for users.
[14:04] <mok0> eeekk gotta go
[14:05] <mantiena> slangasek: so, what you think about finding a developer to fix bug 464422 ? Or maybe you can fix this bug?
[14:10] <slangasek> mantiena: I'll take a look, but I don't guarantee that it'll get fixed for 9.10; most downloader packages I've seen have been horribly done, and it may resist surgical fixing
[14:12] <mantiena> slangasek: If this package will be not fixed and not put into karmic-proposed, then there will be 200 duplicates after 2 weeks... :(
[14:13] <apw> slangasek, any idea where i'd find the gcc devs ?
[14:13] <mantiena> I can help you to find ideas how to fix and to test ;)
[14:13] <slangasek> apw: no?
[14:13] <apw> seems the compiler is exploding
[14:14] <apw> doko, ahh ... seems you are involved in gcc
[14:14] <slangasek> try turning on -fno-explosions?
[14:14] <apw> i am getting seg faults trying to compile the kernel with the 4.4.2-1ubuntu2 gcc upload
[14:14] <slangasek> ah
[14:14]  * apw wishes
[14:15] <slangasek> there's a -1ubuntu3 that's been uploaded, only the source is available
[14:15] <apw> yeha the changelog there talks only about arm build failures
[14:16] <dholbach> mantiena: I can't remember I ever touched that package - could it be you mean somebody else?
[14:18]  * apw retries the build to see if its consistent on the files which kill it
[14:20] <slangasek> mantiena: looking at the package, it *does* know not to re-download if it already has the fonts
[14:21] <mantiena> dholbach: I've found you name in changelog.gz ;) msttcorefonts (1.2ubuntu1) hoary;
[14:21] <mantiena>   * tightened build-depend on defoma (>= 0.8.11ubuntu2)
[14:21] <mantiena>  -- Daniel Holbach<EMAIL_ADDRESS>Fri, 18 Mar 2005 22:05:09
[14:21] <dholbach> mantiena: that was a mass upload for a couple of fonts
[14:23] <dholbach> so, I'm sorry, but don't think I can help
[14:23] <mantiena> slangasek: maybe, but main problem is not in re-downloading, but in returning an error during configure...
[14:23] <slangasek> mantiena: well, that part we don't seem to be in agreement on; if the fonts aren't there, returning the error is the correct thing to do
[14:23] <mantiena> dholbach: ok, I hope, that slangasek can :)
[14:24] <dholbach> rock on!
[14:24] <mantiena> slangasek: AFAIK the best situation would be: if fonts can't be downloaded from servers, then ttf-mscorefonts-package should be not installed (or not upgraded) and don't return a critical error (distribution upgrading should continue)
[14:25] <slangasek> mantiena: but that's meaningless, because the only thing *trying* to download the fonts is this package
[14:25] <slangasek> you can't know it will fail before it tries
[14:27] <mantiena> slangasek: so, font downloading should be moved to preinst, as preinst script is run before package installation, right?
[14:27] <slangasek> moving it to the preinst won't prevent an error being passed up to the package manager
[14:28] <slangasek> it will just show up as "error unpacking" instead of "error configuring"
[14:32] <mantiena> slangasek: if ttf-mscorefonts-installer package will be not installed, then it's ok, system packaging dabase will be in correct status without half-configured packages
[14:32] <slangasek> I don't think that's a useful distinction
[14:33] <slangasek> the system is still incompletely upgraded
[14:34] <mantiena> slangasek: you think, that there will be a problem, if one package - ttf-mscorefonts-installer will be not upgraded?
[14:35] <slangasek> I think it *is* a problem if the package isn't upgraded
[14:36] <slangasek> I also don't think, from reading the source, that this is being caused by a failure to upgrade the package; I think this is happening when the package is being pulled in as a new dependency
[14:39] <slangasek> Installing ttf-mscorefonts-installer as dep of wine
[14:39] <slangasek> mantiena: ^ in the master bug, that's where the package comes from
[14:39] <slangasek> this is actually a bug in the wine package, which shouldn't really be recommending a package in multiverse
[14:42] <Rockj> if Im wondering if something is a bug regarding dhclient-package, I should idle in #ubuntu-bugs and wait for an answer aye?
[14:49] <dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek Day 4 starting in 11m on #ubuntu-classroom
[15:15] <jcastro> Keybuk, hey you know we're not doing the little intro bits with the schedule and stuff this UDS right?
[15:16] <Keybuk> jcastro: no?
[15:16] <jcastro> it's just going to be "if you need to schedule something, see a track lead"
[15:17] <jcastro> and people seem to be doing a good job registring blueprints and stuff
[15:20] <Keybuk> jcastro: sounds fair :p
[15:22] <ebroder> Is there a way to get the ubuntu-installer to grab udebs from -proposed, or am I stuck doing it by hand?
[15:22] <mantiena> slangasek: I've got that bug during upgrade Jaunty system without wine, just ttf-mscorefonts-installer
[15:38]  * hyperair grumbles. cowbuilder is buggy shit.
[15:40] <Laney> yes
[15:40] <nxvl> slangasek: are we having key signing party again in Dallas?
[15:40] <Laney> It doesn't resolve the dependencies most of the time for me so I just leave it alone
[15:42] <hyperair> Laney: well, it's giving me tonnes of issues with my pbuilderc.
[15:42] <hyperair> pbuilderrc*
[15:46] <Laney> not worth it
[15:46] <Laney> i'd sooner use sbuild
[15:48] <hyperair> heh
[15:48] <hyperair> wait, what dependency issues?
[15:49] <Laney> Cannot install debhelper as it is a virtual package, etc
[15:49] <ebroder> Sounds like a broken sources.list somewhere
[15:49] <Laney> works with pbuilder
[15:52] <maco> debhelper is a virtual package?
[15:52] <Laney> nope
[15:52] <Laney> that's what pbuilder says when it can't find something
[15:58] <hyperair> Laney: yeah, broken sources.list, definitely
[15:58] <hyperair> Laney: probably because it's shitting around with $DISTRIBUTION
[15:58] <hyperair> it mixed up my sid sources with my karmic OTHERMIRRORS sources
[15:58] <hyperair> because it won't preserve $DISTRIBUTION
[15:58] <Laney> did you use pbuilder-dist?
[16:01] <hyperair> no, i rolled out my own cowbuilder-dist >_>
[16:01] <hyperair> but it won't honour my --distribution
[16:01] <hyperair> nor will it honour my $DISTRIBUTION set on the environment
[16:01] <hyperair> which is utterly ridiculous
[16:01] <Laney> well pbuilder-dist passes the sources explicitly
[16:01] <hyperair> it's unsetting it somehow.
[16:02]  * Laney shrugs
[16:02] <hyperair> pbuilder-dist also doesn't allow me to use my own mirror =.=
[16:07] <kirkland> mathiaz: pitti: ETA on getting the Eucalyptus upload into -proposed?
[16:10] <mathiaz> kirkland: well - I first need to upload it to -proposed
[16:10] <mathiaz> kirkland: how is the PPA testing going on?
[16:10] <mathiaz> ttx: ^^ did you get a chance to review the eucalyptus SRU?
[16:11] <ttx> mathiaz: PPA ?
[16:13] <mathiaz> ttx: https://launchpad.net/~mathiaz/+archive/eucalyptus
[16:13] <mathiaz> ttx: I've CC'ed you on an email to mdz about the avahi/eucalyptus SRU
[16:20] <Cilyan> didrocks: Hello ! If you're around, I would like to ask you some questions about your packaging of Clutter (related to the "glReadPixels" bug)
[16:25] <ogra> hmm, funny
[16:25] <ogra> is anyone here currently listening to music with rhythmbox and would like to test something ?
[16:27] <hyperair> Laney: correction: pbuilder is buggy shit. it can't handle passing --distribution after --configfile
[16:27] <hyperair> Laney: which was what cowbuilder was doing
[16:27] <Laney> heh
[16:30] <mathiaz> ttx: https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/
[16:30] <mathiaz> kirkland: ^^
[16:34] <hyperair> Laney: and so the workaround is to use another env var to pass it in
[16:34] <Laney> wanna patch pbuilder-dist?
[16:35] <hyperair> Laney: to do what?
[16:35] <Laney> work
[16:36] <hyperair> Laney: i'd patch pbuilder-dist-simple, but i refuse to touch that convoluted crazy python script that is pbuilder-dist
[16:36] <hyperair> i've looked into it once, really =.=
[16:36] <hyperair> it can seriously be accomplished in bash, and in a much shorter manner.
[16:37] <hyperair> and simpler
[16:43] <ttx> mathiaz: looks good to me
[16:44] <mathiaz> ttx: ok
[16:44] <mathiaz> ttx: wrt to the eucalyptus bug list relevant to karmic
[16:44] <mathiaz> ttx: I were using a tag before right?
[16:45] <mathiaz> ttx: instead of https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/
[16:45] <ttx> mathiaz: no
[16:45] <ttx> mathiaz: the "eucalyptus" tag is for bugs in discussion with upstream
[16:45] <mathiaz> ttx: well - point being that for bug 460085 you had to reopen a task for the eucalyptus package
[16:45] <ttx> mathiaz: which may or may not be ablout SRUs
[16:45] <mathiaz> ttx: which is not really true
[16:45] <mathiaz> ttx: ah ok.
[16:46] <ttx> mathiaz: bug 460085 also needs a fix on euca side
[16:46] <mathiaz> ttx: I'm just trying to define the best way to get a list of bugs related to uec that should be fixed in karmic
[16:46] <ttx> not just on rampart side.
[16:46] <mathiaz> ttx: ah ok.
[16:46] <mathiaz> ttx: so https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/ is a good list
[16:46] <ttx> but yes, "UEC" bugs are more than just eucalyptus
[16:47] <ttx> euca2ools and rampart have a few extra bugs we need to keep in scope
[16:47] <mathiaz> ttx: right - do you track these directly in LP?
[16:47] <mathiaz> ttx: using tags could help - as we can do search on tags under ubuntu/karmic/
[16:48] <mathiaz> ttx: so we can actually track all the bugs tagged uec (for ex) that are *relevant* to karmic (for SRU purposes)
[16:48] <ttx> mathiaz: its a little redundant with the karmic nomination, but not completely
[16:48] <ttx> mathiaz: so that might make sense
[16:49] <ttx> mathiaz: "uec-karmic" tag ?
[16:49] <mathiaz> ttx: well all bugs still need to be nominated for karmic
[16:49] <mathiaz> ttx: just that they get lost in the noise
[16:49] <ttx> mathiaz: I used to use the ubuntu-server / karmic bugs
[16:50] <mathiaz> ttx: ubuntu-server/karmic bugs?
[16:50] <ttx> mathiaz: but signal /noise ratio might go down on that one
[16:50] <ttx> karmic bugs where ubuntu-server is supervisor
[16:50] <mathiaz> ttx: right - that doesn't work as expected :/
[16:51] <mathiaz> ttx: because ubuntu-server is *not* a bug supervisor for ubuntu-server packages
[16:51] <mathiaz> ttx: ubuntu-server is a bug *contact* for these packages
[16:51] <mathiaz> ttx: and there isn't a search critiria for bug contacts (which is what is really needed here)
[16:52] <mathiaz> ttx: this is why a search with ubuntu-server supervisor doesn't give all the expected bugs
[16:53] <mathiaz> ttx: so a proposal is to use the uec tag and then do a advanced search under ubuntu/karmic/ with the uec tags
[16:54] <mathiaz> ttx: that why bugs require to be nominated (which is mandatory for SRUs) and we can get an overview that is cross package.
[16:54] <mathiaz> ttx: that *way*
[16:55] <ttx> mathiaz: ok, makes sense
[16:56] <mathiaz> ttx: ok - I'll update the current bugs
[16:57] <mathiaz> ttx: and send out an email (to ubuntu-devel? ubuntu-server? ubuntu-cloud?) outlining the policy above to track uec bugs relevant for karmic
[16:59] <ttx> mathiaz: I'd say ubuntu-devel.
[17:00] <ttx> mathiaz: these tags are for developer use
[17:08] <Cilyan> bigon: Are you around ?
[17:16] <kirkland> mathiaz: to answer your ppa-testing question...  my testing went well.  i think it should be pushed to bake in karmic-proposed now
[17:16] <mathiaz> kirkland:  ok - I'm about to upload it to -proposed
[17:54] <bigon> Cilyan: yes?
[17:55] <Cilyan> :)
[17:55] <Cilyan> I saw you where involved in the packaging of clutter ?
[17:56] <Cilyan> I'm currently trying to correctly package it on ArchLinux and I'm facing a well known problem with Mesa and the radeon driver (glReadPixels is badly implemented)
[17:57] <Cilyan> And strangely, Ubuntu is not affected by this bug (whereas OpenSuSE and Fedora are for example)
[17:57] <Cilyan> So I would like to know If you made some magic on that package or on Mesa to achieve correct support of picking in clutter ?
[17:58] <mathiaz> bdmurray: hi!
[17:58] <maco> Cilyan: #ubuntu-x would know best i think...
[17:58] <mathiaz> bdmurray: is there a page with the official tags used in LP?
[17:59] <bigon> Cilyan: the clutter pkg doesn't have any patches
[17:59] <bigon> maybe radeon driver?
[18:02] <Cilyan> Hmm, in fact it is not provided by the mesa package, I'm having a look on it
[18:03] <bdmurray> mathiaz: http://wiki.ubuntu.com/Bugs/Tags has some of them but not the "official" ones in Launchpad
[18:04] <mathiaz> bdmurray: ok - I'm compiling a list of tags used by the server team
[18:04] <mathiaz> bdmurray: I plan to put it in the Server Team KnowledgeBase (https://wiki.ubuntu.com/ServerTeam/KnowledgeBase)
[18:05] <bdmurray> mathiaz: the portlet at https://bugs.edge.launchpad.net/ubuntu has the official bug tags (if you disregard all the number ones before bitesize)
[18:05] <bdmurray> mathiaz: could you maybe put them in Bugs/Tags and use an include on the server team page?
[18:06] <apw> doko, you about?
[18:06] <mathiaz> bdmurray: I was thinking about doing something like that (the other way around probably)
[18:07] <mathiaz> bdmurray: as long as the information shows up in both places, but only maintained at one place
[18:07] <bdmurray> mathiaz: sure, I actually think that's how some of them work
[18:07] <doko> apw: ?
[18:07] <apw> doko, the 4.4.2 compiler have seems to have at least two internal compiler errors when compiling the kernel
[18:08] <apw> doko what should i be doing beyond filing a bug against gcc-4.4 in LP
[18:08] <doko> apw: which version, which arch, preprocess source?
[18:09] <doko> preprocessed even, and how to build it
[18:09] <apw> amd64 and lpia for sure (which is i386) the 4.4.2-1ubuntu2 upload in lucid
[18:09] <apw> i've put the snippets which trigger the issue in the bug
[18:10] <doko> apw: and telling me if gcc-snapshot works. so 4.4.2-1ubuntu1 did work?
[18:10] <apw> https://bugs.edge.launchpad.net/ubuntu/+source/gcc-4.4/+bug/475450
[18:10] <doko> apw: it it's a self-contained test case, it fine
[18:10] <apw> yeah there are two bugs apparently in a similar construct
[18:11] <apw> one in __builtin_offsetof and one in & (address of)
[18:11] <apw> i've pared the triggers down the minimum and put them in the LP bug
[18:11] <apw> i'll go find the ubuntu1 and see if that work
[18:12] <apw> i am bolloxed without a working compiler in lucid, so let me know what i can do to help
[18:12] <apw> i can work round the first one in the kereml, but & not workig is a bit of a showstopper
[18:13] <Cilyan> bigon: thanks for the help, it seems that KMS and DRI2 are needed here
[18:27] <zul> james_w: can you import apache2 please using your bzr magic
[18:31] <james_w> zul: queued, should be there in around 20 minutes
[18:31] <zul> james_w: thanks
[18:49] <lbrinkma> Can I upgrade to lucid yet?
[19:01] <pitti> lbrinkma: technically yes, but you really must know what you are doing; if it breaks, you have to keep both pieces
[19:02] <pitti> lbrinkma: at this point, I think that most of the developers still run karmic (mainly to focus on SRUs, etc.)
[19:02] <lbrinkma> pitti, I'm running as well. I want to test lucid in a vm
[19:08] <lbrinkma> how can i performe an update?
[19:09] <pitti> lbrinkma: we don't have an alpha yet, so install karmic, replace "karmic" with "lucid" in /etc/apt/sources.list and upgrade
[19:11] <lbrinkma> pitti, I alredy thought that's something like that. Thanks in advanced.
[19:17] <thebloggu> I am sorry for asking for support in a development channel, but I need to talk to one developer because of the function keys in my asus eee pc 1101HA. Brightness keys simply wont work. gnome-brightness-applet works but fn+f5 and fn+f6 aren't recognized by any of the capturing keybind programs i used. compiz wont catch it, neither wont xev or showkey and xbindkeys -k
[19:21] <pitti> thebloggu: can you please exercise the steps in https://wiki.ubuntu.com/Hotkeys/Troubleshooting ?
[19:24] <thebloggu> pitti, sure
[19:46] <thebloggu> pitti, after killing gnome-settings-daemon and power manager xev continued to report nothing
[19:47] <pitti> thebloggu: I suppose it doesn't know about the scan codes; you have to run /usr/share/doc/udev/README.keymap.txt
[19:47] <thebloggu> pitti, i read /usr/share/doc/udev/README.keymap.txt  and tried the steps to identify both the keyboard and the keypress event code
[19:47] <pitti> (as described on the wiki page)
[19:47] <thebloggu> codes*
[19:50] <thebloggu> pitti, tried ti find the broken keycodes with /lib/udev/keymap and none of the special fn keys (besides from numbers and home,end,insert, numlock, etc) work. they wont show up
[19:50] <thebloggu> pitti, acpi_listen produces output to most fn keys except brightness
[19:52] <james_w> zul: there's a performance issue somewhere, so that 20 minutes is looking incredibly optimistic right now
[19:53] <james_w> it's churning, but the ETA may be some time off, in case you are waiting
[19:54] <thebloggu> pitti, https://bugs.launchpad.net/ubuntu/+bug/429942
[21:25] <wgrant> lamont: Around today?
[21:32] <lamont> yeah - fighting with a kernel thing
[21:34] <wgrant> lamont: Ah. Well, if you have time today, it would be handy to talk about source format 3.0 support on the buildds at some point.
[21:39] <lamont> wgrant: what all does it require?
[21:40] <lamont> when do you go offline?  (what tz are you??) <--wgrant
[21:41] <wgrant> lamont: I'm +11. I go offline somewhere around 1300UTC, normally.
[21:42] <wgrant> lamont: It requires either a new (Karmic-era) dpkg on all the buildds, or sbuild modified to run dpkg-source inside the chroot.
[21:42] <wgrant> lamont: Neither is trivial.
[21:46] <lamont> any chance of backporting just that piece to hardy (and dapper, thank you ppc) versions of dpkg?
[21:47] <gigabytes> hello
[21:47] <wgrant> lamont: I'm not sure (I wouldn't have been too concerned about backporting everything, but then I remembered powerpc).
[21:48] <gigabytes> to write an init script that saves a value on shutdown and restores it at startup, where is a right place to store that value?
[21:48] <wgrant> lamont: A plain backport of dpkg (with a couple of dependencies) to hardy crashes dpkg-source. Not quite sure why, and didn't have time to look deeply into it.
[21:48] <gigabytes> a file somewhere... but where? it's not something editable by the user
[21:48] <wgrant> I daren't even think about dapper.
[21:49] <lamont> great
[21:49] <gigabytes> anybody knows?
[21:49] <gigabytes> alsa scripts do that
[21:52] <wgrant> lamont: Note that non-ancient-unmaintained-fork-of-dead-fork sbuild runs it inside the chroot.
[21:53] <lamont> wgrant: runs apt-get install inside the chroot - the source is still fetched outside
[21:53] <wgrant> lamont: I see it called with CHROOT => 1 here.
[21:53] <lamont> so... running the source fetch inside the chroot sounds like a good plan
[21:53] <wgrant> (our sbuild does not, but real sbuild does)
[21:54] <lamont> "real sbuild" ==?
[21:54] <wgrant> The one in Debian, that most of the Debian buildds use now.
[21:55] <lamont> right - migrating towards that one is probably a good idea
[21:55] <wgrant> Certainly. Will be easier once we get rid of the revolting ddeb and translation hacks.
[21:55] <wgrant> But we need a solution to this before then, unfortunately :(
[21:59] <lamont> are we really going to get rid of ddeb and translation hacks?
[22:00] <wgrant> lamont: The translation hack hasn't been necessary for nearly three and a half years. The ddeb hack will become unnecessary in a month or two.
[22:01] <lamont> yay!
[22:03]  * wgrant checks the current sbuild diff that we hold.
[22:05] <wgrant> Oh, right, I remember this.
[22:05] <wgrant> We have no version control history for most of the changes, and nobody is quite sure which point of which fork we forked from.
[22:06] <lamont> "we" might be a bit of an overstatement
[22:06] <lamont> though the relationship between the version in debian and the version that used to be used on debian buildds is unknown to me
[22:07] <wgrant> Most of the changes were made before sbuild appeared in the LP tree.
[22:08] <lamont> yeah - I have that tree in arch, of all things
[22:08] <lamont> maybe converted to bazaar, almost certainly not in bzr
[22:08] <wgrant> Oh! That sounds useful.
[22:09] <lamont> well, except for the arch part. :-p
[22:09] <wgrant> But arch is easy enough to import.
[22:10] <lamont> yeah.  'tis arch
[22:10] <lamont> {arch} even
[22:10] <lamont> and there might be a hole between there and the lp tree
[22:10] <wgrant> alternatively, all I would really like is the full Ubuntu diff.
[22:11] <wgrant> So I can see what needs to be done to open up the possibility to migrate to a stock sbuild.
[22:12] <lamont> the lp tree should give you that, no?
[22:12] <lamont> or you need the debian version it's based on?
[22:13] <wgrant> lamont: I don't think the LP tree goes all the way back to the Debian version. It looks to me like there are changes in between, but I don't know since I can't find a Debian buildd sbuild from that era.
[22:14] <lamont> right.  so the original debian sbuild that we forked, + top-of-lp, should give you the total diff, yes?
[22:15] <wgrant> It should.
[22:15] <wgrant> Do you know which original Debian sbuild that was? It's not anything that was ever in the archive, IIRC.
[22:16] <lamont> never was in the archive - there was a bit of a "that stuff is crack" schism, and a separate version was maintained from the archive, with totally diff version numbers
[22:17] <wgrant> Lovely, lovely, lovely.
[22:17] <lamont> yeah - I'm pretty sure I might have something close lying around
[22:17] <lamont> will have to dig though
[22:19] <wgrant> That would be great, thanks.
[22:19] <wgrant> Who hacks lp-buildd these days?
[22:26] <lamont> mostly me, though in theory it's trying to be the soyuz guys
[22:26] <lamont> and there's at least one tweak that hasn't made it back into the tree (EPERM)
[22:26] <lamont> which I'll get hashed out tomorrow, possibly.  failing that, next week
[22:27] <wgrant> What is it? I have three other compatibility changes that I need to land soonish.
[22:27] <lamont> ah, right.  Depends: apt-transport-https
[22:27] <lamont> and rev 52
[22:27] <lamont> though if we get the source fetching into the chroot, then we can drop that broken-on-dapper depends, too
[22:27] <wgrant> True.
[22:28] <wgrant> So you have a separate bzr tree for this, which is only occasionally copied into RF?
[22:29] <lamont> well...  historically, the archive has been the revision control history..  I'm new to this whole "it's in LP" thing... note also that there's a bug that it doesn't actually build from source atm, either
[22:29] <lamont> it needs things that are above the "top" directory for the dpkg-source, and hence dies in copy
[22:29] <wgrant> daemons/buildd-slave.tac?
[22:29] <lamont> sounds about right
[22:29] <wgrant> Right, it's a bit strange that it lives outside.
[22:30] <wgrant> "the archive" -- there is an internal archive as well? Is that this dapper-cat thing I see in changelogs?
[22:31] <lamont> yep
[22:31] <wgrant> I seeeee.
[22:31] <lamont> mind you, that's mostly because it has things that we can use internally, but can't redistribute, and has no concept of public/private
[22:31] <lamont> and it's easier to have one archive than 2
[22:32] <wgrant> Yep.
[22:50] <slangasek> nxvl: I haven't planned one; would be great if someone else had time to plan it
[22:50] <slangasek> ... in advance, so we can bring our own paper this time :)
[23:10] <nxvl> slangasek: yeah, that would be great
[23:11] <nxvl> slangasek: we still have one week for planning it
[23:19] <jelmer> /win 20
[23:23] <ogra> Keybuk, any chance that we get MoM's overview pages back at some point ? while i like merging with bzr i really miss the simple overview MoM gave me
[23:23] <Keybuk> ogra: no, it's completely screwed up by the v3 packages
[23:23] <Keybuk> keeps tripping over them
[23:23] <ogra> :(
[23:23] <ogra> *sniff*
[23:24] <ogra> Keybuk, btw, take a look at the disk throughput :-D http://people.canonical.com/~ogra/osiris-karmic-20091105-4.png
[23:25] <Keybuk> nice SSD, which is it?
[23:25] <ogra> samsung
[23:25] <ogra> it's specced with 240MB/s ...
[23:25] <Keybuk> what's the modprobe taking all the time in the initramfs?
[23:25] <Keybuk> heh, nice to see we're almost maxing it
[23:25] <ogra> sadly i didnt get such rates in subsequent boots
[23:26] <ogra> its rather at 180/190
[23:26] <ogra> modprobe is getting mad about my touchscreen
[23:26] <Keybuk> ah
[23:26] <ogra> it loops several times until it times out
[23:26] <Keybuk> modprobe doesn't loop?
[23:26] <Keybuk> do you mean the driver?
[23:26] <slangasek> Keybuk: how does it trip over them?  There should be no v3 packages in testing today, and couldn't the /current/ set of merges still be made available on the website?
[23:26] <lamont> dear cryptsetup understading people... when are you around maybe?
[23:26] <ogra> well, there is a probe loop somewhere
[23:26] <slangasek> even if importing new ones fails?
[23:27] <lamont> specifically looking for what I missed on this "install" such that I have to run cryptsetup manually in initramfs in order to have any love
[23:27] <Keybuk> slangasek: well, there clearly are v3 packages
[23:27] <Keybuk> one of them begins "a"
[23:27] <Keybuk> which pretty much screws things up, since it processes alphabetically
[23:27] <slangasek> in testing?
[23:27] <Keybuk> I assume so
[23:27] <Keybuk> I looked at it for about 10 seconds
[23:28] <Keybuk> the package had extra files in its dsc, etc.
[23:28] <slangasek> v3 packages have been supported in the Debian archive for a week; I don't see how that could possibly be the case in testing already
[23:28] <wgrant> There were none in testing yesterday.
[23:29] <wgrant> The first won't migrate for another three days.
[23:30] <slangasek> Keybuk: anyway, not having the list of already-known merges available is kinda hamstringing the start of lucid; what breaks by just making the last successful run available at merges.u.c?
[23:30] <Keybuk> slangasek: the last successful run was in august
[23:30] <Keybuk> from unstable
[23:31] <slangasek> hmm
[23:31] <Keybuk> and I wiped that from the disk
[23:31] <wgrant> There is always http://qa.ubuntuwire.org/mdt/, although that doesn't show ownership.
[23:32] <slangasek> Keybuk: where's the MoM code located?
[23:32] <Keybuk> slangasek: in launchpad
[23:32] <Keybuk> lp:merge-o-matic iirc
[23:32] <slangasek> ok
[23:33] <Keybuk> slangasek: I suspect a large part of the fail is that casey doesn't have an updated dpkg on it
[23:33] <Keybuk> so it can't unpack them
[23:33] <slangasek> there shouldn't be any "them" to unpack
[23:34] <Keybuk> # Default source distrbution and release
[23:34] <Keybuk> SRC_DISTRO = "debian"
[23:34] <Keybuk> SRC_DIST   = "testing"
[23:35] <Keybuk> *shrug*
[23:35] <Keybuk> oh, it's probably because it has to download unstable too
[23:35] <slangasek> yes, which is why I want a look at the code to find out exactly which package it's failing with
[23:35] <slangasek> ah
[23:35] <Keybuk> otherwise we could never go back to merging from unstable
[23:35] <slangasek> well, does it have to be able to parse them at that time?
[23:36] <Keybuk> feel free to rewrite the code so it doesn't ;P
[23:36] <Keybuk> shouldn't we be using james_w's bzr branches this cycle anyway?
[23:36]  * Keybuk thought we were
[23:36] <slangasek> Keybuk: happy to, but MoM was the only index to what *needs* merging
[23:36] <james_w> hey Keybuk
[23:36] <slangasek> and who's responsible for it
[23:37] <Keybuk> slangasek: right, but that index is the last thing it generates
[23:37] <Keybuk> MoM is not very well written :p
[23:38] <Keybuk> hmm
[23:38]  * Keybuk tries something
[23:41] <Keybuk> slangasek: I've turned off the code that mails patches to the Debian PTS
[23:41] <Keybuk> that might be the only bit unpacking unstable packages
[23:41] <Keybuk> if wgrant is right that a v3 package is not due in testing for another few days, it'll give us a few merge runs
[23:42] <Keybuk> slangasek: could you RT for elmo to upgrade casey to have lynx's packaging chain
[23:42] <wgrant> Keybuk: ftplib was first. PTS says 6/10 days.
[23:43] <Keybuk> of course
[23:43] <Keybuk> this could still fail
[23:43] <Keybuk> if we have any packages with a base debian version newer than what's in testing
[23:43] <Keybuk> but I'm hoping it just doesn't generate a merge for those
[23:43] <slangasek> Keybuk: yep, can do that this evening


[00:09] <jimerickson> xorg-server still not fixed with latest update. log in screen is still all i get. this is on the 12.10 omap4+armhf image on a pandaboard ES.
[00:20] <jimerickson> after a reboot there isn't even a log in screen just the console.
[08:06] <marvin24> janimo: the ac100 said, that xserver doesn't crash without xorg.conf ...
[08:06] <marvin24> maybe another test point ...
[08:26] <prologic> Anyone aware of any other 1RU/2RU ARM powered servers? I've found the ZT R1801e (http://www.ztsystems.com/Default.aspx?tabid=1483) and am inquiring on price. Wondering if anyone is aware of any others like this?
[08:30] <scientes> http://content.dell.com/us/en/enterprise/d/campaigns/project-copper
[08:30] <scientes> http://www.calxeda.com/
[08:30] <scientes> prologic, ^
[08:31] <scientes> they are a bit bigger than 2U however
[08:33] <prologic> yeah I'm aware of calxeda, but avoiding it due to cost
[08:34] <scientes> also the dell link
[08:35] <scientes> thats 3U sie
[08:35] <scientes> *size
[08:35] <prologic> yeah and it's price range would be high too
[08:35] <prologic> so far I've only found the ZT system that might fit the power and cost budget
[08:38] <scientes> prologic, how much does the full 8 slow thing cost?
[08:38] <scientes> *slot
[08:39] <prologic> I'm finding out :)
[08:39] <prologic> but I bet it'll be cheaper than the Del 3RU version
[08:40] <prologic> and the Calxeda based Boston viridis is about $50k fully speced
[08:44] <lilstevie> I'll be happier using arm servers once we get a decent amount of ram in them
[11:33] <janimo> marvin24, I am not aware of creating and xorg.conf, do the L4T tools do? I don't have the ac100 open now, but will check this too
[11:37] <marvin24> janimo: L4T provides an almost empty xorg.conf
[11:37] <marvin24> I don't know if nvidia-tegra just copies it
[16:52] <prpplague> infinity: ping
[16:52] <prpplague> oops
[16:52] <prpplague> infinity: give me a shout when you have a couple minutes
[16:59] <infinity> prpplague: I'm vaguely around, what's up?
[17:02] <prpplague> infinity: see /msg
[17:51] <wookey> something is very wrong in quantal: dpkg --print-foreign-architectures is: i386 armhf
[17:52] <xnox> wookey: looks good to me.
[17:52] <wookey> but sudo apt-get install zlib1g-dev:armhf gives: zlib1g-dev:armel : Depends: zlib1g:armel (= 1:1.2.7.dfsg-13) but it is not going to be installed
[17:52] <xnox> wookey: now that's funny ;-)
[17:52] <wookey> apt seems to be deciding I'd much prefer armel for reason despite not mentioning it anywhere
[17:53] <wookey> well, the only place it is mentionned is in sources.list: deb [arch=armhf,armel] http://ports.ubuntu.com/ubuntu-ports quantal main universe
[17:53] <infinity> wookey: No, that means you already have the armel package installed.
[17:53] <infinity> wookey: At least, I suspect that's what it means.
[17:54] <wookey> dpkg --get-selections | grep zlib says zlib1g:amd64install zlib1g-dev:amd64				install
[17:54] <wookey> I have a libc6-armel-cross. that should be OK
[17:55] <wookey> dpkg --get-selections | grep armel only shows toolchain armel-cross packages
[17:56] <infinity> Weird.
[17:57] <infinity> Could be that apt hates you.
[17:57] <infinity> Drop the armel from sources.list and see if it gets wise?
[17:58] <infinity> Though, I can't see how this would be apt's fault, even if both arches were enabled.
[17:58] <infinity> Seems just plain weird.


[00:10] <veebers> thumper, wallyworld (anyone) Tests are passing, ready for another review: https://github.com/juju/juju/pull/8498 Have been doing some manual testing as well
[00:44] <wallyworld> veebers: awesome, just got out f all my meetings for a bit (until next one), will look
[00:45] <wallyworld> 181 files! close to a record :-)
[00:45] <wallyworld> i think babbageclunk has the recent record with his raft one
[00:47] <wallyworld> veebers: remind me - the utlimate plan is to go to macaroon.v2 rather than unstable right, but we need to do this in stages
[00:52] <thumper> wallyworld: there is no macaroon.v2
[00:52] <thumper> it is all unstable
[00:53] <thumper> my brain is almost exploding
[00:53] <thumper> threading the presence stuff through hit model migrations
[00:53] <veebers> wallyworld: initially we wanted to up deps but stopped short of macaroon v2-us, then we decided to get in line with what charmstore.v5 had (hence the macaroon-bakery.v2-us parts)
[01:18] <wallyworld> veebers: review done, a few small things only
[01:24] <veebers> wallyworld: awesome, I'll get them sorted posthaste
[01:25] <wallyworld> let me know if anything is unclear
[01:39] <thumper> babbageclunk: got a few minutes?
[01:41] <wallyworld> babbageclunk: are you looking at thumper's comments?
[01:41] <babbageclunk> wallyworld: yup
[01:41] <babbageclunk> also thumper: yup
[01:42] <babbageclunk> thumper: in 1:1?
[01:42] <wallyworld> ok, i'll look at thumper's PR next
[01:42] <thumper> babbageclunk: ack
[01:43] <thumper> babbageclunk: waiting
[01:48] <veebers> wallyworld: re: the comments, er, comment. Is the expectation something like "RootKey implements bakery.Storage.RootKey" or more: "RootKey returns the rootkey found in the bakery storage, used for making new macaroons." (same for Get)
[01:48] <wallyworld> if the method comes from an interface we typically use the former
[01:49] <veebers> wallyworld: cool, does it make sense to have the package in there? (i.e. bakery.) or is <inteface>.<method> the done thing? (i.e. Storage.Get)
[01:50] <wallyworld> i think we mostly do not include the package name'
[02:01] <thumper> babbageclunk: not too big, just 900 lines or so
[02:02] <babbageclunk> thumper: hey you tricked me!
[02:11] <wallyworld> thumper: review done
[02:13] <thumper> wallyworld: awesome, thanks
[02:28] <babbageclunk> Is anyone else running the pre-push git hook?
[02:33] <veebers> wallyworld: can you clarify your comment "These need to operate on both the embedded suites"?
[02:33] <veebers> babbageclunk: oh, no I'm not but I should be. Its just a matter of symlinking something isn't it?
[02:35] <wallyworld> babbageclunk: i normally run it
[02:36] <wallyworld> veebers: if a suite embeds > 1 other suite, you need to call the SetUp/TearDown funcs on all the embedded suites or else only one will get run
[02:36] <wallyworld> the other embedded suites will not get setup/torndown
[02:38] <babbageclunk> veebers: yup - see here https://github.com/juju/juju/blob/master/CONTRIBUTING.md#local-clone
[02:38] <veebers> wallyworld: ah I see, I was only matching any setups with a teardown.
[02:39] <veebers> wallyworld: does that mean I need to add a loggingsuite setuptest too? (or are it's setupsuites enough
[02:39] <wallyworld> veebers: the embedded suites may not explicitly define a SetUp (for example) *today*, but if one were to be added....
[02:39] <wallyworld> if loggingsuite doesn't have one at all, then no needed
[02:40] <wallyworld> but if there's one by virute of an embedded suite in loggingsuite
[02:40] <veebers> wallyworld: loggingsuite has a setuptest, so I'll add it too
[02:40] <wallyworld> great, yup
[02:41] <wallyworld> and order of teardown should be opposite of setup
[02:41] <veebers> ack
[02:42] <veebers> wallyworld: does the same count for setup/teardown suite? (i.e. I have the looging one there, should I add the mgo)
[02:43] <wallyworld> any embedded suite that has a setup/teardown needs to have those called by the outer suite
[02:43] <wallyworld> otherwise go will be a single, arbitrary one to call and not call the others
[02:43] <wallyworld> s/be/pick
[02:44] <veebers> ah ok, gotcha
[02:44] <wallyworld> same even goes for if you add logic to the outer setup and there's only one embedded suite
[02:44] <wallyworld> still need to then call the embedded suite setup
[02:59] <babbageclunk> thumper: are you happy with https://github.com/juju/juju/pull/8571 or do you want wallyworld to look at it too?
[03:00] <veebers> wallyworld: re: the macaroon.New wrapper, would the function be New or NewMacaroon() to be clearer?
[03:01] <wallyworld> veebers: NewMacaroon works i think as it will be in a testing package
[03:02] <veebers> sweet, makes sense
[04:02] <thumper> babbageclunk: all good
[04:02] <babbageclunk> thumper: cool, thanks!
[04:03] <thumper> jam: in our 1:1
[04:03] <veebers> wallyworld: FYI have pushed pr review changes. Also I had a go at getting a failure when using a charm with resources, but couldn't. It's possible I don't fully understand the process required.
[04:03] <jam> thumper: omw
[04:04] <veebers> I published a charm to the store, I've deployed it (it got me to auth), I upgraded the controller +  model to the 2.4-b1 and attached a new resource to teh application but it all worked
[04:05] <veebers> ah man, failling tests. I should have caught that locally :-\
[04:06] <veebers> ah, I see why.
[04:08] <veebers> babbageclunk: is there a nice way to "go test" but just build the test not run them (i.e. so I can catch compile errors)
[04:09] <babbageclunk> veebers: go test -c
[04:09] <babbageclunk> But I haven't really worked out a nice way to do that across all packages.
[04:09] <veebers> babbageclunk: cool thanks. Huh that succeeds, but there are errors to be found :0\
[04:10] <veebers> ah, just in juju/juju won't do much will it
[04:10] <babbageclunk> It only builds the tests for the package you're in.
[04:10] <veebers> aye :-)
[05:26] <kelvinliu> sorry, got a quesiton about current supported golang version, `make install-dependencies` will install golang-1.10 from snap but README.md shows it should be 1.9.  I am currently on `develop` branch
[05:26] <kelvinliu> seems README needs to be updated.
[05:26] <thumper> kelvinliu: yes
[05:26] <wallyworld> it was 1.9 until recently
[05:27] <kelvinliu> thx :)
[05:27] <wallyworld> we should tell folks just to use Go from the snap
[05:28] <kelvinliu> yes, snap is handy rather than installing manually
[05:28] <wallyworld> it is, and it's easy to try rc of next go version etc
[05:28] <wallyworld> so we can be sure juju will continue to work when next version is out
[05:29] <kelvinliu> yes, agreed
[05:29] <kelvinliu> wondering if I wanna update the README, how  do we manage branchs?
[05:30] <wallyworld> sure, feel free to propose a change. vino had the same thought but i've given her a bug to work on so you could look at a readme change
[05:32] <babbageclunk> jam: ping?
[05:38] <thumper> night all
[05:38]  * thumper goes to make dinner and have a glass of wine
[05:39] <kelvinliu> yup thx
[05:40] <kelvinliu> night thumper
[05:40] <babbageclunk> kelvinliu: he never waits for responses. I was going to say it too. :(
[05:46] <kelvinliu> haha
[06:28] <anastasiamac> a very quick and easy review plz: https://github.com/juju/juju/pull/8584
[06:58] <wallyworld> anastasiamac: looking
[06:59] <anastasiamac> wallyworld: thnx
[06:59] <wallyworld> anastasiamac: nice
[07:00] <anastasiamac> m thinking it should mayb (!) say 'odel cannot be upgraded to x.x.x while the controller is y.y.y: upgrade 'controller' model first'...
[07:00] <anastasiamac> does it read better to u^^
[07:01] <anastasiamac> wallyworld: ^^
[07:01] <wallyworld> sure, sounds good to me
[07:01] <anastasiamac> \o/
[07:01] <anastasiamac> i'll re-phrase in a sec... m just a breath (or a few) away from proposign worker/maniforld for cred check...
[07:02] <wallyworld> jam: i had to make a fix to a recent juju/description commit which added some stuff for caas support, any chance of a review before you EOD? i need this to be able to add support for model import/export in juju itself https://github.com/juju/description/pull/37
[07:27] <vino_> hi kelvin
[07:33] <kelvinliu> hi vino
[07:34] <vino_> hi.. did u manage to get details abt branches ? i closed freenode.
[07:38] <kelvinliu> yes, https://github.com/juju/juju/blob/develop/CONTRIBUTING.md
[07:39] <kelvinliu> just have a check CONTRIBUTING.md
[07:41] <wallyworld> jam: thanks for review, i responded to comments if you are interested. i'll test with model export in juju before landing
[07:44] <wallyworld> kelvinliu: i left a comment - let's change the readme to tell people ot use the snap
[07:45] <kelvinliu> yes, go point, I m updating it now
[07:54] <vino_> snap install of go ?
[07:56] <kelvinliu> yes
[07:57] <vino_> i had issue installing snap version by default installed 1.6 and that had issues with juju installation
[08:01] <wallyworld> kelvinliu: lgtm
[08:01] <wallyworld> vino_: it should have installed the latest stable go release, not sure why it installed 1.6
[08:02] <wallyworld> juju won't compile with go < 1.10
[08:02] <vino_> yes. in 16.04
[08:03] <wallyworld> hmm, no idea why off hand. i'm running bionic
[08:04] <kelvinliu> i am running bionic as well
[08:04] <kelvinliu> `make install-dependencies` will install all for u, vino
[08:04] <vino_> so i tried upgrading it to 1.10 and eventually it allowed me to do it only with longsleep/golang-backports
[08:05] <vino_> maybe i can recheck
[08:05] <vino_> https://bugs.launchpad.net/juju/+bug/1763201
[08:05] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged> <https://launchpad.net/bugs/1763201>
[08:05] <wallyworld> vino_: you sure you used the snap?
[08:05] <wallyworld> rather than the one from the archive?
[08:05] <wallyworld> i'd expect 1.6 to be in the archive
[08:05] <vino_> i did. but i can recheck again.
[08:06] <wallyworld> the reference to backports implies archive
[08:14] <vino_> i rechecked and snap installs 1.10 - i was wrong here.
[08:15] <vino_> wallyworld : i reachecked and i couldnt reproduce how i got 1.62 where i faced issues to upgrade and referred to link :  https://github.com/golang/go/wiki/Ubuntu
[08:17] <wallyworld> no worries. we should update that wiki page to refer to snap also
[08:18] <vino_> It already does.
[08:18] <vino_> https://github.com/juju/juju/blob/develop/README.md
[08:18] <vino_> snap also or snap only ?
[08:21] <wallyworld> vino_: i meant this one https://github.com/golang/go/wiki/Ubuntu
[08:22] <wallyworld> oh never mind
[08:22] <wallyworld> i didn't scroll down far enough
[08:22] <wallyworld> it already mentions snaps
[08:22] <vino_> I am not clear.
[08:22] <vino_> apologise
[08:23] <vino_> did u mean that juju README.md should also mention snap ?
[08:23] <wallyworld> for the juju readme, IMO it should be snap ony
[08:23] <wallyworld> since people on xenial etc would otherwise get an older version of go that won't ork with juju
[08:23] <vino_> ok snap only is correct. apt install info can be removed
[08:23] <vino_> ok.
[08:24] <wallyworld> yeah i think so
[08:41] <anastasiamac> wallyworld: if u plan more insomnia or r just looking for bedtime reading, PTAL https://github.com/juju/juju/pull/8586 - cred worker/manifold... :D
[08:42] <wallyworld> ok, will try and get to it after i finish this current PR
[08:42] <anastasiamac> wallyworld: was kind of hoping u'd look at it at the earliest tomorrow :)
[08:42] <wallyworld> can do
[08:52] <vino_> wallyworld : i will update the bug i opened this morning https://bugs.launchpad.net/juju/+bug/1763201
[08:52] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged> <https://launchpad.net/bugs/1763201>
[08:53] <vino_> but just to update : both snap and apt-get install go install 1.10 and works fine for me to build juju and installing.
[08:54] <vino_> i will detail in the bug report
[08:57] <vino_> snap install go --classic is fine
[08:58] <vino_> only the next option needs to be updated with - sudo apt-get install golang-go
[09:02] <vino_> hi Kelvin.. Can i assign that bug to you  as you are updating it ?
[09:36] <kelvinliu> sure, just give it to me. I v already got a PR for it.  Vino
[09:47] <vino_> i just saw that.
[09:47] <vino_> i felt u can add apt-get as it works fine for me
[09:48] <vino_> it installs latest go version.
[09:49] <vino_> i have assigned it to u
[09:52] <vino_> get u get mail notification kelvin ?
[10:00] <vino_> https://bugs.launchpad.net/juju/+bug/1763201
[10:01] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged by kelvinliu1976> <https://launchpad.net/bugs/1763201>
[10:35] <jam> manadart: if its possible while you're in the area, bug #1753418 is one reason why our ci run isn't clear.
[10:35] <mup> Bug #1753418: intermittent failure in kvmProvisionerSuite.TestKVMProvisionerObservesConfigChanges <intermittent-failure> <test-failure> <juju:Triaged> <https://launchpad.net/bugs/1753418>
[10:36] <manadart> jam: Yep. Will take a look.
[10:36] <jam> manadart: lower priority than finishing the work, but since you're working with KVM right now
[13:47] <balloons> externalreality, are you ok with doing the change for the runtime panics on that bug to start?
[13:47] <balloons> externalreality, I'll look quickly for ovh account
[14:55] <externalreality> ballons, sounds good, will do.
[18:13] <hml> balloons: subprocess.check_output is working… but have to change a lot of things over to use it…
[18:13] <hml> unhappy it’s not clear why yet
[18:18] <balloons> OK, so you are unblocked?
[18:40] <hml> balloons: currently -
[20:17] <thumper> morning team
[20:19] <rick_h_> thumper: morning and +1000 on the collapse of the juju vs -dev list/channels
[20:19] <rick_h_> in case you were looking for votes. I've been saving up my paper ballots :P
[20:19] <thumper> balloons: where are we with 1.25.14 build needs - go/1.8 etc
[20:20] <thumper> rick_h_: heh, ack
[20:20] <balloons> good morning thumper
[20:24] <thumper> also status for 2.3.6?
[20:25] <thumper> since we are co-opting the release call for whole team meeting :)
[20:25] <balloons> thumper, yea.. We have 3 releases we need to do. 1.25, 2.3, and 2.4
[20:25] <thumper> yeah
[20:25] <thumper> 2.3.6 first, then 2.4 then 1.25
[20:26] <balloons> thumper, 2.3.6 has to have a call on if we wait for the container-image-metadata or not
[20:26] <thumper> we've waited long enough for the 1.25 build, another week or two won't kill them
[20:26] <thumper> I don't think we need to wait
[20:26] <thumper> I'm happy enough that going into 2.4
[20:26] <thumper> field are working around the issue now
[20:26] <thumper> it isn't critical
[20:26] <thumper> 2.3.6 is
[20:26] <balloons> this needs to land then, and we should be good https://github.com/juju/juju/pull/8589
[20:27] <thumper> balloons: is mongo 3.6 in bionic yet?
[20:27] <balloons> thumper, it went into the queue a few hours ago. Needs approval, then it will land in proposed
[20:29]  * thumper nods
[20:29]  * thumper jumps in call 1 of 3
[20:35] <veebers> Morning all o/
[20:38]  * balloons tips hat
[21:31] <wallyworld> kelvinliu: if you're online, come to team meeting?
[21:40] <babbageclunk> morning everyone
[21:58] <hml> veebers: if you would, i updated the pr from yesterday with the change
[21:59] <veebers> hml: mean, you have a link?
[21:59] <veebers> hah I have a Link, I hear him crying right now :-P
[21:59] <hml> veebers: https://github.com/juju/juju/pull/8582
[22:09] <hml> feeling paranoid - i manually did the upgrade series setups on a 2.3.6 config - then did juju upgrade-juju to get to 2.4-beta1 and the unit was still happy.  :-)
[22:13] <veebers> hml: what's the difference to what the script used to be doing (with the .tmp that's different to using --output-file) don't both write a 'tmp' file and then mv it in place at the last second?
[22:14] <hml> veebers: there are shades of “last second”
[22:15] <hml> veebers: i could have just removed the os.rename and done the mv after ifdown
[22:15] <hml> veebers: but since we can specify the input file, it’s “nicer” to specify an output file too?
[22:16] <veebers> hml: perhaps I don't fully understand the script . . . ah I see, right *that's* the important part here, not moving the interfaces file to bak before it's time
[22:16] <veebers> I was focusing on the wrong part :-)
[22:17] <hml> veebers: i changed so it was a copy to .bak - then the replacement was done very last we could
[22:17] <veebers> hml: ack, that makes sense and obvious now that I see it
[22:18] <veebers> hml: LGTM
[22:18] <hml> veebers: TY!  :-)
[22:22] <veebers> thumper: Seems it's really easy to add gometalinter to emacs (using spacemacs too): https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Blang/go#pre-requisites
[22:23] <babbageclunk> veebers: Also really CPU hungry
[22:24] <babbageclunk> (Probably because of the size of the codebase)
[22:25] <veebers> babbageclunk: ah right, I'm not so keen to add more CPU load to my emacs usage ^_^
[22:28] <vino> C, c++
[22:28] <vino> and python scripting
[22:29] <vino> in cloud i used JAVA RestApi
[22:29] <veebers> vino: might be wrong channel :-)
[22:30] <vino> yes yes.
[22:30] <veebers> vino, kelvinliu: Where you making changes to CONTRIBUTING.md? I think I want to make some updates too
[22:30] <vino> i am still sleepy
[22:31] <veebers> ^_^
[22:31] <vino> i already generated a PR
[22:31] <vino> in the Local Clone section.
[22:31] <veebers> Is master even a branch we really care about now? I think CONTRIBUTING.md should mention develop, not master.
[22:32] <vino> https://github.com/juju/juju/pull/8588
[22:32] <veebers> vino: lol that's exactly the change I was going to make
[22:33] <vino> Oh sorry.
[22:33] <vino> i missed something and Kelvin did it yesterday in README>md
[22:33] <veebers> vino: hah no it's good, you got to it first.
[22:33] <vino> the go version
[22:34] <veebers> vino: note, there is a typo in the PR typo, it's a little long too (will be truncated in the git log)
[22:38] <vino> done.
[22:38] <vino> corrected it
[22:40] <veebers> vino: you'll need to update the summary part too, it still has "…ection with correct path" as the first line
[22:41] <vino> good eyes.
[22:46] <hml> has anyone tried to bootstrap from a mac recently?  (i’m using a remote openstack cloud)
[22:48] <wallyworld> babbageclunk: i might be a minute late for standup, so tell some jokes if i'm not there on time :-)
[22:48] <babbageclunk> wallyworld: I'll do my best man, but if the audience are expecting you they'll still be disappointed
[22:57] <hml> how do you build agents for a different processor?  trying to bootstrap 2.4-beta1 (develop) it complains about not having agent binaries, even if they are built during bootstrap.  Wrong OS?  and the 2.4beta1 binaries are not online yet
[23:03] <babbageclunk> veebers: review plz? https://github.com/juju/juju/pull/8590
[23:04] <veebers> babbageclunk: sure thing!
[23:04] <babbageclunk> hml: Don't know, sorry! anastasiamac/balloons/thumper?
[23:05] <babbageclunk> veebers: fanks
[23:05] <hml> i was able to bootstrap with 2.3.5 at least?
[23:07] <babbageclunk> I think once you have a controller you could build the binaries for the different arch and then use sync-tools to push them up, then upgrade?
[23:08] <hml> hrm
[23:08] <hml> get juju to build the binaries?
[23:09] <hml> babbageclunk: how would you get the controller to build the binaries?
[23:10] <babbageclunk> no, build them locally - I think by setting GOOS and GOARCH?
[23:11] <babbageclunk> hml: Something like this https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5
[23:11] <hml> haven’t played with those before
[23:11] <veebers> babbageclunk: "Thanks ants, Thants". lgtm
[23:12] <babbageclunk> veebers: Just... look around you!
[23:12] <veebers> hml: with 2.3.5 it would have pulled agent from streams, for 2.4-b1 you'll need to use the testing streams to do that
[23:12] <veebers> babbageclunk: ^_^ that's the one
[23:12] <hml> veebers: there’s a testing streams?
[23:13] <veebers> hml: for each build we generate a stream entry and put it in s3.
[23:13] <hml> veebers: though that won’t allow me to test my code easily?
[23:13] <hml> veebers: how do you use it?
[23:14] <veebers> hml: not if you're needing an agent you've just built :-\
[23:14] <hml> veebers: sounds like i need to learn to use GOOS and GOARCH?
[23:15] <hml> veebers: i was just courious
[23:31] <veebers> hml: if you have a log of the upgrade series test too that would be useful
[23:38] <hml> veebers: not sure if the logs i have now are useful?
[23:38] <hml> veebers: i know where they are failing now…
[23:38] <hml> veebers: if i find a new one, i’ll forward along :-)
[23:39] <veebers> hml: sweet :-)
[23:40] <hml> veebers: eventually i’d be curious as to what broke which lead me to using subprocess.check_output to run remote commands
[23:40] <hml> some juju some not
[23:40] <hml> veebers: it’s not warm fuzzy that this is needed
[23:40] <hml> but i want it done too :-)
[23:41]  * hml waves goodnight!
[23:41] <veebers> o/
[23:53] <babbageclunk> bye hml