[00:03] <slangasek> cjwatson: hmm, could also use build score bumps for language-pack{-gnome,}-de{,-base}
[00:08] <Caesar> slangasek: the gssd upstart job, did it ever respect RPCSECGSSOPTS from /etc/default/nfs-common?
[00:09] <Caesar> Sorry, RPCGSSDOPTS
[00:11] <slangasek> Caesar: it did, but I noticed that /etc/default/nfs-common didn't set this as a template, and I ran into bug #545673 that can be worked around by making sure to use exec directly instead of 'script [...] exec'
[00:12] <slangasek> Caesar: since the recommendation from upstart upstream is to not source files in /etc/default anyway, I would recommend you apply your tunings directly to the upstart job
[00:13] <Caesar> slangasek: argh
[00:13] <Caesar> That seems so gross
[00:13] <Caesar> Okay, so today in Hardy, we tweak RPCGSSDOPTS in /etc/default/nfs-common
[00:13] <Caesar> Nice, easy to parse and manage file
[00:14] <Caesar> You/Scott are saying the new "right" way is to munge the upstart job instead?
[00:14] <slangasek> Scott says that
[00:14] <slangasek> I remain mute on the subject of whether it's right :-)
[00:14] <Caesar> I think a little bit of pushback is warranted
[00:15] <lifeless> are upstart jobs 'config files'
[00:15] <slangasek> well, quite aside from whether it's right, I can't see another way to not hit that bug with /usr-as-separate-partition + NFS-mounted-at-boot
[00:15] <slangasek> lifeless: so are init scripts, but nobody wants to have to edit them
[00:16] <lifeless> slangasek: yeah
[00:16] <Caesar> slangasek: I'm still trying to get my head around this bug you're talking about
[00:17] <slangasek> Caesar: so what happens is that when you use 'script', upstart launches a shell to execute the specified script; which means when rpc.gssd fails to start because /usr isn't mounted yet, the exact nature of the failure is masked from upstart
[00:18] <slangasek> if upstart knew it was execve()->ENOENT, it would handle it gracefully
[00:18] <Caesar> Can it not handle a non-zero return code from a script fragment?
[00:19] <slangasek> in general, yes
[00:19] <slangasek> in this case, something goes Screwy
[00:19] <slangasek> I haven't looked to see /why/ it goes screwy, though
[00:19] <Caesar> Oh Upstart, please don't snatch defeat from the jaws of victory
[00:21] <Caesar> slangasek: I'm sorry, I have conscientious objections to modifying init scripts and upstart jobs fall into the same category
[00:21] <Caesar> Isn't this why $DEITY invented /etc/default in the first place?
[00:21]  * Caesar goes and reads the FHS and Debian Policy
[00:23] <slangasek> FWIW, I think that /etc/default is an annoying indirection; I don't know if I'd go so far as Keybuk has and conclude that upstart's declarative syntax is sufficiently friendly to remove the need for them
[00:23] <slangasek> but there are certainly many other /etc/default/ files that I expect to become obsolete besides this one
[00:23] <slangasek> (including, thankfully, all of the START=no ones)
[00:24] <Caesar> slangasek: what is wrong with Debian Policy 9.3.2 though?
[00:24] <Caesar> The issue that this tries to address is still there
[00:25] <Caesar> (third-last paragraph specifically)
[00:26] <slangasek> "Often there are some variables in the `init.d' scripts whose values control the behavior of the scripts" - sure; except that in this case, the only reason to *have* it as a variable, instead of in-line in the upstart job, is *because* of that file
[00:26] <Caesar> " As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes"
[00:26] <Caesar> Upstart jobs are conffiles, right?
[00:26] <slangasek> yes
[00:27] <Caesar> I think the point is that SUSv3 sh format files are more manageable than upstart job files
[00:27] <slangasek> given that the next bit says "files in /etc/default may be conffiles", the only justification for having it as a separate file is that it's easier to hand-merge a default file than an upstart job
[00:28] <slangasek> ... than an initscript, I mean
[00:28] <Caesar> So out of curiosity, if this was managed by debconf, how would that be managed?
[00:28] <slangasek> it's also easier to hand-merge an upstart job than to hand-merge an initscript; the question is whether it's easy enough
[00:29] <slangasek> if it were managed by debconf, wherever you store it can't be a conffile
[00:29] <Caesar> Right, so that might be /etc/default/foo
[00:29] <Caesar> So we're right back where we started again
[00:29] <slangasek> so you get to pick between sourcing /etc/default and managing that, or having an upstart job that's not a conffile and managing that
[00:30] <Caesar> Okay
[00:30] <Caesar> Meanwhile, we have an unmanageable rpc.gssd
[00:30] <satwell> The advantage of /etc/default is that in most cases changes do not need to be merged.
[00:30] <satwell> Whereas changes to an upstart job do need to be merged.
[00:31] <cjwatson> the reason /etc/default was introduced (I was there, I remember) was that merging init script changes was often really scary and difficult
[00:31] <slangasek> is it not sufficient to do 's/^\(exec rpc.gssd\).*/\1 myopts/' ?
[00:31] <satwell> Upstart jobs need some way to be configured, and directly editing the upstart jobs sounds pretty burdensome.
[00:32] <Caesar> slangasek: no, that would work
[00:32] <slangasek> if we have the upstart job *right*, merges will be very infrequent
[00:32] <cjwatson> slangasek: German language packs rescored
[00:32] <slangasek> cjwatson: ta
[00:35] <Caesar> slangasek: so far it's changed a bit during Lucid's development
[00:35] <Caesar> I think we're going to just have to hold our noses and ship our own Upstart job with Puppet
[00:35] <Caesar> It makes me sad, because we're going to have notice when the upstart job changes upstream
[00:38] <slangasek> I'm sorry for that, but if I change it back then the upstart bug makes it impossible for me to dogfood it because the rpc.gssd upstart job will zombify on my system
[00:39] <satwell> It seems like the ideal solution would be for upstart to be able to read env variables out of /etc/default and pass them on exec lines.
[00:39] <Caesar> slangasek: isn't the right solution to fix the Upstart bug?
[00:40] <Caesar> You're kind of papering over it
[00:40] <cjwatson> papering over bugs is often what happens shortly before release!
[00:40] <slangasek> upstart should be fixed; I don't think that's going to happen in time for lucid
[00:41] <cjwatson> anyone here who's never papered over a bug to get a release out, raise your hand
[00:41] <slangasek> I expect upstart's ptrace handling is implicated here, which Keybuk has just today made warding signs against changing for lcid
[00:41] <slangasek> lucid
[00:42] <Caesar> cjwatson: heh
[00:45] <Caesar> What's better ettiquette for a sync request? A new bug number or tack it onto the bug that's intended to be fixed by the sync request?
[00:45] <slangasek> the latter, IMHO
[00:46] <Caesar> goodo
[00:46] <Caesar> But requestsync isn't geared towards doing that is it?
[00:46] <slangasek> nope
[00:47] <Caesar> I'll try to figure out what bits I need to twiddle from a previous sync request
[00:47] <slangasek> doing whatever you find easier is fine :)  but it should only require subscribing ubuntu-sponsors
[00:48] <Caesar> ok
[00:48] <Caesar> I really need to pull my finger out and go for Ubuntu Membership again
[00:50] <Caesar> slangasek: so I guess retitle the bug report as part of doing the latter?
[00:51] <slangasek> Caesar: I would do so, yes
[00:52] <slangasek> (and add the usual information about why to overwrite any Ubuntu delta, etc)
[00:52] <Caesar> Yep
[00:52] <Caesar> Fortunately there is no delta
[01:12] <Caesar> Man, Launchpad is cool
[01:38] <LaserJock> sweet, 10GB on dropbox for free
[01:41] <nixternal> how?
[01:41] <nixternal> tell me now!
[01:42] <LaserJock> they bumped up the max referrel reward to 10gb
[01:42] <LaserJock> apparently I already had enough, so I just looked and I had 10GB
[01:43] <LaserJock> so for a 2GB plan that's pretty kickin'
[01:43] <nixternal> dang
[01:43] <nixternal> I had 2.5 from referrals, but it went back to 2
[01:43] <nixternal> now it says 2.25GB
[01:43] <LaserJock> nixternal: did you put it on twitter/identi.ca?
[01:43] <nixternal> no
[01:43] <LaserJock> that's what really shot mine up
[01:43] <nixternal> should I?
[01:43] <nixternal> here we go!!!
[02:07] <happyaron> jcastro: ping
[02:16] <cody-somerville> It seems Whenever apparmour gets updated, my computer stats crawling to a stop.
[02:18] <lifeless> there was some discussion of kernel memory pressure from apparmour
[02:28] <jdong> cody-somerville: there's a bug on that
[02:28] <jdong> bug 458299
[02:43] <psusi> am I crazy for thinking that the kernel should... you know... actually HIDE partitions with the hidden flag?
[02:47] <lifeless> yes
[02:48] <ion> yes
[02:50] <jdong> psusi: PSHHHHHHH next you'll say that movie rentals should be non-DRM'ed and based on the O_IPINKYSWEAR bit in the metadata...
[02:50] <jdong> *ducks*
[02:50] <psusi> I'm crazy for thinking that the hidden flag should actually do something?
[02:50] <ajmitch> like PDFs?
[02:51] <psusi> or that in general, the kernel should pay attention to any of the fields in the partition table besides start and length?
[02:51] <jdong> ajmitch: haha pretty much. Aren't there actually "cryptographically" enforced ones though?
[02:51] <jdong> or is that a even more proprietary format?
[02:51] <ajmitch> no idea :)
[02:52]  * psusi throws jdong a copy of the e2defrag package to play with
[02:52] <jdong> hahahaha *takes snapshot*
[02:52] <jdong> is it ureadahead-aware yet?
[02:53] <psusi> jdong, I fed it a list transformed from ureadahead's list to prioritize the defragging and it did help, but only so much... it still does not want to move the blocks out of the block group the inode is in, and it doesn't do inode relocation
[02:53] <jdong> psusi: oh :(
[02:53] <jdong> psusi: I think one of the most useful optimizations is going to be the ability to say "move this list of files such that they're close to each other"
[02:53] <psusi> jdong, it also still does not do extents and uninit_bg
[02:54] <psusi> aye
[02:54] <jdong> lol isn't that the default creation mode for ext4 in Ubuntu since Karmic?
[02:54] <ion> It seems the lucid kernel lacks the configuration to load DSDT from initramfs.
[02:55] <stgraber> ion: that's since karmic ... had to boot a jaunty system to test a DSDT fix :(
[02:57] <psusi> jdong, yes... and extents also seem to REALLY minimize fragmentation anyhow
[02:58] <psusi> though I did find that the man page states that lazy_bg_init defaults to on, but it does not... when you specify it the mkfs really goes much faster ;)
[02:58] <jdong> psusi: it's not file level fgramentation that worries me these days. it's more "logical" fragmentation between groups of related files for tasks.
[02:58] <jdong> psusi: which is one reason I find Windows (XP, Vista, 7)'s idea of "prefetch packs" to be pretty brilliant
[02:58] <joshuah> hello everyone, I'm trying to use groundcontrol to check out a project and I get "please enter account details". even if I enter them, I still get that. does anyone know what I might be doing wrong?
[02:58] <psusi> jdong, right
[02:59] <jdong> psusi: where they attach a machine learning self-training algorithm to the launch of each executable
[02:59] <psusi> yea... would be nice if ureadahead could do that.... pack it into one file then tell the kernel to stuff that into the cache for the files it came from
[02:59] <jdong> of course right now they seem to be hitting the not-enough-cache-to-be-awesome barrier
[02:59] <jdong> yeah, indeed
[03:00] <jdong> if there's a way to have ureadahead generate separate packs for bootup, login, starting openoffice, etc
[03:00] <psusi> don't they also have something where they can put the pack files on a usb memory stick for fast reading during boot?
[03:00] <jdong> yup
[03:00] <jdong> ReadyBoost
[03:00] <jdong> and not just during boot
[03:00] <jdong> launching programs in general
[03:00] <psusi> I've been wondering that myself lately... would be nice to at least have a different pack for boot and one for login
[03:00] <jdong> the Prefetch folder in C:\Windows is full of ureadahead-style strategy files for what blocks are used in what order to start various .EXEs
[03:01] <jdong> and then, their idle defragger "merges" these packs together and picks the most optimal way to reorder things on disk
[03:01] <psusi> really?
[03:01] <jdong> so not only is there ureadhead-style smart reading order per app launch, but ProcessIdleTasks()'s defragger actually repositions stuff on disk
[03:02] <jdong> and 3rd party defraggers like PerfectDisk read the same Prefetch files and applies a "smarter" layout algorithm for even better (claimed) performance
[03:02] <jdong> it's such an impressively designed system on paper, I'm slightly surprised it isn't the case that we praise Windows for their IO performance...
[03:03] <jdong> when reading and talking about this, it kinda does sound like doubleplusuber-readahead :)
[03:03] <psusi> reminds me of when NT had zero copy async io and TransmitFile and Linus poo-pooed the idea of adding sendfile() to the kernel
[03:04] <Aquina> must be a long time ago
[03:04] <psusi> I found an old copy of dd I modified years ago to use O_DIRECT aio with 16 simultanious requests... tried it on my new ssd and actually exceeded the mfr throughput specs ;)
[03:07] <psusi> I've been playing around with gpt partitions lately and it's upsetting me that it goes to all the trouble of designating really unique type codes for partitions, and explicitly defines a hidden flag, and the kernel pays attention to none of it
[03:08] <Aquina> You like that hidden flag-thing, huh?
[03:08] <psusi> well, if they bothered designing the fields in there, they ought to be used
[03:10] <psusi> I mean if an OEM puts a hidden rescue partition on the disk, it shouldn't show up on the user's desktop for them to go gee, what are all these files?
[03:12] <Aquina> Well... I dislike that hidden rescue stuff. Reminds me about computers from the supermarket with included M$ OEM CS and a super-duper hidden volume with lot of crap on it (drivers, recovery stuff, etc.).
[03:13] <lifeless> psusi: the hidden field was important in DOS
[03:13] <lifeless> psusi: its not anymore
[03:13] <joshuah> has anyone here used ground control? I can't seem to get it to log in for me
[03:13] <Aquina> no, sry
[03:13] <lifeless> psusi: in DOS it was critical to be able to boot parallel installs, because of the brain dead lack of abstraction layers DOS used (C: rather than mount points)
[03:13] <psusi> lifeless, yea... because nobody respects it... so why did they bother putting it in GPT?  where it is explicitly defined as such, rather than just the high bit of the type that one os decided would be used to hide partitions?
[03:14] <psusi> for that matter, why use big GUIDs to type the partitions if that information is also totally ignored?
[03:15] <lifeless> microsoft have a hammer in their APIs
[03:15] <lifeless> and to them, everything looks like a nail.
[03:15] <psusi> gpt doesn't have anythign to do with microsoft
[03:15] <lifeless> orly?
[03:16] <psusi> yea.. Intel and Apple seem to be the main ones behind it
[03:17] <psusi> seems a case of "not invented here" to decide to ignore the fields just because someone else designed them
[03:17] <lifeless> NIH would be doing our own disklabel
[03:17] <psusi> with msdos partitions it was kind of understandable because there never was any real good design specified, it just kind of grew organically, but with gpt this is not the case
[03:19] <psusi> for that matter, why the hell did the linux community bother defining msdos partition tags for raid and lvm when they aren't used?  same goes for swap
[03:19] <lifeless> anyhow, it was intel + ms
[03:19] <lifeless> uefi consortium
[03:20] <lifeless> apple is a late comer to it, they just skipped DOS disklabel support entirely in their intel machines
[03:20] <lifeless> psusi: swap label is used
[03:20] <psusi> lifeless, by what?  swapon works just fine if the partition is not marked as swap
[03:21] <lifeless> sure
[03:21] <lifeless> depends how you define 'used' I guess
[03:21] <lifeless> anyhow, lunch tmie
[03:26] <cody-somerville> odd. my selected search engine keeps defaulting back to yahoo!.
[03:27] <psusi> oh well, at least I managed to get parted fixed so it can manipulate other partitions on a disk that has one mounted again
[03:30] <Aquina> What do you put under /usr/local/sbin (instead of /usr/local/bin)? I can't decide where to put some of my self-written applications.
[03:31] <psusi> Aquina, sbin is for system management/maintainance apps
[03:32] <psusi> i.e. things that the super user would want to run
[03:32] <cody-somerville> On some setups, users don't even have sbin in their path.
[03:32] <psusi> aye
[03:33] <Aquina> man hier and no toher resource mentiones this explicitly though.
[03:34] <Aquina> but maybe I just had better deduced it from the other /sbin dirs
[03:35] <psusi> man hier seems to specify that sbin is for system administration
[03:35] <cody-somerville> Aquina, Do your scripts require to be executed as root?
[03:35] <psusi> although the entry for /usr/sbin seems wrong... looks like it was duplicated from /sbin since it says contains programs needed to mount /usr
[03:36] <cody-somerville> lol
[03:39] <Aquina> some, cody
[03:40] <Aquina> I'm seperating the system related (which also require root previleges) to /usr/local/sbin
[03:40] <Aquina> These are not only scripts however. :-)
[03:41] <Aquina> Yes I also noticed that mistake. You can find it on everal websites. *rofl*
[04:03] <kirkland> slangasek: around?  i have a few questions about /etc/init/mounted-varrun.conf
[04:03] <kirkland> slangasek: i think this file is causing Bug #550561
[04:04] <kirkland> slangasek: i think /var/run/motd should be cleanly generated by pam_motd now
[04:04] <kirkland> slangasek: i don't think it needs to be seeded by this upstart script
[04:05] <kirkland> slangasek: hmm, well, maybe not causing that bug upon closer inspection
[04:06] <kirkland> slangasek: actually let me take a different approach ...
[04:06] <kirkland> keybuk: wanna improve bootspeed ever so slightly?  :-)  you can gut the motd parts of /etc/init/mounted-varrun.conf
[05:18] <tjaalton> can someone bump the build priority on xserver-xorg-input-evdev & -synaptics?
[06:06] <slangasek> doko__: being able to cross-compile a package is a feature; please respect the feature freeze
[07:06] <NCommander> Silly question, if I have a package in restricted (or multiverse) that makes free binaries and non-free binaries, can those binaries be placed in main/universe?
[07:07] <pitti> Good morning
[07:10] <StevenK> NCommander: No
[07:11] <NCommander> StevenK: ugh, so I need to split this into multiple source packages :-/
[07:20] <lifeless> NCommander: how would a single package make both free and nonfree binaries
[07:21] <NCommander> lifeless: I have an Xorg driver for a vendor, it builds once with free source only (MIT), and again with free source+embedded binary blob for full functionality
[07:21] <NCommander> lifeless: I was wondering if I need two source packages, or one.
[07:22] <lifeless> ugh
[07:22] <lifeless> what card?
[07:22] <NCommander> lifeless: ARM SoC, not public yet
[07:22] <lifeless> ah kk
[07:22] <NCommander> lifeless: I'd just do the embedded binary blob, but I rather have the FOSS driver for the image, then the blob for full acceleration if the user is willing to taint there system
[07:23] <pitti> tjaalton, bryceh: does either of you have time for bug 539473? (revert the introduction of libutempter); I can take it if you are too busy
[07:23] <lifeless> yeah
[07:23] <lifeless> two packages
[07:23] <NCommander> lifeless: Its a unique situation, hence why I asked.
[07:23] <NCommander> lifeless: *grumble*. I'm still talking with the vendor on how we can improve the design
[07:25] <lifeless> step 1, don't do a binary blob:)
[07:25] <RAOF> Step 1 is surprisingly hard, judging by the profusion of binary blobs.
[07:30] <tjaalton> pitti: i can take it
[07:30] <pitti> tjaalton: thanks
[07:32] <lifeless> The following packages have unmet dependencies:
[07:32] <lifeless>   bzr-builddeb: Depends: dpkg-dev but it is not going to be installed
[07:32] <lifeless>                 Depends: devscripts but it is not going to be installed
[07:32] <lifeless> thats apt-get install bzr-builddeb reading from the dc archive
[07:32] <lifeless> any thoughts on why ?
[07:32] <lifeless> james_w: ^
[07:57] <tjaalton> pitti: would it be ok to merge xterm 256 as well? here's the upstream changelog http://invisible-island.net/xterm/xterm.log.html#xterm_256
[07:58] <pitti> tjaalton: looks fine, yes
[07:58] <tjaalton> pitti: ok, thanks
[08:02] <dholbach> good morning
[08:07] <nobuto> pitti: Could you take a look at this bug? it seems change you made cause regression.
[08:07] <nobuto> https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/531155
[08:08] <pitti> nobuto: it's on my list to look at
[08:09] <nobuto> pitti: I  feel relieved. thank you.
[08:12] <kenvandine> good morning pitti
[08:12] <pitti> hey kenvandine; late for you..
[08:12] <kenvandine> yup
[08:16] <pitti> slangasek: what do you think about building openldap against db4.8? (it's one of the last two packages in main still using 4.7)
[08:54] <\sh> hmm..empathy is gone after last update on lucid somehow
[08:56] <fale> hello
[08:57] <fale> I was looking into firefox package, and I haven't seen the point in which is setted the default homepage... Am I looking into the right package'
[10:25] <mthaddon> Launchpad down/in read-only 11:00 UTC - 13:00 UTC for a code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[10:27] <mthaddon> let's try that again...
[10:27] <mthaddon> and final time...
[11:44] <lifeless> persia: ping
[11:54] <ScottK> pitti: Would you please rescore kdepimlibs on sparc (the only arch it's not built on)?  It would avoid some other build failures is a few hours if you would.
[11:55] <pitti> ScottK: done
[11:55] <ScottK> pitti: Thanks.
[12:13]  * Keybuk has a sudden epiphany with the mountall prompt issue
[12:13] <Keybuk> very much of the "the answer's not in the box, it's in the band" variety
[12:13] <ion> Oh?
[12:14] <Keybuk> had been trying to work out how to deal with more important prompts replacing less important ones
[12:14] <Keybuk> how to make sure that if we were bored waiting for /porn, and bored waiting for /warez
[12:14] <Keybuk> and /porn showed up, we'd replace the message with one about /warez
[12:14] <Keybuk> but if an fsck failed in the meantime, etc.
[12:14] <Keybuk> had thought of a complicated message list, which needed continuous grooming, etc.
[12:14] <Keybuk> then realised much easier way
[12:15] <Keybuk> just have, on each mount point, a state variable
[12:15] <Keybuk> after changing that, call a function to "update plymouth"
[12:15] <Keybuk> that picks the most important message from the list of mounts and shows that one (if not already the one showing)
[12:17] <ion> I was thinking of dumping all prompts asynchronously to plymouth with priority as an integer and letting it handle them. :-P
[12:17] <Keybuk> that'd require rather more logic at the other end
[12:17] <ion> It already needs to handle multiple simultaneous prompts, doesn’t it?
[12:18] <Keybuk> it does, but by blocking them
[12:18] <Keybuk> which is the exact behaviour we need to avoid in mountall
[12:22]  * amitk wonders if Keybug is talking about bug 527666
[12:23] <Keybuk> amitk: I'm talking about a known issue with mountall
[12:23] <Keybuk> it may or may not be the cause of may of the apparent "bugs"
[12:37] <sladen> Keybuk: fonts tend to be up your street;  any idea which package the new 'Ubuntu' (not Title) font is in
[12:37] <Keybuk> sladen: is it packaged yet?
[12:38] <sladen> Keybuk: this was I was wondering... if not, where do I file visual kerning issues?
[12:39] <Keybuk> with dalton maag I guess ;)
[12:39] <Keybuk> though how can you have kerning issues if you don't have the font? :p
[12:40] <sladen> Keybuk: I have *eyes*.  The spacing between the 'u' and the 'b' is too wide in and the spacing between 'k' and 'u' too narrow
[12:40] <sladen> Keybuk: it's the same as looking at a boot screen and going "that's slipping down"!
[12:41] <Keybuk> in the logos?  they may be still using unfinished versions, etc.
[12:41] <Keybuk> that's an artwork issue
[12:41] <Keybuk> talk to the art team
[12:41] <Keybuk> (the font is certainly going to be released aiui, it's just still not finished and such things are being tweaked every day)
[12:44] <Keybuk> though, if you ask me, the logo is slipping to the right, not down :p
[12:53] <Keybuk> I wish LP would invest the time into giving themselves the ability to do Live Rollouts
[13:25] <cjwatson> bdmurray: could we have a page like http://qa.ubuntu.com/reports/team-assigned/canonical-foundations-assigned-bug-tasks.html, except for milestones?  In particular I'd like something like LP's milestone view but that shows assignees as well.  I started trying to produce this, but it looks like you might already have the infrastructure to do this nicely.
[13:29] <pitti> Riddell, lex79: do you know why KDE dropped the kdesu wrapping for mounting internal drives in the first place? with the recent hal, the policy is very open, and every user/script (including non-admins) can now mess with internal disks
[13:34] <Riddell> pitti: that was always a patch we added, and we still add it people.canonical.com/~jriddell/tmp/kubuntu_06_user_disk_mounting.diff
[13:34] <pitti> Riddell: so that broke somehow?
[13:35] <Riddell> that or hal broke, I've not looked into the issue
[13:35] <pitti> hal didn't change since karmic
[13:39] <Riddell> pitti: except that 10_nonpolkit-mount-policy.patch was added?
[13:40] <pitti> Riddell: no, that's been there since jaunty or so
[13:40] <pitti> hal has never allowed any user to mount internal disks, until yesterday
[13:44] <Riddell> pitti: let's wait and see what lex says then
[13:54] <deryck> having to add an hour to downtime for LP.  sorry.
[13:54] <pitti> :(
[13:54] <deryck> I know :(
[13:54] <pitti> deryck: good luck!
[13:54] <deryck> thanks!
[13:55] <cjwatson> foundations team: is it worth holding our meeting today, given that we're all going to be "LP was down and I'm still catching up"?
[13:56] <Keybuk> cjwatson: I'm happy to skip it
[13:57] <seb128> deryck, I guess there is no way to bzr pull things during downtime?
[13:58] <seb128> having launchpad down for 3 hours during work hours sucks
[13:59] <ttx> seb128: especially on the last day before Freeze
[13:59] <deryck> seb128, yes, it does suck.  and no, I saw reports this morning that bzr pull did not work, though I thought that was some of the point of read only mode for us.
[13:59] <seb128> :-(
[13:59] <lamont> mvo: how come is it that everytime update-manager gets upgraded, I get to re-remove a conffile? (update-motd.d/91-release-upgrade).  If I removed a conffile, it should remain removed.
[13:59] <lamont> or is that by design?
[14:00]  * cjwatson is keeping an informal upload queue log in a text file so that he can remember what to commit/upload when LP comes back
[14:01] <pitti> lamont: hm, it's a symlink, not a real conffile; that might be it?
[14:01]  * seb128 can't bzr pull so hard to know on what to work
[14:01] <seb128> or rather annoying to apt-get source to then copy things over
[14:01]  * pitti is catching up with email
[14:01] <seb128> I should reply to bugs using the email interface ;-)
[14:02] <pitti> seb128: that works fine indeed
[14:02] <ttx> jdstrand, mdeslaur: about bug 537978, there is a regression in debian recent "feature" allowing DHCP to change any hostname in lease renewal. I was pondering if it should not just be reverted, I wonder about security implications... The previous design was limiting the hostname change-by-DHCP to only if it wasn't previously set, which is quite safer.
[14:02] <ttx> "Feature" was introduced in debian bug 508804
[14:05] <james_w> lifeless: usually not the package you are trying to install's fault. Try installing devscripts explicitly and repeat until you get a better reason than "not going to be installed".
[14:10] <mdeslaur> ttx: let me take a look, hold on
[14:10] <msetim> hello
[14:12] <mdeslaur> ttx: agreed. Dhcp should not change hostname if it is set locally
[14:12] <mdeslaur> ttx: please revert to non-broken pre-lucid behaviour
[14:13] <ttx> mdeslaur: will do. I won't ask you to comment on that bug... :)
[14:13] <mdeslaur> ttx: sure, hold on
[14:13] <mdeslaur> ttx: let me just check the debian bug first
[14:13] <ttx> mdeslaur: because you can't :)
[14:14] <mdeslaur> ttx: I can't what?
[14:14] <mdeslaur> ttx: hold on a sec, it seems the fix was actually for a bug
[14:14] <msetim> I have installed ubuntu 10.04 64 bits. It was working fine when I closed my laptop entering in suspend mode and when I opened my laptop he show me the window to type my password, but after first updates it doesn't show window to type my user password and get me back to GDM to start a fresh gnome login =/
[14:15] <mdeslaur> ttx: the current script doesn't write to /etc/hostname anywhere, right?
[14:15] <ttx> mdeslaur: no it doesn't
[14:15] <msetim> the suspend mode continues working, the issue is when ubuntu come back to work (opened laptop)
[14:16] <mdeslaur> ttx: yeah, the fix is wrong, I would go back to pre-lucid
[14:17] <ttx> mdeslaur: ack
[14:17] <mdeslaur> ttx: actually...what's old_host_name?
[14:18] <mdeslaur> ttx: is it the name the dhcp server _previously_ returned?
[14:19] <ttx> mdeslaur: I'm not exactly sure. We could honor it for example is /etc/hostname is still empty/missing.
[14:20] <mdeslaur> ttx: if old_host_name is the previous name returned by dhcp, I like your suggestion in comment #3
[14:20] <primes2h> msetim: This is not the right channel. Would you like to join testing team and test your laptop. Have a look here. https://wiki.ubuntu.com/Testing/Laptop
[14:21] <primes2h> s./?
[14:21] <ttx> mdeslaur: I'd add a check on /etc/hostname to only switch if hostname is not set by config.
[14:21] <ttx> because old_host_name is controlled by the DHCP server
[14:22] <ttx> otherwise you're back to enabling the DHCP server to change your hostname if it knows it.
[14:22] <mdeslaur> ttx: right
[14:24] <msetim> primes2h, thanks ;)
[14:25] <mdeslaur> ttx: ok, so if /etc/hostname is set, never change, or else honor dhcp hostname.
[14:25] <mdeslaur> ttx: makes sense?
[14:25] <primes2h> msetim: np. :-)
[14:25] <ttx> mdeslaur: yes
[14:25] <mdeslaur> ttx: cool
[14:33] <FeasibilityStudy> I am trying to build a .deb, and I keep getting this error: http://pastebin.com/MbytmVSa
[14:33] <FeasibilityStudy> can anyone help
[14:36] <sebner> FeasibilityStudy: mind posting your rules file?
[14:37] <FeasibilityStudy> OK
[14:39] <FeasibilityStudy> one sec.
[14:41] <FeasibilityStudy> http://pastebin.com/632TzTrA
[14:41] <FeasibilityStudy> Now after messing around a bit with the spaces/tabs, I got it to go past that part.  Now it is stuck at build saying no rule to target
[14:46] <sebner> FeasibilityStudy: I'd recomment using dh7 with overrides. Less to break imho, give me a sec
[14:47] <cjwatson> you don't even need overrides for any of that
[14:48] <cjwatson> rules.tiny and an install file should do fine
[14:48] <sebner> cjwatson: FeasibilityStudy http://pastebin.com/VBcFELkW
[14:48] <sebner> cjwatson: hehehehehee
[14:50] <cjwatson> but if you do use an override target, fix the bizarre indentation.  a single tab is all you need
[14:50] <sebner> cjwatson: I blame pastebin
[14:50] <sebner> FeasibilityStudy: should do: http://pastebin.com/dsjNUyQQ
[14:55] <FeasibilityStudy> getting an error about a file already existing
[14:55] <sebner> FeasibilityStudy: so you do have a buildsystem?
[14:55] <FeasibilityStudy> http://pastebin.com/q7bQNmW5
[14:56] <FeasibilityStudy> I think so.  I believe I installed all of that.
[14:58] <sebner> FeasibilityStudy: nah, just put the second mkdir under the first one. though it seems you could delete it as well
[14:59] <FeasibilityStudy> hmm I still get the error
[15:04] <sebner> FeasibilityStudy: then delete the second mkdir
[15:06] <FeasibilityStudy> still get error
[15:06] <FeasibilityStudy> must be something wrong with the spaces/tabs somehow
[15:08] <sebner> FeasibilityStudy: that would be another error, paste it again
[15:09] <FeasibilityStudy> http://pastebin.com/HNKrdY0q
[15:09] <cjwatson> 46. mkdir -­p /home/chrono/Desktop/Development/PyPass/dist/sandbox/pypass-1.0/debian/pypass
[15:09] <cjwatson> you have two different kinds of hyphens in there
[15:09] <cjwatson> this is all more work than you need, anyway
[15:10] <cjwatson> you could just put this in debian/install:
[15:10] <cjwatson> pypass usr/local
[15:10] <cjwatson> er, sorry
[15:10] <cjwatson> pypass.py usr/local
[15:10] <cjwatson> data usr/local/pypass
[15:10] <cjwatson> (why are you installing files to /usr/local, anyway?  programs would go in /usr/local/bin)
[15:10]  * sebner agrees with cjwatson 
[15:17] <psusi> Keybuk: it looks like the sys5 compat scripts conflict with upstart in runlevel 1.. it's trying to killall, and upstart keeps restarting tasks that rc kills
[15:20] <Keybuk> psusi: yes, long known bug
[15:20] <Keybuk> really the bug is that the sysv scripts use killall there at all
[15:20] <psusi> Keybuk: seems like upstart should handle the killall no?
[15:21] <FeasibilityStudy> cjwatson: what do you mean I have two different kind of hyphens in there?
[15:21] <Keybuk> psusi: there should be no "killall" when entering runlevel 1
[15:22] <hggdh> ttx: I did not preview anything else from what is already there, did not have time
[15:22] <psusi> Keybuk: why not?  we need to make sure that everything is shut down
[15:23] <Keybuk> no you don't
[15:23] <Keybuk> single user mode != no processes running
[15:23] <psusi> that's kind of the point isn't it?  yea... not no processes, but no processes that aren't set to run in single user mode
[15:23] <Keybuk> no
[15:23] <Keybuk> it isn't the point
[15:24] <Keybuk> the point is that only one user is logged in, and additional users cannot log in
[15:24] <Keybuk> not that there is nothing running
[15:24] <psusi> yea... and if other users left background jobs running, then should not be running once switched to single user mode
[15:25] <Keybuk> why not?
[15:25] <Keybuk> I don't see anything in the sysv spec about htat
[15:25] <cjwatson> FeasibilityStudy: your paste shows "mkdir -­p"
[15:25] <Keybuk> (and you could argue the same for any change of runlevel)
[15:25] <Keybuk> according to sysv, if you runlevel 3 within X, your login session should be logged out, etc.
[15:25] <psusi> the whole point of single user mode is to make sure that no normal user stuff is running so the admin can perform system maintainence... do things like remount the root ro....
[15:26] <cjwatson> FeasibilityStudy: I don't know if it's visible in your font, but that's  hyphen soft-hyphen p
[15:26] <cjwatson> you need to remove the soft-hyphen or it won't work
[15:26] <FeasibilityStudy> cjwatson: must be the font I am using..
[15:26] <cjwatson> the font would influence how it's displayed for you, but the stray character is certainly there
[15:27] <psusi> of user background jobs are not killed, he can't do that
[15:27] <psusi> s/of/if
[15:27] <cjwatson> and that's the cause of the error you're seeing
[15:27] <Keybuk> psusi: no it isn't ;) not according to the spec
[15:27] <psusi> badly written spec the ;)
[15:28] <Keybuk> I would agree
[15:28] <FeasibilityStudy> cjwatson: probably because I copied a template from a .pdf file tutorial and it didnt translate
[15:28] <Keybuk> this is why Upstart doesn't *do* SysV by itself
[15:28] <FeasibilityStudy> but I am at a loss of what to do now..
[15:29] <Keybuk> psusi: arguably the sysvinit script should omit pids managed by Upstart, like the shutdown ones
[15:29] <cjwatson> FeasibilityStudy: remove the character immediately before "p" in that mkdir line.  It should read "mkdir -p".
[15:29] <cjwatson> FeasibilityStudy: I don't know how to be any clearer than this - sorry
[15:29] <psusi> Keybuk: the killall would not be needed if say, when the getty upstart job spawns a user shell, upstart keeps track of this and makes sure it's dead when the getty job is stopped
[15:29] <psusi> imho that's really the right way to do it
[15:30] <Keybuk> upstart does do that
[15:30] <Keybuk> but it allows processes to escape
[15:31] <psusi> what do you mean?
[15:31] <FeasibilityStudy> but I am copying what sebner pasted verbatim
[15:31] <FeasibilityStudy> what he suggested I put in rules..
[15:31] <psusi> if a user logs into a gnome desktop and spawns a background job, then you stop gdm, does that background process get killed?
[15:31] <Keybuk> no
[15:32] <psusi> didn't think so... that's the problem that killall was put there to fix
[15:32] <cnd> slangasek: I'm trying to figure out how plymouth logging works, shouldn't there be a /var/log/boot.log file?
[15:32] <cjwatson> FeasibilityStudy: I'm afraid you aren't.  I just rechecked sebner's version and it does not match yours.
[15:32] <cnd> by default
[15:33] <FeasibilityStudy> this is odd..I am using nano and I can only see that -- if I move the cursor over it, then it appears
[15:33] <lamont> pitti: what have you done to me?  http://paste.ubuntu.com/407086/
[15:33]  * lamont remembers fondly when gnome would actually come up when he logged in.
[15:33] <lamont> it seems like only yesterday
[15:33] <cjwatson> FeasibilityStudy: wait, sebner's version is a bit broken, but in a different way
[15:34] <pitti> lamont: the guest session isn't supposed to have access to other people's home directories; even less so if that person is as important as lamont!
[15:34] <cjwatson> FeasibilityStudy: OK, look.  DELETE that override_dh_auto_install paragraph entirely.  ADD a debian/install file that contains two lines, as follows:
[15:34] <cjwatson> pypass.py usr/local
[15:34] <cjwatson> data usr/local/pypass
[15:34] <lamont> pitti: I logged in as ME
[15:34] <FeasibilityStudy> Ok I got the hyphen thing fixed..now the error is cp: cannot stat `data/': No such file or directory
[15:34] <lamont> pitti: so WTF am I guest?
[15:34] <pitti> lamont: hm, apparently with using /usr/share/xsessions/guest-restricted.desktop ?
[15:34] <sebner> cjwatson: what was broken?
[15:34] <cjwatson> well, that's a matter for you, if you don't have a data/ directory in your package then you shouldn't be trying to copy it :-)
[15:34] <pitti> lamont: what does "Session" say in ~/.dmrc ?
[15:34] <cjwatson> sebner: you had some stray soft hyphens
[15:35] <lamont> pitti: interesting... I dist-upgraded, rebooted, and then logged in.
[15:35] <FeasibilityStudy> cjwatson: what should my rules file contain?
[15:35] <cjwatson> sebner: visible in w3m, not in firefox
[15:35] <sebner> cjwatson: grml, I just copied from him in the first place
[15:35] <cjwatson> FeasibilityStudy: it should be a copy of /usr/share/doc/debhelper/examples/rules.tiny
[15:35] <lamont> [Desktop]
[15:35] <lamont> Session=gnome
[15:35] <lamont> Language=en_US.utf8
[15:35] <lamont> Layout=us
[15:35] <lamont> ^^piti
[15:35] <lamont> with a leading blank line
[15:36] <pitti> that looks fine
[15:36] <pitti> lamont: $ echo $GDMSESSION
[15:36] <pitti> ?
[15:36] <lamont> +mix 303 : grep lamont /etc/passwd
[15:36] <lamont> +mix 304 : id lamont
[15:36] <lamont> uid=2501(lamont) gid=850(mmj) groups=850(mmj),2502(desktop)...
[15:36] <lamont> pitti: totally not logged in
[15:36] <lamont> login works just fine, and then blank screen, still with the gdm background
[15:36] <FeasibilityStudy> cjwatson: do you recommend /usr/local/bin instead of /usr/local?
[15:36] <lamont> logging in on a tty? no problem
[15:36] <cjwatson> FeasibilityStudy: yes
[15:36] <lamont> so I'm gonna bet that GDMSESSION=null
[15:37] <pitti> lamont: you see the gdm screen?
[15:37] <lamont> pitti: I wonder if it has anything to do with the login not being in /etc/passwd?
[15:37] <pitti> lamont: what does it say when you select your user and look at the "session" picker at the bottom?
[15:37] <pitti> lamont: perhaps
[15:37] <lamont> gdm screen (with user pretty faces turned off), click on 'login' (or whatever), type in my name and password, just like all the times before
[15:37] <pitti> but it should use pam
[15:38] <lamont> pitti: adding to my fun was that I left my laptop in town last night, so I'm now about 30 minutes from my computer with the issue
[15:38] <pitti> lamont: right, but if you type your name, you should see a keyboard, loclae, and session selector, while the password input line is shown
[15:38] <pitti> "locale"
[15:38] <lamont> LANG=en_US.UTF-8
[15:38] <lamont>  and all that jazz.  (ssh'ed into the machine)
[15:38] <cjwatson> mvo: so is dropping files in /var/lib/update-notifier/user.d/ still the way to make notifications appear?
[15:39] <lamont> ah, buttons. yeah... I can't see 13 miles through walls, though
[15:39] <pitti> lamont: that was just a typo correction from the previous sentence
[15:39] <pitti> lamont: can you check /var/cache/gdm/martin/dmrc
[15:39] <pitti> sorry, /var/cache/gdm/lamont/dmrc
[15:39] <mvo> cjwatson: yes, but it will only show them after /var/lib/update-notifier/dpkg-was-run got touched (that happens when apt finishes)
[15:40] <Keybuk> err, wtf
[15:40] <lamont> pitti: identical to the above
[15:40] <Keybuk> gcc just "optimised" my code to be in the wrong order
[15:40] <mvo> cjwatson: or on the next reboot of course (if you do it from the installer)
[15:40] <cjwatson> dpkg-run-stamp?  ok
[15:40] <lamont> Keybuk: clearly you haven't informed gcc adequately
[15:40] <cjwatson> mvo: didn't see it on the next reboot, which is why I asked :)
[15:40] <Keybuk> lamont: err, wtf?
[15:40] <lamont> heh
[15:41] <pitti> lamont: hmm; when's the next time you can log into gdm on that thing?
[15:41] <Keybuk> 	mnt->error = ERROR_NONE;
[15:41] <Keybuk> 	plymouth_update (FALSE);
[15:41] <Keybuk> according to gdb, it did those two statements in the *opposite* order
[15:41] <pitti> gdb with -O2 screws up ordering all over, though
[15:41] <lamont> pitti: now that I have my laptop, I suppose I could run back home, otherwise it'll be around 2400 UTC
[15:41] <pitti> when stepping through, it appears to run almost all statements twice
[15:42] <pitti> lamont: hm, tomorrow then?
[15:42] <lamont> Keybuk: gcc vs gdb is always lost on optimized code - gotta look at the actual assembly to see wtf is up
[15:42] <Keybuk> lamont: I did
[15:42] <lamont> pitti: sure - I'll be back online about 1100 UTC
[15:42] <lamont> Keybuk: ew
[15:42] <pitti> lamont: sounds fine
[15:42] <lamont> pitti: meanwhile, I miss my desktop. :-p
[15:43] <pitti> lamont: I thought you aren't sitting on it anyway?
[15:43] <lamont> yeah, but it still  eats at me
[15:43] <psusi> Keybuk: wow... so you checked the asm and it actually made the call before the ld?  that's messed up
[15:44] <psusi> that violates the sequence point rule
[15:44] <Keybuk> precisely
[15:44] <psusi> plymout_update is actually a function right?  not a macro?
[15:45] <lamont> http://paste.ubuntu.com/407093/ <-- pitti the upgrade that killed it, and since
[15:45] <pitti> lamont: erm, you removed gnome-session?
[15:45] <mdeslaur> lamont: you removed a bunch of required packages!
[15:45] <pitti> that's doomed to fail
[15:45] <lamont> well, that'd do it
[15:45] <lamont> I didn't remove them... ghome-update did
[15:45] <pitti> lamont: yes, it'll totally not work without gnome-session
[15:45] <lamont> er, dist-upgrade did
[15:46] <pitti> DDTT ;) use upgrade and hold back, not remove
[15:46] <cjwatson> mvo: definitely not showing it - how should I go about debugging it?  can I kill update-notifier and then run it under strace or something?
[15:46] <lamont>   ubuntu-desktop: Depends: gnome-applets but it is not going to be installed
[15:46] <lamont>                   Depends: gnome-control-center but it is not going to be installed
[15:46] <lamont>                   Depends: gnome-panel but it is not going to be installed
[15:46] <lamont>                   Depends: gnome-session but it is not going to be installed
[15:46] <lamont>                   Depends: indicator-applet-session but it is not going to be installed
[15:46] <lamont> sigh
[15:46] <pitti> lamont: amd64?
[15:46] <lamont> yep
[15:46] <pitti> lamont: there was a soyuz bug which didn't publish gnome-panel and others for half a dsy
[15:46] <pitti> day
[15:47] <pitti> this caused a lot of FTBFS :(
[15:47] <lamont> and nothing in /topic here to warn me that I'd be dead if I upgraded?
[15:47] <lamont> sihg
[15:47] <mdeslaur> lamont: you see, it's your own fault :)
[15:47] <lamont> note to self.  do not sleep through the dist-upgrade
[15:47] <Keybuk> lamont: the great big THE FOLLOWING PACKAGES WILL BE REMOVED is the warning ;-)
[15:48] <mvo> cjwatson: it has a --debug-hooks switch  that will print out some output, if you could paste that
[15:48] <lamont> Keybuk: at least it didn't give me the opportunity to type Yes, do as I say!
[15:49]  * lamont goes to find a corner to sit in
[15:50] <mdeslaur> lol
[15:51] <kirkland> slangasek: could you have a look at (my fixes for) https://bugs.edge.launchpad.net/ubuntu/+source/base-files/+bug/550561
[15:52] <cjwatson> mvo: I think it was user error, sorry
[15:52] <mvo> cjwatson: no worries
[15:53] <apw> i just did a clean install using 'todays' live-CD and it seemed to be using the network ... downloading several sets of files.  would i expect that, and does it work without the network present?
[15:55] <cjwatson> apw: language support files; and it should do, modulo bugs
[15:55] <apw> cjwatson, will try it without the network next time ... thanks
[15:59] <apw> cjwatson, on a different note, its looking pretty professional
[15:59] <cjwatson> lool,doko__,mvo,slangasek,james_w: I didn't have time to send out a mail, but I'm cancelling the foundations meeting this week - LP downtime put the Europeans out of kilter in their work days, and everyone should be working on beta-2 bugs
[16:00] <cjwatson> apw: the new slideshow is very nice
[16:00] <apw> shame the little minimise icon is a bit crap
[16:04] <ttx> asac, ogra: about bug 532733, should one of you be assigned to it, or do you need qemu-kvm maintainer to help / be assigned to it ?
[16:05] <asac> ttx: help much appreciated
[16:06] <asac> ttx: we are kind of lost how to debug this. we suspect its either kernel or qemu enging having a thumb2 bug (though thats rather unlikely how late this happs imo)
[16:06] <ttx> asac: you can ping kirkland if that can be of any help. I'm not sure I understand where the problem lies either
[16:06] <ttx> but having a high/beta2-targeted bug without assignee sounds wrong :)
[16:06] <asac> ttx: oh yeah. pleas assign to kirkland ;)
[16:07] <ttx> asac: well, I don't think he can really fix it as it stands
[16:07] <asac> ttx: but he can ask for more info etc.
[16:07] <asac> or probably has upstream contacts that might be able to
[16:07] <james_w> cjwatson: ACK
[16:07] <FeasibilityStudy> Argh..this drives me crazy..http://pastebin.com/VpHYmvtG
[16:08] <cjwatson> FeasibilityStudy: if you don't have a data directory, why were you trying to install it?
[16:08] <cjwatson> FeasibilityStudy: where is the original source that you're trying to package?
[16:09] <FeasibilityStudy> in the directory I am in
[16:09] <cjwatson> not on the Internet anywhere so we can look?
[16:09] <ttx> kirkland: ^ I'll let you comment on that, and assign yourself to it if you think it's the best way to fix this bug
[16:09] <FeasibilityStudy> cjwatson: No I wrote it
[16:10] <cjwatson> FeasibilityStudy: so, you were trying to install a 'data' directory.  Where is it?
[16:10] <kirkland> ttx: i can forward the bug to upstream qemu, and ask if anyone has ideas
[16:10] <FeasibilityStudy> cjwatson: you told me to add data to /debian/install
[16:10] <ttx> kirkland: sounds good.
[16:10] <kirkland> ttx: it would probably take me a lot of time to dig deep into the arm emulation code and actually develop a fix
[16:11] <kirkland> ttx: which, at this point, it looks to me like some strange issue in the arm emulation code
[16:11] <cjwatson> FeasibilityStudy: your original rules paste was http://pastebin.com/632TzTrA, and it contained 'cp -r data/ $(CURDIR)/debian/pypass/usr/local/pypass'
[16:11] <kirkland> asac: is that what it looks like to you?
[16:11] <FeasibilityStudy> data usr/local/bin
[16:11] <FeasibilityStudy> is what you said to add to install
[16:11] <cjwatson> FeasibilityStudy: all I did was copy that over; I'm not telepathic and can't tell what your package looks like
[16:11] <cjwatson> *no I didn't* - I said 'data usr/local/pypass' which was a *direct translation* of what was in your original rules file
[16:12] <cjwatson> if you don't have a data directory, just remove that line from debian/install - I don't know why you had that cp -r there to begin with, in that case?
[16:13] <FeasibilityStudy> cjwatson: because some tutorial said to..
[16:14] <rbellamy> I need some guidance on linking some c code to a "library support file"
[16:14] <cjwatson> FeasibilityStudy: that tutorial was no doubt describing how things would work for the application it was dealing with.  You're supposed to adapt these things to meet your particular requirements
[16:14] <cjwatson> FeasibilityStudy: in that case, just remove that line from debian/install
[16:14] <rbellamy> the policy manual for library support files states that they should be placed in a subdirectory of the primary library (e.g. /usr/lib/somedir)
[16:14] <FeasibilityStudy> cjwatson I did
[16:15] <rbellamy> when I link to that file, and compile, everything works fine
[16:16] <rbellamy> but then when I try to execute, I get a "cannot open shared object file", since ldconfig doesn't traverse the subdirectories
[16:16] <rbellamy> so, now to my question:
[16:16] <asac> kirkland: i would think it has to do with IO in the emulation code. yes
[16:16] <asac> some deadlock
[16:16] <asac> kirkland: please get it upstream ... thats the least we can do
[16:16] <rbellamy> what is the accepted solution for linking only to a support file when then executing?
[16:17] <kirkland> asac: i'll email upstream today
[16:17] <asac> kirkland: thanks. please CC me and ogra
[16:18] <asac> kirkland: and lool
[16:18] <kirkland> asac: you bet, i'm drafting the email now
[16:18] <asac> rock
[16:18] <FeasibilityStudy> cjwatson: any idea why i get this: http://pastebin.com/Jp7irZeq
[16:19] <kirkland> asac: oh, couple of questions for you ...
[16:19] <FeasibilityStudy> I mean I know it is not a directory, but why is it wanting it to be a dir?
[16:19] <kirkland> asac: so this is in a chroot?  or is there a backing disk?
[16:19] <cjwatson> rbellamy: normally, you'd use -rpath
[16:20] <kirkland> asac: ah, i see a backing disk, root or qcow2
[16:20] <rbellamy> cjwatson: I thought I was.... I'll have to review the build settings. No wonder I was confused. :)
[16:20] <kirkland> asac: okay, are the disks scsi emulated, or virtio?
[16:20] <asac> kirkland: its a disk. raw
[16:20] <asac> disc image raw i am told
[16:21] <asac> makes sense?
[16:21] <kirkland> asac: first thing upstream is going to ask is if you tried virtio, as that's what they recommend in almost all cases
[16:21] <cjwatson> FeasibilityStudy: side-effect of how dh_usrlocal works - while I can recommend a fix, the more immediately urgent question, I think, is whether you have a good reason to install into /usr/local/ (or any of its subdirectories) at all?
[16:21] <kirkland> asac: can you get me the *full* qemu-system-arm command line used (running in ps -ef) when this happens?
[16:21] <asac> kirkland: ogra will put that command line in bug
[16:22] <asac> kirkland: we dont know what virtio means ;)
[16:22] <kirkland> asac: i see something at https://wiki.ubuntu.com/ARM/RootfsFromScratch
[16:22] <asac> kirkland: yes. wait. we paste you the definitly command line in bug
[16:22] <rbellamy> cjwatson: dude, that was exactly my problem. Thanks for the pointer.
[16:22] <kirkland> asac: can you try this:
[16:22] <FeasibilityStudy> cjwatson: probably not.  Where would you recommend I install?  The program does not need root..Keep in mind I am not installing this for ME..I am just wanting to package it, mainly to leanr how to.
[16:22] <kirkland> asac: sorry, looks like this is what you're running:
[16:22] <kirkland> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[16:22] <kirkland> asac: ogra_cmpc: can you confirm?
[16:22] <cjwatson> FeasibilityStudy: it would be more normal to install into usr/bin
[16:23] <FeasibilityStudy> ok, would that fix this error?
[16:23] <asac> kirkland: ok its RootfsFromScratch command line really
[16:23] <cjwatson> yes
[16:23] <asac> kirkland: ogra_cmpc has no internet and cannot chat till next week
[16:23] <asac> i am proxying
[16:23] <cjwatson> if you absolutely have to install files into /usr/local for some reason, http://paste.ubuntu.com/407112/ would make it work
[16:23] <cjwatson> but I'd recommend just installing to /usr/bin instead
[16:24] <kirkland> asac: sorry, i don't know what RootfsFromScratch means
[16:24] <asac> kirkland: ogra here, follow the instructions on rootfs from scratch to build an ubuntu-minimal setup (use --notarball to get a qemi
[16:24] <asac> u image)
[16:24] <FeasibilityStudy> YAY!
[16:25] <apw> cjwatson, this install is at 95% and is slowly flashing my HDD, any idea what phase that is?  it could do with a message
[16:25] <FeasibilityStudy> however, it failed to pick up my GPG key..But I didn't use the -k flag.
[16:25] <asac> kirkland: its a wikipage
[16:25] <kirkland> asac: url?
[16:25] <kirkland> ogra_cmpc: hiya, are you around?
[16:25] <asac> kirkland: its a http://wiki.ubuntu.com/ARM/RootfsFromScratch
[16:25] <FeasibilityStudy> cjwatson: If one has one's own PPA is it necessary to sign the package when building the .deb, or does uploading it to the PPA do that for you?
[16:25] <cjwatson> FeasibilityStudy: that's OK, you can just run debsign by hand afterwards if you like
[16:26] <asac> kirkland: as asac said, i cant get my machine online from here
[16:26] <cjwatson> FeasibilityStudy: you have to sign it before upload - the PPA system doesn't (and shouldn't!) have your personal key
[16:26] <asac> <-- ogra
[16:26] <FeasibilityStudy> because when i created my PPA it created a new GPG key for me.  So I figured it would be redundant to sign it with my personal key.
[16:26] <asac> ogra_cmpc is my idling machine at home
[16:26] <kirkland> asac: :-D
[16:26] <cjwatson> FeasibilityStudy: no, that's not the same
[16:27] <kirkland> asac: so no human-ogra here right now then?  :-)
[16:27] <cjwatson> FeasibilityStudy: that's the GPG key that signs the archive so that your PPA's users can trust that somebody evil on their network isn't substituting a different package
[16:27] <cjwatson> FeasibilityStudy: it's not the GPG key that the archive uses to ensure that the upload really came from you
[16:27] <cjwatson> the latter is the one you use when you run debsign (or debuild -k)
[16:27] <asac> kirkland: on the wiki, follow the first reciepe under 'building a root filesystem image instead of a tarball'
[16:28] <asac> kirkland: then boot that as described under 'Using a qemu image with full emulation'
[16:29] <asac> kirkland: in the booted VM do: sudo apt-get install ubuntu-netbook^
[16:29] <asac> and watch it hang somewhere
[16:29] <kirkland> asac: how long does that take?
[16:29] <kirkland> asac: the hang
[16:29] <ninjai> is there anybody that's able to help me with the brightness keys on my laptop not working in lucid beta 1?
[16:29] <asac> quite a while depending how speedy your host machine is
[16:30] <asac> kirkland: its relatively fast if yu have a local mirror of ports
[16:31] <ScottK> ninjai: You want #ubuntu+1 for that.
[16:31] <slangasek> pitti: openldap> I'm not current on the db compatibility stuff with openldap, that should be checked with upstream before any change
[16:31] <kirkland> asac: okay, stay tuned ... i'm putting this together now
[16:31] <asac> kirkland: it usually hangs at unpacking iputils-something or at iso-codes
[16:31] <slangasek> cnd_mini: there *should* be a /var/log/boot.log file - that didn't work in the past, it does work now
[16:31] <slangasek> cnd_mini: at least, I have one here
[16:32] <asac> kirkland: the package seems to vary for different people but is individually reproducable for them then
[16:32] <slangasek> kirkland: 550561> from the bug description, it doesn't look to me like anything that needs an FFe - it's just a bugfix?
[16:32] <kirkland> asac: okay, i'll try to reproduce it with scsi emulation first
[16:33] <kirkland> slangasek: see the debdiff... there's a bit of other cleanup in there, but I definitely feel it's a bugfix;  just looking for a second opinion since it's such a fundamental package
[16:33] <kirkland> slangasek: and I've tested it thoroughly here
[16:33] <kirkland> asac: and then i'll try with virtio ;-)
[16:34] <asac> kirkland: the call rootstock uses to trigger it is similar to whats on teh wiki, lool suggested to try -disk instead and play with some cacing options, which i didnt manage to test yet due to traveling
[16:34]  * asac .... ogra hands the laptop back to asac
[16:35] <kirkland> ah, asac was ogra :-)
[16:35]  * asac reads if bought something ;)
[16:35] <asac> ogra said he stated that initially
[16:35] <kirkland> asac: sorry, i missed it
[16:35] <asac> heh ... all fine ;)
[16:36] <mdz> I assume I'm not the only one getting spammed with ancient bug comments since the LP rollout?
[16:36] <slangasek> kirkland: ok; I can look at this in ~1h
[16:36] <kirkland> slangasek: perfect; i'm sure that qemu-system-arm will consume me until then :-)
[16:37] <kirkland> asac/ogra: okay, just clarifying ....  I'm following the instructions at https://wiki.ubuntu.com/ARM/RootfsFromScratch
[16:37] <apw> cjwatson, this install just completed ... and ejected the CD, and puked sr0 errors ... and stopped
[16:38] <kirkland> asac: where do i get armel-rootfs-200904151837.tgz
[16:38] <kirkland>  from?
[16:38] <cjwatson> apw: I doubt that has anything to do with network connectivity
[16:38] <apw> cjwatson, no ... i suspect not :)
[16:39] <cjwatson> the general idea is that casper's meant to read everything it'll need into page cache before ejecting the CD
[16:39] <cjwatson> it may have missed something
[16:39] <apw> cjwatson, this machine is likely memory 'lacking'
[16:39] <cjwatson> mdz: I figure I'm going to be getting it for roughly the rest of time
[16:39] <cjwatson> mdz: though I suppose there's a chance that it'll remind me of some things I should have closed but didn't
[16:40] <mdz> cjwatson, I've got 20 so far, and it's only on bug 7076
[16:40] <mdz> only 500,000 to go
[16:41] <mdz> cjwatson, #launchpad is just happy it's working ;-)
[16:41] <slangasek> pitti: should your latest edit to /ReleaseProcess say 'release' instead of 'beta'?
[16:42] <kirkland> asac: doh, i think rootstock is creating that for me....
[16:42] <kirkland> :-)
[16:42] <pitti> slangasek: erm yes, sorry; fixed
[16:42] <pitti> slangasek: (I replied to dpm's mail about coordination, for the context)
[16:43] <cjwatson> mdz: I must admit that I am rather looking forward to having useful comment aggregation in LP
[16:43] <dpm> pitti, ah, yeah, thanks for that
[16:44] <cjwatson> Caesar: bug 546405: are there multiple LUKS containers here, or just one?  (i.e. multiple passphrase prompts or just one?)
[16:45] <kirkland> asac: hmm, okay ... so rootstock created qemu-armel-201003311032.img for me
[16:45] <cjwatson> marjo: your lists of ISO testing bugs don't appear to filter out duplicates, e.g. bug 541539
[16:46] <kirkland> asac: and now i'm running "qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201003311032.img -append "root=/dev/sda mem=384M devtmpfs.mount=0 rw"
[16:46] <kirkland> asac: kernel panics though
[16:46] <cjwatson> marjo: (filter out, or consider the dup target instead, or whatever)
[16:46] <kirkland> asac: does not like the root filesystem
[16:46] <marjo> cjwatson: ack
[16:47] <marjo> cjwatson: will try to fix by Friday morning
[16:47] <kirkland> asac: nevermind, owned by root
[16:47] <cjwatson> marjo: thanks
[16:48] <FeasibilityStudy> cjwatson can you give me a quick rundown of how to sign a .deb once it has already been created?  Do I need to sign the .deb itself or just the .dsc? or Both?
[16:51] <zul> pitti: ping about #493593 can you approve python-formencode. I have updated the bug with the required info
[16:52] <kees> FeasibilityStudy: for uploading? you need to sign the source.changes file (debs aren't signed)
[16:52] <pitti> zul: I'm just looking at it incidentally
[16:53] <zul> pitti: ah good...because ttx was bugging me about it incidentally ;)
[16:53] <FeasibilityStudy> kees: ok clearsign, detached sign or what?
[16:53] <ttx> ttx is bugging everyone on beta2 targeted bugs :P
[16:54] <jibel> mvo, hey, when you have a minute could you review apt fix for bug 130289. Thanks.
[16:54] <kees> FeasibilityStudy: "debsign foo_*source.changes"
[16:54] <dpm> hey mvo, when you've got some time, do you think you could look at bug 552542? It seems that the ddtp translations in Chinese and Japanese have some breakage
[16:57] <lamont> asac: btw, the first 3 of 8 armel buildds are the new boards
[16:57] <FeasibilityStudy> argh, getting an error that secret key cannot be found..I know it exists
[16:58] <lamont> StevenK: and cushaw fixed.
[16:58] <cjwatson> FeasibilityStudy: as a simpler alternative to what kees said, you can just run debsign in the source directory
[16:58] <cjwatson> there are options to debsign to set the signing key id ...
[17:02] <FeasibilityStudy> OK I had to pass the -k flag to make it work.
[17:02] <FeasibilityStudy> and enter key ID...
[17:02] <FeasibilityStudy> thanks
[17:03] <kirkland> asac: well i'm having a hell of a time getting a network connection inside of this vm
[17:04] <kirkland> asac: doesn't seem to have enough of a kernel (or modules) to see an emulated network device
[17:04] <kirkland> asac: okay, i'm rebuilding my image with a bigger seed
[17:29] <zul> pitti: thanks
[17:37]  * lamont stabs at dch deciding that I  must be doing an NMU
[17:41] <mvo_> jibel: thanks, patch is fine, I merge it today or tomorrow
[17:41] <mvo_> dpm: I check i tou
[17:42] <dpm> thanks mvo_!
[17:42] <mvo_> dpm: oh, a line breaks issue
[17:42] <mvo_> ?
[17:43] <jibel> mvo: donkult merged it into debian. It would be better to merge this one.
[17:45] <mvo_> dpm: I milestoned it
[17:45] <mvo_> jibel: yeah, I noticed. its very similar, I will merge his version (there is also some other bugfixes I need to merge from him today)
[17:45]  * mvo_ hugs jibel for the fix
[17:46] <jibel> mvo_, and gnome team merged the terminal fix \o/
[17:47] <dpm> mvo_, thanks!
[17:48] <Caesar> cjwatson: just the one
[17:49] <jibel> mvo_, any objection to replace synaptic's own proxy settings and use gconf settings instead ?
[17:50] <zyga> hello everyone
[17:52] <mvo_> jibel: well, it runs as root
[17:52] <mvo_> jibel: how would it get the users settings?
[17:52] <mvo_> jibel: cool :)
[17:54] <mvo_> (g-t fix merge)
[17:55] <jibel> mvo_, the 'apply system wide' applies settings to root too. If a user is able to run synaptic as root he's able to apply network settings too.
[17:56] <mvo_> jibel: right, that is fine, but debian does not carry that patch so we still need a way to set it when that is not available
[17:56] <mvo_> jibel: but in general I like the idea, ideally it would go upstream, but its not currently (the apply-system-wide)
[17:58] <cjwatson> Caesar: cool, that makes the bug tractable
[17:58] <cjwatson> Caesar: (otherwise I'd have to invent some way to have different preseedable passphrases for different partitions and argh)
[18:01] <jibel> mvo_, btw I noticed that apt.postinst doesn't set the proxy auth string. Is it a desired behavior ?
[18:01] <zyga> Keybuk: hi, kiko asked me to check with you what kind of bootchart solution we're using for lucid
[18:01] <cjwatson> Riddell: I'm confused about what to do about bug 386099.  Is it plasma-netbook-appletsrc or plasma-netbook-applicationrc (the bug trail mentions both) and what's the difference between them?  What happens if such a file already exists?  What should it contain?  I don't think I'm in a position to answer any of these questions at the moment
[18:01] <Keybuk> zyga: it's called "bootchart"
[18:02] <zyga> Keybuk: right but there are maaaany versions
[18:02] <zyga> Keybuk: I just want to confirm we're using the c+python one
[18:02] <cjwatson> Riddell: I can see what casper is doing, but that relies on a file in the kubuntu-netbook-default-settings package
[18:02] <Keybuk> zyga: since we wrote large parts of it, yes ;-)
[18:02] <Keybuk> though there are at least two variants of the C version <g>
[18:02] <zyga> Keybuk:  ok that's all I needed, thans
[18:02] <cjwatson> (which BTW seems like a very weird way for ubiquity to deliver a desktop file)
[18:02] <zyga> Keybuk: right, apparently there is another one that looks quite promising
[18:03] <Keybuk> the two C versions are known, colloquially, as the "Keybuk version" and the "mmeeks version"
[18:03] <zyga> Keybuk: meego one
[18:03] <kirkland> asac: ogra: around?
[18:03] <Keybuk> I don't know which one is in M{oblin,aemo,eego}
[18:03] <zyga> Keybuk: http://meego.gitorious.org/meego-developer-tools/bootchart/trees/master
[18:03] <Keybuk> that might be an, as yet, undiscovered third
[18:03] <zyga> Keybuk: custom version rewritten from scratch
[18:03] <Keybuk> *shock*
[18:03] <Keybuk> Intel rewrite something from scratch
[18:03] <zyga> hehe
[18:03] <Keybuk> I wonder if it's as amazing as their piece of crap readahead rewrite? :p
[18:04] <zyga> but it seems to be quite good actually, better than what we have
[18:04] <Keybuk> why better?
[18:04] <zyga> less cpu/mem required
[18:04] <zyga> on-the-fly graph
[18:04] <zyga> no python dependency
[18:04] <mvo_> jibel: well, sort of. its a bit dangerous as the password is in cleartext
[18:04] <zyga> pure c
[18:05] <Keybuk> I quite like the fact the graphing is done in python
[18:05] <Keybuk> it's a better language for it
[18:05] <Keybuk> anyway
[18:05] <Keybuk> in summary, no we're not using that version
[18:05] <zyga> Keybuk: the architecture is different - we have to keep the data
[18:05] <Keybuk> we're using the Ubuntu version of bootchart
[18:05] <Keybuk> and actively contributing to a "one true version" of bootchart project being led by mmeeks
[18:05] <zyga> Keybuk: they're just graphing the data in svg which seems less IO constrained
[18:05] <Keybuk> yes, it's amazing how often you want to keep that data
[18:06] <zyga> Keybuk: each time?
[18:06] <Keybuk> and how often you don't want to generate svg on the machine you're trying to boot profile
[18:06] <Keybuk> (I don't at all)
[18:06] <zyga> Keybuk: well it's certainly an argument but their version has some merits
[18:06] <Keybuk> but that's not the conversation you started with :p
[18:06] <zyga> right :D
[18:06] <Keybuk> we're not using that version
[18:06] <zyga> no flame required
[18:06] <Keybuk> I first learned about that version 30 seconds ago <g>
[18:06] <Keybuk> oh, I'm not flaming
[18:06] <zyga> neither am I
[18:06] <asac> kirkland: just quick
[18:06] <asac> ;)
[18:07] <kirkland> asac: okay, i have a small rootstock image running in arm qemu, with networking
[18:07] <zyga> Keybuk: for some rationale (I'm sure you are interested) you can read their readme file: http://meego.gitorious.org/meego-developer-tools/bootchart/blobs/master/README
[18:07] <kirkland> asac: and now I'm going to try sudo apt-get install ubuntu-netbook, right?
[18:08] <Keybuk> zyga: already read through it
[18:08] <Caesar> cjwatson: heh, yeah that sounds like no fun
[18:08] <Caesar> We're not doing anything particularly crazy on the encryption front
[18:09] <asac> kirkland: yes. that works
[18:09] <asac> kirkland: it will hang sooner or later
[18:10] <kirkland> asac: okay, taking a snapshot of my disk, then trying it
[18:10] <asac> cool
[18:10] <kirkland> asac: how much longer are you and/or ogra going to be around today?
[18:11] <asac> kirkland: i will be here for another 20 minutes ... then we are heading for dinner
[18:11] <zyga> mvo_: hi, is there any chance you can run that script (update-alternatives) on the repo today?
[18:11] <kirkland> asac: okay, i probably won't have anything by then, but check in with me if you come back online later
[18:11] <davmor2> pitti: do you need a copy of the udev log with RB fired up too so you can compare them?
[18:12] <nigelb> bryceh, if you've got some time, can you update the lp-gm-scripts PPA? (bdmurray had merged a branch of mine in)
[18:12] <mvo_> asac: oh, the problem with apt-get is actually a qemu bug?
[18:12] <kirkland> asac: oh, another thing ... i see these are running with 256M of memory
[18:12] <asac> mvo_: we dont know
[18:12] <kirkland> asac: is that enough?  especially if there's no swap ....
[18:12] <cjwatson> Keybuk: so in the process of working through bug 548954, I noticed that upstart doesn't pass INIT_VERBOSE through to jobs, so the stuff in /lib/init/vars.sh to detect it doesn't work.  Is there a way for a job to ask that particular named variables from pid 1's environment be exported to it, or should I just have /lib/init/vars.sh parse /proc/cmdline for INIT_VERBOSE as well as everything else?
[18:12] <mvo_> zyga: not today, maybe tomorrow, but I'm swamped a bit currently
[18:12] <slangasek> pitti: hmm, I don't seem to have said mail from dpm
[18:12] <Keybuk> cjwatson: by design ;-)
[18:13] <zyga> mvo_: ok, I'll ask again on Friday, maybe you'll have some more time then, thanks
[18:13] <slangasek> cjwatson: do you want weekly reports to you this week again?
[18:13] <cjwatson> I assumed that defaulting to a clean environment was by design, certainly
[18:13] <cjwatson> slangasek: might as well
[18:13] <slangasek> ok
[18:13] <Keybuk> cjwatson: add "env INIT_VERBOSE" to rc.conf
[18:13] <cjwatson> Keybuk: perfect, thanks.  Want a documentation patch for that? :-)
[18:13] <Keybuk> documentation patch?
[18:14] <cjwatson>        env KEY=VALUE
[18:14] <cjwatson>               Defines a default environment variable, the value of which may be overriden by the event or command that starts the job.
[18:14] <Keybuk> oh, I never documented you could use without the value
[18:14] <cjwatson> perhaps 'env KEY[=VALUE]'
[18:14] <Keybuk> please :p
[18:14] <kirkland> mvo_: do you have any idea how much MEM an apt-get install of ubuntu-netbook might take?
[18:14] <kirkland> mvo_: seems like some of that operation might be memory-intensive?
[18:15] <Keybuk> cjwatson: where does INIT_VERBOSE come from?
[18:15] <zyga> hmm is dying intel graphics a common treat on 10.04?
[18:16] <cjwatson> Keybuk: I'm assuming the kernel command line
[18:16] <cjwatson> or /etc/default/rcS, although it isn't documented there - it seems like a command-line override for VERBOSE
[18:17] <cjwatson> i.e. quiet + INIT_VERBOSE = you get init script output but not vast piles of kernel output
[18:17] <kirkland> zyga: what do you mean by that?
[18:18] <kirkland> zyga: i've noted a couple of weird things with my intel graphics in my Thinkpad; wondered if my hardware might be going bad
[18:18] <cjwatson> which I think is the combination the server team is after; VERBOSE=yes in /etc/default/rcS would work too and I haven't yet decided which would make more sense from an installer POV
[18:18] <bryceh> nigelb, sorry kind of tied up with other stuff at the moment
[18:18] <zyga> kirkland: I just ran daily upgrades and my screen got corrupted for a moment (90% black with some junk at the top)
[18:18] <zyga> this happens quite often, I'm not sure it's related to updates
[18:18] <zyga> sometimes it lasts
[18:18] <nigelb> bryceh, any time you get time is fine too :)
[18:18] <zyga> so if it happens again I can take a photo
[18:18] <bryceh> nigelb, why don't you ask brian to set you up with access to update the ppa?
[18:18] <zyga> usually alt-tabbing fixes it
[18:19] <zyga> kirkland: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
[18:19] <nigelb> bryceh, brian's on vacation.  I forgot to remind to update earlier.
[18:21] <kirkland> zyga: hrm, mine looks like a glitch in the Matrix
[18:23] <bryceh> nigelb, ah, ok well hang on for a bit
[18:23] <zyga> kirkland: so you seen this too?
[18:23] <kirkland> bryceh: i just heard zyga say that he's had some odd issues with intel graphics... i've seen a couple of things too, that i was chalking up to hardware possibly going bad
[18:23] <nigelb> bryceh, I just asked kees too since you were busy, so if either of you get the time :)
[18:24] <bryceh> nigelb, ok great.  Yeah I've not actually updated the ppa so dunno if there's any extra steps to do there
[18:24] <kirkland> bryceh: the two things ... 1) sometimes (maybe 1 in 20) times I open my laptop lid, the screen is so dark I can barely see it (like way darker than minimum contrast)
[18:24] <bryceh> kirkland, lp#?
[18:25] <kirkland> bryceh: and 2) about 3 times in the last two weeks, I've had a "glitch" in the Matrix, where for 1/10th of a second, the screen "glitches", like turning on old tv on, and then it's fine
[18:25] <kirkland> bryceh: i'm not sure it's a bug; think my hardware might be going bad, but i just happened to see zyga asking about Intel graphics issues, and it piqued my curiosity
[18:26] <zyga> bryceh: I'm sure it's a bug
[18:26] <Riddell> cjwatson: bug 386099 wants a plasma-netbook-appletsrc like the "moved_plasma-netbook-appletsrc" one which is used to put ubiquity there, however that needs some changes now because of changes in the default layout
[18:26] <zyga> sorry, kirkland
[18:26] <zyga> I dual boot with 9.04
[18:26] <zyga> never ever on 9.04
[18:26] <Riddell> cjwatson: I can get it sorted, where's the code that gets run before login for the oem user?
[18:31] <cjwatson> Riddell: do you mean bin/oem-config-firstboot?  I think your original suggestion of making the change in scripts/install.py was better though
[18:33] <bryceh> kirkland, yeah dunno, but there's plenty of bug reports about lid issues and glitches so could well be software
[18:34] <bryceh> kirkland, you know the drill... file bug reports, we'll get to them when we have time
[18:34] <kirkland> bryceh: will do
[18:34] <kirkland> bryceh: thanks
[18:35] <Riddell> cjwatson: that looks like it, I'll fix it up
[18:53] <kirkland> asac: okay, i *think* i'm seeing the hang unpacking firefox-gnome-support
[19:19] <lex79> pitti: if I understand, since the nonpolkit-mount-policy patch was in hal from jaunty, this means the patch in kdebase is broken, right?
[19:19] <lex79> we have to fix the patch in kdebase...
[19:22] <lex79> ehrm, in kdelibs, not in kdebase
[19:52] <cjwatson> Riddell: cool, thanks
[19:54] <Riddell> cjwatson: I might move /usr/share/applications/kde/oem-config-prepare-kde.desktop to /usr/share/applications/kde4/oem-config-prepare-kde.desktop, in the kde/ directory it gets marked as being a KDE 3 app which looks bad
[19:55] <cjwatson> ok by me
[19:55] <lex79> doko__: this patch in Qt http://bazaar.launchpad.net/~kubuntu-members/qt/ubuntu/annotate/head:/debian/patches/90_ia64_opts.diff is obsolete since seems you fix the bug also in gcc ?
[19:56] <doko__> lex79: yes, afaik ScottK did want to remove it
[19:57] <lex79> doko__: ok, to fix this ftbs https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.6.2-0ubuntu3 should we drop the patch then?
[19:59] <doko__> lex79: enoclue, that is a different one. please investigate
[20:00] <lex79> oh, ok
[20:13] <kirkland> slangasek: any chance to look at the motd change?  i'd like to upload it before the freeze goes into effect
[20:15] <slangasek> kirkland: looking now
[20:22] <slangasek> kirkland: which part of this corrects the double-printing of motd.tail?
[20:23] <kirkland> slangasek: the postinst.in part
[20:24] <kirkland> slangasek: the part that moves the generated motd.tail out of the way
[20:24] <slangasek> kirkland: so it's not "double-printing of motd.tail", it's "double-displaying of the information we were writing to /etc/motd.tail"?
[20:25] <kirkland> slangasek: that's linguistically more correct, yes
[20:28] <slangasek> kirkland: looks good to me
[20:28] <kirkland> slangasek: thanks man
[20:28] <soren> I've used mk-sbuild to build an sbuild chroot. When I build a package in there, it gets "Distribution: lucid-amd64" in the binary .changes file. Does anyone know off the top of their head where it gets that value?
[20:28] <soren> (I launch sbuild like so: sbuild -d lucid-amd64 blahblahblah.dsc)
[20:30] <geser> I remember reading a discussion about a similar problem, let my try to find it.
[20:30] <soren> Is it passed as an environment variable or something?
[20:30] <soren> It seems I can do -d lucid instead and it works it out anyway.
[20:31] <geser> IIRC this is also the solution
[20:33]  * soren scratches head a little bit
[20:34] <geser> soren: see http://lists.debian.org/debian-devel/2010/03/msg00600.html
[20:39] <Penguin> Can anyone give me a link to a guide on updating deb packages?
[20:45] <soren> geser: Awesome. Thanks for the link!
[21:03] <mvo_> jibel: apt fix is commited, I upload in a little bit
[21:03] <akgraner> hey all - we have a guy in the NC channel who switched to Lucid - he did updates today - and rebooted like it said - now he is in a loop that keeps taking him to his logon screen - I can't help him - but can you all or point me in the right direction to I can tell him?
[21:08] <akgraner> Hi all - magedragon25 just joined - he is the one from the NC channel - thanks in advance to whomever :-)
[21:11] <slangasek> akgraner, magedragon25: this is probably bug #516520, which seems to have regressed in the past few days; I've confirmed that it appears to be a gdm bug, but need the desktop team for further triaging
[21:11] <slangasek> chrisccoulson, seb128: either of you still around and have any insight there? ^^
[21:12] <seb128> I'm around, let me have a look to the bug
[21:12] <magedragon25> that bug says he could get into console from safe mode....my recovery console won't even come up
[21:13] <akgraner> slangasek, is there a way he can fix his system or is it a complete reinstall?  and slangasek thank you for looking into the question for us :-)
[21:13] <slangasek> magedragon25: recovery console may be a whole 'nother kettle of fish right now.  When you get to the login screen, can you hit Ctrl+Alt+F1?  This should take you to a console login prompt; afterwards you can use Alt+F7 to switch back to GDM
[21:14] <seb128> slangasek, doesn't seem a gdm issue there
[21:14] <magedragon25> I will have to reboot, i have only one pc and i had to log into win7 to get here for help
[21:14] <seb128> it seems that the session or xorg crash and they got back to gdm then
[21:14] <cjwatson> systems are always recoverable without reinstalling; it's just a question of how much effort you want to go to. :-)
[21:14] <slangasek> seb128: the log says 'conversation failed', which implies that the application-supplied conversation function returned a failure
[21:14] <seb128> seems another bug which collect different issues
[21:15] <seb128> some comments say startx doesn't work
[21:15] <slangasek> seb128: sorry - to be clear, I'm reading from the bottom of the bug rather than from the top.  The bug was originally opened for a separate issue :/
[21:15] <seb128> ok, let me look at it this way too
[21:15] <magedragon25> be back shortly if it doesn't work
[21:16] <slangasek> akgraner: I hope he also comes back if it *does* work, because I have more questions and would like to debug this in realtime with him :)
[21:16] <seb128> slangasek, gdm didn't really change in the recent weeks
[21:16] <seb128> out of xkb layout changes from pitti
[21:16] <seb128> and gdmsetup
[21:16] <seb128> but neither of those should impact on login
[21:16] <akgraner> slangasek, let me tell him
[21:16] <seb128> are you sure it's not something in the pam stack which changed?
[21:18] <slangasek> seb128: no, I'm not sure; but the 'conversation failed' comes from the application side.  If it's a PAM stack bug, I have a guess where it is, but I need someone who can reproduce the bug to help me narrow it down
[21:18] <akgraner> slangasek, I sent him a message
[21:19] <seb128> slangasek, it doesn't help that the bug collect different issues
[21:19] <seb128> that one seems one and I've no clue about it
[21:19] <seb128> some other comments looks like users dist-upgraded while things were not installable and removed things required
[21:19] <seb128> ie gnome-session
[21:19] <slangasek> heh
[21:19] <seb128> which leads to GNOME not starting
[21:20] <seb128> but it's weird, as said gdm didn't change out of xkb and gdmsetup recently
[21:22] <slangasek> one thing that *did* change recently was the winbind package getting pam-auth-update integration on March 19th; but I don't have any explanation for how that would cause the error shown
[21:29] <magedragon25> I was able to get into console, but startx didn't work
[21:30] <magedragon25> I also switched to gdm, but it just went to my login
[21:34] <magedragon25> slangasek: I am back, I got into console but startx didn't work, it gave me an error about no such process, and switching to gdm just goes to my login
[21:36] <slangasek> magedragon25: hi - what do you mean, "goes to your login"?
[21:37] <slangasek> you mean it takes you back to the login screen (which is what I would expect)?
[21:37] <magedragon25> yes
[21:37] <slangasek> ok
[21:37] <magedragon25> sorry
[21:37] <slangasek> do you have the exact error message from startx?
[21:37] <slangasek> do you know if you have the 'winbind' package installed on this system?
[21:39] <magedragon25> there was no number just said no such process, I assume it's installed if it should be....unfortunately I have to switch back and forth on the same pc
[21:42] <slangasek> magedragon25: winbind is only supposed to be installed if you want to use it; I ask because I'm trying to determine if it's linked in some way to the problems users are reporting
[21:42] <magedragon25> oh
[21:43] <magedragon25> then no, i don't have it
[21:45] <slangasek> a very troubling bug
[21:45] <magedragon25> slangasek: unfortunately, i am gonna have to bail for now. I have to get ready for my college class tonight. it's a redhat class, and being as i am ahead of everyone else, I might be able to get back on, and have my laptop setup next to me
[21:46] <slangasek> magedragon25: ok - the next step for troubleshooting this is going to be to try to log in, then switch with Ctrl+Alt+F1 and examine /var/log/auth.log
[21:47] <magedragon25> ok....I have class at 6pm est, so between 6 and 7, I will know if I can get back on
[21:55] <Caesar> This whole amd64 builder being way behind the i386 one really bites
[22:02] <mathiaz> mvo_: hi!
[22:02] <mvo_> hi
[22:03] <mathiaz> mvo_: is it possible to add some code to update-manager to modify a conffile?
[22:03] <slangasek> twitch
[22:03] <slangasek> why is the package not taking care of it directly?
[22:03] <mathiaz> slangasek: the use case is an upgrade of mysql from 5.0 to 5.1
[22:03] <mvo_> mathiaz: what is the use case? it can do that, but as slangasek says, doing it in the package has the benefit that apt-get users are also happy
[22:04] <mathiaz> slangasek: the skip-bdb option is no longer recognized by 5.1
[22:04] <mathiaz> slangasek: if skip-bdb is in /etc/mysql.my.cnf 5.1 fails to start and the package upgrade fails
[22:04] <mvo_> jibel: thanks for lp:~jibel/synaptic/bug.292267 ! rock on!
[22:04] <mathiaz> slangasek: however /etc/mysql/my.cnf is a conffile
[22:05] <mathiaz> slangasek: and the debian policy states that maintainer scripts should not modify conffiles
[22:05] <slangasek> mathiaz: update-manager shouldn't do it either; if you're going to violate policy, best to do it local to the problem ;)
[22:06] <jibel> mvo_, thanks for merging !
[22:06] <mathiaz> slangasek: ok - there is an item about skip-bdb in the NEWS file
[22:06] <mathiaz> slangasek: however users don't seem to read it :/
[22:07] <mathiaz> slangasek: which causes a lot of package upgrade to fail
[22:07] <chrisccoulson> slangasek / seb128 - sorry, just got back from dinner
[22:07] <slangasek> mathiaz: so what policy really says is "local changes must be preserved during upgrade", and "if you're managing a configuration file in the maintainer scripts, it must not be a conffile".  This appears to be a case where an option which is not present in either the old or new version of the default conffile is no longer supported, correct?
[22:08] <chrisccoulson> did you figure out the issue? (i've not read all the scrollback yet)
[22:08] <slangasek> mathiaz: I think it's reasonable for the maintainer script to remove the unsupported option on upgrade (in the preinst), making a backup copy of the file, and (optionally) throw a debconf note that this has been done
[22:09]  * ScottK notes debconf is for questions, not notes.
[22:09] <slangasek> debconf isn't appropriate for *unconditional* notes; for conditional ones, I think it's suitable, more suitable than anything else
[22:10] <mathiaz> slangasek: well - skip-bdb is in the default hardy my.cnf file
[22:10] <mathiaz> slangasek: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/hardy/mysql-dfsg-5.0/hardy/annotate/head%3A/debian/additions/my.cnf
[22:10] <mathiaz> slangasek: so on upgrade from hardy to lucid, the skip-bdb option needs to be removed/commented
[22:10] <soren> ScottK: Well, the debconf protocol has a "note" type.
[22:11] <slangasek> soren: the "note" type is deprecated
[22:11] <slangasek> (however, "error" is not)
[22:11] <soren> slangasek: Where does it say that?
[22:11] <soren> slangasek: I'm not questioning it, I'm just wondering where I could have found out on my own.
[22:11] <ScottK> Since it affects the default config file, it will affect ~everyone.
[22:12] <slangasek> soren: in the words of Joey Hess on debian-devel a number of years ago; if it doesn't say this in the manpage, that's a bug
[22:12] <soren> slangasek: It doesn't.
[22:12] <cjwatson> it sort of half does
[22:12] <soren> slangasek: (in debconf-devel(7) at least)
[22:12] <cjwatson> "It's best to use these only for warning about very serious problems, and the error datatype is often more suitable."
[22:12] <soren> cjwatson: Fair point.
[22:12] <cjwatson> I think there do exist situations where "note" is appropriate, but they're rare
[22:13] <slangasek> mathiaz: so this affects only users that 1) have modified the conffile, and 2) choose "keep my version"?  is that a common case?
[22:13] <soren> It's the default, isn't it?
[22:13] <soren> 2) in the case of 1), I mean.
[22:14] <slangasek> the default is that the conffile hasn't been modified
[22:14] <mathiaz> slangasek: hm - good point. I don't think so
[22:14] <soren> slangasek: Assuming it's been modified.
[22:14] <mathiaz> slangasek: most of the reports/comments I saw were desktop users installing mysql
[22:14] <slangasek> mathiaz: interesting - why would a desktop user edit this file? :)
[22:15] <soren> Boredom?
[22:15] <ScottK> Inquisitiveness in beyond their experience base?
[22:16] <slangasek> mathiaz: so I think the best way out is mysql-common to have a preinst that checks whether /etc/mysql/my.cnf has been modified (there are copy-waste maintainer script snippets for this, I ca dig one up if you need it); if so, look for skip-bdb; if found, make a backup and sed it out of the file and (if you decide to) send a debconf error message about the change
[22:16] <highvoltage> sheesh, I missed almost all of #ubuntu-devel today!
[22:16] <mathiaz> slangasek: ok - I'll think about it
[22:17] <soren> ScottK: Tomato, tomato?
[22:17] <ScottK> Something like that
[22:18] <slangasek> mathiaz: in the unmodified conffile case, dpkg will already handle the update smoothly.  in the modified conffile case, the user is going to get a conffile prompt no matter what we do.  so in both cases, we're free of skip-bdb, without inconveniencing users with the dreaded "what do you mean, 'local version'?  I don't know what that file is!" exerience
[22:18] <slangasek> +p
[22:23] <mathiaz> slangasek: do you have an example package that checks whether a conffile has been modified?
[22:24] <slangasek> mathiaz: acpi-support preinst
[22:29] <mvo_> jibel: I'm playing with the ~jibel/synaptic/jibel branch but when I search for "apt" I get it rankend relatively low (its not on the first page. the current ubuntu version ranks it higher (also still not on top)
[22:37] <jibel> mvo_, hm, I'll check that tomorrow.
[22:37] <mvo_> jibel: cool, thanks.
[22:39] <zyga> intel gfx drivers crashed/froze my system just now, apport didn't pick it up, is there anything I can look for to trace this?
[23:01] <lex79> doko__: is there a way to testbuild a package on ia64? in local, maybe with pbuilder? or is there any ppa where I can upload a package to see if build?
[23:07] <lifeless> james_w: I think its recovered now; it was in a vm - a littly tricky to get to manually
[23:50] <bdrung_> kirkland: ping