[12:34] <LaserJock> hi minghua 
[12:34] <pygi> LaserJock, !!
[12:35] <minghua> hello LaserJock
[12:35] <LaserJock> hi pygi 
[12:49] <etank> pygi: i came up with a question for you if you have a few moments.
[12:49] <pygi> etank, oki, pm
[12:49] <etank> sure
[12:49] <pygi> if I know, I can answer ^_^
[12:57] <pygi> LaserJock, did we backport deboostrap from gutsy to feisty-backports?
[12:57] <LaserJock> I think it actually goes into -updates
[12:58] <pygi> LaserJock, understood, thanks
[02:46] <ubunt1> hi
[02:46] <ubunt1> how can i program.
[02:46] <ubunt1> c++
[03:01] <ripl> where is hobbsee?
[03:54] <Hobbsee> morning all
[04:15] <racarr> Hello Hobbsee 
[04:15] <Hobbsee> hi racarr :)
[04:15] <racarr> How are you?
[04:16] <Hobbsee> meh.
[04:16] <Hobbsee> reading backscroll and such, thinking about actually going to uni today
[04:19] <racarr> That might be a good idea.
[04:20] <Hobbsee> yeah, maybe.
[04:20] <racarr> In other news, I made nautilus crackful! http://www.rpi.edu/~carrr/woo.png
[04:20] <racarr> (different wallpapers)
[04:21] <Hobbsee> heh, nice :)
[04:30] <nixternal> Mithrandir: GPL copyright holder seems to be using a pseudonym for his name, is this legal, or acceptable for a package that I want to get into Debian and Ubuntu? I am currently working on one now that is like that. thanks!
[04:32] <Hobbsee> nixternal: he'll be asleep, FYI
[04:32] <nixternal> ya, I kind of figured that...to bad I didn't have his phone number ;p
[04:32] <Hobbsee> LaserJock!
[04:32] <Hobbsee> nixternal: it'd still require actually claling the correct number, evenif you had it
[04:33] <nixternal> any other archive admins awake or around?
[04:33] <Hobbsee> unlikely
[04:33] <Hobbsee> it's au day
[04:33] <nixternal> hrmm, seems like pitti said g'nite 8 hours ago...about time he woke up :)
[04:34] <Hobbsee> it was a weekend 8 hours ago in most countries, still
[04:34] <nixternal> yes, but he needs to wake up and help me...I mean go to work ;p
[04:38] <Hobbsee> hehe
[06:24] <fabbione> morning guys
[06:25] <Hobbsee> hi fabbione!
[06:25] <fabbione> yo
[06:25] <Burgundavia> hey jsgotangco
[06:26] <jsgotangco> hi!
[06:26] <Hobbsee> hi Burgundavia 
[07:21] <pitti> Good morning
[07:23] <Burgundavia> hey pitti
[07:26] <Hobbsee> hi pitti!
[07:27] <LaserJock> hi pitti and Hobbsee 
[07:27] <Hobbsee> hiya LaserJock :)
[08:45] <siretart> morning folks
[08:45] <pitti> hi siretart 
[08:45] <siretart> Mithrandir: can you please give back xine-lib on all archs? (again, this time it should work, since I fixed ffmpeg, again)
[08:45] <siretart> hey pitti
[08:47] <Hobbsee> hi siretart 
[08:49] <siretart> :)
[09:07] <Mithrandir> siretart: given-back
[09:19] <pitti> Riddell, LongPointyStick: Any idea about digikaminageplugins? It's uninstallable, but ISTR someone mentioning that it is obsolete?
[09:28] <Adri2000> Mithrandir: should I ask you to review an upload for feisty-backports? or should I just find a core-dev to upload it? (because I believe I can't upload to -backports as a motu)
[09:29] <Mithrandir> Adri2000: is there a reason it can't be done through the normal backports process?
[09:31] <StevenK> Wah. Why does next doors band have to practice when I'm crabby, tired and have a headache?
[09:31] <Adri2000> Mithrandir: yes, it requires a newer version of libgnutls than the one available in the feisty archive. the patch which fixes that is known to work because it is also used in the current package in feisty
[09:31] <StevenK> A street-wide power outage appeals, but that doesn't fix the drum kit.
[09:32] <Mithrandir> Adri2000: hm, ok.  You don't need pre-approval from archive to upload to backports, but you should have coordinated with the backports team.  As long as that's done, please feel free to find a core-dev sponsor
[09:33] <Adri2000> ok
[09:33] <mpt> hi StevenK 
[09:36] <cjwatson> pygi: yes, we did backport it. use 'rmadison -u ubuntu debootstrap' on gutsy to see
[09:36] <pygi> cjwatson, thanks
[09:36] <mpt> StevenK, did you ever get about-window packaged?
[09:37] <cjwatson> it goes into -backports
[09:37] <Lure> pitti: digikamimageplugins is included in digikam now, I have opened bug to remove it from archive
[09:37] <pygi> cjwatson, thought so. thanks :)
[09:37] <Lure> pitti: ubuntu-archive is subscribed to bug
[09:37] <pitti> Lure: ah, then I'll look at those right now; thanks
[09:39] <pitti> it's gone
[09:40] <pitti> doko_: any idea about the uninstallability of libgcj7-awt?
[09:41] <pitti> doko_: it depends on an old version of gcj-4.1-base
[09:41] <pitti> oh, it's NBS
[09:42] <pitti> doko_: so, it seems we need to rebuild openoffice.org to have openoffice.org-officebean drop its libgcj7-awt dependency, then we can remove it
[09:43] <pitti> right now, -officebean is uninstallable
[09:46] <StevenK> mpt: Somewhat.
[09:53] <dholbach> good morning
[09:54] <pygi> morning dholbach 
[09:54] <dholbach> hi pygi
[10:02] <mvo> good morning dholbach!
[10:03] <highvoltage> hello dholbach, pygi and mvo 
[10:03] <pygi> hey highvoltage :)
[10:04] <dholbach> hey mvo
[10:04] <dholbach> hey highvoltage
[10:04] <mvo> hey highvoltage
[10:05] <doko_> pitti: correct, but the openoffice.org-officebean should be in universe anyway
[10:05] <doko_> will have to update the OOo build today
[10:06] <pitti> oh, ok, I can demote it
[10:06] <pitti> doko_: it's not in anastacia, thus likely seeded
[10:06] <pitti> doko_: shall I unseed it?
[10:07] <pitti> doko_: it's currently in the 'development' section
[10:09] <doko_> hmm, not now, let's see how this works with openJDK. put on my "things to remember for gutsy"
[10:11] <StevenK> doko_: For a main merge, are -java-gcj packages still required?
[10:16] <pitti> doko_: ok; FYI, I removed libgcj-awt since it is uninstallable anyway
[10:16] <lool> doko_: Happy birthday!
[10:18] <pitti> argh, vmware kernel mod doesn't build for 2.6.22; so back to 2.6.20, brb
[10:23] <cjwatson> 15:22 <BenC> s/h/mac_header/
[10:23] <cjwatson> 15:22 <BenC> s/nh/network_header/
[10:23] <cjwatson> pitti: ^-- advice on fixing vmmon/userif.c
[10:23] <cjwatson> er, vmnet
[10:23] <pitti> oh, sweet, thanks
[10:27] <fabbione> nah wait
[10:27] <fabbione> it's not enough
[10:27] <doko_> StevenK: yes, they speed up interpreted code quiet a lot
[10:27] <doko_> lool: thanks :)
[10:27] <fabbione> pitti: chinstrap:~bcollins/vmnet.tar
[10:27] <fabbione> doko: hey old man
[10:27] <StevenK> doko: Many happy returns!
[10:28] <pitti> that's even better, thanks fabbione 
[10:34] <mvo> doko: happy birthday from me too
[10:34] <pygi> oh, birthday!
[10:34] <pygi> doko, happy birthday ^_^
[11:05] <Riddell> pitti: yes, it is obsolete, Lure will tell you if it can just be deleted now
[11:05] <pitti> Riddell: thanks; I killed it already
[11:05] <Riddell> cool
[11:07] <glatzor> mpt: Hello, have you already found the time to look at the user interface of displayconfig?
[11:12] <mpt> glatzor, yes, sorry I haven't replied yet
[11:12] <mpt> I had a couple of questions
[11:13] <mpt> * Is this intended to replace gnome-display-properties?
[11:13] <mpt> (and if not, why not?)
[11:13] <cjwatson> mpt: the spec discusses that
[11:13] <glatzor> mpt: I would like to. Mdz would like to have it as an advanced button.
[11:13] <cjwatson> displayconfig-gtk
[11:13] <mpt> oh, there's a spec?
[11:14] <cjwatson> yeah, a gutsy target
[11:14] <glatzor> mpt: http://wiki.ubuntu.com/DisplayConfigGTK
[11:15] <mpt> ah
[11:15] <mpt> I did skim that page, but I was looking for the screenshots so I didn't even notice it was a spec :-/
[11:16] <pitti> doko: FYI, I fix libbcel-java-doc not to depend on libxerces2-java-doc, since the latter does not exist; ok with you? 
[11:17] <glatzor> mpt: I came up with a redesign here recently: https://lists.ubuntu.com/archives/ubuntu-desktop/2007-May/001057.html
[11:18] <pitti> doko: alternatively I can move libbcel-java-doc to multiverse, so that it becomes installable; what do you prefer?
[11:18] <mpt> glatzor, I think we can handle the cases of one screen, two screens, and three screens all in the same window without it getting complicated
[11:18] <mpt> and that would be far preferable to having three different UIs for those three cases
[11:19] <mpt> glatzor, what happens in the window when you plug in an extra monitor? Does it appear in the list automatically?
[11:19] <doko> pitti: hmm, maybe make it a recommends instead of a depends
[11:20] <pitti> doko: right, I dropped it to Suggests:
[11:20] <mpt> oh, nm, I should just read the spec first
[11:20] <glatzor> mpt: that is not supported on all cards (hardware side) furthermore it is also not supported by X
[11:21] <Mithrandir> glatzor: (yet)
[11:21] <Mithrandir> it will be soonish
[11:21] <glatzor> Mithrandir: Do you know when there will be a dbus interface roughly?
[11:22] <Mithrandir> glatzor: I think X hotplug is 7.3 material, but it might be later.
[11:23] <mpt> glatzor, so how are you supposed to set it up? Is there supposed to be a "Detect" button somewhere? Or do you need to restart the computer?
[11:23] <glatzor> Mithrandir: I thought you were talking about emitting a device change signal.
[11:23] <Mithrandir> glatzor: *shrug*; that's utterly trivial once all the other bits are in place.
[11:25] <glatzor> mpt: We still use the xorg.conf for the configuration. So you have to restart your X server. I already send a signal to gdm to do this if you made any corresponding changes. So logging off should be sufficient.
[11:25] <mpt> Ok, there needs to be a sentence to that effect in this window
[11:26] <mpt> Otherwise people will stand there staring at it waiting while nothing happens
[11:26] <glatzor> mpt: you get a dialog depending on the changes.
[11:26] <glatzor> mpt: we can apply some changes instantly using xrandr
[11:26] <mpt> I'm not talking about having changed settings, I'm talking about plugging in another display
[11:27] <glatzor> mpt: Oh, the available screens are tried to guess from the hardware.
[11:27] <tepsipakki> x server 1.3 supports output hotplug (=randr 1.2), it's just that only the intel driver supports that properly
[11:27] <glatzor> mpt: If there is no screen attached to the output we just show it as disabled.
[11:27] <mpt> glatzor, what do you mean by "the output"?
[11:28] <glatzor> mpt: the output jacket of your graphics card.
[11:28] <pitti> Riddell: can you please unseed strigi from the Kubuntu seeds as long as it (and the plethora of build deps and deps) are still in universe? 
[11:28] <pitti> Riddell: I can do it as well if you give me your ok
[11:28] <Riddell> pitti: why?  I hope to get it into main soon and the seeds should reflect what is wanted 
[11:29] <pitti> Riddell: it generates a lot of clutter in anastacia, but I can try to ignore it
[11:29] <glatzor> mpt: For example ATI cards with dual head support are detected by their pci string: it contains the term "Secondary"
[11:29] <pitti> but in general, things should be seeded when they have MIRs
[11:30] <mpt> glatzor, does that mean that because I might one day plug a USB monitor into one of my USB ports, this window needs to contain one disabled item for each of my USB ports?
[11:31] <tepsipakki> usb monitor?
[11:31] <glatzor> mpt: if there are any USB monitors: yes.
[11:31] <glatzor> mpt: but luckily that is not the case
[11:31] <mvo> tepsipakki: do you know is xrandr will send a XRRNotifyEvent if a additional monitor is pluged in?
[11:32] <glatzor> mpt: We are just limited by the available technologies
[11:32] <Mithrandir> mpt: I'd argue no, since USB is a general interface while your display connectors are hardly useful for anything but plugging in monitors.
[11:32] <Mithrandir> iwj: any chance I could grab a bit of your time today to get some bits of dpkg svn merged into our package?
[11:32] <mpt> I was confused by http://computing.kelkoo.co.uk/b/a/cp_114401_filter_interface_usb.html
[11:32] <mpt> It looks like it's selling USB monitors, but apparently not
[11:33] <cjwatson> woo, usplash console font handling fixed
[11:33] <cjwatson> there goes a big load of bugs
[11:33] <tepsipakki> mvo: no idea..
[11:33] <Keybuk> cjwatson: oh aye?
[11:33] <persia> mpt: There are USB video interfaces (I have one), but not yet monitors.
[11:34] <tepsipakki> mpt: ah, they could have usb hubs in the m :)
[11:34] <mpt> yeah
[11:34] <tepsipakki> -" "
[11:34] <mpt> heh
[11:34] <Mithrandir> mpt: however, if you have a USB video interface with no connected monitor, showing it as disabled is fine.  IMO, at least.
[11:34] <iwj> Mithrandir: Sure.  I haven't looked at the svn changes in detail.  Did you have any particular things in mind \/
[11:34] <cjwatson> Keybuk: if you switch to graphics mode and back, the kernel doesn't save the previous console font for you - so the console-setup initramfs business to set the font early wasn't working
[11:34] <iwj> s,\\/,?
[11:35] <Keybuk> cjwatson: ahh
[11:35] <cjwatson> Keybuk: fix is to get usplash to save the console font before switching to KD_GRAPHICS, and restore it after switching back to KD_TEXT
[11:35] <cjwatson> bug 91422 and friends
[11:35] <ubotu> Launchpad bug 91422 in console-setup "FEISTY: ctrl alt f1 terminal doesn't work with special characters (, ..)" [Undecided,Needs info]  https://launchpad.net/bugs/91422
[11:35] <Mithrandir> iwj: the changes needed for lpia are in svn; I'm not sure of the exact set of commits we want to merge, but I could find it for you
[11:36] <mpt> glatzor, is the "primary screen" the one on which the panels appear?
[11:36] <iwj> Mithrandir: If you know what you're looking for then yes, sure.  If you point me at it I'd be happy to merge it in.  (It might be trivial.)
[11:37] <glatzor> mpt: I would recommend to look at this screenshot: http://glatzor.de/filesink/allinone.png
[11:37] <iwj> Or alternative I'm happy to do the digging.
[11:37] <iwj> s/ive/&ly
[11:37] <glatzor> mpt: this is what I am planing to upload soon.
[11:37] <glatzor> mpt: yes. the primary screen is the default/main screen
[11:38] <Mithrandir> iwj: if you'd like, please.  It should be mostly limited to dpkg-architecture and is a week-ish old.
[11:38] <Mithrandir> iwj: anything mentioning "lpia" is interesting
[11:39] <glatzor> mpt: the displayconfig can already handle unplugged primary screens by showing a move displayconfig dialog to this screen buttons on every screen.
[11:39] <iwj> Mithrandir: OK, I'll take a look.  Do you have a cutoff date before which it definitely won't be there ?
[11:41] <mpt> glatzor, that would be no use if you couldn't launch it in the first place :-)
[11:42] <Mithrandir> iwj: anything older than May 15th should be uninteresting.
[11:42] <Mithrandir> that should leave you with 30-odd commits to go through, I think
[11:43] <glatzor> mpt: Displayconfig will also be used in the failed x session
[11:43] <iwj> Mithrandir: Thanks, that should be NP.
[11:43] <glatzor> mpt: furthermore you have to relay on the Window manager to not open the dialog window on the correct screen.
[11:44] <glatzor> mpt: to not open the dialog on the wrong screen
[11:48] <StevenK> iwj: If you're going to do an dpkg upload, I've noticed update-alternatives throwing a Perl warning. I just can't recall more details at this point.
[11:49] <iwj> StevenK: I'll check my diff.  I might have missed a `my'.
[11:49] <iwj> (The merge from Debian included turning warnings on.)
[11:50] <Mithrandir> there's a slew of commits in Debian which fixes warnings too
[11:50] <iwj> (And a concomitant coding style change.)
[11:50] <iwj> Maybe we should just merge from the SVN head.
[11:50] <iwj> I'll see what it looks like and decide.
[11:51] <Mithrandir> I wouldn't mind
[11:51] <mpt> glatzor, if you could rely on the window manager to do that, then half this problem would go away: you wouldn't need a list of displays, because each display could have its own settings window.
[11:52] <glatzor> mpt: that is definitely a cool idea.
[11:52] <mpt> Can you rely on Metacity to get it right, at least?
[11:53] <glatzor> mpt: oh, but how to enable screens?
[11:53] <glatzor> mpt: could be a little bit tricky :)
[11:53] <glatzor> mpt: not with metacity, but on a lower level.
[11:56] <mpt> glatzor, ah, so that's where the auto-detection is required, hmm
[11:57] <mpt> glatzor, what do you mean by "on a lower level"?
[11:57] <glatzor> mpt: and that is also where you depend on the hardware again. there is no guarantee that the output on the screen is actually visible for a human.
[11:58] <glatzor> mpt: we cannot detect jammed outputs from the software side.
[11:58] <mpt> "jammed"?
[11:58] <mdz> tepsipakki: yay, no more xlibs-dev
[11:59] <glatzor> mpt: with not working/broken configurations.
[11:59] <mpt> oh
[11:59] <mpt> Supporting a limited subset of displays, perhaps
[11:59] <pitti> carlos: ^ thank you
[12:00] <carlos> pitti: :-)
[12:00] <carlos> cool
[12:00] <StevenK> pitti: Yay!
[12:01] <iwj> #
[12:01] <iwj> Oops.
[12:01] <pitti> "Parlez vous francais" anyone?
[12:02] <pitti> Riddell: could you please test the brand new gutsy langpacks for KDE? (French and English)
[12:02] <ssam> mpt, you can plug almost any display/projector into mac os x, and it will automagically enable it (though there is a button to tell it to redetect monitors)
[12:02] <glatzor> mpt: You cannot prevent that the user chooses the wrong CRT, since many monitors identify themselves incorrectly. So you have to allow enforcing a configuration.
[12:03] <mvo> pitti: app-install-data-ubuntu is uploaded, I have a small fix for g-a-i as well, do you want it too? or should I wait until the freeze is over?
[12:04] <mpt> ssam, right, I wasn't wondering about the detection (any more), I was wondering how OS X doesn't have the problem with (as glatzor says) choosing the wrong CRT
[12:05] <pitti> mvo: freeze hasn't even begun yet, so feel free
[12:05] <mvo> pitti: heh :) ok, looks like I haven't catched up yet :)
[12:06] <StevenK> Oh, that's right. I ought to get Tribe 1 for my birthday.
[12:06] <Mithrandir> I think we should delay it by a day so I'll get it for mine
[12:06] <mvo> Riddell: the new kde-guidance b-depens on python-kde3 3.17.2-1ubuntu2, but that does not appear to be in the archive yet? 
[12:07] <StevenK> Mithrandir: I think I get it for mine due to timezones.
[12:07] <StevenK> Mithrandir: But it seems we share a birthday.
[12:07] <Mithrandir> StevenK: yes, we do
[12:07] <Riddell> mvo: yeah, getting to it now
[12:08] <StevenK> Yay me for forgetting that.
[12:08] <mvo> Riddell: cool, thanks (no pressure, I was just wondering if it was intentional or not)
[12:08] <dholbach> pitti: did you find somebody speaking french already?
[12:08] <dholbach> mvo: enjoy
[12:08] <glatzor> Riddell: I cleaned up the patches folder in the displayconfig bzr repository. The pathces now have got better names and there is a STATUS file to keep track of merges
[12:09] <pitti> dholbach: nope; any popular language will do, it's just testing the new gutsy langpacks a bit before uploading
[12:09] <pitti> dholbach: German looks good here for Gnome
[12:09] <Riddell> glatzor: ok , cool.  I havn't heard from sime for a while so not sure what the best way is to just merge those upstream
[12:10] <dholbach> pitti: ah ok
[12:10] <Riddell> glatzor: probably keep pinging him and just merge them if he doesn't show up
[12:10] <Riddell> pitti: sure
[12:10] <pitti> dholbach: I'll just test Russian myself, I think, that will be fine; if a KDE guy tests some KDE packages, that should suffice
[12:10] <pitti> Riddell: merci :)
[12:26] <pitti> Riddell: Russian, German, and English looks good for Gnome; let's hope the best for KDE, too :)
[12:44] <pitti> carlos: ah, I had a look
[12:44] <pitti> carlos: so, e. g. gnome-panel-2.0.mo is in language-pack-gnome-de-base_6.06+20070129_all.deb
[12:45] <pitti> carlos: and also in the later update
[12:45] <pitti> carlos: s/the/a/
[12:46] <pitti> carlos: so the latest language-pack-gnome-de replaced the files in -base, and now they are gone from installations
[12:47] <pitti> carlos: that at least explains why there is no gnome-panel-2.0.mo *at all* on an updated dapper
[12:47] <pitti> carlos: I'm not sure whether the presence of the mo is due to me not cleaning up the source packages on import (for various reasons), or due to Rosetta dropping the .po files at some point in the updates tarball
[12:51] <mpt> glatzor, replied to your original message
[12:52] <carlos> pitti: I'm working on the DB to see whether we removed them because the files don't have any update since our last base package update (Last January)
[12:52] <carlos> pitti: in which case it means is correct
[12:53] <pitti> carlos: DB-wise it would be correct, yeah, then I need to always build the packages against their previous version instead of from scratch
[12:55] <pitti> carlos: so AFAICS this should only affect dapper, since for edgy we didn't do a base upgrade
[01:00] <glatzor> mpt: I am writing on my reply
[01:00] <glatzor> mpt: macos shows the config dialog on each display?
[01:01] <glatzor> mpt: So it cannot providing cloning/duplicating of screens?
[01:02] <tepsipakki> mdz: yep, about time to get rid of it :)
[01:02] <glatzor> mpt: ah, there is a mirror checkbutton. but how does this work on more than two monitors?
[01:04] <carlos> pitti: sorry, I don't get you. Aren't we already doing that?
[01:04] <pitti> carlos: IOW, I cannot just build dapper langpacks from your tarball, but update the existing ones with your tarball
[01:04] <pitti> carlos: it's pretty clear to me now
[01:05] <carlos> pitti: I have two kind of language packs
[01:05] <carlos> a full one
[01:05] <carlos> and updates based on that one
[01:06] <carlos> dapper is doing update based on latest full export for Dapper which was on 2007-01-15
[01:06] <pitti> carlos: right; somehow e. g. gnome-panel-2.0.po landed in an update pack after the base refreshment
[01:06] <carlos> s/dapper is doing/launchpad is doing for dapper/
[01:06] <pitti> and due to that I *always* have to ship gnome-panel-2.0 in the update packs
[01:06] <carlos> that was what we tried to solve with January update
[01:07] <carlos> pitti: don't you remember that?
[01:07] <pitti> carlos: of course I do
[01:07] <carlos> we did a full base update to restore some removed packages that were being exported by mistake from Launchpad
[01:07] <pitti> but somehow the affected .po files still landed in the update packages afterwards
[01:07] <carlos> pitti: then, does it mean it happen again?
[01:08] <carlos> once we fixed it, if it lands to the packages, it means they should remain there...
[01:08] <carlos> or we have a bug...
[01:09] <pitti> I'm not sure when and where that originated, and I guess we don't have those old update tarballs any more
[01:09] <pitti> carlos: anyway, I'll build the new ones based on the current ones to ensure that files will not get lost
[01:09] <mpt> glatzor, with OS X mirroring multiple screens is not obvious
[01:09] <mpt> you Option+drag one display onto another in the Arrange tab
[01:10] <carlos> pitti: my question is
[01:10] <mpt> The Arrange tab appears only on the primary display, not any of the others.
[01:10] <carlos> would that produce that we have some Dapper users that lost .mo files like we had before January's update?
[01:11] <mpt> glatzor, more details and screenshots at http://www.macinstruct.com/node/78
[01:11] <pitti> carlos: if I built update packages just from your tarball now, yes, it would
[01:14] <carlos> pitti: hmm, are you completely sure you didn't add those .mo files manually?
[01:14] <carlos> pitti: you said you did it in the past
[01:14] <carlos> and I wonder whether would be possible that we disabled it too late
[01:15] <pitti> carlos: that's what I said; I nuked the existing update packages after the base refreshment of course
[01:15] <pitti> carlos: but at some point they crawled into the daily update packages again
[01:15] <carlos> ok
[01:15] <pitti> so I'd think that *at some point* they have been part of the updated tarballs from you
[01:15] <pitti> but I cannot say when
[01:15] <pitti> (at some point after the base refreshment)
[01:16] <carlos> pitti: are you able to provide me with a list of missing files?
[01:16] <glatzor> mpt: by the way the new XRandR hotplug thing does not support multiple graphics cards.
[01:16] <pitti> carlos: I think I could do that if you need them, yes
[01:16] <pitti> carlos: I'll build good ones over lunch and then debdiff them
[01:16] <carlos> pitti: well, that's the only way I could 'force' to get those files exported again
[01:17] <carlos> pitti: either that or do another base update...
[01:17] <carlos> although I would like to see why did we get this regression
[01:17] <carlos> s/see/know/
[01:17] <pitti> carlos: I don't think we actually need to do that, but let's keep the list for the future anyway
[01:17] <glatzor> mpt: what does the "gather windows" button?
[01:18] <carlos> pitti: well, if we don't export missing files, people using Dapper will see again some applications in English
[01:18] <pitti> carlos: no, because I will build them using the existing packages in -updates
[01:19] <carlos> oh
[01:19] <glatzor> mpt: and how do you disable a monitor again on MacOS?
[01:20] <carlos> so you get previous source in Dapper and will add the ones provided by Launchpad?
[01:20] <pitti> carlos: right
[01:20] <carlos> I see
[01:20] <carlos> ok
[01:20] <pitti> carlos: that's how I build them normally
[01:20] <pitti> carlos: because it easily allows me to avoid updating packages which did not change at all
[01:20] <mpt> glatzor, you turn it off, I guess.
[01:20] <pitti> I just nuked them today to clean up rookery, but I restored them
[01:21] <pitti> carlos: at some point I either need to rewrite langpack-o-matic from scratch, or we can build the source packages straight from Rosetta...
[01:21] <carlos> pitti: good trick
[01:21] <carlos> pitti: I would like to build packages from Rosetta directlyu
[01:21] <carlos> but we are not yet there
[01:21] <mpt> glatzor, "Gather Windows" moves all windows that are on other displays onto the display in which you click the button.
[01:22] <mpt> So if a display stops working for whatever reason you can get the windows back.
[01:22] <mpt> oh wait, cancel that
[01:22] <mpt> aha
[01:23] <mpt> It moves only the display settings windows from the secondary displays onto the primary display.
[01:23] <mpt> actually, no (I'll get this right eventually)
[01:23] <glatzor> mpt: the other way would make more sense.
[01:23] <mpt> It moves the display settings windows from the other displays onto the display where you click the button.
[01:23] <glatzor> that makes sense.
[01:24] <glatzor> mpt: it is a funny idea to put the dialogs on the devices.
[01:24] <mpt> indeed
[01:24] <glatzor> mpt: but how does this work with cloned monitors?
[01:24] <mpt> It's called "direct manipulation" ;-)
[01:25] <mpt> glatzor, I don't know. If I had to guess, I'd guess that the display is cloned *except for* the display settings windows.
[01:25] <glatzor> mpt: I think that this could actually be done using XRandR.
[01:26] <mpt> cool
[01:26] <glatzor> AFAIK It allows to clone only a part of the screen. But I don't know if it allows to exlcude a part :)
[01:27] <mpt> Yeah, "clone everything except this window"
[01:27] <mpt> That's what Linux people call ... violation of ... something
[01:27] <mpt> "rampant layering violation"
[01:29] <glatzor> but it is really strange that there is no disable screen button
[01:31] <glatzor> mpt: "If you move icons from your main monitor to your secondary and then disconnect the secondary monitor, those icons may disappear. They will still be there when you have one monitor connected, but the way to get them back would be to highlight everything and then select "Clean Up Selection" from the View menu in the Finder, or select an "Arrange By..." also in the View menu in the Finder."
[01:31] <glatzor> mpt: so they cannot handle disabled devices at all :)
[01:31] <mpt> That can't be true, because then you'd lose entire windows
[01:31] <mpt> hmmmm
[01:34] <mpt> I agree that rearranging icons when you lose a display sucks
[01:34] <glatzor> mpt: Apple does not always to the things in the right way too :)
[01:35] <glatzor> mpt: on GNOME the situation is even wore since the desktop is always oriented to the upper left.
[01:36] <mpt> glatzor, I know, sometimes Apple does things very badly
[01:36] <glatzor> mpt: so if you have got a screen left of your main screen, the icons would show up there
[01:36] <mpt> oh, that's not good
[01:36] <mpt> Nautilus bug?
[01:36] <glatzor> mpt: I don't know.
[01:36] <glatzor> mpt: perhaps intended.
[01:37] <glatzor> mpt: by the way I replied on the list.
[01:37] <mpt> Ah, I knew I'd read about this before: "Disconnect the external display, and the right thing will happen, where by 'right thing' I mean that any windows which were open on the no-longer-available display will be moved to the internal display, and resized, if necessary, to fit."
[01:38] <mpt> So it moves+resizes the windows automatically, just not the icons
[01:38] <glatzor> that is cool.
[01:38] <glatzor> oh I haven't tested this with XRandR yet.
[02:10] <pygi> pitti, around by any chance?
[02:18] <pitti> pygi: just back from lunch
[02:18] <pygi> oh, oki :)
[02:18] <pygi> wanted to bug about sponsoring, but it seems pochu created the same package, and somebody is already sponsoring for him
[02:19] <hunger> Just got this error upgrading: /var/lib/dpkg/info/xserver-xorg.postinst: 2197: Syntax error: "then" unexpected (expecting "fi")
[02:19] <pitti> tepsipakki: ^
[02:20] <StevenK> Twitch. Line 2197?
[02:20] <asac> pitti: welcome back ... dapper build done?
[02:22] <pitti> asac: yep
[02:22] <asac> pitti: cool ... everything prepared for the diff.gz only arrival on edgy/feisty?
[02:22] <pitti> asac: so, let me pre-publish this
[02:22] <asac> pitti: sure ... let me know
[02:22] <pitti> asac: hold on
[02:23] <pygi> mvo, awake?
[02:24] <mvo> pygi: hello, yes
[02:25] <gnomefreak> hunger: it should be fine i dont think you will lose X even on restarting X
[02:25] <pitti> asac: ready
[02:26] <asac> pitti: k
[02:26] <hunger> gnomefreak: I am not planing to do that;-)
[02:27] <gnomefreak> hunger: i dont think it will hurt anything since your old versions are still installed ill try it in a bit ;)
[02:30] <BenC> pitti: chinstrap:~bcollins/vmnet.tar can be dropped in place too
[02:31] <pitti> BenC: great, thanks!
[02:31] <BenC> pitti: that's for ws6
[02:32] <pitti> BenC: btw, does linux-backport-modules still make sense, or is that merged into linux-ubuntu-modules?
[02:32] <pitti> BenC: ah, I see; I still have 5.5 (no license for 6)
[02:32] <BenC> pitti: it does, but I haven't updated it for 2.6.22 yet
[02:32] <BenC> pitti: go ahead and grab ws6 with temp key, and I'll get you a perm one
[02:32] <pitti> BenC: ok; the metapackages are currently uninstallable, that's why I wondered
[02:33] <BenC> pitti: doh, right, guess I should get that uploaded today
[02:34] <pitti> BenC: I'll shove it through NEW quickly once it arrived
[02:36] <asac> pitti: all uploaded
[02:38] <fabbione> cjwatson: what was the magic to boot an alternate cdrom and do a netinstall? I have a machine that cannot do PXE and the cdreader is.. hmmm flaky :)
[02:41] <pitti> carlos: got it: http://people.ubuntu.com/~pitti/langpacks/dapper-updates-incomplete.txt
[02:41] <pitti> carlos: I have a good set of dapper-proposed packages now
[02:42] <cjwatson> fabbione: you'll need to boot /install/netboot/ubuntu-installer/i386/linux with /install/netboot/ubuntu-installer/i386/initrd.gz as the initrd; isolinux.cfg isn't set up to help you
[02:43] <fabbione> cjwatson: ok thanks.. 
[02:44] <pitti> BenC: hmm, the sparc metapackages are not installable either; any idea why?
[02:45] <cjwatson> pitti: I don't think linux-ubuntu-modules built for sparc
[02:45] <cjwatson> https://launchpad.net/+builds/+build/342882
[02:46] <pitti> cjwatson: ah, that would be it
[02:48] <carlos> pitti: that's a lot of files...
[02:48] <carlos> pitti: thanks, I will take a look once I'm done with lunch
[02:48] <Hobbsee> hi all!
[02:48] <pitti> carlos: as I said, it's not particularly urgent
[02:48] <carlos> pitti: sure, but i would like to know what's going on
[02:53] <BenC> lum didn't build for ia64 or sparc
[02:53] <BenC> missing header, I can reupload that today too
[03:04] <cjwatson> Keybuk: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/118561 - is it possible that when 'modprobe loop' returns, /sys/block/loop* won't be there yet?
[03:04] <ubotu> Launchpad bug 118561 in casper "[Gutsy]  Kubuntu liveCD 20070603 doesn't boot" [Undecided,Unconfirmed]  
[03:04] <cjwatson> the earlier errors make me suspicious as well though
[03:04] <Keybuk> cjwatson: it's both possible and likely
[03:04] <Keybuk> it tends to bite dual-core systems more than single, obviously
[03:04] <Keybuk> they race better
[03:05] <cjwatson> evand: are you using dual-core?
[03:05] <Keybuk> it also could be a sign of a missing udev, of course
[03:05] <Keybuk> given the number of device errors
[03:06] <evand> cjwatson: yeah, core 2 duo
[03:06] <BenC> cjwatson: how many loop devs does livecd use?
[03:07] <Mithrandir> BenC: one, typically.
[03:07] <BenC> I recall a bug early in 2.6.22 where only one loop dev showed up, but I thought it was fixed
[03:07] <cjwatson> BenC: glob expansion's failing, so there aren't any there at all in this case
[03:08] <Arby> cjwatson: anymore info I can supply for that bug (I'm the reporter)?
[03:08] <cjwatson> Arby: from the shell, if you wait for a bit, is /sys/block/loop0 there?
[03:08] <cjwatson> whoa, here
[03:08] <cjwatson> 'modprobe loop' on gutsy leaves no /sys/block/loop*
[03:09] <evand> indeed, I just noticed that as well
[03:09] <BenC> let me find this bug
[03:09] <Arby> not that I've seen, it drops to an initramfs prompt and just sits there.
[03:09] <Keybuk> looking
[03:09] <Keybuk> confirmed
[03:09] <Keybuk> loading the loop module creates no devices
[03:09] <shawarma> What should it leave there? Loading the loop driver just provides the hooks for creating the device nodes.
[03:09] <cjwatson> Arby: I meant if you run ls to check, but it looks like we've confirmed it outside the initramfs
[03:09] <Keybuk> (nothing in sysfs, no uevent --> iz kernel boog)
[03:10] <shawarma> Or should it create some that we bind to stuff afterwards?
[03:10] <Keybuk> shawarma: historically it sets up 8 devices for use
[03:10] <shawarma> Keybuk: Oh, I see.
[03:10] <Arby> cjwatson: ah, OK /sys/block was there, beyond that I don't remember and I don't have the machine here
[03:10] <Arby> (at work)
[03:11] <Arby> this is all a bit beyond my skills to be honest but I do what I can.
[03:11] <Keybuk> hmm
[03:11] <shawarma> modinfo -p:
[03:11] <shawarma> max_loop:obsolete, loop device is created on-demand
[03:11] <Keybuk> max_loop:obsolete, loop device is created on-demand (int)
[03:11] <Keybuk> heh, jinx
[03:11] <shawarma> :)
[03:11] <cjwatson> er, seriously? how do I remand it? :)
[03:11] <cjwatson> demand
[03:11] <Keybuk> cjwatson: losetup
[03:12] <Keybuk> losetup -f does indeed make a /dev/loop0 for me
[03:12] <cjwatson> ouch
[03:13] <BenC> yeah, lkml claims "not a bug" :)
[03:13] <StevenK> Hrrm. How can I get make to report which rule it's jumping into? I'm trying to trace a build failure and want to know where in debian/rules to start shovelling.
[03:14] <Keybuk> BenC: the workflow is not immediately obvious to me
[03:14] <cjwatson> StevenK: make -d?
[03:14] <Keybuk> LOOP=$(losetup -f)
[03:14] <Keybuk> losetup $LOOP ...
[03:14] <Keybuk> ?
[03:15] <cjwatson> unfortunately busybox's losetup doesn't support -f, so this will take a bit of work
[03:15] <Keybuk> hmm, this isn't working now
[03:15] <Keybuk> now it says "could not find any device /dev/loop#"
[03:17] <ompaul> Hobbsee, you can claim anything you want, you just can't substanciate your claims that is all ;-)
[03:17] <BenC> Hobbsee you can't escape my next kernel upload :P
[03:17] <Hobbsee> BenC: oh dear.
[03:18] <Hobbsee> BenC: but my wifi appears to be broken on this one, so...
[03:18] <Hobbsee> it may well be pebkac, i havent found the problem yet
[03:22] <ShinyMonster> must...have...shiny....
[03:22] <carlos> pitti: filed as https://bugs.launchpad.net/rosetta/+bug/118638
[03:22] <ubotu> Launchpad bug 118638 in rosetta "Language pack export lacks some files that were exported before" [Undecided,Unconfirmed]  
[03:23] <pitti> carlos: I'll subscribe, thanks
[03:23] <ogra> StevenK, thanks for taking the fuse merge
[03:23] <StevenK> ogra: No problem. It was ... fun. I have scars. :-)
[03:23] <ogra> heh
[03:26] <dholbach> did anybody experience a xserver-xorg postinst error in the last update?
[03:27] <ShinyMonster> yes
[03:27] <StevenK> I saw that here about an hour ago.
 Just got this error upgrading: /var/lib/dpkg/info/xserver-xorg.postinst: 2197: Syntax error: "then" unexpected (expecting "fi")
 tepsipakki: ^
