[01:57] <mathiaz> slangasek: what's your opinion on bug https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631?
[01:57] <slangasek> mathiaz: <opinion>"blech"</opinion>
[01:57] <mathiaz> slangasek: it seems that most of the issue are related to network manager.
[01:58] <mathiaz> slangasek: what about adding an script to umount cifs share in ifdown.d for network manager?
[01:58] <slangasek> two things: 1) network-manager shouldn't be allowed to kill off the network before unmounting remote filesystems in the general case, 2) the kernel and/or umount.cifs needs to be fixed to not have long timeouts in the case that the server is unreachable
[01:59] <slangasek> I think the latter is actually a kernel rather than userspace issue
[01:59] <slangasek> ifdown.d is probably wrong because you don't want to unmount the remote filesystems when *a* network interface goes down, you want to unmount them when the *corresponding* network interface goes down
[02:00] <mathiaz> slangasek: right - there is also the issue of processes having an file open on the mounted device
[02:01] <mathiaz> slangasek: IIUC this is why umountnfs is run after sendsigs in the shutdown sequence
[02:01] <slangasek> yes
[02:01] <mathiaz> slangasek: in the case of network manager it may not be a good idea to kill all process that have a file open on the mounted device
[02:02] <slangasek> sorry, what do you mean?
[02:02] <mathiaz> slangasek: before umount a network fs, we could try to figure which processes have a fd open on the network fs and kill them.
[02:03] <slangasek> are you talking about at shutdown time?
[02:03] <mathiaz> slangasek: to mimic the shutdown sequence where processes are killed before umounting network filesystem
[02:03] <mathiaz> slangasek: nope - when a interface is brought down
[02:03] <mathiaz> slangasek: assuming we'd add a pre-ifdown.d script to umount the network filesystem
[02:04] <slangasek> er, how are you going to write an ifdown.d script that doesn't gratuitously unmount filesystems that it shouldn't?
[02:05] <mathiaz> slangasek: well - I haven't about that yet. But it seems that adding adding an ifdown script is too complicated.
[02:05] <mathiaz> slangasek: haven't *thought*
[02:05] <slangasek> if I have more than one interface, I don't want all the NFS mounts for my internal network to disappear every time I adjust my external interface, e.g.
[02:06] <slangasek> regardless of anything else, the timeouts are a kernel/umount.cifs bug that should be fixed there
[02:06] <slangasek> and if we fix that, the only other problem is at shutdown time, AFAICS
[02:06] <mathiaz> slangasek: correct. And you'd also have to figure out a way to match which interface is used for each network filesystem.
[02:07] <slangasek> which can be addressed by fixing n-m's behavior on shutdown
[02:07] <mathiaz> slangasek: correct. people are complaining because it takes too long to shutdown.
[02:08] <slangasek> i.e., either move n-m to /sbin and add it to the ignore list for sendsigs, or arrange for n-m to not tear down the interfaces when signalled, I think?
[02:09] <mathiaz> slangasek: well - some user reported that they had issue when logging off.
[02:09] <mathiaz> slangasek: in the case of a wireless connection, is the connection brought down when the user logs off?
[02:09] <slangasek> possibly.  shouldn't that be considered a bug?
[02:11] <mathiaz> slangasek: hm - I don't know. asac and the desktop team should probably be involved into this discussion.
[02:11]  * slangasek nods
[02:11] <mathiaz> slangasek: anyway it seems that the most practical solution is to lower the timeout.
[02:11] <slangasek> that's a bandaid, though.
[02:12] <slangasek> what *should* be happening in this case is that the network route is gone, so trying to send to it will get you a no-route-to-host
[02:12] <slangasek> which can be detected and handled by the kernel
[02:12] <slangasek> so either the route isn't being torn out when it should be, and we should fix that; or the cifs driver doesn't handle no-route-to-host, and we should fix that
[02:12] <slangasek> then adjusting the timeouts shouldn't matter at all
[02:14] <mathiaz> slangasek: ok. I'll add a note to the bug with the explanation you've just given.
[02:14] <slangasek> ok
[03:44] <EvanCarroll> man bluetooth support is *so* bad overall.
[03:44] <EvanCarroll> I've literally had problems with every component of bluetooth support.
[03:47] <EvanCarroll> seems as if there are general problems with all keyboards and keymaps in ibex, as well as no ui to make a bluetooth keyboard setup for gdm. and no logs for bluetooth-applet, no decent reconnects,,, gah i rant
[03:48] <EvanCarroll> having been sold into bluetooth I'm trying to run three devices a keyboard mouse and mic/earphone phone thingy
[03:48] <EvanCarroll> so far they all have suprises.
[03:51] <cody-somerville> Its a good thing you're working on it then
[03:56] <EvanCarroll> the catch is, I'm not sure which bugs are faulty hardware, or which bugs are OS.
[03:56] <EvanCarroll> I'd have to install windows to figure it out.
[03:57] <EvanCarroll> the disconnects could be faulty hardware from the bluetooth usb dongle or from the mouse. or from the load of three devices on the adapter
[03:57] <EvanCarroll> or, most probably, linux support
[03:58] <cody-somerville> then why even go with the improbably premise until probable?
[04:01] <EvanCarroll> well. the probability is based on the guilty-by-association.. which seems to be based on things *I* know to be reproducable linux problems lingering from a bad userspace implimentation for hotswap devices.
[04:03] <EvanCarroll> like keymaps, how can unplugging a usb keyboard and plugging it back in revert a keymap, and how come when a computer comes on with a bluetooth keyboard it has to be manually connected in bluetooth-applet, and after it is connected even though the keymap is international in keyboard preferences, it is en-us in reality.
[04:04] <EvanCarroll> if you only have a bluetooth keyboard, how do you type in your password in GDM.
[04:04] <EvanCarroll> lol.
[04:29] <emgent> moin moin
[06:33] <pitti> Good morning
[06:33] <pitti> kirkland: looking
[06:37] <pitti> kirkland: that looks excellent
[06:55] <dholbach> good morning
[07:17] <geser> good morning dholbach, pitti
[07:17] <dholbach> hiya geser
[07:20] <NCommander> morning geser
[07:20] <pitti> hey geser
[07:20] <pitti> NCommander: congrats to your MOTU badge!
[07:21] <NCommander> pitti, yup, it got my my backports one too
[07:21] <NCommander> (and I highly recommend you use caution on opening your inbox pitti :-))
[07:21] <NCommander> There is one removal, and 14-16 backporting ACKs
[07:21] <pitti> NCommander: too late
[07:22]  * NCommander gives you the flamethrower of justice
[07:22] <NCommander> oh and an SRU
[07:22] <NCommander> ;-)
[07:24] <geser> Hi NCommander
[07:24] <NCommander> morning geser
[07:27] <NCommander> geser, I'm loking at your merges, any one you want me to do upfront?
[07:34] <geser> NCommander: no specific order
[07:35] <NCommander> geser, well, one of your merges became a sync since Debian rolled your fix bashisms patch
[07:35] <NCommander> so one down
[07:36] <geser> NCommander: I guess squid3 might be a sync too as that patch came from upstream and should be included in 3.0.STABLE8
[07:37]  * NCommander is trying to determine if the requestsync script actually works :-)
[07:37] <geser> NCommander: ilohamail is a fakesync due to bad versioning, so an easy one too (if you prefer the easy ones :)
[07:37] <NCommander> fakesync?
[07:40] <geser> NCommander: in cases where we don't have any changes but can't sync (different .orig.tar.gz, bad versioning etc.) we need to do an upload nonetheless (e.g. take the Ubuntu .orig.tar.gz and Debian .diff.gz in the case of a different .orig.tar.gz)
[07:40] <NCommander> What's the version number I need to upload w/?
[07:40]  * NCommander requests another sync for libnet-cups-perl
[07:42] <geser> as there aren't any changes -XbuildY should work (generally speaking)
[07:43]  * NCommander nods
[07:43] <geser> in case of ilohamail you need to upload 0.8.14-0rc3sid6 as  0.8.14-0rc3ubuntu4
[07:44]  * NCommander grabs the debian packaging
[07:44] <NCommander> so debian diff, ubuntu orig.tar.gz
[07:46] <geser> you can use also the debian .orig.tar.gz as they're both the same (it's just the versioning which went bad in the past)
[07:46]  * soren wishes people would stop writing more php webmail systems and write a Python one instead
[07:46]  * NCommander nods
[07:46] <NCommander> geser, what do I use for the -v in debuild?
[07:47] <soren> The last version known to Ubuntu.
[07:48] <NCommander> Right
[07:48] <NCommander> But there are no other ubuntu entries in the changelog
[07:49] <geser> use 0.8.14-0rc3sid5 so you get also the new Debian changelog entry into the .changes file
[07:49] <NCommander> ah
[07:49] <soren> The point is that the .changes file should list all the changes since the last version uploaded to Ubuntu.
[07:49]  * NCommander test builds, and installs
[07:49] <NCommander> Ok, now it makes sense
[07:55] <liw> lifeless, and don't you just love a discussion that bounces across channels? :)
[07:55] <lifeless> liw: only when there is enough people capable of following it
[07:58] <ara> NCommander: congratulations on your MOTU!
[07:58] <NCommander> Yup :-)
[07:58]  * NCommander takes his head off to you
[08:11] <kirkland> pitti: awesome, thanks!
[09:03] <seb128> calc: why did you reassign this mimetype issue thing to nautilus?
[09:27] <t3rm1n4l> hi
[09:28] <t3rm1n4l> may i know who is loading kernel modules for ethernet card, graphic cards?
[09:28] <t3rm1n4l> is that udev?
[10:31] <kelemengabor> hi mvo, do you have some time for i18n bugs? :)
[10:31] <kelemengabor> for example bug #289798
[10:33] <mvo> kelemengabor: oh, right - sorry that I haven't worked on it earlier
[10:33] <kelemengabor> np
[10:33]  * mvo puts it on his list for today
[10:33] <kelemengabor> any hope that such changes can make it into intrepid? or only jaunty?
[10:34] <kelemengabor> thanks
[10:34] <mvo> kelemengabor: I think we could sru it, but from a first glance it looks like we might get a ways with regenerating the pot template and uploading into into rosetta
[10:35] <mvo> kelemengabor: what do you think?
[10:35] <kelemengabor> yeah, some 160 new strings showed up for me locally
[10:36] <kelemengabor> oops, life calls me, see you later
[12:22] <pitti> crimsun: is bug 282316 fixed in jaunty's alsa-plugins?
[13:11] <ScottK> pitti: On spamassiss, the dapper task needs to stay open.  The one that got accepted didn't actually apply the patch and there's another one in -proposed for testing.  I'll reopen the task.
[13:26] <pitti> ScottK: I thought that's what I did? dapper -> fixcommitted, dapper backports -> fixreleased?
[13:27] <pitti> ScottK: anyway, that's what I *intended* to do. If I broke them, I apologize
[13:27] <ScottK> pitti: On one bug.  On the other one you did dapper fix-released.  No trouble.  It's a confusing situation.
[13:27] <pitti> ScottK: thanks for double-checking
[14:13] <ScottK> pitti: (Still double checking spamassassin) were you going to do the backports for Gutsy/Hardy too?
[14:14] <pitti> ScottK: yes, backports and other archive stuff is still on my list
[14:14] <pitti> I still didn't finish with SRUs
[14:14] <pitti> (gosh...)
[14:14] <ScottK> pitti: OK.  No rush.  Just making sure (since it's a lot of pieces to push around on that package).
[15:56] <james_w> pitti: hi, I have a user that has an apparent problem with the sources.list entry added for their printer driver
[15:57] <james_w> pitti: apparently it is not the right case. It sounds like this is a problem with openprinting's database, but should it be filed on jockey?
[15:57] <pitti> james_w: yes, please file it on jockey for now, it should filter those out; I'll forward it to openprinting
[15:58] <james_w> thanks
[16:10] <mathiaz> pitti: when an SRU bug is marked for verification-needed, should the uploader do the verification or it'd better be someone else?
[16:10] <pitti> mathiaz: usually someone else, like QA team or bug reporter
[16:14] <persia> mathiaz, Note that if nobody steps up, asking for help in #ubuntu-bugs or #ubuntu-testing can help the process.
[16:34] <pitti> Riddell: can you please commit your cdbs change to bzr?
[16:34] <Riddell> pitti: oh doh, will do
[16:34] <pitti> Riddell: for 0.4.52ubuntu7 too, please; thanks!
[16:37] <Riddell> done
[16:44] <pitti> NEW -> 611 entries
[16:44] <pitti> yeah, must be post-release time ...
[16:45]  * jdong blames NCommander  :)
[16:45] <ScottK> Good thing Lenny freeze slowed things down.
[16:45] <ScottK> ;-)
[16:45] <pitti> well, credit where credit is due, most is Debian imports :)
[16:45] <pitti> (I *hope*)
[16:49] <thvdburgt> hi all, I would like to try to add emesene support to the fast-user-switch applet. Is there a bzr-branch for the code or is http://packages.ubuntu.com/source/intrepid/fast-user-switch-applet this the most recent code?
[16:52] <pitti> tedg: ^
[16:53] <thvdburgt> ah, I notices Ted is the maintainer, tedg can you help me?
[16:54] <tedg> thvdburgt: Sure.  I'm sorry, what is emesene?
[16:55] <thvdburgt> http://www.emesene.org/ It is an Instant messenger for the msn-network
[16:57] <tedg> thvdburgt: Ah, cool.  Probably the branch you want is this one: https://code.launchpad.net/~ted-gould/fast-user-switch-applet/show_status  (note, you can get all of them by looking here: http://code.launchpad.net/fast-user-switch-applet )
[16:57] <tedg> thvdburgt: You should only have to edit src/status-manager.c to add another set of functions for emesene.
[16:58] <thvdburgt> thank you tedg I'll give it a shot :)
[17:18] <aaroncampbell> How would I configure Gtk+ to allow "accelerator changes" ?  I'm running Kubuntu, but I guess Pidgin could use this?
[17:21] <little> Are there any developers in here who can answer a question about the linux-ubuntu-modules-2.6.24-21-generic update?
[17:28] <little> Is anybody in here who knows anything about the linux-ubuntu-modules-2.6.24-21-generic update?
[17:29] <seb128> if you were asking your question maybe somebody would reply
[17:30] <little> The description for the update says, "You likely do not want to install this package directly. Instead, install the linux-generic meta-package, which will ensure that upgrades work correctly, and that supporting packages are also installed.". Is this anything to worry about, or can I go ahead and update it?
[17:33] <tseliot> little: you can go ahead
[17:34] <little> tseliot: Any idea why there's a warning?
[17:35] <tseliot> little: because we want users to install the linux-generic metapackage so that when the kernel is updated you will automatically get  linux-ubuntu-modules for the new kernel
[17:36] <little> tseliot: I never messed with the kernel when installing Hardy Heron - I let it install whatever it wanted. (:
[17:37] <tseliot> little: if you install the package without the metapackage your linux-ubuntu-modules won't match the new kernel
[17:37] <cjwatson> then you should have linux-generic already installed
[17:37] <little> I'll check for both of those before I do the upgrade, then, thanks!
[17:37] <cjwatson> that isn't a warning primarily intended for upgraders - it's in the package description so that people installing the package from scratch know the intention
[17:38] <cjwatson> it happens that update-manager can be asked to display the description
[17:38] <cjwatson> but it's a description of the package rather than of this specific update, if you see what I mean
[17:39] <little> Ah, okay, that makes sense.
[17:39] <pitti> cjwatson: installation-report ended up on my merge list, since I did a small fix; shall I do it, or is it on your radar anyway?
[17:39] <cjwatson> pitti: either's fine with me; all of d-i is notionally on my list if nobody else does it
[17:39] <little> You guys might want to re-word those warnings, then. (:
[17:40] <cjwatson> linux-ubuntu-modules no longer exists in more recent releases than 8.04, so we probably won't put too much effort into its description TBH :-)
[17:40] <cjwatson> it got folded back into the main image
[17:40] <little> Ah well. (:
[17:40] <cjwatson> I think actually we should probably rethink how update-manager displays this stuff, rather than rewording the descriptions
[17:40] <cjwatson> it's not going to be a problem unique to linux-ubuntu-modules
[17:41] <cjwatson> bug 145764 is related
[17:43] <cjwatson> I've added a comment to that bug about this case
[17:44] <little> From a user's standpoint, many users will probably just grab the update, but those of us who read somthing like that will hesitate or not install it at all. If the update in question fixes a vulnerability or other significant issue, that might leave a lot of users without the update. (:
[17:44] <cjwatson> I agree that it is a confusing presentation, just debating how to fix it properly :-)
[17:44] <little> For the record, I'm using Kubuntu Hardy Heron, so this is in Adept Manager.
[17:44] <little> I'm not sure how it displays in Ubuntu.
[17:45]  * little is into documentation
[17:45] <cjwatson> ah. could you file a bug on adept about this, then? I don't see one there
[17:46] <little> Okay, will do.
[17:46] <cjwatson> thanks
[17:48] <little> Should it be a bug on warnings in descriptions in general?
[17:50] <cjwatson> no, I don't think so
[17:50] <cjwatson> the description wasn't intended to be displayed this way, so it's hardly surprising that it seems odd
[17:50] <cjwatson> the bug is in the presentation, not the content (which is designed for an entirely different use case)
[17:50] <cjwatson> I think we'd be fighting an uphill battle to make descriptions suitable, and that doing so would not buy very much
[17:52] <little> I don't know how those descriptions are created, but maybe instead of changing them, you could simply add a blanket comment beneath any that are like that to let people know that if this is an update for an existing package, the warning doesn't apply.
[17:53] <little> If that's something that could be done by running one command that would affect all similar packages, it might not be too hard to do. (:
[18:01] <cjwatson> little: I honestly don't think that would be appropriate
[18:01] <cjwatson> little: we shouldn't need to touch the descriptions at all for this - we should simply not present them as descriptions of the update
[18:01] <cjwatson> because they aren't
[18:02] <cjwatson> and no, it wouldn't be a matter of running a command, it would be a slow and tedious process of uploading lots of packages
[18:02] <cjwatson> which is one reason I think we should fix it in the right place rather than a workaround that's in fact harder work :-)
[18:04] <little> LOL! You poor things! Isn't there a team somewhere in Ubuntu that works on simplifying all that stuff? (:
[18:06] <cjwatson> we are indeed working on improved collaborative development
[18:06] <cjwatson> still wouldn't change the fact that the package descriptions are the *wrong place to change this* :-)
[18:06] <little> I mean the final database that holds all the information about all the packages. It would be awesome if that was in plain text and accessible so you could do blanket edits. (:
[18:07] <kees> cjwatson, slangasek, or others, I'm trying to understand what seems to be vagueness in the Debian Policy Manual regarding Depends.  Here are the two sections that are confusing me:
[18:07] <kees> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
[18:07] <cjwatson> little: we don't want to maintain that as a central database, rather than considering the package the proper source of that information
[18:07] <kees> http://www.debian.org/doc/debian-policy/ch-relationships.html (7.2)
[18:08] <cjwatson> little: the database is built dynamically from the packages
[18:08] <cjwatson> this is actually much more maintainable in reality
[18:08] <kees> first says "Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package."
[18:08] <little> cjwatson: Ah, that makes sense.
[18:08] <kees> second says "A package will not be configured unless all of the packages listed in its Depends field have been correctly configured.'
[18:08] <slangasek> kees: the second use of "installed" there should be "unpacked"
[18:09] <kees> slangasek: ah-ha!
[18:09] <cjwatson> yeah, "installed" is dpkg internal jargon for "unpacked"
[18:09] <cjwatson> and hence policy is sometimes a bit confused about the wording here
[18:09] <Koon> ah-ha!
[18:10] <kees> okay, that resolves some confusion, but now it sounds like if I have  Depends: one, two   then one and two will run their postinsts before my own
[18:10] <cjwatson> yes, unless there is a dependency loop involved
[18:10]  * slangasek nods
[18:10] <Koon> cjwatson: in which case the loop is broken arbitrarily, right
[18:10] <kees> okay, I believe that's what we're fighting, then.
[18:10] <cjwatson> Koon: right
[18:11] <cjwatson> if you have a dependency loop you need to ensure that it works either way round
[18:15] <dx9s_work> still is an unusual question.. but where does one download the ubuntu maintained patches for the kernel source code? I know I can download the kernel source code already patched by ubuntu maintainers, but where do I get what the maintainers used to patch the kernel source in the first place?
[18:15] <cjwatson> the .diff.gz for the package contains the differences between our source and upstream
[18:16] <cjwatson> they were acquired from a number of sources; the easiest way to inspect them is probably by using revision control. http://wiki.ubuntu.com/KernelGitGuide
[18:17] <dx9s_work> sooo. I have to download the source for a package that is (in itself) already source code.. two levels of source getting ...
[18:18] <pwnguin> im pretty sure the kernel team uses git
[18:18] <pwnguin> so it's not quite that bad
[18:19] <dx9s_work> pwnguin, am I making sense.. I don't want the source code to the kernel.. I want the patches (diffs) the ubuntu team applies to that source code
[18:19] <pwnguin> thats what git keeps track of
[18:19] <pwnguin> they dont publish it seperately
[18:19] <cjwatson> that's what's in the .diff.gz file
[18:20] <cjwatson> I do not believe that it is shipped as part of the linux-source binary package, which seems to be what you're thinking of
[18:20] <cjwatson> linux-source isn't really intended for this purpose, as far as I know; for more sophisticated questions like yours you are better off ignoring linux-source and just fetching it from git
[18:20] <pwnguin> cjwatson: how does it figure out what the base tarball is?
[18:20] <dx9s_work> I understand that the ubuntu patches are outside the offical kernel source (been compiling kernels from kernel.org for years)
[18:21] <cjwatson> pwnguin: the developer doing the upload supplies it
[18:21] <dx9s_work> just trying to find the easiest way to get ubuntu's diffs on that source
[18:21] <cjwatson> I've now told you it twice
[18:21] <cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.24-21.43.diff.gz for 8.04, http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.27-8.17.diff.gz for 8.10
[18:23] <dx9s_work> cjwatson, thanks
[18:24] <pwnguin> dx9s_work: there's 12 megs of diff there
[18:24] <persia> 8.17 is in -proposed.  8.10 is currently still 7-16.
[18:25] <cjwatson> .diff.gz tells you what the patches *are*; git will let you ask questions about how they break down in more detail
[18:25] <cjwatson> depends what you need to know
[18:25] <cjwatson> some people just care about the sum total of what we change
[18:25] <dx9s_work> is each diff dependent (aka not accumulative)? (hence the 12M comment from pwnguin )
[18:26] <pwnguin> "each diff"
[18:26] <pwnguin> it's just one diff
[18:26] <pwnguin> not patches
[18:26] <pwnguin> one patch
[18:26] <cjwatson> if you want to get separate patches, use git
[18:26] <cjwatson> each .diff.gz is the accumulated change from the base tarball to that Ubuntu revision
[18:27] <pwnguin> it should also contain things like how to build the .deb
[18:28] <dx9s_work> been doing the kernel .deb thing for a little while on a newer machine
[18:28] <dx9s_work> have that bookmarked on computer at home
[18:29] <pwnguin> what is your goal here? to rebuild your kernel based on the ubuntu kernel?
[18:29] <dx9s_work> using "fakeroot make-kpkg ..."
[18:29] <dx9s_work> no .. interested in trying a few different options
[18:29] <pwnguin> so rebuild... with a few different options
[18:31] <dx9s_work> I am about 1-2 years into ubuntu (former slackware guy, and the slack-build process is different and simplier -- no dependency checking) .. just trying to do something and figured instead of brute force compiling a kernel/installing (was installing kernel outside .deb for the first year BTW).. should review the whole process ... it's 1 part learning and 1 part I am interesting in custom tweaked rt kernel
[18:32] <pwnguin> in my opinion, the first thing you should learn about the kernel is git
[18:33] <dx9s_work> I've used git a little bit in the past... and before git was even a tool written to help maintain the kernel source
[18:34] <dx9s_work> aka I'm not new to compiling the kernel... I'm new to ubuntu's way .. and still have some to learn about git ...
[18:34] <pwnguin> ubuntu's way is subject to stupidity, improvements and change ;)
[18:34] <pwnguin> git however, is probably going to be a bit more stable
[18:34] <dx9s_work> too many cooks in the kitchen?
[18:35] <pwnguin> i dont think so.
[18:35] <pwnguin> maybe even too few
[18:35] <pwnguin> anyways, i gotta bolt for work
[18:36] <dx9s_work> thanks
[18:41] <dx9s_work> who comes up with this names ... "Trembling Tortoise" .. heheh
[18:41] <little> cjwatson: I filed the bug. I hope I worded it well: https://bugs.launchpad.net/ubuntu/+source/adept/+bug/295277
[18:53] <persia> dx9s_work, If you're interested in the -rt kernel, you might want to also take a look at the linux-rt source package.
[18:53]  * dx9s_work understood
[18:53] <dx9s_work> persia, understood
[18:58] <dx9s_work> persia, that rt kernel is not *perfect* hence this WHOLE line of questioning in the first place
[18:59] <cjwatson> little: thanks; I have added some clarification
[19:00] <persia> dx9s_work, In fact it has several bugs, for which fixes would be appreciated.  It's the combination of the things in git or in the linux source with the patches in the linux-rt source that are your best bet for -rt though.
[19:00] <dx9s_work> persia, are the patches that the -rt patches use in the same git source?
[19:05] <persia> dx9s_work, No.  Those are in the linux-rt package.
[19:05] <persia> upstream -rt is in quilt, and linux-rt uses quilt to apply those (and some integration bits) to the linux-source binary package produced from the linux source, which is in git.
[19:09] <dx9s_work> I don't know what quilt is .. I know of http://rt.wiki.kernel.org/
[19:13] <cjwatson> kees: I've filed a debian-policy bug for the text to be disambiguated
[19:14] <cjwatson> dx9s_work: apt-cache show quilt
[19:17] <dx9s_work> ah
[19:18] <little> cjwatson: Thanks - well done! I didn't want to put in any explanations since bug reports generally don't want us (the general user) venturing guesses. (:
[19:23] <kees> cjwatson: oh! thanks
[19:23] <thvdburgt> tedg, how can I easily test my newly compiled version of the applet?
[19:24] <thvdburgt> I see the "old" version is in /usr/lib/fast-user-.../ how can I get the panel t pick up my version?
[19:24] <tedg> thvdburgt: killall fast-user-switch-applet then a dialog will come up to reload.  Run yours, it'll sit there a second, then hit reload.
[21:06] <little> Hey there, should users of the 64 bit release of Kubuntu Intrepid Ibex have this file: linux-kernel-devel ?
[21:15] <dharanpdeepak> any one here to help me ?
[21:16] <dharanpdeepak> i wish to start contributing to ubuntu
[21:16] <dharanpdeepak> but i don't know where to start
[21:16] <dharanpdeepak> ???
[21:16] <dharanpdeepak> helloo ?
[21:16] <dharanpdeepak> anyone in there ???
[21:18] <little> dharanpdeepak: How would you like to contribute?
[21:19] <little> dharanpdeepak: This is a good place to start: https://wiki.ubuntu.com/Teams?action=show&redirect=TheUbuntuCommunity
[21:33] <cjwatson> little: linux-kernel-devel was removed in 8.10
[21:33] <cjwatson> regardless of architecture
[21:33] <RainCT> mvo_: Hi. Yesterday I looked at that method to only retrive the diff of Sources files which can be used in Debian experimental and in a comment on the BTS you stated that it doesn't work for Ubuntu. Could you explain why please?
[21:33] <cjwatson> little: you may still have it installed if you installed it manually on 8.04
[21:33] <cjwatson> (and then upgraded)
[21:34] <cjwatson> Depends: build-essential, curl, debhelper, git-core, gitk, kernel-package, kernel-wedge, openssh-client, rsync
[21:34] <little> cjwatson: Uh oh. There is a user following my instructions for installing the NVIDIA driver and he can't find the file. Does he simply not need it? My instructions (the one in question) are here: http://littlergirl.googlepages.com/NvidiaDriverHowTo.html#step04
[21:34] <cjwatson> is all it contained so you could just install that stuff manually
[21:34] <cjwatson> and some of that was just for committing to the kernel anyway
[21:35] <little> Can he just ignore that part of that step?
[21:35] <cjwatson> looking at your page,  build-essential debhelper kernel-package kernel-wedge  would probably be sufficient
[21:35] <little> Did you catch that, thomas?
[21:35] <cjwatson> (to replace linux-kernel-devel)
[21:36] <cjwatson> and if you mention build-essential then you can remove gcc and make, as well
[21:36] <cjwatson> or rather you don't need to list those explicitly
[21:37] <thomas_> I caught it but I dont understand it.. lol
[21:37] <cjwatson> thomas_: instead of "linux-kernel-devel", pretend that that page says "build-essential debhelper kernel-package kernel-wedge"
[21:38] <little> So Intrepid users need build-essentials, debhelper, kernel-package, kernel-wedge, pkg-config, xserver-xorg-dev, linux-source-2.6.24, linux-headers-2.6.24-19 and linux-headers-2.6.24-19-generic, right?
[21:38] <thomas_> oh... haha alright
[21:38] <little> And everyone else needs what I have listed minus gcc and make and with build-essentials instead, right?
[21:38] <cjwatson> little: for intrepid, it shouldn't be 2.6.24(-19) - replace with appropriate versions
[21:38] <cjwatson> the substitutions I gave are good for 8.04 too
[21:38] <little> cjwatson: Yeah, I'll update it with the latest kernel.
[21:39] <little> thomas: I'll paste a list for you in pastebin.
[21:39] <thomas_> alright
[21:40] <little> thomas, what do you get when you type this in a terminal window: uname -r
[21:40] <thomas_> 2.6.27-7-generic
[21:41] <little> These are the packages you must have installed: http://paste.ubuntu.com/69012/
[21:41] <little> Is that right, cjwatson?
[21:42]  * little doesn't want to steer thomas wrong.
[21:42] <thomas_> alright, they are installing
[21:48] <cjwatson> little: looks fine except you wrote "build-essentials" instead of "build-essential"
[21:49] <little> Ouch, thanks, I'll fix it and tell thomas.
[21:53] <crimsun> pitti: yes, 282316 is fixed in jaunty's alsa-plugins
[21:55] <thomas_> cjwatson: when I try installing the display drivers as little suggests it gives me an error saying something like unable to find the source tree for the currently running kernel
[21:55] <thomas_> then it says something about kernel-devel
[21:55] <little> Maybe my instructions won't work in Intrepid?
[22:00] <cjwatson> thomas_: at this point I suggest the two of you should take this to a different channel
[22:00] <cjwatson> this isn't really a discussion about development of Ubuntu as such
[22:01] <cjwatson> plus I don't know any further answers here :-)
[22:02] <thomas_> alright thanks
[22:58] <mvo_> RainCT: pdiff in debian can be used because debian re-generates the packages file only twice a day
[22:58] <mvo_> (used to be once a day only)
[22:58] <mvo_> RainCT: we used to do it every 1h (not sure how often we do it now) - so it does not scale well for us as its one individual file per change
[22:59] <mvo_> RainCT: the other thing is that its most interessting for unstable, the stable Packages file does not change, only -updates -security etc but they are much smaller than the full packages file
[23:00] <mvo_> RainCT: I'm off to bed now, but I'm happy to talk about this in more detail if you are interessted
[23:00] <RainCT> mvo_: what about implementing some fallback? like keeping one week of files and for people who haven't update since over a week apt would just download everything like it does normally
[23:01] <RainCT> mvo_: I am :). When should I best ping you to talk about it? (Or will you ping me? :))
[23:02] <mvo_> RainCT: I'm here all week usually during european daytime hours :)
[23:02] <mvo_> RainCT: (and a bit more usually)
[23:02] <mvo_> RainCT: the support in apt is available, we just need something that puts the diff on the server and we are ready
[23:04] <RainCT> mvo_: "something to put the diff on the server"? How is it working on Debian if this isn't done?
[23:05] <RainCT> (we can continue tomorrow if you want to leave :))
[23:07] <mvo_> RainCT: essentially its as simple as "diff -e Packages.old Packages.new; md5sum Packages.new >> DiffIndex" (well, slightly more, but not a lot really)
[23:07] <mvo_> RainCT: it would need support from the soyuz infrastrucure
[23:08] <mvo_> RainCT: https://bugs.edge.launchpad.net/soyuz/+bug/214612
[23:08] <RainCT> Ah, so there's nothing we (ie, the community) can do?
[23:09] <RainCT> @ mvo_
[23:09] <mvo_> RainCT: not sure, I can ask the soyuz people for their opinion - but I think its less interessting for ubuntu really because of the massive churn we do
[23:09] <mvo_> or at least we would/should try to make it better
[23:12] <mvo_> RainCT: in the meantime a "me too" comment n the bug is probably the right answer
[23:14] <mvo_> RainCT: happy to talk about it later, need to get some rest now :)
[23:18] <wgrant> pitti: Around?
[23:20] <wgrant> Hmm, I'd guess not. I can't count.
[23:21] <RainCT> wgrant: he's away - "off for the weekend"
[23:21] <wgrant> Blah. Unfortunate.
[23:26] <LaserJock> persia: ok, so here's what I'm trying to accomplish
[23:26]  * persia notes that the publisher still tries to run roughly every hour
[23:26] <LaserJock> I have 1, and perhaps more, people who would like to help maintain some Edubuntu packages
[23:26] <LaserJock> I'm trying to figure out the best way to set that up so we can collaborate via VCS and still keep it sane
[23:27] <LaserJock> it was suggested that I create a edubuntu-packaging LP team and throw branches in there
[23:27] <superm1> yeah
[23:27] <persia> OK, so you do have the use case where you want many people to collaborate on uploads, but not have frequent uploads (because they can't all upload those packages).
[23:27] <superm1> just make sure that they never actually put the distro in the changelog entry until it gets uploaded
[23:28] <persia> ArchiveReorganisation would help, but in the short term, having packaging in VCS makes it easier.
[23:28] <superm1> so most people should leave it as UNRELEASED, and then whoever has rights and does upload it makes that one change
[23:28] <LaserJock> a few of the packages do have vcs-imports so I have access to upstream code
[23:28] <LaserJock> but I'm wondering if it's easier to just put debian/ in VCS
[23:28] <persia> And all the packages have Debian packaging, but none of that is VCS, right?
[23:28] <LaserJock> hmm, most that I'm particularly interested in don't
[23:29] <LaserJock> there might be a few that do
[23:29] <persia> In that case, I'd recommend just putting debian/ in VCS for now.  Proper VCS packaging is lots easier than just debian/ in VCS, but the infrastructure isn't all there if you can't get a vcs-imports feed from Debian.
[23:30] <LaserJock> right
[23:30] <persia> So you'd do a commit for each change, including merges with Debian.
[23:31] <persia> When something is in sync, just shove the debdiff as a commit when autosync publishes to keep things sane.
[23:32] <LaserJock> yeah, none of the packages are really active in Debian, such that it would be very difficult to keep up
[23:33] <persia> From what I understand of future infrastructure, there should be generated branches of Debian upload history and Ubuntu upload history from which you can derive, which would allow for proper VCS packaging, but trying to replicate that manually is just going to be painful.
[23:33] <LaserJock> ok, sounds reasonable
[23:33] <LaserJock> does creating a packaging team seem decent?
[23:34] <persia> (and possibly generated branches from Debian VCS history, but that's only gravy)
[23:34] <LaserJock> I'm not sure if other projects are doing that
[23:35] <persia> On the strength of ArchiveReorgansiation alone, I'd advocate the creation of an Edubuntu-dev group.  If you end up with too many people in it, you can always create an Edubuntu-core-dev group, where -dev can commit to branches, and core-dev upload if you need.
[23:36] <persia> Personally, I'd recommend that people first interested be expected to submit some patches (perhaps preparing candidate branches for merging) first, and only after showing a history of good contributions be added to edubuntu-dev.
[23:36] <LaserJock> persia: heh, we have over 20 Edubuntu LP teams but no -dev
[23:36] <persia> Yeah.  You went crazy on teams a couple years ago :)
[23:37] <LaserJock> is there any decent ETA on ArchiveReorganisation ?
[23:39] <persia> None I've seen announced.  At one point a member of the TB suggested it would happen for Jaunty, but Jaunty opened.  I'm currently choosing to interpret that remark as "During the Jaunty cycle".
[23:40] <cjwatson> it's on my list but no ETA yet
[23:41] <cjwatson> there's a dependency on the Soyuz development roadmap which was given a high priority but I don't have an ETA on *that*
[23:42] <persia> cjwatson, On your list for implementation, or for more spec documentation?  What needs doing beyond Soyuz, process coordination, and TB confirmation of delegated groups?
[23:45] <cjwatson> persia: mostly implementation, although still need to sort out how apt and mirroring utilities are going to play with it
[23:47] <persia> Well, the quick & dirty way is to just semantically redefine "main", but that's probably not enough to preserve ogre-model style restrictions.
[23:48] <cjwatson> ogre-model is exactly the concern