[00:05] 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] YokoZar, add a set -x to the postinst, you should see each command [00:06] superm1: thanks [00:19] 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] ok [00:21] 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] no, nothing in the way - just nobody's had time [00:23] 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] 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] Keybuk: Is there any wiki that would get me going on it? [00:25] no, not really [00:25] Upstart config files are quite different from initscripts [00:25] initscripts are basically programs that start and stop services [00:25] in Upstart, Upstart is that program, and the config files tell it what to do [00:25] an Upstart script can be as simple as "exec /sbin/daemon" [00:26] with all the tracking of the processes and stuff being down by Upstart [00:26] a good place to start is "man 5 init" [00:27] I've been looking around at the differneces. upstart seems to be very similar to openrc [00:29] I don't know what that is [00:29] It's Gentoo's replacement of the same thing [00:30] OpenRC is dependency based. [00:30] And it’s not an implementation of init. [00:31] Isn't Upstart pretty much dependency based too? [00:32] start on stopped udevtrigger [00:32] That's just a local configuration though. [00:33] no [00:33] Upstart is *not* dependency based [00:34] let me explain [00:34] Keybuk: ack sorry, I sent MTecknology over but I also wanted to preface the question a bit but was AFK [00:34] I'll use a different example of a dependency based system to illustrate [00:34] dpkg/apt [00:34] 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] packages have dependencies [00:34] when you install apache, that will also install a whole bunch of other packages [00:34] libraries, other daemons, etc. [00:35] when you install squid, that might share some of those in common, and others it won't [00:35] if you uninstall apache, apt can "clean up" the unused dependencies - but won't remove those used by squid [00:35] then when you uninstall squid, again you can clean up the unused deps [00:35] the important thing is that it's top down [00:35] what you want is apache and squid [00:35] what you get is a whole bunch of packages [00:35] dependency based init systems work in *exactly* the same way [00:36] you say you want apache and squid started [00:36] and they work out what else they need to start (and in what order) to get you there [00:36] likewise if you stop apache and squid, they may be able to stop other ancillary services [00:36] *this is NOT how Upstart works* [00:36] Upstart is event-based [00:36] basically it's backwards [00:36] rather than having goal services, instead it has events [00:37] as a result of events, services might be started [00:37] to put it one way [00:37] services are started because the things they depend on are now running [00:37] to use dpkg as the example [00:37] you can't install apache [00:37] 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] right [00:38] I think dep-based is correct for package managers [00:38] ;-) [00:38] the reason I think event-based is right for service managers is hardware [00:38] is there any way to use the event information in reverse for dependencies? [00:39] let's take the easy example of the Bluetooth service [00:39] it depends on hardware [00:39] how would you cause the hardware to magically appear when required (which is what the dep-based model requires) [00:39] I’d love a package manager that installs Apache, OpenOffice and OpenTTD because i wanted GNU libc. [00:39] james_w: well I used to graph based on events as a DAG, and that reasonably communicated bootup "order" [00:40] 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] james_w: yes, but it's important to remember that Upstart doesn't work that way [00:40] 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] james_w: if the complex daemon can be running, it's already running [00:41] true [00:41] so it would have to be disabled, and then asking it to start would start it [00:41] james_w: I guess [00:41] 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] 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] at this point, I'm not that interested in daemons that are configured to not run by default [00:42] since Upstart doesn't support that [00:42] Ah, so those should stay initscripts for now. [00:42] 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] wow.. I iz opened a can of werms :P [00:43] MTecknology: so you can see why it hasn't just been done yet :) [00:44] ajmitch: ya, I still want to do it [00:45] 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] james_w: you'd be surprised how few services *actually* depend on each other [00:46] at least application-level services that sysadmins might want to deal with manually [00:46] yeah [00:46] imbrandon: In general I agree with you, but I've seem some bug reports recently specifically wanting ad-hoc game servers. [00:46] I was thinking of perhaps custom jobs on top, but you can do that with custom events instead [00:46] that being said, I do have a plan [00:47] insert some synthetic event at a certain level of the DAG and then just emit that event to start everything above it [00:47] what's the plan? [00:47] 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] imho [00:48] upstart in maverick separates events and states more than the current version [00:48] services will be more often bound to states than started by events [00:48] (states are still described in terms of events) [00:49] a job in manual mode will have a true state, but not be started [00:49] in that situation a sysadmin can start and stop [00:49] 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] Keybuk: hum manual mode huh? sounds like a good solution for the game-servers ... *thinks* [00:50] if the state is false, and the bits that are false depend on events, the "start" command will fail [00:50] 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] I think we could invent a system for cataloguing helpful messages [00:51] I suspect /sbin/start would say something a bit jargony [00:51] while the GNOME UI would be helpful [00:52] * persia backs away from dangerous sounding mixing of system/user interfaces [00:52] 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] imbrandon: yes, it's called D-Bus [00:52] * imbrandon facepalms , shoulda thought of that [00:53] Keybuk: now, what conventions would you like to be followed for upstart-ifying init scripts? [00:53] 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] I'm not sure there are conventions just yet [00:54] Keybuk: ok, I can forsee our desire to start , say, apache after a GUI is up [00:54] (on desktop systems) [00:54] 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] 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] MTecknology: well, there's like half a dozen people on the planet who know Upstart well [00:54] having another is always good [00:55] persia: actually, having apport do that for services we know *should* be running wouldn't be bad [00:56] persia: i was gonna sak, why would that be bad ? [00:56] ask* [00:56] Keybuk: I've mixed thoughts about that. How do we define "should"? [00:57] ? [00:57] persia: morally wrong not to. [00:58] 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] 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] 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] Keybuk: I actually just got interested today because I'd like to see sysv go away [01:00] 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] MTecknology: I don't think you'd have to learn C, no [01:00] persia: but we're not talking about admins [01:00] there's certainly good cases for users being helped to file bugs when their system misbehaves [01:01] 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] 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] how would that help the user file the bug? [01:04] lol... dhillon-v10 is interested in that team too [01:04] that's what apport is for [01:05] Ah, that takes away all my concerns :) apport hooks for upstart jobs is definitely the way to go. [01:05] So the failure gets logged normally, and we have decent UIs for arbitrary environments that let the bugs get reported. [01:06] exactly [01:06] you could have, e.g. services that fail result in an e-mail to root with the output [01:06] bbiab - gotta run to the store quick === rgreening__ is now known as rgreening [01:07] 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] no, I mean as alternatives for apport [01:08] 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] But if it doesn't exist, yes, certainly, it ought. [01:10] Same applies to managed farms of desktops, etc. [01:21] 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] I don't follow [01:22] e.g i have a service now, thats based on init.d , i want it installed but not running unless someone types "start " or dbus tells it to start [01:22] can i do that in lucid now or have to wait for mavric [01:22] if i convert to upstart [01:24] you have to wait [01:24] 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] thus they want the game server to only run when the gui client does ( like in windows ) [01:25] but keep the option to have it as a dedicated service , see the delima [01:25] ;) [01:27] 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] imbrandon: So if you and I want to play together, only one of us needs start the service. [01:28] 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] btw - I was also wondering what purpose plymouth has aside from the pretty splash [01:29] 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] persia: ^ [01:29] MTecknology: to serilize the console on startup [01:29] imbrandon: what's that mean? [01:30] imbrandon: I'm of much the same preference, but gave up back in feisty or so because of bug reports. [01:30] MTecknology: i'm probably not the best to explain it, but basicly pre-gui messages and ttys etc [01:31] imbrandon: I'm just lost because the package description even says that it only provides boot animation [01:31] not only, but that's all it says about itself [01:32] MTecknology: heh its probably a bit light on the documentation , its still fairly new [01:33] 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] 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] 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] 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] As upstart starts things in parallel, these are both started, and both interested in your input. Where does your keyboard input go? [01:37] fifo? [01:37] But “first” is no longer well-defined, because upstart is starting things in parallel. [01:38] 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] RAOF: I guess that's the point of plymouth? [01:39] at least that's what I understood plymouth to be. never looked at it (tm) [01:40] so what's the solution? [01:40] MTecknology: the solution to what ? [01:40] 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] and I was under the assumption that's what Plymouth was for [01:41] imbrandon: the solution for how plymouth handles that [01:44] MTecknology: i dont know how it handels it technicly, i just know it does [01:44] :) [01:44] MTecknology: if plymouth handles that, then the solution is fairly intuitive. [01:44] before each app would (1) print question (2) read response. [01:44] 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] now, plymouth would be the only one that (1) print question (2) read response) [01:45] and other services ask plymouth to bug the user. [01:46] 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] MTecknology: right, but thats alot of assumptions , especialy on a global scale like ubuntu [01:47] MTecknology: Well, and nothing wants to output status messages to the console. [01:47] MTecknology: I suppose, but that won't be the case in most setups [01:48] 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] jdong: I figured no setup can have those assumptions unless it's an embedded device [01:49] so plymouth now makes a whole lotta sense [01:49] MTecknology: exactly [01:49] imbrandon: haha once I was stupid enough to turn on fsck on my N800. [01:49] jdong: lol [01:49] what happened? [01:49] imbrandon: I figured since it was *cringe* using ext2 that bad poweroffs were going to be harsh on it. [01:49] jdong: how long did you wait for? [01:50] MTecknology: Zero block group? (y/n) [01:50] (touchscreen driver not up) [01:50] CRAP. [01:50] ouch [01:50] oh [01:50] :) [01:50] what's that do? [01:50] jdong: that was foolish [01:50] zero block grou* [01:51] MTecknology: he means that he had no way of entering y or n :) [01:51] I got that part :) - I was curious about what that does though [01:51] 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] lmgtfy.com hahaha j/k ;) [01:51] MTecknology: generic "fsck found a problem, but just zeroing the problem area technically makes it go away, should I do that?" [01:52] oh [01:52] MTecknology: (which is again why you don't blindly say y to everything fsck asks and assume it smartly fixes your disk) [01:52] brb [01:52] jdong: I'm surpised you didn't have some crackful FS on ther instead [01:52] it's the equivalent of your mechanic just ripping out hoses that look cracked and saying there's no more defective pipes :) [01:52] btrfs ? [01:52] ajmitch: in my opinion the default setup of running ext2 and not fscking no matter what... is pretty crackful [01:52] imbrandon: too stable for jdong [01:53] ajmitch: but I totally understood that they didn't have a "cough once for y, twice for n" inputdev. [01:53] fuse zfs / ? [01:53] :) [01:53] ajmitch: ANNOYINGLY the rocker was wired up to the *arrow keys* and put ^[[A's and so on to the screen. [01:53] so I wouldn't have imagined it to be a hard thing to map that to y vs n.... [01:53] (yeah yeah, file a bug, write a patch) [01:54] jdong: sure, and remap that once booted? [01:54] ajmitch: hehe yeah :) [01:54] as long as you dident forget what one was maped to n [01:54] red / green ? [01:55] or typing a password by left-right combos [01:55] everyoens n800 passwd would be "aaa" [01:56] like arcade game high scores === yofel_ is now known as yofel [02:25] That was awesome chatter :) [02:25] thanks everyone [02:49] 8/c [02:57] * ccheney think he is confused [02:57] didn't we disable bug reporting directly on launchpad at some point? [02:58] 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] ccheney: ?no-redirect or something like that? [03:03] ccheney: sometimes it's a pita to know what package is causing the issue - that's a feature that I personally like [03:13] ccheney: The root Ubuntu +filebug will redirect. [03:13] If you go directly to a source package's +filebug, it will not. [03:13] It will also not redirect for you at all, since you are in -bugcontrol. [03:15] wgrant: ah, i see that is why :) [03:15] wgrant: i forgot that it might look different since i am in bugcontrol :) [03:26] urgh [03:26] * Keybuk just, seriously, had a "could you turn the computer *on*" type moment on a bug [03:26] lol [03:27] send them a descreet wake-on-lan packet [03:27] bug #570692 [03:27] Launchpad bug 570692 in udev "Ubuntu 10.04 Can't open RFCOMM device: Permission denied" [Medium,Incomplete] https://launchpad.net/bugs/570692 [03:33] Keybuk hahahah ( @the bug ) [03:33] diediedie :) [03:34] we need a channel where the Code of Conduct does not apply [03:34] #ubuntu-two-minutes-hate or something [03:41] araaraaraara [03:44] Keybuk: What are the units on /sys/dev/block/#:#/size ? And just as important, what are the units on the "at " of ureadahead --dump? [03:44] temugen: err, they're units ;) [03:44] probably bytes [03:45] but they might be different, one might be blocks [03:45] I thought the was bytes just based on... well, I don't know, but the size is different for sure [03:45] 31252480 [03:45] wing-commander scott% cat /sys/block/sda/size [03:45] 31252480 [03:45] that looks like blocks to me [03:46] (a block is generally 512 bytes from a disk pov) [03:46] not sure about offset, bytes I expect, but not sure [03:47] might be blocks too [03:47] ah, ok. [03:47] (whereas the page cache operates in 4096 byte pages) [03:47] indeed [03:48] thanks for clearing that up [03:48] some disks might use 4096 byte blocs [03:48] instead of 512 byte ones [03:48] just to add to the confusion [03:50] 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] I don't think I know the answer to that [03:50] it'll be in /sys somewhere if the kernel exposes it [03:50] No problem :) I'll see what I can find [03:51] ah [03:51] queue/physical_block_size [03:51] queue/logical_block_size [03:51] is that what blockdev --report returns? [03:52] jdong: blockdev --report works :) [03:52] I don't know if the sysfs entries go through the same code path :) === almaisan-away is now known as al-maisan === dendro-afk is now known as dedrobates [05:53] Good morning [05:53] ccheney: oh, thanks! === dedrobates is now known as dendro-afk [06:07] pitti: no problem :) [06:07] pitti: my results seem different from what others have posted, i'm not sure what is going on [06:08] superm1: you haven't been seeing bug #570843, have you? [06:08] Launchpad bug 570843 in ubiquity "[Lucid Lynx RC] Install hangs on a LAN-connected (but no internet) workstation" [Undecided,New] https://launchpad.net/bugs/570843 [06:10] ccheney: I have a theory; the "SKIP" might have been a red herring all along, and it was the broken variant [06:10] "U.S. English" is a bogus variant [06:13] ok [06:17] ccheney: hm, https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/548891/comments/8 only has "SKIP", and an empty variant [06:17] Ubuntu bug 548891 in xorg-server "keyboard input broken due to invalid "SKIP" keyboard model" [High,In progress] [06:17] perhaps it's a combination of both [06:19] slangasek, no i haven't seen that [06:19] superm1: ok - phew :) [06:20] 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] 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] dang [06:29] * ccheney is headed to bed now [06:32] ccheney: good night! I'll answer in the bug report for something to try, and test it in the meantime [06:57] bdrung: http://people.canonical.com/~kirkland/Museum back online ;-) [06:57] kirkland: where's karmic? [06:58] micahg: not yet done [07:05] kirkland: ooh, thanks! [07:06] pitti: ;-) [07:07] * pitti gets a ticket for a year [07:08] pitti: :-) the exhibits need some freshening up [07:13] pitti: whoa, lookey there .... http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html [07:13] pitti: ;-) [07:16] * micahg is #14 \o/, althought half were probably fixed upstream :) [07:17] kirkland: uh, congratulations! [07:17] kirkland: seems you fixed a ton in the last week :) [07:17] (last time I checked I had 4 more or so) [07:17] pitti: yeah, might be a bug in the accounting; i'm not sure what happened [07:18] pitti: but i had noticed it hadn't been updated in a few days [07:18] pitti: meh [07:18] kirkland: it was a nice race! *hug* [07:18] pitti: *hug* [07:18] * pitti still has some SRUs up his sleeve, but not enough to fix 12 bugs [07:18] pitti: there's still plenty of room for SRUs [07:18] heh [07:19] pitti: speaking of, i'll be bugging you about that; we've got a stack for eucalyptus, and a handful of others [07:19] pitti: speaking of, can i get an sru ack of Bug 570870 ? [07:19] Launchpad bug 570870 in etherboot "pxe boot doesn't work with kvm" [Low,In progress] https://launchpad.net/bugs/570870 [07:19] * kirkland is off to bed [07:20] kirkland: acked 20 seconds ago :) [07:21] 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] good morning [08:13] guten morgen herr Holbach meister [08:14] I don't know about any Meister :) [08:14] hey sladen :) [08:14] actually, that's not very good faux German, it's got too many spaces in it! [08:19] dholbach: you are on libribox! http://librivox.org/good-sense-by-baron-paul-henri-thiry-dholbach/ [08:19] hahaha [08:19] thanks mvo [08:19] my pleasure "baron" [08:56] 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] dpm: to https://wiki.ubuntu.com/LucidLynx/ReleaseAnnouncement, please [08:58] ah, sorry, yes, the announcement, not the notes [09:00] slangasek: is the annoucement/notes only for stuff in main or universe as well? [09:02] 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] slangasek: ok, we'll probably need to put something in there for lightning, but will discuss with chrisccoulson [09:09] slangasek, ok, two final questions: [09:09] 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] 2) The current text reads: [09:09] "For a list of supported languages and detailed translation statistics for these and other languages, see:" [09:09] 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] 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] 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] 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] dpm: great, thanks :) [09:52] slangasek, thank _you_ for the heads up yesterday :) === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [11:03] 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] (problem was nailed down due to help from kees) [11:07] 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] slangasek: last I checked dssi-vst was part of ubuntustudio's default install [11:10] YokoZar: certainly not, dssi-vst has never been built in Ubuntu [11:12] persia: ping [11:13] 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] 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] YokoZar: "since RC" - er, wrong time to be putting new software in the images, anyway [11:15] persia: tried and failed [11:15] 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] but I don't have time to review it, I'm afraid [11:15] Makes sense, on both counts [11:16] 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] 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] persia: as a new package? [11:18] it never built so its source package is about to be deleted I think [11:18] due to the archive stuff [11:18] *archive rebuild stuff [11:18] no [11:18] What? We're deleting source packages now? We never did that before: mostly just binary deletions. [11:19] no, we're not [11:19] dholbach: how come the wallpaper here isn't blue? http://launchpadlibrarian.net/45931161/kubiquity.png [11:19] Good. [11:19] Riddell: no idea [11:19] Ok I was mistaken then I thought the unbuildable-forever stuff was being removed entirely === al-maisa` is now known as almaisan-away === Ng_ is now known as Ng [11:23] 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. === almaisan-away is now known as almaisan === ion_ is now known as ion === almaisan is now known as al-maisan === MacSlow is now known as MacSlow|lunch [12:33] perfect patch [12:33] oops === MacSlow|lunch is now known as MacSlow === rgreening_ is now known as rgreening [13:38] hello [13:39] 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:39] Launchpad bug 570700 in lirc "lirc-modules-source-0.8.6-0ubuntu4: lirc_dev-2.6.33.patch breaks lirc-nct677x-src" [Undecided,New] [13:40] 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] 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] any ideas are welcome. [13:47] Riddell: is there something like a "pulse" or "spinner" widget in qt/kde? [13:48] mvo: yes, let me look it up [13:49] afternoon [13:50] can anyone tell me if the bug with the flashplugin-installer will be fix at final release ? [13:53] dennis: depends if you can help figure out the solution before tomorrow [13:54] yeah... good one.... it seems to be a problem with the installer trying to installer putting the flashplayer in the wrong folders === dendro-afk is now known as dedrobates [13:55] or so i've read on the net, but i am not sure [13:56] any idea when it will be fixed then ? days, weeks perhaps ? [13:56]