[01:08] <EagleScreen> if I run dch -i, changelog is incremented for intrepid, and later package is built for intrepid, what must I do if I want to increment changelog for jaunty or unstable and to build the package for jaunty or unstable? I have chroots for each release created with pbuilder
[01:21] <jdong> EagleScreen: see -r for dch
[01:23] <EagleScreen> yes I see
[01:24] <EagleScreen> i think that with my actual configuration, debuild builds the package for the release typed in the changelog included if you typed it by hand
[01:26] <jdong> what configuration does that?
[01:26] <jdong> apart from a buildd-style setup
[01:26] <jdong> and all -r does is fill in that part of the changelog header with the release you want
[01:27] <jdong> it is fundamentally no different than typing it in by hand, other than saving a bit of arrow-key usage
[01:28] <EagleScreen> this configuration http://pastebin.ca/1326753
[01:28] <EagleScreen> it has a block to take the release from the changelog
[01:29] <jdong> nice, around line 30
[01:29] <jdong> then dch -r will do the trick
[01:29] <jdong> you can also set the DIST environment variable to override it
[01:31] <EagleScreen> i cannot understand the utility of -r argument
[01:32] <jdong> it's primarily useful for doing a changelog bump from a noninteractive script
[01:34] <EagleScreen> i think i am starting to understand this.. lol
[01:34] <jdong> lazy typers tend to benefit too ;-)
[01:34] <EagleScreen> but I note a difference between debian debuild and ubuntu debuild
[01:35] <EagleScreen> for instance, in debian, dch -i changes version from 0.3.2 to 0.3.2-1 and ubuntu to 0.3.2ubuntu1
[01:36] <jdong> right, because -1 is not a valid version number for an upload into Ubuntu
[01:36] <EagleScreen> if I build Debian native packages will it add ubuntu1 to the version string?
[01:36] <jdong> and Ubuntu's devscripts are designed for Ubuntu developers
[01:39] <EagleScreen> and Debian adds automatically +nmu (non mantainer update)
[01:56] <LordMetroid> Where does APT store information of downloaded package?
[02:03] <RAOF>  /var/lib/dpkg and /var/lib/apt
[02:04] <ion_> Also, /var/cache/apt/archives contains the downloaded packages themselves. Now please read the topic. :-)
[02:05] <RAOF> Is anyone looking at the gnome-desktop2, gnome-desktop-sharp2, tomboy & monodevelop situation?
[02:06] <EagleScreen> what happens when debuild gives me an error of build dependences, but the necessary dependence is in the repository why it does not satisfy the build-dependence?
[02:07] <andersk> debuild only looks at packages on the system; it does not install new packages for you.
[02:07] <andersk> You can install the build dependencies for a source package in the repository with `apt-get build-dep sourcepackage`,
[02:08] <andersk> or for an extracted package on disk with `/usr/lib/pbuilder/pbuilder-satisfydepends` (in the pbuilder package).
[02:08] <RAOF> gnome-desktop-sharp2 at least has a debdiff attached, and this is a prerequisite of fixing Tomboy.
[02:08] <EagleScreen> but i want to install build-deps in the pbuilder fakeroot and not in my real installation, is it possible?
[02:09] <RAOF> EagleScreen: Because you don't have the dependency installed.
[02:09] <RAOF> EagleScreen: debuild doesn't automatically install dependencies for you.
[02:09] <EagleScreen> then how can I install a package in the pbuilder fakeroot enviroment?
[02:10] <andersk> pbuilder will automatically install dependencies for you.  debuild will not.
[02:10] <andersk> Are you actually using pbuilder to run a build, or are you manually entering the chroot and running debuild?
[02:10] <EagleScreen> i used pbuilder to make the root eviroments
[02:11] <EagleScreen> the i must use pbuilder instead of debuild
[02:11] <EagleScreen> can pdebuild sustitute to debuild -b?
[02:11] <andersk> That should work.
[02:15] <EagleScreen> is it possible that launchpad ppa to fail building for use debuild -S to build without all build-dep installed in my system?
[02:17] <EagleScreen> I mean, must I use pbuilder to build source packages instead of debuild -S?
[02:17] <EagleScreen> can pbuilder buils source packages?
[02:21] <EagleScreen> why pbuilder didnt ask me for my PGP passphrase?
[02:27] <EagleScreen> pdebuilder provides a .deb package?
[02:27] <RAOF_> EagleScreen: pbuilder builds source packages, too, but if you just want to build a source package you (generally) don't need the build-depends installed.
[02:32] <EagleScreen> i want to build the .deb package
[02:32] <RAOF_> Well, then you either want pbuilder or to install the build-depends.
[02:33] <EagleScreen> pbuilder to install the dependences in the fake root enviroment
[02:33] <EagleScreen> but pbuilder is only buildding the source package
[02:35] <EagleScreen> pbuilder build *.dsc
[02:35] <RAOF_> No, it's building the binary package.  You might not know where the binary package that it's building _is_ (it's in /var/lib/pbuilder/result, IIRC), but it's building the binary package :)
[02:40] <EagleScreen> yes, they are there :D
[03:28] <EagleScreen> lintian:
[03:28] <EagleScreen> W: mount-systray source: out-of-date-standards-version 3.7.2 (current is 3.8.0)
[03:28] <EagleScreen> W: mount-systray source: native-package-with-dash-version
[03:29] <EagleScreen> what does it mean?
[03:31] <ion_> Pass -i to lintian
[04:41] <slangasek> tkamppeter_: please mind the alpha freeze
[06:44] <Hobbsee> cody-somerville: oh, really?  Why?
[06:47] <IntuitiveNipple> Would we consider ubiquity causing the kernel to *lose* a partition table entry as critical?
[06:50] <slangasek> IntuitiveNipple: causing the *kernel* to lose it?  Probably not.
[06:51] <slangasek> since the kernel is never supposed to overwrite the partition table, it presumably would reappear on reboot
[06:55] <IntuitiveNipple> I meant as in, the partition is lost from /proc/partitions and therefore ubiquity causes itself to fail if that partition is an installation target
[06:56] <IntuitiveNipple> I've been able to reproduce it with alpha 3 LiveCD and the Intrepid LiveCD installer - something to do with d-i/partman but the logs aren't time-stamping so I can't figure out exactly what is being done to cause it
[06:58] <slangasek> hmm
[06:58] <IntuitiveNipple> Indeed!
[06:58] <slangasek> if it's reproducible for you in intrepid, that's certainly a corner-case
[06:59] <slangasek> please file a bug on ubiquity with as much detail as possible, but I'm not, e.g., going to stop the presses on alpha-4 for such an issue
[06:59] <IntuitiveNipple> I'm working through the source right now, but it's not enlightening me
[06:59] <IntuitiveNipple> It could be described with two headings, as you'll see: bug #324987
[07:02] <slangasek> bryce, tjaalton: I notice we have some bugs about touchpad toggling not working through acpi-support - looks like synclient doesn't work, SHMConfig disabled, yadda yadda - do you know what the right way is to fix this?
[07:07] <Amaranth> ooh, can I get my touchpad back please? :)
[07:08] <slangasek> Amaranth: "toggle" - different issue
[07:08] <slangasek> Amaranth: what hardware do you have, what version of xserver-xorg-input-synaptics do you have installed?
[07:08] <slangasek> Amaranth: also, when did it stop working?
[07:09] <Amaranth> wow i totally don't have that package installed
[07:09] <slangasek> heh
[07:09] <slangasek> then that explains your touchpad not working ;)
[07:09] <Amaranth> it stopped working when half way through my jaunty install (daily from the 1st) ubiquity crashed :/
[07:09] <slangasek> ah
[07:09] <Amaranth> forgot to collect the logs for that one, I panic'ed and just made my system work
[07:10] <slangasek> good, thank you for /not/ confirming the kernel bug that the kernel team have been panicking about since last night :-)
[07:11] <tjaalton> slangasek: I'm not familiar with that one, what should it do exactly?
[07:11]  * tjaalton has no touchpad
[07:12] <slangasek> tjaalton: ah.  various laptops have a hotkey that's supposed to toggle the touchpad - an easy way to disable it if it's getting in your way while typing
[07:12] <tjaalton> slangasek: oh, ok. xinput can disable it but you'd have to know the device id
[07:12] <slangasek> tjaalton: but it uses synclient, which does this:
[07:12] <slangasek> $ synclient TouchpadOff=1
[07:12] <slangasek> Can't access shared memory area. SHMConfig disabled?
[07:12] <slangasek> tjaalton: oh interesting!  How does the disabling work?
[07:12] <slangasek> because that would be way better
[07:13] <tjaalton> 'xinput list' shows the input devices, 'list-props N' lists the properties that the device has
[07:14] <tjaalton> N can be the numerical id or the full name
[07:14] <slangasek> tjaalton: sure; I actually assume we'll be walking the hal tree for this, since it's in fact hal that should be handling the keypress itself in the new world order, and hal already has the info about that :)
[07:14] <slangasek> but what's the command to actually disable the input device?
[07:15] <tjaalton> slangasek: 'xinput set-int-prop N 'Device Enabled' 8 0
[07:15] <tjaalton> or something like that
[07:15] <slangasek> awesome
[07:16]  * slangasek hugs tjaalton :)
[07:16] <tjaalton> heh
[07:16] <tjaalton> been there since intrepid ;)
[07:16] <tjaalton> synaptics 1.0 supports float properties too
[07:17] <slangasek> sorry, I'm just excited that we don't need to use synclient anymore, which has never been reliable :)
[07:17] <tjaalton> so SHMConfig is pretty much obsolete
[07:17] <slangasek> yeah
[07:17] <tjaalton> now all that's needed is a pretty GUI for all of this, not just touchpads but mice too
[07:17]  * slangasek nods
[07:17] <tjaalton> and preferably integrated to the DE capplet
[07:18] <tjaalton> because the settings aren't persistent, but with gconf/g-s-d that should be covered (and the same for KDE counterparts)
[07:19] <slangasek> sure
[07:19] <slangasek> in that case, maybe it would be g-s-d itself that should handle the event, with hal just emitting it on the bus
[07:20] <tjaalton> it's also annoying that you can't assign just a mouse button as a shortcut.. my mouse has a number of buttons that are useless right now
[08:58] <pitti> bdmurray: calibre 0.4.133 uploaded
[09:13] <slangasek> superm1: mythbuntu-desktop is currently uninstallable, prevents alpha-4 builds
[09:15] <directhex> alpha 4? it's that time already?
[09:18] <slangasek> yes
[09:18] <IntuitiveNipple> How can I execute the Crash-Report tool manually? It just failed to upload a crash report that occurred when running the hwtest, so I wanted to try resending the report
[09:19] <pitti> IntuitiveNipple: go to /var/crash in nautilus and click on it
[09:20] <IntuitiveNipple> thanks
[09:20] <pitti> IntuitiveNipple: or, if you are CLI oriented, /usr/share/apport/apport-gtk -c /path/to/crash/file
[09:20] <IntuitiveNipple> that's more like it ... thanks!
[09:21] <IntuitiveNipple> Hmmmm... and again "urlopen error The write operation timed out"
[09:27] <slangasek> superm1: because libmyth-0.21-0 depends on a non-existent libx264-59 package?
[09:29] <slangasek> superm1: ... which seems to have been NBSed out, so libmyth-0.21-0 needs a rebuild
 :)
