[00:30] <TheMuso> c/
[01:02] <superm1> StevenK, i'm not convinced that you uploaded everything that you had done test builds for for bug 276343
[01:03] <superm1> i was just randomly looking at anyremote and saw it doesn't have one done
[01:03] <james_w> thanks Riddell
[01:03] <StevenK> superm1: I uploaded everything that was listed I had uploaded in the PPA
[01:03] <superm1> StevenK, hum then.
[01:04] <StevenK> However, I can see no anyremote upload
[01:04] <StevenK> Hm. Someone removed anyremote from the PPA
[01:06] <StevenK> superm1: Uploading anyremote now. Yes, I put the bug number in
[01:06] <superm1> StevenK, okay good thx.
[01:06] <superm1> StevenK, i've not gone through and checked the others yet, so maybe there are more like that too. i'm not sure
[01:07]  * ajmitch was going to upload rezound for the libcupsys2 stuff, but it just decided to FTBFS instead
[01:07] <StevenK> superm1: I thought I did everything that had my name next to it on the PPA, but if I've missed more, please poke me
[01:07] <superm1> StevenK, okay i'll take a look later today or tomorrow
[01:08] <superm1> StevenK, although i'd expect the results of apt-cache rdepends libbluetooth2 are accurate
[01:08] <superm1> StevenK, meaning those are ones that are missing yet
[01:13] <StevenK> superm1: Oh, right. It should show up in NBS too
[01:13]  * StevenK pokes
[01:13] <jdong> *cry*
[01:13] <jdong> "I've build libgegl-0.0-dev version  0.0.18-1, libbabl-0.0-0-dev version  0.0.22-1, webkit  1.0.1-2 (that provides libwebkit-dev) and finally gimp (2.6.0-1ubuntu1) without any problem! The library haven't reverse dependencies (cause they aren't in Hardy repos),
[01:14] <jdong> "
[01:14] <jdong> rmadison begs to differ on package 3 of 3
[01:14] <jdong> I hate it when people tell me things that are 66.67% true
[01:20] <james_w> jdong: hi, have you seen bug 215784?
[01:22] <jdong> james_w: is this a hardy bug?
[01:23] <james_w> jdong: looks like it
[01:23] <james_w> I hadn't noticed
[01:24] <jdong> james_w: I don't think 0.9.4 has this bug. Ask the users to confirm that, but at the same time IMO this is SRU worthy and I'd approve the given patch once it is adapted to the correct patchsys and targeted against hardy-proposed
[01:25] <james_w> jdong: would you put that in the bug please?
[01:27] <jdong> sure
[01:31] <lfaraone> Hey, are FLOSS apps that use non-comm-only APIs OK in univ?
[01:32] <RAOF> non-comm-only APIs?
[01:33] <jdong> I'm guessing that means something like Google API or some other web based service?
[01:37] <goshawk> hi
[01:37] <goshawk> is someone able to comment on revu?
[01:37] <goshawk> i receive an error
[01:37] <goshawk> MOD_PYTHON ERROR
[01:37] <ajmitch> !pastebin
[01:37] <ajmitch> paste it in there ^^ so we can look at it
[01:37] <goshawk> ok
[01:37] <ajmitch> it's probably something known already
[01:38] <goshawk> http://paste.ubuntu.com/55839/
[01:38] <ajmitch> thanks
[01:38]  * ajmitch did see this error in a bug yesterday, at least
[01:39] <ajmitch> you were trying to add a comment to an upload there?
[01:39] <goshawk> yep
[01:39] <ajmitch> which package?
[01:42] <goshawk> wait
[01:42] <goshawk> http://revu.ubuntuwire.com/details.py?package=dsss
[01:42] <goshawk> i tried again
[01:42] <goshawk> no way
[01:45] <goshawk> time to go for me
[01:45] <goshawk> see you
[01:45] <ajmitch> ok
[01:45]  * ajmitch will bug the person who added this change
[01:57] <StevenK> superm1: Right, looks like bluemon, bluetooth-alsa, btscanner, libopensync-plugin-irmc, scmxx, transfermii are my responsibility and haven't been uploaded.
[01:57] <StevenK> superm1: libpam-blue failed to build and NCommander fixed it, so one of us should probably sponsor him
[02:05] <up_the_irons> i looks like this package:
[02:05] <up_the_irons> garry@nf01vm:~$ apt-cache search portmap
[02:05] <up_the_irons> portmap - The RPC portmapper
[02:05] <up_the_irons> (on Hardy)
[02:05] <up_the_irons> doesn't install a portmapper that uses tcpwrappers (hosts.allow/deny)
[02:05] <up_the_irons> is there an alternative package i should use?
[02:06] <up_the_irons> according to this https://help.ubuntu.com/community/SettingUpNFSHowTo
[02:06] <up_the_irons> tcpwrappers should work
[02:06] <up_the_irons> but it don't:
[02:06] <up_the_irons> garry@nf01vm:~$ strings /sbin/portmap |grep hosts
[02:06] <up_the_irons> hosts_ctl
[02:06] <up_the_irons> garry@nf01vm:~$
[02:07] <StevenK> up_the_irons: That's not cool, don't paste that much
[02:07] <up_the_irons> StevenK: sorry
[02:08] <lfaraone> RAOF: non-commercial-use-only
[02:09] <StevenK> up_the_irons: Portmap should be using tcpwrappers
[02:09] <RAOF> lfaraone: What I was more referring to was "APIs"?
[02:09] <RAOF> lfaraone: Presumably you mean web services, yes?
[02:09] <lfaraone> RAOF: flickr's api.
[02:09] <lfaraone> RAOF: yeah.
[02:09]  * wgrant bashes his head into the wall.
[02:09] <wgrant> FORUM USERS ARE SO STUPID.
[02:10] <up_the_irons> StevenK: weird, i'll keep looking
[02:10] <up_the_irons> StevenK: i have "ALL: ALL" in my hosts.deny and i can still do 'rpcinfo -p'
[02:10] <Hobbsee> wgrant: just stop looking, and hope they go away.  :P
[02:10] <StevenK> up_the_irons: On the same host?
[02:11] <ajmitch> wgrant: lucky chap
[02:11] <up_the_irons> StevenK: yeah
[02:11] <StevenK> up_the_irons: Doing RPC calls on the same host is pointless
[02:11] <up_the_irons> StevenK: i know, it's just to test if tcpwrappers is working
[02:11] <StevenK> The R stands for Remote :-P
[02:11] <up_the_irons> StevenK: as documented by http://nfs.sourceforge.net/nfs-howto/ar01s06.html
[02:12] <StevenK> up_the_irons: Doing it locally bypasses tcpwrappers
[02:12] <up_the_irons> StevenK: ok
[02:12] <StevenK> One of the reasons testing RPC stuff sucks so hard
[02:13] <up_the_irons> StevenK: well, no matter, i just tried it from a different host.  Same story (it works)
[02:13] <up_the_irons> i'm just going to apt-get source
[02:13] <up_the_irons> and recompile it w/ wrappers
[02:15] <StevenK> up_the_irons: What about hosts.allow ?
[02:16] <up_the_irons> StevenK: what about it?
[02:16] <StevenK> up_the_irons: If you also have ALL: ALL there ...
[02:17] <up_the_irons> StevenK: that would, presumably, allow all services, so I don't know how i'd test that (I already can rpcinfo the host from anywhere)
[02:21] <up_the_irons> StevenK: oh, i think i know
[02:22] <up_the_irons> StevenK: the nfs howto is old and the 'hosts.allow/deny' strings wouldn't appear in /sbin/portmap anymore, but in libwrap
[02:22] <up_the_irons> which it indeed does
[02:22] <up_the_irons> i'm worrying about nothing
[02:42] <IntuitiveNipple> When using "apt-get build-dep <src-pkg>" is there a way to 'pin' the release as it does with binaries (i.e. using "-t hardy") ?
[02:43] <StevenK> If you do it manually
[02:45] <IntuitiveNipple> how so? I've tried "-t hardy" and <pkg>=<version> and neither works. I was trying to find an easy way to avoid having to disable the intrepid deb-src for apt
[06:48] <didrocks> morning
[06:49] <didrocks> james_w: here?
[07:50] <wgrant> RAOF: Are you still having the BadDevice issue with xinput on your Synaptics laptop?
[07:57] <dholbach> good morning
[08:05] <iulian> Morning dholbach.
[08:05] <dholbach> hi iulian
[08:15] <didrocks> morgs: dholbach
[08:15] <didrocks> morning (sorry morgs ;))
[08:16] <dholbach> hi didrocks, hi morgs
[08:19] <didrocks> dholbach: regarding your message about bugs with "having patchs" triaging : is it possible to unmark those which  have not real patches (ie screenshots only or debug information)?
[08:20] <dholbach> didrocks: yes, there's a "(edit)" link next to them
[08:21] <didrocks> dholbach: you're right, I have only used it to delete a deprecated patch, not for umark it :)
[08:21] <didrocks> dholbach: ok, I will try to give a shot to some bugs for that purpose :)
[08:21] <dholbach> rock and roll!
[08:21] <didrocks> :)
[08:21] <dholbach> didrocks: let's see what people think about the idea
[08:21] <dholbach> it'd be nice to get those 2006 bugs down to a smaller number
[08:21] <didrocks> for sure...
[09:00] <didrocks> dholbach: thx for the upload. It just remains the same kind of thing for nis package bug #259138 and #254262 with an extra FTBFS correction :)
[09:20] <goshawk> hi
[09:21] <goshawk> if someone has free time, can please review http://revu.ubuntuwire.com/details.py?package=dsss ?
[09:23] <persia> goshawk, Did Baby ever contact you?  I know she was interested in that as part of a general D effort.
[09:23] <goshawk> no
[09:23] <goshawk> never
[09:23] <goshawk> Baby
[09:24] <goshawk> i'll for her
[09:24] <goshawk> :D
[09:24] <goshawk> thx
[09:24] <persia> goshawk, No problem.  There's also some talk about starting a D team in Debian, although I don't know if it has come to fruition, which may interest you.
[09:24] <goshawk> yep
[09:24] <goshawk> persia: i packaged also libtango
[09:24] <goshawk> the standard the facto library
[09:25] <goshawk> but i'm waiting for dsss to be accepted
[09:25] <goshawk> since it uses that building system
[09:25] <goshawk> so... maybe they are going to do the same work
[09:25] <goshawk> which is already done
[09:25] <persia> goshawk, That's what I fear, which is part of why I point you at them : I'd think they'd want to work with you and get everything in both Debian and Ubuntu.
[09:26] <goshawk> persia: where can i get infos about this group?
[09:26] <goshawk> persia: it's perfect for me to work for both of them :D
[09:26] <persia> Not sure exactly.  I've only heard rumors.  I'll see if I can find any place they congregate.
[09:26] <goshawk> i also found a way to integrate dsss build system with cdbs... :D
[09:26] <persia> Cool!
[09:27] <goshawk> ;)
[09:27] <goshawk> persia: do you want my mail so if you talk with someone of this group
[09:27] <goshawk> you can give ti to them?
[09:27] <persia> goshawk, It's on REVU :)
[09:27] <goshawk> ah yep :D
[09:27] <goshawk> hihi
[09:28] <persia> I know I've given them your address before.  Now I'm looking for somewhere to point you in hopes that the other direction works better.
[09:29] <goshawk> btw i've a nickname now... Baby :D be sure that i'll contact her...
[09:30] <goshawk> thanks for your help
[09:30] <goshawk> since things are going in this direction i'l put libtango in revu too
[09:30] <goshawk> so they can watch at it
[09:30] <goshawk> too
[10:03] <james_w> hey didrocks
[10:04] <didrocks> hi james_w, when removing the patch for rebasing on swfdec0.7 instead of swfdec0.6, I wanted to unsuscribed the sponsor list, but I think that I can't as I am not a member of team, that's it? (to remind you, it was on bug #279207)
[10:06] <james_w> yeah, you need to be a member to do it
[10:08] <didrocks> james_w: ok, so, sorry that I can't warn you before. This evening, I will have the time to rebase it on swfdec0.7 and both packages will be ready :)
[10:09] <james_w> no problem
[10:45] <james_w> asac: hi, do you use bzr for nm-openvpm and -vpnc?
[10:49] <morgs> james_w: thanks for your help with Sugar! Almost everything has hit the archive
[10:49] <james_w> morgs: hey, nice work.
[10:49] <james_w> morgs: I think some packages will need a helping hand, got a list of what's waiting?
[11:00] <morgs> james_w: sugar-toolkit (binpackage python-sugar-toolkit), sugar-calculate-activity, sugar-web-activity, sugar-pippy-activity, sugar-journal-activity
[11:01] <morgs> james_w: also sugar-sharedstate (binpackage sugar-sharedstate-classes), and sugar-hulahop (binpackage python-hulahop)
[11:01] <james_w> morgs: thanks, do you know what's wrong with them?
[11:01] <morgs> james_w: no, I saw fix_released on the tickets, but I don't see them if I apt-get update.
[11:01] <james_w> ah, sugar-toolkit is built
[11:01] <morgs> james_w: perhaps my mirror is lagging, let me check that
[11:02] <morgs> yeah, I see the correct versions in LP
[11:03] <james_w> yeah, they all seem to be built
[11:04] <james_w> morgs: can you file a removal request for the old hulahop package please?
[11:04] <morgs> james_w: sure. (how?)
[11:05] <james_w> morgs: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removals
[11:06] <morgs> thanks
[11:06] <james_w> morgs: it goes for sponsorship as normal
[11:06] <morgs> OK
[11:23] <james_w> morgs: bug 277798
[11:31] <Laney> Erm, how can I recover from a version numbering faux-pas in my PPA?
[11:31] <wgrant> Laney: You generally cannot.
[11:31] <Laney> damn
[11:32] <Laney> I don't want to break PPA -> official archive updates
[11:34] <Laney> I guess I can do 2.1.0pre3+really2.1.0 and then get it right when 2.1.1 comes out
[11:37] <persia> Laney, For safety, consider A.B.C~ppaD-EubuntuF~ppaG for PPA uploads.
[11:38] <Laney> persia: I've appended ~hardy1~ppa0 to what would be the Ubuntu version
[11:38] <Laney> (to sort below backports)
[11:38] <Laney> Do you think that's good enough?
[11:39] <Hobbsee> Laney: yes, that works
[11:39] <persia> Laney, if you ~ the upstream version, you can guarantee upgrade to anything, regardless of what happens after -
[11:42] <morgs> james_w: bug 281221
[11:43] <james_w> thanks morgs
[12:07] <james_w> asac: mind if I upload bug 275608?
[12:09] <asac> james_w: if its just extracted from upstream svn then its not needed
[12:10] <asac> james_w: well lets say it different. this patch is not needed
[12:10] <asac> james_w: we should produce a new orig.tar.gz from the current tree in the archive
[12:10] <asac> james_w: feel free to do that ;)
[12:10] <james_w> asac: please state that in the bug them
[12:10] <asac> james_w: at best for all three vpn daemons
[12:10] <james_w> er, then
[12:11] <asac> done
[12:12] <james_w> thanks
[12:14] <james_w> Koon: would you be willing to do that?
[12:35] <Koon> james_w: I might tackle it if I find the time. I agree that syncing with current HEAD will solve that one. Just wasn't sure that we would do it at that point in the release cycle.
[12:36] <james_w> Koon: no, neither was I.
[13:45] <sylvaing> huats: hi
[13:46] <huats> hello mister sylvaing !
[13:56] <allee> FYI: siretart, \sh: simple FAI merge does not PXE boot: http://paste.debian.net/18925/ There are some pkgs missing, but in several paths there is a /root/.. prefixed that shoud not be there :( I'll be on #fai to find out how to fix it
[14:30] <jmichel> crimsun: Are still there ?
[14:31] <jmichel> crimsun: yesterday my lib built ok but now I'm packaging an app that uses that lib and I get:
[14:31] <azeem> jmichel: no need to ask somebody specific, other people might be able to help as well
[14:31] <jmichel> dpkg-buildpackage: failure: ne dependency information found for
[14:32] <jmichel> azeem: I know it is only because I thought crimsun would remember the case
[14:32] <jmichel> but maybe someone else would have an idia?
[14:32] <azeem> you didn't paste the whole error yet
[14:32] <azeem> but it looks pretty clear, your library packages lacks shlibs info
[14:33] <jmichel> dpkg-buildpackage: failure: ne dependency information found for /usr/lib/libfec.so.0
[14:33] <jmichel> azeem: yes exactly my question was where can I put this info?
[14:33] <azeem> do you run dh_makeshlibs in debian/rules?
[14:34] <jmichel> no this line is commented
[14:34] <azeem> that'd be it
[14:35] <jmichel> ok I'll try this
[14:35] <azeem> jmichel: in your library packages' debian/rules, I mean
[14:35] <jmichel> yes I understood what you meant
[14:43] <bddebian> Heya gang
[14:45] <jmichel> azeem: After rebuilding I'm getting the same error
[14:45] <jmichel> azeem: and I think I made a mistake when copying the error maessage earlier:
[14:45] <jmichel> dpkg-shlibdeps: failure: no dependency information found for /usr/lib/libfec.so.0
[14:46] <azeem> jmichel: what is the library package name?
[14:47] <jmichel> libfec_3.0.2_i386.deb
[14:48] <jmichel> this is a package that I created myself earlier and that I installed on my machine
[14:48] <azeem> btw, that's not correct according to library packaging policy
[14:48] <azeem> jmichel: did you install the new package you built after you uncommented dh_makeshlibs?
[14:49] <jmichel> no
[14:49] <azeem> then that change will not have effect on packages you build against it
[14:49] <emgent> evening
[14:50] <persia> Well, it will affect packages built if you put it in a common repo, and then have pbuilder or sbuild build against that repo, even if not installed locally.
[14:50] <sebner> emgent: \o/
[14:51] <jmichel> azeem: I think I'm somewhat mixed up: I have libfec which is a library that I built and installed earlier... now I want to build an application using this lib and I get the error mentionned earlier
[14:52] <jmichel> how can it do a difference if I install my lib before or after doing the change in the application?
[14:53] <azeem> 15:32 < azeem> jmichel: in your library packages' debian/rules, I mean
[14:54] <jmichel> ok... when I said "[09:35] <jmichel> yes I understood what you meant" I was not right :)
[14:54] <azeem> jmichel: in any case, your library is packaged correctly, you should review the library packaging policy
[14:55] <jmichel> I'll restart everything and come back after... thanks for the help
[14:55] <jmichel> and where would be that policy?
[14:56] <persia> The policy is hard to read.  The library packaging guide is easier, and if you follow those guidelines you'll generally be policy compliant.  See http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[14:58] <goshawk> hi
[14:58] <goshawk> is someone has free time
[14:58] <goshawk> can review http://revu.ubuntuwire.com/details.py?package=dsss please?
[15:00] <persia> I really think you'll do better with pkg-d-devel :)
[15:02] <luisbg_> ScottK, ping :)
[15:02] <ScottK> Pong
[15:02] <ScottK> Good timing.  I just sat down at the computer about 3 minutes ago.
[15:04] <ScottK> luisbg_: ^^?
[15:04] <luisbg_> ScottK, nice
[15:05] <luisbg_> I have a topic I want to bring up to the Release Meeting
[15:05] <luisbg_> its about linux -rt kernel
[15:05] <luisbg_> very important for Ubuntu Studio
[15:05] <luisbg_> https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/281276
[15:05] <ScottK> OK.  I think you should show up.  I think it's been discussed extensively already.
[15:06] <luisbg_> ScottK, I will shop up but since the item isnt in the agenda
[15:06] <ScottK> Whoever the right rep for ubuntu-studio is should come to the meeting.
[15:06] <luisbg_> I shouldn't bring it up without the aid of somebody in the MOTU Release Team
[15:06] <ScottK> I'd also warn slangasek that you want to discuss it.
[15:06] <luisbg_> ScottK, ok
[15:07] <ScottK> I suppose, but I don't have an opinion on it as I neither have to build the kernel nor need it to work.
[15:07] <luisbg_> will talk to slangasek
[15:07] <luisbg_> slangasek, ping?
[15:14]  * jdong wonders where all his input devices went after this morning's dist-upgrade
[15:15] <luisbg_> jdong, including the keyboard? :P
[15:16] <jdong> yes
[15:16] <jdong> X lost them all
[15:16] <jdong> and Xorg.log is so cute in telling me that there's no input devices.
[15:18] <elkbuntu> which of course you can read by typ...oh, right.
[15:18] <jdong> :D
[15:18] <jdong> oh crap did I agree to removing xserver-xorg-*-input?
[15:18] <jdong> sigh.
[15:18] <persia> heh
[15:19] <jdong> yeah my mistake
[15:19] <luisbg_> lol
[15:19] <jdong> looks like dist-upgrade tries too hard to bring in gnome-settings-daemons
[15:19] <jdong> which conflicts libxi
[15:19] <jdong> grumble.
[15:19] <jdong> back I go
[15:19] <elkbuntu> jdong, who needs ultabreaksit when we have you?
[15:32] <jdong> there we go!
[15:32] <jdong> nothing a bit of dpkg editing didn't fix.
[15:46] <goshawk> persia: i've already written on their ML :D
[15:47] <persia> goshawk, I saw, and nobody responded yet.  I chatted with Baby earlier, and she was interested, so I'm guessing you'll hear something this weekend.
[15:47] <goshawk> Baby... i'm still not able to reach her :D
[15:50] <persia> I suspect you want to try OFTC :)
[16:23] <luisbg_> ScottK, slangasek never pinged me back :(
[16:23] <ScottK> He's not in the release meeting either it seems.
[16:23] <ScottK> Just show up.
[16:24] <luisbg_> I just joined :)
[16:24] <luisbg_> will you call me when the universe section starts/ends?
[16:24] <luisbg_> please
[16:24]  * ScottK is multi-tasking, so no promises, but I'll try to remember
[16:26] <luisbg_> ScottK, I am also, thats why I ask :P
[16:27] <ScottK> Of course
[16:29] <ScottK> luisbg_: Kernel team is up now.  This is probably the best time.
[16:30] <luisbg_> yes
[16:30] <luisbg_> I will interrupt
[16:30] <Koon> james_w: done update for network-manager-openvpn on bug 275608
[16:31] <james_w> Koon: thanks. asac, could you take a look please?
[16:33] <Koon> james_w, asac: the only trick is the direct nm-openvpn-service.name.in patch in diff.gz, I reported it on the new version as is.
[16:39] <luisbg_> ScottK, thanks!
[16:39] <ScottK> No problem.
[17:08] <asac> james_w: ok. commented. you i asked for the other two plugins too
[18:13] <asomething> persia: hi, are you around?
[18:14] <persia> asomething, Usually, but much of the time someone else can also answer a question :)
[18:14] <asomething> hey, I'm looking to fix bug #210456 in gimageview and you were the last uploader. a merge with debian would fix this (the debian upload is bug fix only)
[18:14] <asomething> the only ubuntu change was due to bug #159338, a xine-lib transition in hardy, adding "libxine1-x | libxine1 (<< 1.1.8-2)" to Depends. I'm wondering why ${shlibs:Depends} isn't enough? can this be droped now and just sync?
[18:18] <csilk> Is it standard to make sure desktop/menu shortcuts work in xubuntu kubuntu as well as ubuntu(gnome) when packaging software that's been requested in ubuntu(gnome)?
[18:18] <csilk> *xubuntu and kubuntu
[18:28] <persia> asomething, Check the Debian packaging : if it's done the libxine transition (which is likely at this point), it can be dropped.
[18:28] <persia> I don't actually remember that package, so probably updated it completely accidentally trying to clear the transition.
[18:37] <asomething> in debian the depends on shlibs picks up libxine1 (>= 1.1.8). I guess I was mostly wondering why the depends needed to be added at and not just do a rebuild.
[18:39] <persia> asomething, The bug should explain it.  I think it was something about allowing different UIs.  If the bug doesn't give you enough information, you might ask siretart.
[18:42] <asomething> persia: thanks
[19:18] <slytherin> geser: there?
[19:21] <geser> slytherin: yep
[19:21] <slytherin> geser: who other than slomo is responsible for gstreamer packages?
[19:22] <slytherin> specifically the ones in universe
[19:22] <geser> I don't know
[19:29] <slytherin> geser: Can you please sponsor the patch then. It will be great if you can do some testing first. The results of tests done by other users are not very consistent. Some DVD's play while some don't, but it is better than not being able to play anything at all.
[19:33] <DoYouKnow> I think it would be cool if CIAO 4.0 were included in Ubuntu. Granted, it's a research tool for analyzing data from the Chandra X-Ray Telescope, but I think that with some guidance it could be really useful for doing research-class astronomy at home in front of the computer.
[19:34] <slytherin> DoYouKnow: file a bug
[19:34] <slomo> slytherin: write me a mail about the issue and i'll care for it tomorrow
[19:35] <slomo> slytherin: slomo@debian.org ;)
[19:35] <DoYouKnow> ok
[19:35] <slytherin> slomo: Ok.
[19:35] <slytherin> Thanks in advance.
[19:40] <Laney> superm1: Do you know/care about these messages when upgrading bluez? http://pastebin.ubuntu.com/56076/
[19:40] <persia> Laney, known, unimportant.
[19:41] <Laney> persia: Right, fine. As long as you're aware
[19:41] <persia> Laney, More verbosely, to make that go away would break support for users who need the devices created (non-udev users), and it's just terminal noise for people with udev.
[19:42] <persia> I suppose it could be redirected to /dev/null or something, but I'm not sure that's best.
[19:42] <superm1> persia, yeah i've been debating doing that 1>/dev/null 2>/dev/null
[19:42] <superm1> persia, particularly since udev is part of ubuntu-minimal
[19:42] <Laney> Can't you detect the situations where it's needed and only do it then?
[19:44] <persia> Laney, That's an interesting idea.  Only create the device nodes if udev is *not* active.
[19:44] <persia> superm1, What do you think?
[19:45] <geser> slytherin: I probably won't have the time for the testing before next week, so it would be better if you can find an other sponsor
[19:46] <slytherin> geser: slomo is going to take care. :-)
[19:46] <geser> good
[19:48] <superm1> persia, well I think that would have an equivalent result of what we see now
[19:48] <superm1> persia, that these device nodes aren't made when udev is active
[19:48] <superm1> persia, how is the best way to query if udev is active though?
[19:49] <persia> see if "udev" is mounted maybe?
[19:49] <persia> I thought there used to be a /dev/.udev, but I don't see it now.
[19:50] <superm1> persia, well actually something is a bit odd here.  why is /dev/.static read only?
[19:50] <superm1> it should have been able to put stuff in there
[19:50] <superm1> udev is mounted on /dev type tmpfs, rw
[19:51] <persia> Yeah, which means "udev" is just a convenience label, and not safe to check.
[19:51] <superm1> persia, so /dev/blah can be touched, so can /dev/.static/blah
[19:51] <superm1> just not /dev/.static/dev/blah
[19:52] <superm1> something's fishy here
[19:53] <persia> superm1, Maybe some sort of odd bind-mounting is going on?  I'd suggest asking Keybuk
[19:54] <superm1> persia, i'm actually all for just dropping the call to MAKEDEV anyway though
[19:54] <superm1> because it is supposed to make rfcommX devices, which is pointless
[19:54] <superm1> you get one created by the init script if you need it already
[19:55] <persia> superm1, And the init script is run at install time, right?  In that case, yeah, drop it.
[19:55] <superm1> yeah
[19:56] <superm1> persia, and this is a good excuse while i'm rebuilding to test the supposedly better headset support in 4.13 from today's release :)
[19:57] <persia> I'm excited about that : the one thing I couldn't get to do more than pair was my handset, and I'm curious if it works as a bonus.
[19:57] <persia> I don't expect that many users have a handset, so I'm not worried if it doesn't.
[20:01] <Laney> Is 3G internet over bluetooth in Intrepid at a Just Working state yet?
[20:02] <Laney> Or at least easily achieveble
[20:02] <superm1> Laney, it's achievable
[20:02] <superm1> by the exact interface i was just referring to, rfcomm
[20:02] <superm1> if you modify /etc/bluetooth/rfcomm.conf
[20:02] <superm1> and put in the appropriate information for the DUN service on your device (queried via sdptool)
[20:02] <Laney> superm1: That's cool. Is there a wiki page or other guide?
[20:02] <superm1> then use /dev/rfcomm0 as your modem, and it will work
[20:03] <superm1> Laney, there's wiki pages discussing it yeah
[20:03] <Laney> I just got a new N96 and am considering buying a USB dongle to be able to internet on the go
[20:03] <persia> Having it just work and integrated as an option in NM is probably a 9.04 or 9.10 thing, depending on how many people test and hack at it.
[20:04]  * Laney nods
[20:04] <Laney> I'll do whatever I can
[20:05] <superm1> persia, it was supposed to be in NM 0.7, but slipped
[20:05] <superm1> it can all be done via dbus automagic stuff though
[20:05] <persia> superm1, Right, part of it was that bluetooth didn't work, and part of it was the lack of people testing.
[20:05] <persia> *Should* be 9.04, but I'm not going to promise anything, as I'm not likely to do it, and I haven't seen the approved list of Jaunty specs yet.
[20:13] <slytherin> superm1: any word form crevette about the nautilus-sendto issue?
[20:14] <superm1> slytherin, not that i've heard
[20:14] <superm1> slytherin, any update on the GTK tooltips?
[20:14] <slytherin> superm1: Nothing. Didn't find time. Will do surely tomorrow.
[20:15] <persia> nhandler_, Any ideas on nautilus-sendto?
[20:16] <persia> Could someone help me with Python?  If I call "a = b == c" wll that assign 'a' a boolean value, or check if the result of "a = b" matches 'c'?
[20:18] <james_w> persia: it will assign a boolean
[20:18] <persia> james_w, Excellent : that's what I intended.  Thank you.
[20:19] <ScottK> persia: = is assignement and == is a comparison, so as james_w says ...
[20:20]  * persia appreciates that operator precedence is largely language-independent
[20:24] <ScottK> I'll confess I tried it to make sure.  Sometimes Python's booleans approach math differently than I would.
[20:25] <persia> heh.
[20:26] <persia> In an amusing twist, I'm actually writing Python code for KDE right now.  Certainly not my native habitat.
[20:27] <emh> persia: I would use a = (b == c) for clarity.
[20:28] <persia> emh, Does that change anything, or just for readability?  There's very limited use of parenthesis in the code I'm touching, and I'd prefer to follow style.
[20:28] <emh> persia: Just for readability.
[20:29] <persia> I'll look then : if I can find anything similar, I'll add the parens.  Thanks for the hint.
[20:54] <slytherin> persia: do you know what is default jdk for sparc?
[20:56] <persia> slytherin, Not offhand.  Have you looked at the default-jdk package for sparc?
[20:57] <slytherin> no checking
[20:57] <slytherin> but where do I check it?
[20:57] <persia> Let's check together :)
[20:58] <persia> First, visit http://ports.ubuntu.com/pool/main/j/java-common/ and grab the sparc deb
[20:59] <slytherin> Ok. I thought you had better idea. :-)
[20:59] <kees> ScottK: I'd like to get (sort of?) a feature-freeze exception for ubuntu-dev-tools.  0.46 has several bug fixes but technically contains a new utility as well.  I figure the regression potental is very low as result, and I'd really like to get the bug fixes in.
[21:00] <slytherin> persia: it says openjdk
[21:00] <persia> Yep, so it's openjdk-7-jdk
[21:00] <persia> s/7/6/
[21:01] <kees> ScottK: er, nevermind, looks like mdz didn't add the program to bzr...
[21:01] <slytherin> yes. So that means if change build-dep of some package to default-jdk and build on i386, it is likely to be built on sparc as well
[21:01] <persia> Should do.  No promises for powerpc, ia64, or hppa.
[21:02] <persia> I think cacao works fairly well for powerpc, but ia64 and hppa just don't have much support.
[21:02] <slytherin> not worried. I am already too late getting the custom power adapter made for my ibook but I hope I will be able to squash some powerpc specific FTBFS in 3rd week of the month.
[21:03] <slytherin> on hppa I don't think there is any java compiler
[21:03] <persia> Not even gcj?
[21:03] <kees> ScottK: er, rather he got the name wrong.  wheee
[21:04] <slytherin> persia: Last time I checked it wasn't there. only -base package was built. But that was more than a month ago
[21:04] <persia> Oh.  Probably FTBFS and needs careful build sequencing or something.
[21:05] <superm1> for a package that is regularly synced from release to release, that we just need to make a small change too debian/control for intrepid, what version number should it be bumped to so that it's still automatically synced come jaunty DIF?
[21:05] <superm1> *too=to
[21:05] <kees> slangasek: as a member of ubuntu-release, can you approve an upload of 0.46 of ubuntu-dev-tools?  it technically needs a FFe, but I don't think it's a problem since the only feature is an isolated script.
[21:06] <slytherin> superm1: doesn't matter how small is change, if it changed in ubuntu it won't be synced automatically
[21:06] <superm1> slytherin, I thought normally appending buildX would allow these types of things come next release?
[21:06] <superm1> perhaps i was mistaken then
[21:07] <slytherin> superm1: you might want to take second opinion about buiildX
[21:07] <persia> superm1, How sure are you that autosync won't break anything?
[21:08] <superm1> persia, absolutely positive.
[21:08] <slangasek> kees: if you don't think it should require a freeze exception, then don't ask for my approval; if you ask for my approval, I'll insist on looking at it first :)
[21:08] <persia> superm1 What sort of change is required now that won't be required later?
[21:08] <superm1> persia, the change is already in the new upstream version, but i dont see a need for that new version
[21:09] <superm1> persia, it's just a typographical change in debian/control
[21:09] <slytherin> does anyone know why cups-pdf has moved to universe?
[21:09] <persia> Oh, so you're backporting a fix from Debian.  Yeah: those are tricky.  I just use XubuntuY for clarity, and file a sync request when the archive opens, but XbuildY would work (but would annoy people because it's not right).
[21:11] <superm1> persia, well I'm almost apt to think XbuildY would be more reliable to ensure that it didn't get forgotten
[21:13] <persia> superm1, The problem is that XbuildY is incorrect, and the systems that check XbuildY packages for changes outside debian/changelog would flag it, and someone might have to take the time to look.
[21:13] <superm1> persia, ah i see.  okay
[21:13] <persia> I think it's better to flag it on MoM than there.  It will even have your name on it to find it easily :)
[21:14] <persia> I'm not sure if anyone is running such a checker for intrepid, but I know they've been run before, and like to avoid such issues :)
[21:14] <slytherin> persia: where can I find log of promotions/demotions for intrepid i.e. main->universe and vice-versa?
[21:15] <persia> slytherin, I don't know of such a list.  You can probably convince quinn-diff to tell you packages moved since hardy.
[21:16] <slytherin> persia: I know of a package moved form main->universe and I am looking for reason
[21:17]  * slytherin searches through bugs
[21:17] <persia> Oh, there's usually no explicit reason, except that nothing in main depended, recommends, or build-depended on it and someone noticed.
[21:17] <superm1> slytherin, you are probably best asking tkamppeter
[21:17] <persia> About half the time there's not even a bug.
[21:17] <superm1> slytherin, he's the one who has looked after it for a while
[21:19] <james_w> I need some advice, I have some C++ code where loader.cpp includes a.h and b.h, a.h includes something which defines FOO to 1, and then b.h includes something which uses FOO in an enum, not intending it to be the same FOO.
[21:19] <james_w> what's the best way to protect the thing included by b.h from having FOO #defined?
[21:19] <slytherin> persia: Right, cups only suggests cups-pdf. Now I have to look into changelog if it was demoted form recommends.
[21:22] <slytherin> persia: this is funny, cups-pdf was never recommends of cups. :-)
[21:24] <slytherin> On a second thought I think it is ok, the print dialog has ability to print to PS or PDF file even without cups-pdf.
[21:24] <persia> james_w, In what scope are you concerned?  If you're mostly worried about loader.cpp, just including a.h after b.h will overwrite the b.h definition.
[21:26] <james_w> that works, thanks
[21:27] <james_w> though it's not really overwriting, it's just stopping the pre-processor stomping on the C++ tokens
[21:27] <persia> No, it's really redefining it.
[21:28] <stefanlsd> can i just delete config.guess and config.sub?  or should debhelper be doing that during the clean rule?
[21:28] <persia> You'll notice that lots of #define directives are wrapped in #ifndef to protect against this, but for code as messy as hat you've described, I was sure it wouldn't be the case :)
[21:28] <ScottK> kees: I don't think native pacakges like u-d-t need FFe, but that's just me.
[21:29] <kees> ScottK: okay, cool
[21:30] <ScottK> kees: So as long as you don't break stuff, I don't think anyone will complain.
[21:30] <ScottK> kees: Please don't break stuff.
[21:30] <kees> ScottK: heheh.
[21:30] <kees> ScottK: afaict, it doesn't, and fixes a bug I just ran into (submittodebian had "hardy" in the usertags)
[21:32] <directhex> NCommander, GFDL *is* non-free! netcraft confirms it!
[21:32] <NCommander> directhex, generally speaking, the GFDL is non-free with invarient sections, BUT every software has non-varient sections (Copyright notices)
[21:33]  * slytherin wonders why seahorse has suddenly stopped accepting passphrase for his gpg key
[21:33] <NCommander> Even stuff in the public domain need to say that
[21:33] <NCommander> slytherin, you kicked us out of -devel with our discussion ;-)
[21:33] <NCommander> (well, ok, we went off topic but :-P!)
[21:33] <ScottK> directhex: GFDL with invariant sections is non-free.
[21:33] <directhex> seahorse is punishing you. i blame SigBlk.
[21:34]  * NCommander notes that he feels the AGPL is non-free
[21:34]  * ScottK totally agrees.
[21:34] <directhex> NCommander, Expat fan?
[21:34] <NCommander> It, to me, fails the desert island test
[21:34] <NCommander> directhex, I use the MIT license, yes.
[21:35] <directhex> try Ms-PL! it's fruity and dfsg-free ;)
[21:35] <NCommander> MSPL is just a directive of the MIT license ;-)
[21:36] <ScottK> Well one of the prime features for GPL is that it does not impose use restrictions, only distribution restrictions.  AGPL breaks that rather badly.
[21:37]  * directhex makes ScottK agree to a EULA
[21:37]  * slytherin gets back to fixing FTBFS in a package inherited from Debian and written in truly cross platform language.
[21:37]  * ScottK folds the EULA into a shart pointy paper airplane and throws it at directhex's left eye.
[21:38]  * directhex wears glasses \o/
[21:38] <directhex> slytherin, tcl? \o/
[21:39] <slytherin> directhex: java :-P
[21:39] <NCommander> slytherin, which language?
[21:39]  * directhex runs slytherin's package through ikvm.net
[21:39]  * NCommander should package REVU for multiverse
[21:40] <persia> NCommander, Why multiverse?
[21:40] <slytherin> NCommander: why, is revu not Free?
[21:41] <NCommander> Dependency on Launchpad
[21:41] <directhex> how does it communicate with LP?
[21:41] <NCommander> OpenID and GPG key exchanges via OpenID protocol, and RDF scalping w/ gpg keyserver magic
[21:42] <slytherin> NCommander: So if someone wrote a Free alternative to launchpad, revu will work with it just fine right?
[21:42] <NCommander> Techinically, all you need is an openid server, and then a free way to get GPG keys to be autodownloaded
[21:44] <NCommander> but yes, REVU is non-free due to its LP dependnecy
[21:44] <directhex> RDF you say? oh deary me :| http://www.google.com/patents?q=Resource+Description+Framework&btnG=Search+Patents
[21:44] <directhex> also http://www.google.com/patents?q=openid&btnG=Search+Patents
[21:45] <persia> Right.  Enough with the patents and non-freeness, or I'll start handing out packages needing work.
[21:45] <NCommander> persia, what packages?
[21:46] <persia> NCommander, Well there are heaps.  compiz-fusion-plugins-extras is the one I'm procrastinating looking at right now, if you want one.
[21:47] <NCommander> I don't use compiz nor does my HW support it
[21:47] <persia> Yeah, me either.  That's why I'm procrastinating :)  I'll go get a useful package then.
[21:49] <james_w> NCommander: there's a request to sync firebird where the person doing it would like some help to make it compile on Ubuntu if you are looking for something to do
[21:49] <persia> On the theme of questionably free, here's a list of packages in universe with dependencies in multiverse or restricted: http://qa.ubuntuwire.com/debcheck/debcheck.py?dist=intrepid&list=withinuniverse&arch=ANY
[21:49] <james_w> bug 271919
[21:50] <NCommander> Isn't it by definition if universe depends on multiverse, it should FTBFS due to build-deps?
[21:50] <NCommander> oh
[21:50] <NCommander> not build-dep
[21:50] <persia> That's Build-Depends.  These packages just don't install within the ogre model.
[21:50] <NCommander> right
[21:50] <NCommander> Hence the "not build-dep"
[21:51] <NCommander> In Debian, that would fall into contrib, right?
[21:51] <persia> NCommander, Another I'd love to see is ctsim ported to some newer version of WX and not segfault on start afterwards.
[21:51] <persia> Right.  multiverse is contrib+non-free
[21:51] <NCommander> So how'd those packages end up in universe
[21:51] <NCommander> if they were synced, it should have landed in multiverse
[21:52] <Laney> Is the RC bugs list really empty?
[21:52] <persia> Maybe they weren't synced?
[21:52] <persia> Laney, I doubt it : more likely it's either thinking, or needs a kick, but he who kicks it isn't likely to be around for another couple hours.
[21:52] <Laney> persia: That's what I thought
[21:52] <ajmitch> or is awake & was hacking on it yesterday, and something broke?
[21:53] <ajmitch> and didn't know about it, of course
[21:53] <persia> Good morning ajmitch :)
[21:54] <ajmitch> hi
[21:54] <ajmitch> "a couple of hours" for me is lunchtime :)
[21:54]  * Laney giggles
[21:54] <persia> Isn't it only about 9am there?
[21:55] <persia> And it's it saturday?  And isn't Friday traditionally beer day?
[21:55] <ajmitch> daylight saving time
[21:55] <ajmitch> it is saturday
[21:56] <persia> Ah.  Missed the DST change.
[21:59] <slytherin> NCommander: which package are you talking about?
[22:00] <NCommander> What am I talking about?
[22:01] <ajmitch> ok, so my code cleanup had a minor bug
[22:13] <slytherin> NCommander: some package that is in universe even though it is in Debina contrib
[22:19] <slytherin> persia: shouldn't sun-java5 packages be removed from archives now? openjdk is in better shape than most Free JDK/JRE and we already have another Sun JDK.
[22:20] <persia> I think there was some discussion about that at the Foundations meeting this week.  Let me see if I can find the log.
[22:21] <persia> slytherin, According to http://irclogs.ubuntu.com/2008/10/08/%23ubuntu-meeting.html it looks like it's a release-notes issue for intrepid, and maybe a goal for jaunty.  Perhaps you could write a spec about moving everything to the 1.6 class format?
[22:22] <slytherin> we don't need to move everything to 1.6 class format. we need to compiler everything in 1.5 format using either Sun JDK 6 or openjdk
[22:24] <persia> openjdk generates 1.6 by default, according to the meeting log.
[22:24] <stefanlsd> i've made a debdiff for mplayer in dapper. is it normal that the config.sub and config.guess remain in the diff?  Or can i remove them.
[22:25] <slytherin> right and if we have to keep compatibility with GCJ we need 1.5. Of course I wonder if GCJ will be of any relevance in another year.
[22:26] <persia> stefanlsd, It's normal that they remain in the diff if they were copied at packaging time.  Personally, I think it's better to copy them in configure: rather than clean:, but that's the sort of change that should not be made for an SRU.
[22:27] <persia> slytherin, Write a spec.  It can get a review.  Either 1.5 or 1.6 might be correct.
[22:27] <slytherin> persia: sure. I will write one as soon as jaunty cycle starts
[22:31] <persia> slytherin, OK.  Specs should be loosely drafted by mid-November, and mostly ready for review by end-November, just so you can plan your schedule.
[22:31] <slytherin> Ok. Cool
[22:37] <stefanlsd> persia: looks the they were included in the original .diff file. In this case, it copies them in clean:: unpatch.  -  then when i do my debdiff, i get the updated files showing. So thats ok in this case (as its not worth moving)
[22:39] <persia> stefanlsd, It's very much not worth fixing in an SRU.  I personally don't like it, but others prefer it for different reasons.
[22:40] <stefanlsd> persia: just to check if i get it right. if it was in configure, it would be there for the build, but would be removed during the clean phase, so wouldnt appear in the diff...
[22:41] <persia> stefanlsd, No, if the copy was in configure: you'd leave it alone, so it wouldn't be in the diff.gz, and it wouldn't be in the debdiff, but it would be copied before ./configure was called in the build.
[22:42] <persia> clean would also leave it alone.  The reason some people don't like this is because debian/rules clean isn't idempotent when you do it like that.
[22:53] <stefanlsd> persia: heh. sorry, still not sure why I dont see it if im copying it.  (i've tried it, and yes - the diff.gz show the same content for config.guess and config.sub).  So what happens different by copying it before ./configure as opposed to it being in a clean rule?
[22:55] <persia> stefanlsd, It's when it gets copied.  debian/rules clean gets called when you create the source package.  The configure: target is usually called by build: and only happens at build time.
[22:56] <persia> One interesting side effect is that if we had different config.{sub.guess} in Debian and Ubuntu, packages in sync that copied it in clean: would use the Debian version, and those that copied it in configure: would use the Ubuntu version.
[22:57] <stefanlsd> persia: aah. great. thanks. that makes sense then.  thanks for your patience :)
[22:57] <persia> stefanlsd, No problem.  Always good to see questions, rather than people trying to do things when they aren't sure :)
[23:00] <slytherin> persia: if you have nothing better to do, bug #281480
[23:02] <persia> slytherin, I've lots of other stuff, but I'll push that if nobody else does soon.
[23:02] <slytherin> persia: no issues. That is why I said 'if you have nothing better to do' :-)
[23:02] <stefanlsd> typo in the debdiff - defaulf jdk.
[23:03] <persia> That ought get fixed :)
[23:03] <slytherin> stefanlsd: It's 3:30 am here and I already had hectic day at office. :-)
[23:04] <stefanlsd> hehe. ouch :)
[23:04] <slytherin> got to go now. bye all.
[23:08] <persia> Going to bed without fixing the debdiff?  That's not ideal.
[23:10] <Syntux> Thou shall receive nightmares!
[23:36] <james_w> has anyone ever seen dpatch-edit-patch convert the patches to context diffs?
[23:39] <persia> james_w, If they weren't context diffs previously, yes, although wrapped in the special dpatch wrapper.
[23:39] <james_w> yeah
[23:49] <emgent> heya
[23:50] <nhandler_> Hi emgent
[23:50] <emgent> heya nhandler_ :)