[03:27] <dholbach> ah ok
[03:27] <dholbach> right
[03:28] <pitti> dholbach: but no answer so far; if you feel like fixing that, go ahead :)
[03:29] <dholbach> right :)
[03:31] <tepsipakki> pitti: gah
[03:36] <siretart> Keybuk: you said last week that you have a mdadm merge in the pipe. do you have an ETA for that? c.f. bug 87745
[03:36] <ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  https://launchpad.net/bugs/87745
[03:37] <Keybuk> siretart: waiting on an LVM/devmapper patch from SuSE to fix known bugs there
[03:37] <Keybuk> err, that bug appears to be entirely unrelated to mdadm, no?
[03:38] <siretart> Keybuk: see https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/87745/comments/5
[03:38] <ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  
[03:38] <Keybuk> siretart: yeah, but since the bug was reported about feisty, that's probably not the problem here <g>
[03:38] <Keybuk> (yes, lvm-on md won't work in gutsy right now)
[03:39] <siretart> well, yes, thats the problem I'm experiencing with my workstation machine at home
[03:39] <Keybuk> so mdadm
[03:39] <Keybuk> the merge is pretty trivial, and won't help
[03:39] <Keybuk> there's a patch from SuSE which is pretty trivial, that lets us have a 65-mdadm.vol_id.rules which will run vol_id on complete md devices
[03:39] <Keybuk> (as apposed to partially assembled ones)
[03:40] <Keybuk> so that solves the "lvm issue"
[03:40] <siretart> well, why not upload that to let folks boot again?
[03:40] <Keybuk> the non-trivial bit is working out what to do about running mdadm on block devices identified as linux raid
[03:40] <siretart> hm
[03:40] <Keybuk> because it wouldn't let them boot
[03:40] <Keybuk> since mdadm would never be run :)
[03:41] <Keybuk> right now, there's mdadm, mdrun, and a complicated initramfs script
[03:41] <siretart> my raid devices are assembled correctly
[03:41] <Keybuk> depending which way the neutrinos come in, you may get one or more in random orders
[03:41] <Keybuk> I'd kinda like to understand this, and just have one that works
[03:41] <siretart> sure
[03:42] <tepsipakki> umm, how to find the "line 2197" from the postinst.. does it count commented/empty lines?
[03:43] <Keybuk> help understanding how to run mdadm would be most welcome
[03:43] <jdub> http://www.microsoft.com/presspass/press/2007/jun07/06-04XandrosPR.mspx
[03:45] <jsgotangco> jdub: ick
[03:45] <sn0> eep @ xandros
[03:45] <jsgotangco> i guess that's why one of the people i know left recently heh
[03:46] <glatzor> mpt: do you want a feisty package of the latest displayconfig?
[03:46] <Keybuk> jsgotangco: they looking for jobs? :)
[03:46] <jsgotangco> i can ask heh
[03:47] <Keybuk> www.ubuntu.com/employment
[03:48] <zul> heh its corel all over again
[03:48] <Keybuk> isn't Xandros what's left of Corel?
[03:48] <zul> yep
[03:49] <jsgotangco> yep ming poon is still pretty much tech lead on it i believe
[03:57] <BenC> So is bug #118561 really being considered a kernel bug, or is it something that d-i/ubiquity needs to handle?
[03:57] <ubotu> Launchpad bug 118561 in casper "[Gutsy]  Kubuntu liveCD 20070603 doesn't boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118561
[03:57] <BenC> this is the loop problem
[04:02] <cjwatson> BenC: I punted it back to casper, sounds like it's our problem
[04:03] <BenC> cjwatson: ok, thanks
[04:03] <cjwatson> working on enhancing busybox's losetup now
[04:03] <cjwatson> this is a bit weird, though, after a 'sudo losetup -f':
[04:03] <cjwatson> $ sudo losetup /dev/loop0
[04:03] <cjwatson> /dev/loop0: [3002e6bc] :268435508 0R) offset 805321200, undefined encryption
[04:03] <cjwatson> loop: can't get info on device /dev/loop0: No such device or address
[04:04] <cjwatson> maybe that's losetup's fault
[04:05] <cjwatson> mm, looks like it should be zeroing loopinfo before it passes it in
[04:05] <tepsipakki> pitti: I found the bug in xorg, it was an elif-line appended to the previous one :/
[04:08] <tepsipakki> hunger: thanks for telling about the xserver-xorg postinst bug, and sorry
[04:09] <cjwatson> BenC: actually, no, I don't get this. 'sudo losetup -f' works once, but after I losetup a file onto that, 'sudo losetup -f' doesn't work again
[04:10] <BenC> cjwatson: that was the bug report, and according to the thread, it's userspace breakage...but I'm not sure yet where that is broken
[04:10] <BenC> could be mount and losetup
[04:11] <cjwatson> all losetup does is walk through /dev/loop* statting them
[04:11] <cjwatson> if the device node isn't there, it won't worrk
[04:13] <cjwatson> looks like you need to mknod the devices yourself now :-/
[04:14] <cjwatson> some discussion in the thread seems to indicate that it's supposed to create one extra device though, so that you don't need to do that
[04:15] <BenC> cjwatson: a work around might be to add "options loop max_loop=8" to get the old behavior
[04:15] <BenC> but that sets a hard max limit on loop devices too
[04:17] <cjwatson> yeah, tolerable on the live CD though
[04:17] <Hobbsee> BenC: you wouldnt happen to know if intel 3945 cards were touched in the last kernel update would you?  I cant seem to modprobe it to get it flashing - modprobe ieee1394 comes back without errors, but doesnt seem to activate the card either.
[04:17] <cjwatson> thanks, I think I might do that for now
[04:17] <StevenK> I thought 1394 was Firewire
[04:17] <BenC> Hobbsee: wasn't touched...are you sure you have lrm for -16 installed?
[04:17] <BenC> cjwatson: ok
[04:18] <Hobbsee> BenC: gutsy.  -6.  yes, both the ubuntu modules and the restricted modules
[04:19] <Hobbsee> BenC:  i havent tried a reboot etc, yet - only modprobing the cards after the ubuntu modules came in
[04:19] <BenC> has to be done when lrm is also installed, because it requires the ipw3945d-`uname -r`
[04:20] <BenC> you could try "modprobe -r ipw3945; modprobe ipw3945" and see if that fixes it
[04:21] <cjwatson> BenC: we don't seem to be up-to-date with the patch in http://lkml.org/lkml/2007/3/29/47; specifically we're missing the if (!loop_find_dev(lo->lo_number + 1)) loop_init_one(lo->lo_number + 1); in lo_open
[04:21] <cjwatson> and the loop_find_dev function
[04:21] <Hobbsee> BenC: okay, where's the duncecap.  
[04:22] <Hobbsee> BenC: too many damned numbers.     loaded the wrong module.  sorry for the noise
[04:22] <BenC> np :)
[04:22] <BenC> cjwatson: there's a lot of back and forth about how to handle that patch among others
[04:22] <BenC> I'm still digging through the thread
[04:24] <Keybuk> it does seem a bit broken
[04:24] <Keybuk> "mknod the device yourself" is very 1980s
[04:25] <iwj> OK, here's a question: I want to merge dpkg from svn and it looks like pushing svn trunk into gutsy is the right thing.  I what form should my package take (particularly, which version number) to avoid confusing MoM and similar tools ?
[04:25] <iwj> Actually constructing the package is easy - I can do that bit.
[04:25] <Keybuk> iwj: it depends
[04:25] <iwj> Go on ...
[04:25] <Keybuk> if a new version is uploaded to Debian, do you want that to be sync'd or merge'd ?
[04:25] <Keybuk> or do you want our dpkg to be a permanent fork, only merged from svn?
[04:26] <iwj> Merged.
[04:26] <Keybuk> then I would suggest something like
[04:26] <Keybuk> dpkg 1.14.4+svn20070304-0ubuntu1
[04:26] <iwj> We might later choose to either merge from somewhere in svn, or to merge from sid.
[04:26] <Keybuk> where 1.14.4 is the last Debian release
[04:26] <StevenK> svn20070604, surely?
[04:26] <iwj> svn<whatever>, right :-).
[04:26] <Keybuk> StevenK: I just made up a number without looking at the date :p
[04:26] <StevenK> Keybuk: :-P
[04:27] <Keybuk> you could also use
[04:27] <Keybuk> 1.14.5~svn20070604-0ubuntu1
[04:27] <Keybuk> where 1.14.5 is the next version to be released
[04:27] <Keybuk> depending whether you want the version number to mean "1.14.4 and some more bits" or "the work towards 1.14.5 taken from svn at this date"
[04:27] <Keybuk> both would work
[04:27] <iwj> And single tarball is still fine ?  OK.
[04:28] <iwj> .4+ or .5~> I don't think there's much of a distinction in this case.
[04:28] <Keybuk> the -0ubuntu1 makes it clear to the sync and merge stuff that this is something done in ubuntu
[04:28] <iwj> Right, OK.
[04:28] <Keybuk> "the first ubuntu revision of an upstream version that's not packaged in Debian yet"
[04:31] <pygi> dholbach, you have some time? I wanna bug you to try out something :)
[04:32] <dholbach> pygi: a tiny little bit only
[04:32] <pygi> dholbach, oh, I'll bug you later then :)
[04:32] <dholbach> ok thanks :)
[04:42] <iwj> StevenK: If you're still seeing warnings from dpkg-foobar please do c&p one and let me know.  Any remaining warnings that you see with 1.14.4ubuntu2 are not fixed upstream so it would be good to know about them.
[04:43] <Hobbsee> iwj: (he's gone to bed)
[04:46] <cjwatson> BenC: do you have any idea why keyboard input in gutsy when using vmware might be very much slower than in feisty?
[04:47] <cjwatson> it takes something like half a second to a second to process each keypress
[05:09] <iwj> Mithrandir: Let me know if dpkg 1.14.4+svn20070602r802-0ubuntu1 doesn't sort out your lpia problem.
[05:37] <BenC> cjwatson: no idea why. I hadn't noticed that in my vmware install, but mine is just console
[05:46] <pitti> tepsipakki: recent xorg upload introduced a dependency xorg-docs for xorg, but that's in universe; there needs to be either a MIR or dropping the depends to a suggests or so
[05:48] <pitti> tepsipakki: NB that a MIR needs to be accompanied by one for xorg-sgml-doctools, since that's a build dep
[06:12] <bryce> pitti, hmm, I don't think there's a reason we need xorg-docs as a depends for xorg.  
[06:12] <geser> Mithrandir: please give-back tntdb on all archs. Thanks.
[06:13] <iwj> bryce: It seems odd that Debian introduced it as a Depends.  Until we know why I'd be cautious - it might be something to do with the /usr/X11R6 transition.
[06:14] <bryce> true
[06:42] <pitti> bryce: we need to get xorg installable until tomorrow, so for the moment I'd prefer loosening the dependency (if it doesn't break anything)
[06:43] <bryce> ok
[07:08] <bryce> pitti, this appears to be the entry for when xorg-docs was added:
[07:08] <bryce>  * Add xorg-docs to the xorg package dependencies. There's some very usefu
[07:08] <bryce> l
[07:08] <bryce>     manpages in there, among other things.
[07:08] <bryce>  -- David Nusinow <dnusinow@debian.org>  Sun,  4 Mar 2007 15:38:57 -0500
[07:09] <pitti> bryce: I looked at that changelog entry, that's why I'd prefer the 'drop to suggests' approach for now
[07:09] <pitti> bryce: also in terms of CD size increase
[07:09] <pitti> bryce: it's only one MB of course, but it still matters for us
[07:10] <bryce> Suggests or Recommends?
[07:11] <pitti> bryce: main Recommends: should be resolvable in main (since our tools install them by default), so Suggests:
[07:20] <bryce> pitti, would you mind reviewing this change?  This is the first change I've done for the xorg package:  http://people.ubuntu.com/~bryce/Uploads/
[07:21] <pitti> bryce: what's the change exactly? there's no new xorg package there
[07:22] <pitti> bryce: also, can you please put a debdiff there for me to review? (for the packages you want to modify)
[07:22] <pitti> bryce: oh, I see, you created xorg 1:7.2-3ubuntu2
[07:22] <pitti> bryce: that already exists, though (tepsipakki uploaded it a few hours ago)
[07:24] <bryce> debdiff posted
[07:25] <pitti> bryce: looks fine, when you apply that to the -3ubuntu2 in the archive
[07:25] <pitti> bryce: <nitpick>the changelog could give the rationale, something like 'because it is in universe and we need to save CD space' or so</nitpick>
[07:26] <bryce> ok
[07:27] <bryce> hmm, according to apt-cache madison, 1:7.2-3ubuntu1 is the latest, so 1:7.2-3ubuntu2 should be the next number, no?
[07:28] <pitti> bryce: apt-get update :)
[07:28] <mdz> shawarma: was it you who mentioned network-manager-openvpn to me at UDS?
[07:28] <pitti>       xorg | 1:7.2-3ubuntu2 | http://archive.ubuntu.com gutsy/main Sources
[07:28] <shawarma> mdz: I may very well have.
[07:28] <mdz> shawarma: my impression was that we should Just Do It
[07:28] <bryce> aha
[07:29] <shawarma> mdz: yes?
[07:29] <shawarma> mdz: I've got an long overdue update on my TODO list, but the current version should (mostly) work.
[07:29] <mdz> shawarma: is there work to be done on the server side?
[07:30] <shawarma> mdz: Well... If the server doesn't push DNS settings, the client acts... well, funny.
[07:30] <mdz> what about -vpnc?
[07:30] <shawarma> mdz: That's even better.
[07:30] <shawarma> mdz: I'm working on updating the UI to work with some of the new features in vpnc 0.4.
[07:30] <pitti> bryce: I need to go now, so I cannot sponsor this, sorry
[07:31] <shawarma> mdz: (mainly being able to use the encoded passwords from Cisco's pcf files)
[07:32] <mdz> shawarma: sounds like a project for a later date then
[07:32] <mdz> openvpn seems like it might be a nice ubuntu server + ubuntu clients solution
[07:32] <shawarma> Oh, definitely.
[07:33] <shawarma> mdz: this Ebox thing does VPN, too.
[07:33] <mdz> shawarma: what's the backend?
[07:33] <shawarma> mdz: Openvpn.
[07:33] <mdz> oh, neat
[07:33] <shawarma> mdz: I've got an e-mail to you about that's almost done.
[07:33] <shawarma> mdz: Give me a minute.
[07:33] <mdz> shawarma: if it works in the version we ship, we should definitely consider shipping the client side as well
[07:34] <shawarma> mdz: Sure, that makes perfect sense.
[07:35] <mdz> shawarma: I'll read your email when it comes and then we can talk further tomorrowish
[07:35] <shawarma> mdz: Oh, I've got tomorrow off.
[07:35] <shawarma> mdz: Constitution day.
[07:35] <mdz> aha
[07:35] <mdz> I don't have dk holidays in my calendar yet
[07:36] <shawarma> There. Added to my calendar.
[07:39] <shawarma> mdz: Mail sent.
[07:49] <tepsipakki> pitti, bryce, iwj: xorg depends on xorg-docs because "There's some very useful manpages in there, among other things."
[07:50] <tepsipakki> but I can upload a new version
[07:50] <tepsipakki> moving the dep to Suggests as in bryce's patch
[07:50] <bryce> cool, thanks
[07:51] <tepsipakki> we can sort that out later
[07:51] <tepsipakki> xorg-docs, that is
[07:51] <bryce> btw, I'm also looking at another recent issue reported
[07:51] <tepsipakki> shoot
[07:51] <bryce> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/118661
[07:51] <ubotu> Launchpad bug 118661 in xorg "[gutsy]  xserver-xorg (1:7.2-3ubuntu1) configure error" [Undecided,Confirmed]  
[07:52] <tepsipakki> that's fixed in -3ubuntu2 :)
[07:52] <bryce> ahh, ok cool
[07:53] <bryce> closing as fixed
[07:56] <tepsipakki> uploaded
[07:56] <tepsipakki> now home ->
[07:57] <bryce> cya
[08:44] <ashrack> hello! I was just wondering how come with the latest feisty kernel the NVIDIA NFORCE2 PATA driver has been disabled from the new Serial ATA (prod) and Parallel ATA (experimental) drivers' and the old ATA driver is now used again AMD and nVidia IDE support (BLK_DEV_AMD74XX).
[10:10] <keescook> Keybuk: can you confirm bug 118164?  I'm shy to add any deps to udev, but it looks correct.
[10:10] <ubotu> Launchpad bug 118164 in udev "Missing udev dependency: adduser" [Undecided,Confirmed]  https://launchpad.net/bugs/118164
[10:11] <Keybuk> keescook: yup, seems reasonable
[10:12] <keescook> Keybuk: okay, I'll commit it, thanks.
[10:13] <Keybuk> commit?
[10:13] <keescook> commit meaning "stuff it into the package and upload it"
[10:14] <Keybuk> :)
[10:14] <Keybuk> was just checking
[10:16] <Keybuk> keescook: there are LP branches of udev that I've never been able to eradicate
[10:17] <Keybuk> (which I don't use)
[10:17] <keescook> heh.  yeah, I didn't think there was a vcs for it.  you scared me for a second.  :)
[10:18] <Keybuk> I've not found a model of source-package-in-vcs that I'm happy with
[10:18] <Mithrandir> iwj: thanks, I'll take a look.
[10:18] <Mithrandir> geser: given-back
[10:46] <sabdfl_> in a bash script, is it easy to read a word from the console?
[10:46] <sabdfl_> i'd like to read a variable, and pre-seed it with a default
[10:46] <sabdfl_> like:
[10:46] <sabdfl_> What is your username? [mark]  _
[10:47] <sabdfl_> enter would return "mark"
[10:47] <Mithrandir> DEF="mark"; printf "What is your username? [$DEF]  " ; read FOO ; if [ -z "$FOO" ] ; then FOO="$DEF" ; fi
[10:47] <pygi> sabdfl_, use read and see if input is empty?
[10:47] <pygi> meh :P
[10:47] <kylem> heh. Mithrandir is faster than i am.
[10:47] <pygi> Mithrandir, :)
[10:49] <sabdfl_> thanks Mithrandir, pygi