[00:05] <YokoZar> Is there a way to tell dpkg to walk through a postinst script step by step?  I need to figure out where it's failing (and it only seems to fail in pbuiler environment for some reason)
[00:06] <superm1> YokoZar, add a set -x to the postinst, you should see each command
[00:06] <YokoZar> superm1: thanks
[00:19] <MTecknology> Keybuk: Hey, imbrandon and I would like to work on this upstart thing.. I'd like to get every init.d script converted to an upstart script so we can maybe remove sysv-rv, sysvinit-utils, and initscripts as dependencies from upstart. jdong said I should talk to you about it.
[00:19] <Keybuk> ok
[00:21] <MTecknology> Keybuk: I'm obviously very novice, but it's something I'd like to work on for 10.10; You think you could steer me in the right direction? Or maybe there's something I'm clueless about that would make what I want to do pointless..
[00:22] <Keybuk> no, nothing in the way - just nobody's had time
[00:23] <MTecknology> Keybuk: if that's the only reason then... I'm perfect. I don't have a whole lot of time but I can devote ~1/2 of my FOSS time to it until it's done.
[00:23] <persia> cody-somerville: It may be too late to mean anything this time, but in general I prefer the term "defer" to "decline": I'm not sure we've ever had a case (and I hope we never do) where we really mean "decline" in any permanent sense.
[00:24] <MTecknology> Keybuk: Is there any wiki that would get me going on it?
[00:25] <Keybuk> no, not really
[00:25] <Keybuk> Upstart config files are quite different from initscripts
[00:25] <Keybuk> initscripts are basically programs that start and stop services
[00:25] <Keybuk> in Upstart, Upstart is that program, and the config files tell it what to do
[00:25] <Keybuk> an Upstart script can be as simple as "exec /sbin/daemon"
[00:26] <Keybuk> with all the tracking of the processes and stuff being down by Upstart
[00:26] <Keybuk> a good place to start is "man 5 init"
[00:27] <MTecknology> I've been looking around at the differneces. upstart seems to be very similar to openrc
[00:29] <Keybuk> I don't know what that is
[00:29] <MTecknology> It's Gentoo's replacement of the same thing
[00:30] <ion> OpenRC is dependency based.
[00:30] <ion> And it’s not an implementation of init.
[00:31] <MTecknology> Isn't Upstart pretty much dependency based too?
[00:32] <MTecknology> start on stopped udevtrigger
[00:32] <persia> That's just a local configuration though.
[00:33] <Keybuk> no
[00:33] <Keybuk> Upstart is *not* dependency based
[00:34] <Keybuk> let me explain
[00:34] <jdong> Keybuk: ack sorry, I sent MTecknology over but I also wanted to preface the question a bit but was AFK
[00:34] <Keybuk> I'll use a different example of a dependency based system to illustrate
[00:34] <Keybuk> dpkg/apt
[00:34] <jdong> Keybuk: I was mainly curious if you've communicated your thought on what events you'd like arbitrary services to start on, etc.
[00:34] <Keybuk> packages have dependencies
[00:34] <Keybuk> when you install apache, that will also install a whole bunch of other packages
[00:34] <Keybuk> libraries, other daemons, etc.
[00:35] <Keybuk> when you install squid, that might share some of those in common, and others it won't
[00:35] <Keybuk> if you uninstall apache, apt can "clean up" the unused dependencies - but won't remove those used by squid
[00:35] <Keybuk> then when you uninstall squid, again you can clean up the unused deps
[00:35] <Keybuk> the important thing is that it's top down
[00:35] <Keybuk> what you want is apache and squid
[00:35] <Keybuk> what you get is a whole bunch of packages
[00:35] <Keybuk> dependency based init systems work in *exactly* the same way
[00:36] <Keybuk> you say you want apache and squid started
[00:36] <Keybuk> and they work out what else they need to start (and in what order) to get you there
[00:36] <Keybuk> likewise if you stop apache and squid, they may be able to stop other ancillary services
[00:36] <Keybuk> *this is NOT how Upstart works*
[00:36] <Keybuk> Upstart is event-based
[00:36] <Keybuk> basically it's backwards
[00:36] <Keybuk> rather than having goal services, instead it has events
[00:37] <Keybuk> as a result of events, services might be started
[00:37] <Keybuk> to put it one way
[00:37] <Keybuk> services are started because the things they depend on are now running
[00:37] <Keybuk> to use dpkg as the example
[00:37] <Keybuk> you can't install apache
[00:37] <Keybuk> but if you install a whole bunch of libraries, dpkg might realise you had everything you needed for apache and install apache for you ;-)
[00:38]  * persia is kinda glad that upstart works that way and even moreso that dpkg doesn't
[00:38] <Keybuk> right
[00:38] <Keybuk> I think dep-based is correct for package managers
[00:38] <Keybuk> ;-)
[00:38] <Keybuk> the reason I think event-based is right for service managers is hardware
[00:38] <james_w> is there any way to use the event information in reverse for dependencies?
[00:39] <Keybuk> let's take the easy example of the Bluetooth service
[00:39] <Keybuk> it depends on hardware
[00:39] <Keybuk> how would you cause the hardware to magically appear when required (which is what the dep-based model requires)
[00:39] <ion> I’d love a package manager that installs Apache, OpenOffice and OpenTTD because i wanted GNU libc.
[00:39] <jdong> james_w: well I used to graph based on events as a DAG, and that reasonably communicated bootup "order"
[00:40] <james_w> If you are on a simple system, and want to start some complex daemon, do you have to work out which series of events you have to trigger and cause them to be emitted to get the daemon to run, or is there a way to ask for the daemon to be started, with anything else that is needed being done as well?
[00:40] <Keybuk> james_w: yes, but it's important to remember that Upstart doesn't work that way
[00:40] <persia> james_w: You mean have some ${upstart:Depends} that tracked which events were needed, which packages provided those events, and did the right thing?  My fear there is twofold 1) not everything is migrated to upstart and 2) many services do poorly in chroots, so that makes for awkward build-deps.
[00:40] <Keybuk> james_w: if the complex daemon can be running, it's already running
[00:41] <james_w> true
[00:41] <james_w> so it would have to be disabled, and then asking it to start would start it
[00:41] <Keybuk> james_w: I guess
[00:41] <james_w> so when we have disabled jobs, there may be a desire to enable chains such that you can bring up sets of services that aren't run by default
[00:41] <persia> Keybuk: Consider the case of daemons that are configured *not* to run by default, but only on demand.  This is common with game servers, for example.  Does upstart do the right thing if one calls e.g. `start wesnoth-server`?
[00:42] <Keybuk> at this point, I'm not that interested in daemons that are configured to not run by default
[00:42] <Keybuk> since Upstart doesn't support that
[00:42] <persia> Ah, so those should stay initscripts for now.
[00:42] <james_w> persia: the current way that you can do that is to have no "start on" line, so yes, that will start that daemon, but will assume that the job does everything that is needed from the current state of the system
[00:43] <MTecknology> wow.. I iz opened a can of werms :P
[00:43] <ajmitch> MTecknology: so you can see why it hasn't just been done yet :)
[00:44] <MTecknology> ajmitch: ya, I still want to do it
[00:45] <imbrandon> persia: good call, that bug is still itching at me , i still think its wrong to have server (even game) installed and not running by default
[00:45] <Keybuk> james_w: you'd be surprised how few services *actually* depend on each other
[00:46] <Keybuk> at least application-level services that sysadmins might want to deal with manually
[00:46] <james_w> yeah
[00:46] <persia> imbrandon: In general I agree with you, but I've seem some bug reports recently specifically wanting ad-hoc game servers.
[00:46] <james_w> I was thinking of perhaps custom jobs on top, but you can do that with custom events instead
[00:46] <Keybuk> that being said, I do have a plan
[00:47] <james_w> insert some synthetic event at a certain level of the DAG and then just emit that event to start everything above it
[00:47] <MTecknology> what's the plan?
[00:47] <imbrandon> persia: yea but like in the case of wensworth its a bug in the gameserver, e.g. its coded diffrent for windows/linux, windows runs on demand and dosent install a service, thus thats how it should be on linux if they want it ad-hoc, if you install the service then it should run by default
[00:47] <imbrandon> imho
[00:48] <Keybuk> upstart in maverick separates events and states more than the current version
[00:48] <Keybuk> services will be more often bound to states than started by events
[00:48] <Keybuk> (states are still described in terms of events)
[00:49] <Keybuk> a job in manual mode will have a true state, but not be started
[00:49] <Keybuk> in that situation a sysadmin can start and stop
[00:49] <Keybuk> if the state is false, but the bits that are false are references to other jobs, the "start" command will work and just start both
[00:49] <imbrandon> Keybuk: hum manual mode huh? sounds like a good solution for the game-servers ... *thinks*
[00:50] <Keybuk> if the state is false, and the bits that are false depend on events, the "start" command will fail
[00:50] <persia> Keybuk: And if the bits that are false are hardware, would it just emit a helpful message (e.g. "Please insert a bluetooth dongle if you'd like to make your pan work")?
[00:51] <Keybuk> I think we could invent a system for cataloguing helpful messages
[00:51] <Keybuk> I suspect /sbin/start would say something a bit jargony
[00:51] <Keybuk> while the GNOME UI would be helpful
[00:52]  * persia backs away from dangerous sounding mixing of system/user interfaces
[00:52] <imbrandon> Keybuk: is there an API where a (GUI) program could start a service daemon when its running and stop it when it closes ?
[00:52] <Keybuk> imbrandon: yes, it's called D-Bus
[00:52]  * imbrandon facepalms , shoulda thought of that
[00:53] <jdong> Keybuk: now, what conventions would you like to be followed for upstart-ifying init scripts?
[00:53] <imbrandon> persia: see where i'm going with this ? maybe a generic wrapper script for game clients, and the daemon side set to manual ...
[00:54] <Keybuk> I'm not sure there are conventions just yet
[00:54] <jdong> Keybuk: ok, I can forsee our desire to start , say, apache after a GUI is up
[00:54] <jdong> (on desktop systems)
[00:54] <MTecknology> Keybuk: so, is this maybe a little too advanced for my skill level, or do you think I could work myself into helping without too much headache?
[00:54] <persia> imbrandon: That's fine.  What I fear is some little window popping up and saying "The following services didn't start" or similar.
[00:54] <Keybuk> MTecknology: well, there's like half a dozen people on the planet who know Upstart well
[00:54] <Keybuk> having another is always good
[00:55] <Keybuk> persia: actually, having apport do that for services we know *should* be running wouldn't be bad
[00:56] <imbrandon> persia: i was gonna sak, why would that be bad ?
[00:56] <imbrandon> ask*
[00:56] <persia> Keybuk: I've mixed thoughts about that.  How do we define "should"?
[00:57] <Keybuk> ?
[00:57] <lifeless> persia: morally wrong not to.
[00:58] <imbrandon> persia: as long as you could turn the messages off for certain services it thinks *should* be started for the corner cases i think it would be an overall good thing(tm)
[00:59] <MTecknology> Keybuk: Would I have any need to actually learn C to contribute to it or is there room for working on scripts only?
[00:59] <persia> Well, fine, if Y'all really want it.  I think it breaks the user/admin paradigm.  I want there to be *one* place that the admin checks for that stuff, be it handheld, server, laptop, etc.  That's a core requirement.  That said, I'd like to trivially mask that sort of thing from non-admins.
[00:59] <MTecknology> Keybuk: I actually just got interested today because I'd like to see sysv go away
[01:00] <persia> And, in general, I prefer not to consider myself an admin when using a machine I administrate just because I'm logged in.
[01:00] <Keybuk> MTecknology: I don't think you'd have to learn C, no
[01:00] <Keybuk> persia: but we're not talking about admins
[01:00] <Keybuk> there's certainly good cases for users being helped to file bugs when their system misbehaves
[01:01] <MTecknology> I have a 20sec boot on my 5400rpm drive - I'm happy for the most part, but it took a good chunk of hacking at things to get there
[01:02] <persia> Keybuk: Hrm.  My perception may be outdated (and I may find this sad in some ways), but I can see that.  Could we not just have a syslog facility that talked D-Bus to handle that case?
[01:04] <Keybuk> how would that help the user file the bug?
[01:04] <MTecknology> lol... dhillon-v10 is interested in that team too
[01:04] <Keybuk> that's what apport is for
[01:05] <persia> Ah, that takes away all my concerns :)  apport hooks for upstart jobs is definitely the way to go.
[01:05] <persia> So the failure gets logged normally, and we have decent UIs for arbitrary environments that let the bugs get reported.
[01:06] <Keybuk> exactly
[01:06] <Keybuk> you could have, e.g. services that fail result in an e-mail to root with the output
[01:06] <MTecknology> bbiab - gotta run to the store quick
[01:07] <persia> Don't we already have a means to notify admins of pending unprocessed apport bugs?  I thought there was a /var/crash scan or something.
[01:08] <Keybuk> no, I mean as alternatives for apport
[01:08] <Keybuk> e.g. on servers
[01:09]  * persia was under the impression there was such a thing already, and has used bits of apport to file bugs on servers.
[01:10] <persia> But if it doesn't exist, yes, certainly, it ought.
[01:10] <persia> Same applies to managed farms of desktops, etc.
[01:21] <imbrandon> Keybuk: so it the "manual" mode currently in upstart thats publishing with lucid and/or is it the equiv of not having a "start on" line ...
[01:21] <Keybuk> I don't follow
[01:22] <imbrandon> e.g i have a service now, thats based on init.d , i want it installed but not running unless someone types "start <blah>" or dbus tells it to start
[01:22] <imbrandon> can i do that in lucid now or have to wait for mavric
[01:22] <imbrandon> if i convert to upstart
[01:24] <Keybuk> you have to wait
[01:24] <imbrandon> i know thats normaly not debian policy and you arent really worried about that corner case atm, but just curious if its possible ( its for a game server that has a bug in lp because it runs on install )
[01:25] <imbrandon> thus they want the game server to only run when the gui client does ( like in windows )
[01:25] <imbrandon> but keep the option to have it as a dedicated service , see the delima
[01:25] <imbrandon> ;)
[01:27] <persia> imbrandon: Or have it only run on-demand when the client runs, or when manually started (teg is an example of an implementation of that which once worked, but needs love)
[01:27] <persia> imbrandon: So if you and I want to play together, only one of us needs start the service.
[01:28] <imbrandon> persia: yea, thats why i'm thinking about a wrapper script for the gui, but i wanna make it generic so we can wholesaly ( is that a word ) use it
[01:28] <MTecknology> btw - I was also wondering what purpose plymouth has aside from the pretty splash
[01:29] <imbrandon> for other "game servers" , imho i think a server is a server and should be treated via debian policy, but i do see the users PoV
[01:29] <imbrandon> persia: ^
[01:29] <imbrandon> MTecknology: to serilize the console on startup
[01:29] <MTecknology> imbrandon: what's that mean?
[01:30] <persia> imbrandon: I'm of much the same preference, but gave up back in feisty or so because of bug reports.
[01:30] <imbrandon> MTecknology: i'm probably not the best to explain it, but basicly pre-gui messages and ttys etc
[01:31] <MTecknology> imbrandon: I'm just lost because the package description even says that it only provides boot animation
[01:31] <MTecknology> not only, but that's all it says about itself
[01:32] <imbrandon> MTecknology: heh its probably a bit light on the documentation , its still fairly new
[01:33] <imbrandon> MTecknology: basicly its the glue between grub and desktop for the user ( lots of other stuff do the system stuff like whats in the initrd and upstart )
[01:34] <imbrandon> MTecknology: like i said though, i'm probably not the best to explain it, but i do know its more than just a simple splash image, otherwise we would still use usplash
[01:34] <MTecknology> imbrandon: I have no initrd and I have very little going on between desktop and system; It just feels like a little bloat for me and I don't see why it's a Depends instead of Recomends
[01:36] <RAOF> MTecknology: A quick example of where you need to have a properly multiplexed terminal: You've got a dmcrypt device, so need to be prompted for a passphrase on bootup.  Also, this boot fsck is running, and offers you the option to cancel the check.
[01:36] <RAOF> As upstart starts things in parallel, these are both started, and both interested in your input.  Where does your keyboard input go?
[01:37] <MTecknology> fifo?
[01:37] <RAOF> But “first” is no longer well-defined, because upstart is starting things in parallel.
[01:38] <RAOF> Does the “c” that I type to cancel the fsck actually get fed to fsck?  Does it get fed to the cryptsetup prompt?  Is this deterministic between boots?
[01:39] <jdong> RAOF: I guess that's the point of plymouth?
[01:39] <jdong> at least that's what I understood plymouth to be. never looked at it (tm)
[01:40] <MTecknology> so what's the solution?
[01:40] <imbrandon> MTecknology: the solution to what ?
[01:40] <jdong> MTecknology: I'd imagine it'd to be to define a higher order abstraction to user interation, for example, result = ask_the_user(question)
[01:40] <jdong> and I was under the assumption that's what Plymouth was for
[01:41] <MTecknology> imbrandon: the solution for how plymouth handles that
[01:44] <imbrandon> MTecknology: i dont know how it handels it technicly, i just know it does
[01:44] <imbrandon> :)
[01:44] <jdong> MTecknology: if plymouth handles that, then the solution is fairly intuitive.
[01:44] <jdong> before each app would (1) print question (2) read response.
[01:44] <RAOF> MTecknology: I'm not sure of the details, but it appears to serialise input (and, I presume, output) into a couple of streams - the “I'm blocking on this” stream, ala cryptsetup, and the “user might want to press this at some point” stream, ala fsck cancelling.
[01:45] <jdong> now, plymouth would be the only one that (1) print question (2) read response)
[01:45] <jdong> and other services ask plymouth to bug the user.
[01:46] <MTecknology> so if the user NEVER needs to interact with more than one thing during boot and no application ever accepts keyboard input more than one at a time during boot, and the user doesn't want a pretty boot screen, then plymouth has no purpose?
[01:47] <imbrandon> MTecknology: right, but thats alot of assumptions , especialy on a global scale like ubuntu
[01:47] <RAOF> MTecknology: Well, and nothing wants to output status messages to the console.
[01:47] <jdong> MTecknology: I suppose, but that won't be the case in most setups
[01:48] <imbrandon> MTecknology: you would just a get a black screen after grub loads untill your gui starts, even if say fsck is going or something, with no idea whats happening
[01:48] <MTecknology> jdong: I figured no setup can have those assumptions unless it's an embedded device
[01:49] <MTecknology> so plymouth now makes a whole lotta sense
[01:49] <jdong> MTecknology: exactly
[01:49] <jdong> imbrandon: haha once I was stupid enough to turn on fsck on my N800.
[01:49] <imbrandon> jdong: lol
[01:49] <MTecknology> what happened?
[01:49] <jdong> imbrandon: I figured since it was *cringe* using ext2 that bad poweroffs were going to be harsh on it.
[01:49] <ajmitch> jdong: how long did you wait for?
[01:50] <jdong> MTecknology: Zero block group? (y/n)
[01:50] <jdong> (touchscreen driver not up)
[01:50] <jdong> CRAP.
[01:50] <ajmitch> ouch
[01:50] <MTecknology> oh
[01:50] <jdong> :)
[01:50] <MTecknology> what's that do?
[01:50] <ajmitch> jdong: that was foolish
[01:50] <MTecknology> zero block grou*
[01:51] <ajmitch> MTecknology: he means that he had no way of entering y or n :)
[01:51] <MTecknology> I got that part :) - I was curious about what that does though
[01:51] <MTecknology> I haven't done anything with fsck in a LONG time other than watch it fly through my disk one in a while
[01:51] <imbrandon> lmgtfy.com hahaha j/k ;)
[01:51] <jdong> MTecknology: generic "fsck found a problem, but just zeroing the problem area technically makes it go away, should I do that?"
[01:52] <MTecknology> oh
[01:52] <jdong> MTecknology: (which is again why you don't blindly say y to everything fsck asks and assume it smartly fixes your disk)
[01:52] <MTecknology> brb
[01:52] <ajmitch> jdong: I'm surpised you didn't have some crackful FS on ther instead
[01:52] <jdong> it's the equivalent of your mechanic just ripping out hoses that look cracked and saying there's no more defective pipes :)
[01:52] <imbrandon> btrfs ?
[01:52] <jdong> ajmitch: in my opinion the default setup of running ext2 and not fscking no matter what... is pretty crackful
[01:52] <ajmitch> imbrandon: too stable for jdong
[01:53] <jdong> ajmitch: but I totally understood that they didn't have a "cough once for y, twice for n" inputdev.
[01:53] <imbrandon> fuse zfs / ?
[01:53] <jdong> :)
[01:53] <jdong> ajmitch: ANNOYINGLY the rocker was wired up to the *arrow keys* and put ^[[A's and so on to the screen.
[01:53] <jdong> so I wouldn't have imagined it to be a hard thing to map that to y vs n....
[01:53] <jdong> (yeah yeah, file a bug, write a patch)
[01:54] <ajmitch> jdong: sure, and remap that once booted?
[01:54] <jdong> ajmitch: hehe yeah :)
[01:54] <imbrandon> as long as you dident forget what one was maped to n
[01:54] <imbrandon> red / green ?
[01:55] <ajmitch> or typing a password by left-right combos
[01:55] <imbrandon> everyoens n800 passwd would be "aaa"
[01:56] <imbrandon> like arcade game high scores
[02:25] <MTecknology> That was awesome chatter :)
[02:25] <MTecknology> thanks everyone
[02:49] <TheMuso> 8/c
[02:57]  * ccheney think he is confused
[02:57] <ccheney> didn't we disable bug reporting directly on launchpad at some point?
[02:58] <ccheney> then we disabled bug reporting in the Help menu, but now launchpad bug reporting seems reenabled, so by default we are not going to be getting bug reports with apport info anymore?
[03:03] <MTecknology> ccheney: ?no-redirect or something like that?
[03:03] <MTecknology> ccheney: sometimes it's a pita to know what package is causing the issue - that's a feature that I personally like
[03:13] <wgrant> ccheney: The root Ubuntu +filebug will redirect.
[03:13] <wgrant> If you go directly to a source package's +filebug, it will not.
[03:13] <wgrant> It will also not redirect for you at all, since you are in -bugcontrol.
[03:15] <ccheney> wgrant: ah, i see that is why :)
[03:15] <ccheney> wgrant: i forgot that it might look different since i am in bugcontrol :)
[03:26] <Keybuk> urgh
[03:26]  * Keybuk just, seriously, had a "could you turn the computer *on*" type moment on a bug
[03:26] <ccheney> lol
[03:27] <sladen> send them a descreet wake-on-lan packet
[03:27] <Keybuk> bug #570692
[03:33] <imbrandon> Keybuk hahahah ( @the bug )
[03:33] <Chipzz> diediedie :)
[03:34] <Keybuk> we need a channel where the Code of Conduct does not apply
[03:34] <Keybuk> #ubuntu-two-minutes-hate or something
[03:41] <sharky> araaraaraara
[03:44] <temugen> Keybuk: What are the units on /sys/dev/block/#:#/size ? And just as important, what are the units on the "at <location>" of ureadahead --dump?
[03:44] <Keybuk> temugen: err, they're units ;)
[03:44] <Keybuk> probably bytes
[03:45] <Keybuk> but they might be different, one might be blocks
[03:45] <temugen> I thought the <location> was bytes just based on... well, I don't know, but the size is different for sure
[03:45] <Keybuk> 31252480
[03:45] <Keybuk> wing-commander scott% cat /sys/block/sda/size
[03:45] <Keybuk> 31252480
[03:45] <Keybuk> that looks like blocks to me
[03:46] <Keybuk> (a block is generally 512 bytes from a disk pov)
[03:46] <Keybuk> not sure about offset, bytes I expect, but not sure
[03:47] <Keybuk> might be blocks too
[03:47] <temugen> ah, ok.
[03:47] <Keybuk> (whereas the page cache operates in 4096 byte pages)
[03:47] <temugen> indeed
[03:48] <temugen> thanks for clearing that up
[03:48] <Keybuk> some disks might use 4096 byte blocs
[03:48] <Keybuk> instead of 512 byte ones
[03:48] <Keybuk> just to add to the confusion
[03:50] <temugen> Keybuk: I figured this much. There wouldn't happen to be an easy way to deduce the block size from the hdd number of --dump, would there?
[03:50] <Keybuk> I don't think I know the answer to that
[03:50] <Keybuk> it'll be in /sys somewhere if the kernel exposes it
[03:50] <temugen> No problem :) I'll see what I can find
[03:51] <Keybuk> ah
[03:51] <Keybuk> queue/physical_block_size
[03:51] <Keybuk> queue/logical_block_size
[03:51] <jdong> is that what blockdev --report returns?
[03:52] <temugen> jdong: blockdev --report works :)
[03:52] <jdong> I don't know if the sysfs entries go through the same code path :)
[05:53] <pitti> Good morning
[05:53] <pitti> ccheney: oh, thanks!
[06:07] <ccheney> pitti: no problem :)
[06:07] <ccheney> pitti: my results seem different from what others have posted, i'm not sure what is going on
[06:08] <slangasek> superm1: you haven't been seeing bug #570843, have you?
[06:10] <pitti> ccheney: I have a theory; the "SKIP" might have been a red herring all along, and it was the broken variant
[06:10] <pitti> "U.S. English" is a bogus variant
[06:13] <ccheney> ok
[06:17] <pitti> ccheney: hm, https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/548891/comments/8 only has "SKIP", and an empty variant
[06:17] <pitti> perhaps it's a combination of both
[06:19] <superm1> slangasek, no i haven't seen that
[06:19] <slangasek> superm1: ok - phew :)
[06:20] <superm1> not to say it's not a real bug though with his env, that guy definitely needs to run in debug mode and apport-collect
[06:21] <slangasek> superm1: right - just trying to figure out the scope of the bug, sounds like it's definitely a corner case (and the submitter has already said he's not going to be able to help us debug, sigh)
[06:21] <superm1> dang
[06:29]  * ccheney is headed to bed now
[06:32] <pitti> ccheney: good night! I'll answer in the bug report for something to try, and test it in the meantime
[06:57] <kirkland> bdrung: http://people.canonical.com/~kirkland/Museum back online ;-)
[06:57] <micahg> kirkland: where's karmic?
[06:58] <kirkland> micahg: not yet done
[07:05] <pitti> kirkland: ooh, thanks!
[07:06] <kirkland> pitti: ;-)
[07:07]  * pitti gets a ticket for a year
[07:08] <kirkland> pitti: :-)  the exhibits need some freshening up
[07:13] <kirkland> pitti: whoa, lookey there .... http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
[07:13] <kirkland> pitti: ;-)
[07:16]  * micahg is #14 \o/, althought half were probably fixed upstream :)
[07:17] <pitti> kirkland: uh, congratulations!
[07:17] <pitti> kirkland: seems you fixed a ton in the last week :)
[07:17] <pitti> (last time I checked I had 4 more or so)
[07:17] <kirkland> pitti: yeah, might be a bug in the accounting; i'm not sure what happened
[07:18] <kirkland> pitti: but i had noticed it hadn't been updated in a few days
[07:18] <kirkland> pitti: meh
[07:18] <pitti> kirkland: it was a nice race! *hug*
[07:18] <kirkland> pitti: *hug*
[07:18]  * pitti still has some SRUs up his sleeve, but not enough to fix 12 bugs
[07:18] <kirkland> pitti: there's still plenty of room for SRUs
[07:18] <kirkland> heh
[07:19] <kirkland> pitti: speaking of, i'll be bugging you about that;  we've got a stack for eucalyptus, and a handful of others
[07:19] <kirkland> pitti: speaking of, can i get an sru ack of Bug 570870 ?
[07:19]  * kirkland is off to bed
[07:20] <pitti> kirkland: acked 20 seconds ago :)
[07:21] <pitti> kirkland: btw, in general it's easier to just upload, and have us review from the queue; prior discussion is only needed if you are unsure whether it's suitable
[08:10] <dholbach> good morning
[08:13] <sladen> guten morgen herr Holbach meister
[08:14] <dholbach> I don't know about any Meister :)
[08:14] <dholbach> hey sladen :)
[08:14] <sladen> actually, that's not very good faux German, it's got too many spaces in it!
[08:19] <mvo> dholbach: you are on libribox! http://librivox.org/good-sense-by-baron-paul-henri-thiry-dholbach/
[08:19] <dholbach> hahaha
[08:19] <dholbach> thanks mvo
[08:19] <mvo> my pleasure "baron"
[08:56] <dpm> hi slangasek, I've got the translations stats for the release notes as we discussed yesterday -> http://people.canonical.com/~dpm/lucid-translation-stats.html . Shall I go ahead and just add them to the release notes wiki page?
[08:57] <slangasek> dpm: to https://wiki.ubuntu.com/LucidLynx/ReleaseAnnouncement, please
[08:58] <dpm> ah, sorry, yes, the announcement, not the notes
[09:00] <micahg> slangasek: is the annoucement/notes only for stuff in main or universe as well?
[09:02] <slangasek> micahg: the announcement goes into almost no detail about packages, so nothing in universe would apply; the release notes can include notes about universe
[09:03] <micahg> slangasek: ok, we'll probably need to put something in there for lightning, but will discuss with chrisccoulson
[09:09] <dpm> slangasek, ok, two final questions:
[09:09] <dpm> 1) I added a note below the FIXME pointing out that stats are now up to date. Shall I leave it like this, or just remove the FIXME alltogether?
[09:09] <dpm> 2) The current text reads:
[09:09] <dpm> "For a list of supported languages and detailed translation statistics for these and other languages, see:"
[09:09] <dpm> I think we should use something else than "supported", as to not give the impression that these are Canonical-supported languages, they are all community ones. Have you got any ideas on what we could use instead? "fully translated", "complete"?
[09:09] <cjwatson> kirkland: a debconf frontend doesn't necessarily actually show a UI - it only shows it if it has a question to ask at sufficient priority
[09:41] <slangasek> dpm: please feel free to remove the fixme; the consensus around the table here seems to be that "supported" is perfectly ok to use here, and "fully translated" or "complete" both seem less accurate
[09:44] <dpm> slangasek, ok, thanks. FIXME removed. I've also added a note on translations at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview, as we did with Karmic
[09:52] <slangasek> dpm: great, thanks :)
[09:52] <dpm> slangasek, thank _you_ for the heads up yesterday :)
[11:03] <YokoZar> slangasek: poke (you have archives and you're online and we're sorta last minute here): I need the wine1.0 upload I just did approved so it passes --configure (and so that dssi-vst can then build, which then allows ubuntustudio to build).  Thanks :)
[11:03] <YokoZar> (problem was nailed down due to help from kees)
[11:07] <slangasek> YokoZar: what do you mean, "allows ubuntustudio to build"?  ubuntustudio images are already in final stages of validation, no one has communicated to me that there were any plans to update other packages for the UbuntuStudio DVDs before release
[11:07] <YokoZar> slangasek: last I checked dssi-vst was part of ubuntustudio's default install
[11:10] <slangasek> YokoZar: certainly not, dssi-vst has never been built in Ubuntu
[11:12] <YokoZar> persia: ping
[11:13] <YokoZar> slangasek: I've been trying to solve this since RC, and at that point there definitely was a trail from dssi-vst to ubuntustudio (it may have been dropped from the RC image due to the build failure)
[11:13] <persia> YokoZar: It would be interesting to add, but no, there won't be an image rebuild request for it: you would have had to get it ready over the weekend.
[11:14] <slangasek> YokoZar: "since RC" - er, wrong time to be putting new software in the images, anyway
[11:15] <YokoZar> persia: tried and failed
[11:15] <slangasek> now, given that this is *not* going to imply an image respin, that *improves* wine1.0's chances of getting into the archive
[11:15] <slangasek> but I don't have time to review it, I'm afraid
[11:15] <YokoZar> Makes sense, on both counts
[11:16] <YokoZar> all I heard was ubuntustudio folks were waiting on it.  I'd never heard of the package before last week as it is
[11:17] <persia> It's one of a few ways to use VSTs in Ubuntu, which tends to be a use case of interest to Ubuntu Studio.  There are other ways (less clean).  With the wine-1.0 stuff, dssi-vst becomes an SRU candidate.
[11:18] <YokoZar> persia: as a new package?
[11:18] <YokoZar> it never built so its source package is about to be deleted I think
[11:18] <YokoZar> due to the archive stuff
[11:18] <YokoZar> *archive rebuild stuff
[11:18] <slangasek> no
[11:18] <persia> What?  We're deleting source packages now?  We never did that before: mostly just binary deletions.
[11:19] <slangasek> no, we're not
[11:19] <Riddell> dholbach: how come the wallpaper here isn't blue? http://launchpadlibrarian.net/45931161/kubiquity.png
[11:19] <persia> Good.
[11:19] <dholbach> Riddell: no idea
[11:19] <YokoZar> Ok I was mistaken then I thought the unbuildable-forever stuff was being removed entirely
[11:23] <persia> YokoZar: It's binaries that were removed (about a month ago) on the premise that if we can't build it, we can't fix bugs in it.  About half of it has been restored since with FTBFS fixes.
[12:33] <spaetz> perfect patch
[12:33] <spaetz> oops
[13:38] <Azoff> hello
[13:39] <Azoff> I have noticed that the 3d party driver for Nuvoton 677x (released by ASRock in my case) breaks due to the lirc_dev-2.6.33.patch as reported here: https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/570700
[13:40] <Azoff> as you can see in the report, I have tracked this down to the name change of the lock attribute in the struct lirc_buffer, but I can't tell *why* this breaks the source package from ASRock
[13:41] <Azoff> AFAIK, the compilation against lirc-modules-source should take care of this name change. There are no references to the lock attribute inside the source package, so it's not that trivial.
[13:41] <Azoff> any ideas are welcome.
[13:47] <mvo> Riddell: is there something like a "pulse" or "spinner" widget in qt/kde?
[13:48] <Riddell> mvo: yes, let me look it up
[13:49] <dennis> afternoon
[13:50] <dennis> can anyone tell me if the bug with the flashplugin-installer will be fix at final release ?
[13:53] <sladen> dennis: depends if you can help figure out the solution before tomorrow
[13:54] <dennis> yeah... good one.... it seems to be a problem with the installer trying to installer putting the flashplayer in the wrong folders
[13:55] <dennis> or so i've read on the net, but i am not sure
[13:56] <dennis> any idea when it will be fixed then ? days, weeks perhaps ?
[13:56] <dennis> the os is useless to me without a working flashplayer
[13:56] <Riddell> mvo: actually it seems to have been taken out of the API since KDE 4, but konqueror uses http://api.kde.org/4.4-api/kdelibs-apidocs/kdeui/html/classKAnimatedButton.html with setIcons("process-working-kde")
[13:57] <Riddell> there's also http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/classPlasma_1_1BusyWidget.html if you're doing Plasma stuff
[13:57] <Riddell> what's it for?
[13:57] <mvo> Riddell: update-manager, to show that the upgrade calculation is in progress
[13:58] <sladen> dennis: is it filed as a bug report?  If not, other people may not be aware that there is an issue.
[13:58] <dennis> there is a bug report but it still says "status new"
[13:59] <sladen> dennis: and what is the number of this bug report?
[13:59] <mvo> Riddell: I will try to  figure out the python-kde support for this
[13:59] <Riddell> mvo: you can also just use a QProgressBar with max set to 0 so it'll bounce left/right
[14:00] <mvo> Riddell: aha, I will try that
[14:00] <dennis> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/532542
[14:01] <dennis> it will refuse to configure the installer and then fail to install the package properly.
[14:02] <Riddell>             progress.setRange(0, 0)
[14:02] <Riddell>             progress.setValue(0)
[14:02] <Riddell> mvo: from apport ^^
[14:06] <mvo> Riddell: thanks!
[14:07] <pitti> it's curious how we have 10 PPA buildds on one day, and just 3 on the other
[14:07] <cjwatson> PPA buildds are shared with hw enablement
[14:07] <persia> pitti: The pool of machines used for PPA builders is *also* used for other purposes.  It's always least available around releases and milestones.
[14:08] <pitti> ah, extra mirrors?
[14:08] <cjwatson> yes, that too
[14:08] <persia> That's one use.
[14:08] <pitti> amd64  3   2829 jobs (four days)
[14:08] <pitti> I just wondered about that
[14:08] <persia> I've seen it down to 2, with 2 weeks pending :)  Just wait a few days, and it usually comes back.
[14:08] <pitti> we probably shouldn't put test rebuilds to times like that
[14:09] <persia> Or use alternate infrastructure.  lucas does a full-archive test-rebuild on those arches in about 8 hours.
[14:09] <pitti> anyway, just made me wonder, thanks for the answer
[14:10] <pitti> persia: you know, if only we had some technology to move computation into the cloud :-P
[14:11] <persia> pitti: That works too, but we don't have any sane autodeployment for the Soyuz buildd bits right now.
[14:11] <pitti> (I know; just kidding)
[14:11] <persia> I think lool was looking at what it would take a couple cycles ago, with the idea of deploying qemu-buildds on ec2 to make up for the speed of ARM hardware available then.
[14:25] <doko_> pitti: hrm, a test rebuild usually has to be done before release, when else? ;)
[14:25] <pitti> we can't fix anything now anyway..
[14:25] <pitti> and lucas just did another rebuild about a week ago or so?
[14:26] <pitti> anyway, they have low build score, so they don't really get in the way
[14:26] <slangasek> pitti: when do we want to accept these langpacks into proposed?
[14:26] <pitti> slangasek: IMHO, as soon as we declare a zero chance of final image rebuilds
[14:27] <slangasek> pitti: why does it wait for this?
[14:27] <pitti> so that they can make use of the otherwise empty i386 buildds and get out of the way of the post-release SRU rush
[14:27] <slangasek> ok
[14:27] <pitti> slangasek: "does it wait"?
[14:27] <slangasek> pitti: why wait until there's zero chance of final image rebuilds before accepting them - your next line answered this for me :)
[14:27] <pitti> slangasek: I just want to avoid a situation where e. g. a -base is updated, but the update pack isn't yet, causing uninstallability
[14:28] <slangasek> but they're only in -proposed, so this doesn't strike me as a big concern
[14:28] <pitti> oh, silly me
[14:28] <pitti> slangasek: right, so let's accept them right now, shall we?
[14:28] <slangasek> pitti: sure, please do :)
[14:31] <kirkland> pitti: thanks for clarifying
[14:31] <kirkland> cjwatson: thanks
[14:34] <spaetz> why would I get: notmuch-maildir-fcc.el:70:8:Warning: `(setq subdir (cdr (assoc-string (message-fetch-field "from") notmuch-fcc-dirs t)))' is a malformed function
[14:34] <spaetz> arrg, ignore me. sorry
[14:46] <ttx> Got threatened to invoke GPL clause 2a to "force" us to upgrade Lucid fetchmail from 6.3.9 to 6.3.16... https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/557467/comments/6
[14:47] <ttx> strange days
[14:59] <zul> ttx: wha?
[14:59] <ttx> zul: we live in strange times
[16:02] <ccheney> pitti: ugh i keeping hitting the virtual keyboard crash now while trying to login to test your new packages :-\
[16:06] <ccheney> pitti: if i am seeing 526791 like the others in the thread (sounds similar at least) then that bug seems pretty bad also
[16:09] <ccheney> hmm 'enhance contrast in colors' seems to permanently screw up the GDM theme
[16:10] <ccheney> even after you disable that the theme stays different across reboot
[16:10] <apw> pitti, just a heads up that i've uploaded a kernel and lbm combo; these are with a view to a realativly early sru for lucid
[16:10] <seb128> the contrast color bug in gdm is a known bug
[16:10] <ccheney> seb128: ok
[16:11] <ccheney> i finally got the virtual keyboard to come up so i could log in, now on to testing :)
[16:11] <slangasek> apw: btw, bug #560717 was fix committed, but not to the branch you've just SRUed? :)
[16:13] <apw> slangasek, right it contains exactly two changes which were approved as urgent
[16:13] <apw> the rest remain 'committed' to our branch
[16:14] <slangasek> well, ok
[16:14] <slangasek> I think anything that I'm putting in the release notes is probably also urgent enough to have included, but that's fine
[16:14] <apw> is that not right?  that they remain committed ?
[16:30] <ccheney> pitti: works for me, i replied to the bug report
[16:43] <jdstrand> mvo: hi! might I just say that I really like how you start an ssh server listening on 9004 in do-release-upgrade? I have upgraded several systems (hardy to lucid) remotely and this was invaluable. Thanks! :)
[16:43] <jdstrand> mvo: 'sudo ufw allow 9004/tcp && sudo do-release-upgrade -d' ftw :)
[16:43] <mvo> jdstrand: cheers, did something go wrong during the upgrade? if so, I want logs :)
[16:44] <mvo> jdstrand: sounds like for lucid+1 we want a) ufw it automatically b) run it inside screen (if screen is availalbe) - what do you think?
[16:44] <slangasek> pitti: I see bug #462704 is fixed now in jockey... does that mean the release note can be dropped because the package update is now done automatically?
[16:44] <mvo> jdstrand: automatically if the user consents with it of course
[16:44] <jdstrand> mvo: it went as well as expected-- a couple of issues with some universe dkms packages, and typically conffile stuff
[16:45] <mvo> jdstrand: ok, cool, happy to hear that :)
[16:45] <jdstrand> mvo: the ufw idea is cool. screen, not so sure, but maybe
[16:46] <mvo> jdstrand: thanks, I'm not a big server/screen user myself, so I can't really judge, I throw the ideas out and see which stick :)
[16:46] <jdstrand> mvo: it was nice having the 9004 cause I could do my manual conffile merging as the install went :)
[16:46] <jdstrand> mvo: there are some who would like it, some who wouldn't
[16:46]  * mvo nods
[16:47] <jdstrand> screen is a great tool, but it is different than a straight terminal
[16:48] <jdstrand> mvo: question-- one thing that wasn't completely clear was if it would be restarted on the libssl upgrade. I assumed 'no', but cautiously didn't restart ssh either
[16:49] <mvo> jdstrand: I don't think it would be restarted as its not started via the normal init script mechanism
[16:49]  * jdstrand nods
[16:50] <jdstrand> that is what I was thinking, but wanted to make sure
[16:50] <ccheney> mvo: do you know if there is a bug about update-manager -d - details page being too large to fit on 600 vertical resolution? (it might be old as i was upgrading from karmic -> lucid)
[16:51] <mvo> ccheney: I think there is a open one for this, yes
[16:52] <ccheney> mvo: ok
[16:59] <ccheney> anyone happen to know when the freeze for 10.04.1 will be, i see the release date is july 29th
[17:07] <chrisccoulson> cjwatson - i see you did the binary removal in bug 568778. i'd prefer just to drop the whole thing and remove the source too. what do you think about that? we've been trying to minimize xulrunner rdepends in the archive this cycle, and i don't see the point in carrying one in the archive which isn't actually used by anything else yet
[17:08] <pitti> re
[17:08] <pitti> apw: I think slangasek already accepted linux
[17:08] <pitti> ccheney: ah, with pitti2? nice!
[17:09] <ccheney> pitti: yes
[17:10] <pitti> slangasek: uh, this is old.. yes, it should be fine now
[17:11] <cjwatson> chrisccoulson: our convention for fails-to-build removals has been to remove only the binaries, and I followed that
[17:12] <chrisccoulson> cjwatson, that's ok, but in this case i think we should remove the source too. do you want me to file a separate removal request for that?
[17:12] <cjwatson> chrisccoulson: doesn't seem to buy us anything
[17:12] <chrisccoulson> having it in the archive doesn't really align well to the new maintenance model of firefox
[17:12] <cjwatson> chrisccoulson: feel free to discuss it with Caesar, but he explicitly requested keeping it and his name's in the Maintainer field so I gave his request primacy
[17:13] <apw> pitti, yes it appears so ... he also suggested i made you aware that it is there and with the severity of the bugs we were looking to abreviate the SRU process as much as possible, hense the heads up :)
[17:13] <cjwatson> chrisccoulson: I won't override that without his consent
[17:13] <chrisccoulson> cjwatson - ok, i'll leave it for now. as long as he's around to port it every time we update firefox and xulrunner ;)
[17:13] <cjwatson> chrisccoulson: but he hasn't uploaded it to use xulrunner yet
[17:14] <cjwatson> chrisccoulson: so, right now, there's nothing to update
[17:14] <chrisccoulson> that's true, but there will be at some point, assuming it's fixed in a SRU
[17:14] <cjwatson> chrisccoulson: so I suggest discussing it with him in advance of such an SRU :-)
[17:14] <chrisccoulson> i was just questioning whether that was worth doing at all, seeing as there isn't anything in the archive that uses it
[17:14] <cjwatson> I don't consider myself qualified to make that judgement
[17:15] <cjwatson> Andrew seems to think it's valuable
[17:18] <slangasek> pitti: great, dropped :)
[17:23] <pitti> bryceh: I now have a tested fix for bug 548891, I just attached a debdiff
[17:24] <pitti> bryceh: can/shall I just upload that to -proposed, or do you want to commit it to git first? (and perhaps add more changes)
[17:24] <slangasek> RAOF, bryceh: is there still something that needs to be release-noted for bug #541511, or was that obsoleted by reverting the i8xx disablement patch?
[17:24] <pitti> RAOF: ^
[17:25] <pitti> slangasek: (just parrotting) from what I understood, there are problems on i845/i855 either way, so I think we still need a release note
[17:25] <slangasek> well, I need to know what to write, the bug log isn't very linear :)
[17:25] <slangasek> pitti: there's already https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Intel%208xx%20X%20freezes/crashes
[17:26] <pitti> slangasek: ah, this looks unspecific enough to still be true (also https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes)
[17:48] <bens> Ubuntu 9.04 and up to 10.04 beta1-4GB RAM, 4GB Swap.  According to ps/top/free/vmstat/anythingelseicanthinkof, there is only 800MB of ram in use, but my swap is full and killing my system.  According to everything, I have 3.2GB ram free, and 3.2GB buffer/cache.  Any idea's?
[17:48] <bens> Havne't tested with the daily build yet.
[17:58] <xnox> bens, are you using 64bit Ubuntu?
[17:59] <bens> either.
[17:59] <bens> xnox, either x86 or x86_64
[17:59] <bens> Though I'm currently experiencing the problem on 64
[17:59] <xnox> =(
[18:15] <bryceh> pitti, I'll queue it with a few other xorg-server patches
[18:17] <bryceh> slangasek, yeah we still need something for the 8xx issues.  It's one of those bugs that we fix for 10 people, and then 10 others report the fix made it regress
[18:18] <bryceh> slangasek, where is the draft of the release notes, I can do a quick review/copyedit for you
[18:32] <slangasek> bryceh: the "Intel 8xx X freezes/crashes" you put there isn't already sufficient? Anyway, draft at https://wiki.ubuntu.com/LucidLynx/ReleaseNotes, but please just put your draft text in the bug for copy-paste so we avoid lock contention
[18:33] <pitti> bryceh: thanks
[18:34] <bryceh> slangasek, I think that should suffice
[18:36] <slangasek> bryceh: ok - would you mind closing the ubuntu-release-notes task then?
[18:36] <TMKCodes> Is the GLX memory leak bug causing problems still?
[18:42] <bryceh> slangasek, done
[18:42] <bryceh> TMKCodes, this is for the issues involving freezes on 8xx
[18:43] <slangasek> bryceh: ta!
[18:56] <arand> I would like to hilight https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-swapfile .  Would I (as a non-attending-UDS non-member) simply register it for uds and see what happens?
[19:00] <cjwatson> as a matter of policy, nobody not attending UDS should propose specs for UDS
[19:00] <cjwatson> it doesn't work
[19:01] <cjwatson> instead, send mail to a development mailing list and try to convince somebody to take it on
[19:01] <cjwatson> otherwise you can easily get the situation where there's something at UDS that nobody's interested in discussing, which we don't want to happen
[19:02] <JFo> arand, also not likely that anyone will be discussing karmic issues
[19:02] <JFo> at least that is my impression
[19:03] <JFo> since the UDS is for planning the next release (in this case Maverick)
[19:03] <cjwatson> well, that's not really too relevant - that spec hasn't been implemented, so that's just a naming issue
[19:03] <cjwatson> it's an old spec that ran into implementation issues
[19:03] <JFo> ah
[19:03] <JFo> I see, disregard then arand :)
[19:04] <arand> JFo: cjwatson: Ok, will do.
[19:05] <bryceh> pitti, slangasek, for doing an SRU of xorg-server, since we haven't begun meerkat, should I be numbering it as 2:1.7.6-2ubuntu7.1 or 2:1.7.6-2ubuntu8 ?
[19:06] <slangasek> bryceh: I'm ok with -2ubuntu8 if it's expected to be copied over to meerkat once it's open
[19:23] <kees> jcastro: why are only some of the sessions for the security track listed here: http://summit.ubuntu.com/uds-m/track/security/ ?
[19:24] <jcastro> kees, on a call, one sec
[19:24] <jcastro> kees, when did you approve them? there's like a 10 minute delay
[19:24] <Daviey> kees: which ones are missing?
[19:24] <kees> jcastro: okay.  mon 15:00 and 17:10 are missing (and were approved a while ago)
[19:24] <kees> jcastro: wait, approved?
[19:24] <kees> jcastro: I need to flip it from "Discussion" to "Approved"?
[19:25] <kees> that hasn't happened for any of mine yet, but most already show up.  whee
[19:25] <kees> I thought "approved" so for after UDS
[19:25] <kees> s/so/was/
[19:27] <Daviey> kees: missing GPG key one?
[19:27] <kees> Daviey: yup, and vmbuilder
[19:28] <Daviey> interesting
[20:27] <bryceh> *boggle* why do people keep toggling the status on lp #565981 ?
[20:28] <bryceh> oh I see, seems to be a usability issue
[21:10] <lifeless> bryceh: as in 'they are able to use lp' ? :)
[21:14] <bryceh> lifeless, apparently not!
[21:33] <Zomb> hello guys. I need a "sane" mirror that everybody should use as default location. To hardcode it as fall-back in apt-cacher-ng on Debian systems (because I cannot pick up the prefered mirror from sources.list there).
[21:34] <jpds> Zomb: de.archive.ubuntu.com ?
[21:34] <Zomb> Debian is using geodns for ftp.debian.org, what do you have?
[21:34] <Zomb> jpds: worldwide please
[21:34] <jpds> Zomb: We don't have anything like that.
[21:37] <Zomb> well, ok. I will take the TLD related part from Debian mirror then (if found) and look whether it hosts Ubuntu too
[21:37] <Zomb> or something like that, we will see
[21:38] <soren> Well, archive.ubuntu.com is what debootstrap uses if you don't tell it otherwise.
[21:39] <cjwatson> if you know the country code then you could use CC.archive.ubuntu.com for any CC
[21:39] <cjwatson> it wildcards to the same as archive.ubuntu.com if there's no specific country mirror set
[21:39] <Zomb> that's what I imagined
[21:39] <Zomb> thanks
[22:10] <cjwatson> jcastro: can I have planning access to the foundations track in summit?  I'm supposed to be organising it
[22:26] <jcastro> cjwatson, done
[22:52] <cjwatson> jcastro: thanks
[23:12] <Keybuk> ion: so you know we've talked about states
[23:12] <ion> Yeah
[23:12] <Keybuk> and state environment being inherited into services
[23:12] <Keybuk> and if a service has "while $SOMESTATE", and there's multiple instances of $SOMESTATE, you get multiple instances of the service
[23:12] <Keybuk> I just had a moment when I realised the most fundamentally cool use
[23:12] <Keybuk> consider the following three things:
[23:12] <Keybuk>   while system
[23:13] <Keybuk>   exec /sbin/unetwork
[23:13] <Keybuk> --
[23:13] <Keybuk>   while user
[23:13] <Keybuk>   exec /usr/bin/ssh-agent   # has $USER
[23:13] <Keybuk> --
[23:13] <Keybuk>   while session
[23:13] <Keybuk>   exec /usr/bin/gconf-daemon  # has $USER, $DISPLAY, etc.
[23:13] <Keybuk> --
[23:14] <ion> Nice
[23:14] <Keybuk> and "user" can be implicit
[23:14] <Keybuk> e.g. user.conf is
[23:14] <Keybuk>   while session
[23:14] <Keybuk>   instance $USER
[23:14] <Keybuk> or whatever syntax we use for that
[23:14] <Keybuk> so you only need to create sessions states, you get the user states for free
[23:14] <Keybuk> and they get reused
[23:15] <ion> Yeah
[23:16] <Keybuk> not sure yet how to get the ssh-agent environment back into the session yet
[23:16] <Keybuk> but I like this
[23:16] <ion> shutdown/reboot -f attached to the system state’s post-stop and e.g. ‘stop system SHUTDOWN_ACTION=reboot’ would bring down the system and reboot? :-)
[23:17] <ion> s/^shutdown/poweroff/
[23:18] <Keybuk> yes, probably
[23:18] <Keybuk> stop user USER=sabdfl
[23:18] <Keybuk> ;-)
[23:18] <ion> :-)
[23:18] <Keybuk> actually
[23:18] <Keybuk> stop session USER=sabdfl SESSION_ID=...
[23:18] <Keybuk> that'd be logout
[23:18] <xnox> Keybuk, =)
[23:19] <xnox> Keybuk, strange that got me a notification in xchat on "sabdfl" =))))
[23:20]  * xnox didn't configure that
[23:20] <ion> while-around session, env-import cmd where cmd prints ‘FOO=bar\nBAZ=quux\n’?
[23:21] <Keybuk> ion: I'd use #upstart for this if it wasn't for the systemd SPIES :p
[23:21] <ion> :-D
[23:29] <Keybuk> ion: the bit I can't quite work out ...
[23:29] <Keybuk> last time I drew all this on paper
[23:29] <Keybuk> udev fell out
[23:31] <Keybuk> it doesn't seem to do anything anymore
[23:32] <ion> Heh
[23:33] <Aquina> What's up what did you destroy, Keybuk?
[23:33] <Keybuk> devtmpfs does the device nodes, aclthingy does the acls, upstart does the RUN+= commands
[23:33] <Aquina> :-)
[23:35] <Keybuk> Aquina: every time we give the operating system a good shake, something falls out!
[23:36] <ion> How about attaching information to devices, such as what the udevification of Xorg used to do before that data was moved to xorg.conf InputClass?
[23:36] <Keybuk> HAL fell out of 10.04
[23:36] <Keybuk> ion: isn't that just Upstart's environment attached to a state? :p
[23:36] <svu> what is the official time of release? 00:00 GMT?
[23:36] <ion> True :-)
[23:36] <Nafai> Keybuk: I'm hoping these good shakes make the OS simpler :)
[23:37] <Keybuk> svu: don't you start ;-)
[23:37] <Keybuk> ion: I think Arjan must have slipped something into my beer at LFC
[23:37] <Keybuk> because I now see his point that we just don't need udev
[23:38] <ion> Heh
[23:38] <svu> Keybuk, I think my question (in negavite form: "do not ask...") should be put into the topic ;)
[23:38] <Keybuk> however I do need my pen, and it's gone walkies
[23:43] <Aquina> I see
[23:44] <Aquina> What is the actual replacement for hal? I can't imagine a system to work without it.
[23:47] <Keybuk> ok, this is silly, where the frak is my pen?
[23:47] <Keybuk> I had it minutes ago
[23:47] <Keybuk> Aquina: udev ;)
[23:54] <Keybuk> right, I have found my pen
[23:54] <Keybuk> I had hung it on the lampshade
[23:54] <Keybuk> seriously, I'm fucked up
[23:56] <Aquina> hm... ok
[23:58] <JanC> svu: the official time for release is: while it's 2010-04-29 in some place on Earth  ;)
[23:59] <Aquina> It' here already 0:58 on 29.04.2010 :-)