[09:34] <pitti> calc: http://qa.ubuntu.com/reports/ogasawara/pet-buglist.html
[09:34] <calc> thanks
[09:57] <slangasek> bryce_, tjaalton: eh, xserver-xorg no longer depends on xserver-xorg-input-all, which means we don't get -synaptics installed?
[09:58] <slangasek> bryce_, tjaalton: can I presume to upload a fixed xserver-xorg that depends on both -evdev and -synaptics, or is there something else we should be doing here?
[09:59] <tjaalton> slangasek: it does
[09:59] <slangasek> hmm?
[09:59] <slangasek> tjaalton: the only input package on the liveCD today in -evdev
[10:01] <tjaalton> well, that satisfies 'x-x-i-all | x-x-i-4'..
[10:01] <tjaalton> which is why -all isn't pulled
[10:01] <tjaalton> +probaly
[10:01] <tjaalton> +b
[10:01] <tjaalton> (damn
[10:01] <tjaalton> it's been like that on intrepid too
[10:02] <slangasek> tjaalton: the intrepid version depends on -all.  the jaunty version *doesn't* - IIRC because of a wacom problem earlier in the cycle
[10:02] <slangasek> I think it was you that I had this conversation with? :)
[10:03] <slangasek> oh, no, that was dropping vmmouse from -input-all, that's different
[10:03] <tjaalton> yes
[10:03] <slangasek> oh, haha
[10:03] <slangasek> I see
[10:03] <slangasek> Depends: xserver-xorg-input-evdev, xserver-xorg-input-all | xserver-xorg-input-4
[10:03] <slangasek> right - can we try reversing the order of those dependencies in debian/control?
[10:04] <tjaalton> sure
[10:04] <slangasek> shall I do it, or would you like to?
[10:04] <tjaalton> I can do it
[10:04] <slangasek> ok, thanks
[10:09] <tjaalton> slangasek: uploaded
[10:28] <slangasek> tjaalton: cheers
[10:30] <slangasek> superm1: ok, mythtv uploaded for a no-change rebuild; I believe I don't have commit access to the bzr repo though
[10:37] <slangasek> superm1: ah, except that source changes are needed for the new x264 after all :-(  so I'll wait for you for further guidance
[10:49] <lool> ScottK-desktop: No, mesa isn't misbuilt; it's just that libdrm-dev should guarantee you get the drm headers
[10:50] <ScottK> lool: OK.  Just checking as I didn't have the background.  I spent most of last night coaxing KDE to build on lpia and I'd hate for it to have been for nought.
[10:50] <ScottK> lool: Thanks.
[11:10] <lool> ScottK: How is KDE looking on lpia/armel these days?  (I mean in terms of builds; I don't expect you to run that :)
[11:11] <lool> slomo_: Poke
[11:11] <ScottK> Up until the kernel upload yesterday we were literally dead on lpia because nothing would build.
[11:11] <lool> slomo_: I'd like to drop the always satisfied version in the sda -> notification-daemon dependency as it prevents an alternate implementation to Provide notification-daemon with sda installed
[11:11] <ScottK> Now lpia in Main is fully built.
[11:12] <lool> ScottK: I guess it's the same on all linux-ports arches then?
[11:12] <lool> (ppc, sparc, hppa, ia64...)
[11:12] <ScottK> Except armel, yes.
[11:12] <ScottK> armel had some other transient problem that seems to have passed and I'm retrying stuff now.
[11:12] <lool> Yeah, armel is built by linux so it's up-to-date
[11:12] <lool> ScottK: Great
[11:12] <ScottK> kde4libs on armel built, so likely the rest of the stack will be ok.
[11:13] <ScottK> Because of boost -> boost1.35 I need to do a main upload before I can finish universe stuff so that'll have to wait until after the alpha.
[11:14] <ScottK> So rapidly moving from really bad to pretty good is how I'd sum it up.
[11:14] <ogra> YokoZar, are you around by chance ?
[11:14] <lool> Hmm right boost broke lots of stuff
[11:14] <lool> Oh I'm uploaded or sda
[11:14] <lool> slomo_: I don't remember whether we have a Vcs for sda
[11:15] <lool> *uploader
[11:17] <dholbach> seb128: pedro_ wants to know hof often you already heard "iz gtk boog"
[11:18] <directhex> if someone were to show some love to 323790, then i could prepare one final app package & sign off on the mono 2.0 app transition as done (leaving only libs and tweaks, which are where space savings will suddenly happen)
[11:22] <slangasek> jelmer: why is bzr 1.11 in experimental instead of in unstable? :)
[11:28] <TheMuso> tjaalton: Turns out that the multifinger patch that tseliot got included in a recent synaptics upload breaks the expected behavior for my touchpad. I now have to use thre fingers instead of two fingers for right-click.
[11:28] <TheMuso> three even'
[11:28] <tseliot> TheMuso: in which version of the driver?
[11:28] <tseliot> version and revision
[11:30] <TheMuso> tseliot: i'll get back to you on that, about to head off for lunch.
[11:31] <tseliot> TheMuso: ok
[11:34] <lool> slomo_: Hmm can't find the sda tarball in the upstream location indicated in copyright
[11:42] <lool> StevenK: [ "$foo" = ${foo/*\///} ]
[11:42] <lool> I'm not particularly proud of that though
[12:32] <TheMuso> tseliot: 0.99.3-2ubuntu2, which is the latest revision. If I drop 105 correct multifinger patch, my touchad works as expected, only two fingers and button click needed for right clicking.
[12:33] <TheMuso> tseliot: I built the package without that patch and things work as I expected them.
[12:34] <tseliot> TheMuso, tjaalton: ok, let's drop patch 105 then
[12:40] <TheMuso> tseliot: Won't that break things again for other people?
[12:41] <directhex> hm, yet more mouse annoyances. if even linux has useful config additions to gnome rejected, is there any point in trying myself?
[12:41] <directhex> s/linux/linus/
[12:41] <tseliot> TheMuso: no, I don't think so. The other patches I added solved their problems.
[12:42] <tseliot> directhex: ?
[12:42] <tjaalton> tseliot: the changelog says that 105 fixes bug 320632
[12:43] <tseliot> let me check
[12:43] <directhex> apple live in a world of 1 button, gnome lives in a world of 3 buttons. if you happen to have more than three, then it's config file city to try & convince the system to use them properly (be it xmodmap or xorg.conf). it would be nice if "use my side buttons for back/forward plz" wasn't a chore to do
[12:43] <tseliot> tjaalton: yes because it undos what my previous patch did ;)
[12:44] <tseliot> undoes
[12:44] <Mithrandir> directhex: doesn't that Just Work now?
[12:45] <tseliot> directhex: I'm working on a daemon which will allow users to save their settings (applied through xinput)
[12:45] <directhex> Mithrandir, as long as you own the same mouse as the guy who implemented it, it works great. otherwise, you can expect muddled key mappings
[12:45] <directhex> Mithrandir, as an example, back/forward appear to be mapped to tilt-mouse-left/right here, not to back/forward
[12:46] <Mithrandir> directhex: hm, maybe I've just been lucky.
[12:46] <Mithrandir> on the other hand, mouse-wheel-tilt doesn't seem to work with my mx400
[12:46] <directhex> Mithrandir, it's an improvement on hardy where tilting the mouse caused xorg to segv
[12:47] <tjaalton> I'd like to be able to assign shortcuts to the buttons
[12:48] <directhex> so this is a ms wireless laser 6000, and back/forward are mapped to the mouse wheel tilt - the mouse wheel has poor response as it is, so accidental tilting is common (and therefore so is accidental b/f)
[12:48] <directhex> at home, my new razer lachesis has the side buttons act as b/f as expected - except they're swapped round from how they should be
[12:50] <directhex> actually, the lachesis has other issues under loonicks, basically because the buttons are hardware-mappable & by default 4 buttons have bindings pre-encoded
[12:50] <directhex> i should ask them for hints on making a control panel thing for it
[12:53]  * tseliot > lunch
[13:42]  * lamont wonders which intrepid (or even hardy-updates) update broke msdund support in bluetooth
[13:44] <lamont> doh.  nevermind
[13:45] <ScottK> In intrepid I'll go for bluez 3 -> 4 transition
[13:50] <lamont> yeah - in hardy, it was plugging the bluetooth adapter into a 1.x hub downstream of the system connectors. :(
[13:50] <lamont> and there's an intrepid bug wrt not being able to force a PIN for the remote device or some such
[13:51] <kagou> Hi, is there a tool to report information of launched xorg ? (driver/dpi/resolution/option etc.)
[13:53] <slangasek> kagou: if you're filing a new bug, 'ubuntu-bug xorg'
[13:54] <kagou> slangasek, excellent ! Thanks
[14:12] <primes2h> pitti: I uploaded debdiff for gnome-icon-theme for this bug #172353. Tell me if it's ok.
[14:41] <Notch-1> hi, i've created a script in /etc/initramfs-tools/scripts/local-top/, but it seems to run 2 times, does anybody know why?
[14:51] <pitti> primes2h: can you please assign the task to me?
[14:52] <pitti> bdmurray: what was the other "dead" hotkey for you (not KEY_DVD)?
 if someone were to show some love to 323790, then i could prepare one final app package & sign off on the mono 2.0 app transition as done (leaving only libs and tweaks, which are where space savings will suddenly happen)
[14:53] <NCommander> TheMuso, ping?
[14:53] <primes2h> pitti: Done.
[14:54] <calc> what is DeadUbuntu?
[14:54] <primes2h> pitti: Thanks
[14:54] <pochu> bug 323790
[14:54] <pitti> primes2h: thanks
[14:54]  * calc thought it was a group for dead users but apparently they are alive
[14:57] <bryce_> calc, maybe undead?
[14:58] <bdmurray> pitti: KEY_PLAYER
[14:58] <pitti> bdmurray: ah, thanks
[15:15] <pitti> slangasek: would you mind if I upload a new hal-info which fixes some keycodes? (doesn't matter if it doesn't land in a4); or should I rather stall it?
[15:21] <slangasek> pitti: go ahead, you're in the seb128 upload window :)
[15:23] <jelmer> slangasek, lenny freeze
[15:25] <slangasek> jelmer: but that doesn't forbid uploads to unstable of leaf packages... :)
[15:26] <jelmer> slangasek, I asked dato about this a bit earlier and he asked me to upload to experimental during the freeze to keep unstable (rather than t-p-u) open for uploads that had to go into testing
[15:29] <directhex> that's been our policy in the mono team
[15:29] <directhex> since t-p-u sucks
[15:37] <superm1> slangasek, <shrug> i'll take a look in a little bit here about it.  in the event that it can't be sorted out easily, can the 2-3-9 disks be marked for a4?
[15:37] <superm1> if it's requiring source changes due to libx264 stuff, i just worry a little that it might be more involved
[15:43] <slangasek> superm1: the biggest reason I wouldn't want to release those as alpha-4 is that you'd be missing ubiquity fixes that all the other flavors have; I'm happy to roll a slightly-later mythbuntu once mythtv is building again? (http://qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/mythbuntu-amd64-desktop.html)
[15:44] <superm1> slangasek, ah that's a bit more than i expected in delta over the last day.  hopefully the x264 changes aren't too invasive then. i'll see
[15:55] <jelmer> slangasek, btw, did you see my message about the upgraded ubuntu-grub branch?
[15:55] <jelmer> now if only subvertpy would get through NEW so I can request a sync for jaunty...
[15:55] <slangasek> jelmer: yes, but I guess you didn't see mine, asking how I'm supposed to get your stuff into the official tree :)
[15:55] <slangasek> do I delete the branch currently there, and branch from yours to ubuntu-core-dev?
[15:56] <jelmer> slangasek, just "bzr push -d lp:~jelmer/grub/ubuntu --overwrite lp:~ubuntu-core/dev/grub/ubuntu" should do it
[15:56] <slangasek> ok
[15:57] <jelmer> ubuntu-core-dev rather than ubuntu-core/dev obviously
[16:02] <directhex> jelmer, welcome to NEW, please enjoy your stay
[16:03] <jelmer> directhex, :-) It's not as bad anymore as it used to be though
[16:03] <directhex> jelmer, really? how bad did it used to be? i think 200 packages queued, and a 4 week turnaround, are pretty bad
[16:07] <jelmer> directhex, I've waited up to two months in the past I think, and it's release time atm
[16:07] <jelmer> directhex, maybe I'm just getting used to it...
[16:08] <directhex> jelmer, when you only release a dist every 2-3 years, perhaps a 1-month NEW time seems fast :p
[16:09] <slangasek> jelmer: bzr: ERROR: Cannot lock LockDir(bzr+ssh://bazaar.launchpad.net/%7Ejelmer/grub/ubuntu/.bzr/branch/lock): Transport operation not possible: readonly transport
[16:10] <jelmer> slangasek: Looks like you'll have to make a copy of my branch locally first, sorry :-/
[16:10] <jelmer> slangasek, after that you should be able to "bzr push --overwrite" to the ubuntu-core-dev branch
[16:10] <slangasek> ack
[16:10] <jelmer> I'll file a bug about "bzr push -d " with remote branches, there's really no reason that shouldn't work
[16:24] <kirkland> Riddell: what was the kubuntu sound package you told me to install to override k3b's annoying sound notifications?
[16:24] <Riddell> kirkland: kubuntu-default-settings
[16:24] <kirkland> Riddell: cheers, thx
[16:27] <slangasek> jelmer: all done now, thanks!
[16:28] <directhex> plinketty plinka plinketty plinka plinketty plinka plink plonk!
[16:28] <directhex> sorry, kde flashback for a moment
[16:30] <jelmer> directhex, otoh, REVU isn't very quick atm either
[16:31] <directhex> jelmer, if you want to go down THAT road, take a look at the slowness of Mentors
[16:31] <directhex> jelmer, some mono-related packages were removed from testing yet fixes were in mentors for months
[16:31] <jelmer> directhex, oh, I wasn't aware of that
[16:33] <jelmer> directhex, being able to find sponsors in Debian is much related to the sort of package you're uploading
[16:33] <directhex> jelmer, yep
[16:33] <directhex> jelmer, a bit like finding people to ACK syncs/merges in here ;)
[16:33] <jelmer> directhex, mono-related packages seem to be a problematic kind, I've always had problems finding mentors for mine as well when I was not yet a DD
[16:34] <directhex> jelmer, certain FUD campaigns are depressingly effective
[16:35] <broonie> Well, there's also the general reluctance to faff about with packages for a software stack you don't understand.
[16:35] <directhex> broonie, which largely comes down to questions of trust & accountability
[16:35] <broonie> yup
[16:36] <directhex> not wanting to be blamed for errors introduced in a package you ack'd
[16:40] <directhex> at least, i hope that's the reasoning used, it's preferable to "you smell bad"
[16:41] <jdong> :)
[16:41] <jdong> you haven't got the "I hate streaming video" comments? :)
[16:42] <directhex> jdong, which package are we talking about now? o_o
[16:42] <jdong> directhex: btw do we have a Mono 2.2-ish PPA for Intrepid?
[16:42] <jdong> I've been spending a bit of this morning compiling the stack in a local prefix
[16:42] <directhex> jdong, no. all cycles being burned on 2.0-related tasks, and 2.2 breaks a LOT of apps
[16:42] <jdong> directhex: ok, understandable
[16:42] <directhex> perhaps "breaks" should be "increases compiler rigour and therefore requires patching of" but still
[16:43] <directhex> t'is the reason jaunty will have 2.0.1 not 2.2
[16:43] <jdong> I need some 2.2-ish features for some stuff I'm doing for work, so I'll just continue on my way :)
[16:43] <directhex> carry on! /me waves his hand dismissively
[16:43] <jdong> lol
[16:43] <directhex> of course, you could always sync mono 2.0.1-4 if you wanted to. that'd help
[16:44] <jdong> haha well I don't have a direct charge account for doing that which pays $37.50/hr :)
[16:44] <directhex> syncing from debian isn't a job, it's a calling! a solemn duty!
[16:44] <jdong> yes but putting food on the table helps with syncing from debian with fewer errors :)
[16:56] <orospakr> I hope this is the right channel to ask this, but I have a package checked out from the package-import bazaar repositories, and I would like to build it using pbuilder.  However, the .dsc and orig tarballs are nowhere to be found inside the tree.
[16:56] <orospakr> The DistributedDevelopment wiki pages only suggest using bzr builddeb.
[16:58] <james_w> orospakr: "bzr builddeb -S" will create a source package for you to build in pbuilder
[16:59] <surfaz> Can anyone look at this issue?
[16:59] <surfaz> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-February/006818.html
[17:02] <orospakr> james_w, thanks!
[17:09] <slangasek> jelmer: hrm, 'bzr merge svn://svn.debian.org/pkg-grub/grub/trunk' still gives me a 'no common ancestor' error?  Did my overwrite of the ~ubuntu-core-dev branch not work as intended?
[17:10] <jelmer> slangasek, you need to merge svn://svn.debian.org/pkg-grub/grub/trunk/debian
[17:12] <slangasek> jelmer: oh!  trying :)
[17:16] <hyperair> does anybody know where software-properties gets its list of mirrors from?
[17:18] <slangasek> jelmer: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. :(
[17:19] <jelmer> slangasek, are you using bzr-svn 0.5 ?
[17:19] <glatzor> hyperair, yes me. The list is part of python-apt
 no, did you tell me to? :-)
[17:20] <hyperair> glatzor: thanks, i'll poke around in there
[17:20] <glatzor> hyperair, There is already code in software-properties to add custom mirrors easily, but I haven't yet found the time to complete this feature
[17:20] <hyperair> glatzor: dyou know if it's possible to add a custom mirror? right now if i dist-upgrade, i have to hack around it by adding a /etc/hosts entry that points to localhost, and use mod_proxy to get the server i want
[17:20] <tseliot> Keybuk: do you know why this dbus call fails? http://pastebin.com/d3c811f58 (I get "The name org.x.config.display0 was not provided by any .service files")
[17:20] <hyperair> glatzor: ah faster than me
[17:21] <hyperair> glatzor: heheh
[17:21] <hyperair> for now i guess i'll dpkg-divert it or something
[17:22] <glatzor> hyperair, why do you need to change it to localhost?
[17:23] <hyperair> glatzor: because the whole dist-upgrade process doesn't recognize my on-lan archive mirror
[17:23] <hyperair> glatzor: i'm an archive mirror admin in my campus network, and it actually uses that to upgrade, i can upgrade at 10MB/s
[17:24] <hyperair> glatzor: to upgrade from hardy to intrepid that's what i did. i set the mirror to sg.archive.ubuntu.com, added a /etc/hosts entry to point sg.archive.ubuntu.com back to my comp, and then used apache2 + mod_proxy to forward requests to ntuoss1.uni.cx
[17:24] <jelmer> slangasek, Sorry :-) It's available from the bzr PPA
[17:25] <jelmer> (https://edge.launchpad.net/~bzr/+archive/ppa)
[17:29] <glatzor> hyperair, you should fill a bug to update-manager to easily allow to custom mirrors
[17:29] <glatzor> hyperair, mvo is the author of the upgrade tool
[17:29] <hyperair> glatzor: but weren't you working on it?
[17:29] <glatzor> hyperair, software-properties is not the same as the upgrade tool
[17:30] <glatzor> the later one is part of update-manager
[17:30] <glatzor> hyperair, please could you fill a bug on python-apt too?
[17:31] <glatzor> hyperair, I will investigate how far the support of custom mirrors is. I worked on it 2 years ago
[17:32] <hyperair> so long? =(
[17:32] <hyperair> what are the package names?
[17:32] <tseliot> Keybuk: never mind
[17:33] <hyperair> glatzor: imo the reason the upgrade tool couldn't support custom mirrors is because there's no real way to identify whether a mirror is an official archives mirror or just some random 3rd-party mirror
[17:34] <glatzor> hyperair, AFAIK it does detect a vailid mirror by taking the mirror list of python-apt into account
[17:34] <hyperair> glatzor: but that's only the python-apt mirror list
[17:34] <hyperair> glatzor: that does not include custom mirrors
[17:35] <hyperair> glatzor: the problem was that my mirror is not in the mirror list
[17:35] <glatzor> hyperair, right. that is why you need the custom mirror support on python-apt level
[17:35] <hyperair> yep
[17:35] <hyperair> which means that if python-apt supported it, everything else above it would work wonderfully
[17:35] <hyperair> glatzor: right?
[17:36] <glatzor> hyperair, I think so
[17:41] <hyperair> glatzor: https://code.launchpad.net/~madjar/python-apt/custom-mirror <-- this?
[17:44] <hyperair> glatzor: so i added http://ntuoss1.uni.cx/ubuntu/ to the list of mirrors in /usr/share/python-apt/templates/Ubuntu.mirrors, but it doesn't seem to work eh =\
[18:07] <directhex> tseliot, can you tell me more about this mouse daemon of yours?
[18:12] <tseliot> directhex: it's a dbus daemon which will use xinput and its methods will be accessible from any language through dbus. This daemon will also be able to read and apply settings from a configuration file
[18:13] <directhex> and in this instance, we're talking about abusing set-button-map ?
[18:14] <tseliot> directhex: ? It will be able to do whatever xinput can do
[18:15] <directhex> hm, interesting
[18:15] <directhex> does this exist yet, or is it all planning-stages?
[18:16] <tseliot> directhex: I'm experimenting a bit in these days
[18:17] <directhex> i'm taking a look at this new mouse, and wondering how to unlock the most advanced features
[18:17] <directhex> i'm thinking i might need a usb bus sniffer on windows to start analysing
[18:17] <directhex> but still, your xinput daemon sounds nifty. i'd like to get my hands on that
[18:17] <directhex> though it's lower priority than a new nvidia 180 in intrepid ;)
[18:53] <orospakr> perhaps I should ask a different question:  how is a .dsc typically generated from the debian/ packaging directory, without actually running a build?
[18:54] <pochu> orospakr: dpkg-buildpackage -S
[18:54] <maxb> (This does run debian/rules clean, though)
[18:54] <orospakr> maxb, yup, that seems to be what bzr db is doing
[18:55] <orospakr> same problem -- dependencies are checked on my host Ubuntu install.
[18:55] <pochu> so
[18:55] <orospakr> normally I would take the path of least resistance and not bother using pbuilder, but I am trying to backport a package to Hardy.
[18:55] <pochu> dpkg-source -b package-1.0/
[19:01] <orospakr> oohl, I think that's what I'm looking for!
[19:01] <orospakr> s/oohl/ooh/
[19:01] <lamont> scanimage --list-devices
[19:01] <lamont> device `v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
[19:01] <lamont> ^^  GAH how do I get that to actually, say, CONTINUE AND FIND THE SCANNER?
[19:06] <orospakr> pochu, it worked!
[19:07] <pochu> great :)
[19:25] <hyperair> aha
[19:25] <hyperair> python-apt doesn't support servers with numbers in their hostname!
[19:25] <hyperair> so that's why adding an address woudln't work
[19:30] <pochu> hyperair: jaunty? I think they should work since 0.7.9~exp2ubuntu1
[19:30] <pochu>   * aptsources/distinfo.py:
[19:30] <pochu>     - fix too restrictive mirror url check
[19:30] <hyperair> pochu: yeah, i just saw the bug
[19:30] <hyperair> pochu: but i'm on intrepid =\
[19:31] <pochu> the fix is trivial
[19:31] <pochu> -        match_mirror_line = re.compile(r"^(#LOC:.+)|(((http)|(ftp)|(rsync)|(file)|(https))://[A-Za-z/\.:\-_]+)$")
[19:31] <hyperair> yeah it is
[19:31] <pochu> +        match_mirror_line = re.compile(r"^(#LOC:.+)|(((http)|(ftp)|(rsync)|(file)|(https))://[A-Za-z0-9/\.:\-_]+)$")
[19:31] <hyperair> i know
[19:31] <hyperair> i know
[19:31] <hyperair> i already fixed it on my system
[19:31] <pochu> ah ok :)
[19:31] <hyperair> but the impact is great isn't it
[19:31] <hyperair> wonder if it would be considered for an SRU
[19:32] <pochu> it probably isn't, otherwise it would have been noticed long time ago ;)
[19:32] <hyperair> hmm
[19:32] <hyperair> treu
[19:32] <hyperair> true*
[19:32] <pochu> I asked mvo and he told me he didn't think it was worth it
[19:32] <hyperair> but all the numbered mirrors are missingfrom the list
[19:32] <hyperair> ah
[19:32] <pochu> but that if I wanted to prepare one, it could be considered
[19:32] <hyperair> not even if someone else prepares the SRU debdiff?
[19:32] <hyperair> ah
[19:32] <hyperair> i see
[19:33] <hyperair> i was considering preparing it myself but seems you're first ;)
[19:33] <hyperair> oh yeah, what does it take for mirrors to be added to the list?
[19:33] <hyperair> Ubuntu.mirrors that is
[19:33] <pochu> oh no, I'm not doing it. Feel free to do it yourself ;)
[19:33] <directhex> usb protocol analysis seems to be hard
[19:34] <hyperair> directhex: sure it is. i went through hell just trying to figure out what some USB hex key codes meant, and that's just the tip of the iceberg
[19:35] <hyperair> pochu: <hyperair> oh yeah, what does it take for mirrors to be added to the Ubuntu.mirrors list?
[19:35] <directhex> hyperair, to what end?
[19:35] <hyperair> directhex: i scrolled through the damn docs multiple times
[19:35] <hyperair> and in the end gave up
[19:35] <hyperair> it wouldn't work anyway
[19:35] <hyperair> i was trying to do the bluetooth profile thing for sony ericsson
[19:35] <hyperair> make one for global keyboard shortcuts
[19:35] <hyperair> but it failed miserably in the end
[19:38] <orospakr> OK, this is strange: pbuilder is failing with "Depends: mozilla-dev (>= 1.1.12) but it is not installable".  However, if I run pbuilder --login and attempt to install that package directly with apt-get, it's fine.
[19:41] <pochu> orospakr: is it a real package or a virtual one?
[19:41] <pochu> orospakr: btw, #ubuntu-motu sounds more appropriate :)
[19:41] <orospakr> pochu, fair enough ;)
[19:42] <orospakr> although to answer your question, yes, it's a virtual package.  I should probably just use the real one it points to, heh. thanks for the tip. :)
[19:58] <hyperair> pochu: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/223097 <-- uploaded debdiffs
[19:59] <hyperair> pochu: could you take a look and give an ack by any chance?
[20:00] <pochu> hyperair: I'm not a core-dev unfortunately ;) but I'm looking at it
[20:01] <hyperair> pochu: okay
[20:01] <pochu> hyperair: I think you can patch the source directly, it's a native package
[20:01] <pochu> no need to use a patch system ;)
[20:01] <hyperair> ah
[20:01] <pochu> otherwise looks good (you could also say in the changelog that it also allows numbers)
[20:01] <hyperair> eh didn't i?
[20:02] <pochu> only for "@" ;)
[20:02] <ScottK> Yes.  Don't use a patch system in a native pacakge.
[20:02] <pochu> oh
[20:02] <pochu> you did mention numbers too :-) nvm
[20:02] <hyperair> +  * debian/patches/01_less-restrictive-uris.patch:
[20:02] <hyperair> +    + Allow @ and numbers in mirror URIs (LP: #223097)
[20:02] <hyperair> hahah
[20:02] <pochu> I'm blind :P
[20:02] <pochu> too many hours in front of the screen, you know ;)
[20:07] <hyperair> pochu, ScottK: i'm done. no patchsys now =)
[20:16] <pochu> hyperair: cool. :)
[20:18] <hyperair> pochu: =)
[20:33] <Davedan>  I'm installing a package with apt-get install. If this package has config files, can I find out where these files are using a script?
[20:34] <maxb> Davedan: Please read the topic and note that usage questions are very much not on topic here
[20:44]  * directhex still thinks dealing with bug 323790 is a great use of time for only the sexiest of core devs
[20:46] <ScottK> directhex: It won't get done until after the Alpha 4 freeze is over anyway, so no rush.
[20:47] <directhex> ScottK, hm, is freeze on? when's that over?
[20:47] <ScottK> directhex: Yes.  As is mentioned in /topic.  When Alpha 4 is released, probably Thursdayish.
[20:48] <directhex> i don't have a big enough monitor for /topic. that's my excuse & i'm sticking with it
[20:49] <davmor2> ScottK: You of course meant to say Thursday afternoon then didn't you ;)
[20:49] <ScottK> No.  It's scheduled for Thursday, but it's done when it's done.
[20:50] <ScottK> So Thursdayish seems about right.
[20:50] <ScottK> Sometimes it's Friday.
[20:51] <davmor2> ScottK: ah but no-one has called for a re-spin yet and I'm nearly at the point at which there is on netboot to go which I can churn out in a morning :)
[20:51] <davmor2> s/on/only
[20:52] <ScottK> Odds are it'll be Thursday afternoon somewhere.
[20:52] <davmor2> I can go with that :)
[21:29] <sven777> hi there - which files should be uploaded to MOTU for a brand new package?  (I'm new  :)  )
[21:30] <sven777> oops - should I ask in #ubuntu-motu ?
[21:36] <sven777> nm - received answer - thx :)
[21:40] <tjaalton> pitti: re: new hal-info; actually XI2 will allow X to use keycodes >255, so maybe for jaunty+1
[21:42] <pitti> tjaalton: ah, good to know
[23:21] <Hobbsee> drat.  the power off button, even on a locked screen, turns off my computer.
[23:24] <lifeless> Hobbsee: you'd rather it didn't?
[23:24] <Hobbsee> lifeless: well, yes.  i'd expect lock screen to actually lock the screen, and not do anything with any keypress (except magic sysrq and such, i guess), until it gets the p/w again
[23:25] <lifeless> oh, you're talking about a soft power button ?
[23:26]  * Hobbsee was meaning the power button that she accidently tapped once, on her laptop.  not sure if i'ts soft or hard?
[23:26] <lifeless> if hitting 'might' turn the machine off, its soft
[23:26] <lifeless> if hitting it always turns it off, its hard
[23:26] <lifeless> a circuit breaker is a hard power switch :)
[23:26] <Hobbsee> ah, i see.
[23:26]  * Hobbsee hasn't tried it multiple times
[23:27] <lifeless> most new machines have software power buttons these days, I was really just being silly ;P
[23:27] <Hobbsee> ahhh
[23:27] <Hobbsee> no wonder i'm getting confused!
[23:28] <lifeless> mission impossible....success
[23:28]  * ScottK watches lifeless push Hobbsee's buttons several time.
[23:28] <lifeless> ScottK: this room is a tad public for that
[23:29]  * lifeless ducks
[23:29]  * ScottK steps away from lifeless
[23:29] <Hobbsee> well, that's not hard.  I *did* boot to KDE after accidently shutting down gnome today
[23:29] <ScottK> ;-)
[23:29] <lifeless> I don't know you anymore
[23:31] <lifeless> Hobbsee: btw, we should have another syd-motu-dinner
[23:31] <lifeless> Hobbsee: I have nearly forgotten the taste of that indian
[23:32] <Hobbsee> lifeless: mmmm....agreed!
[23:32] <Hobbsee> lifeless: late feb, or so?
[23:32] <lifeless> sounds good