[01:28] <psusi> can anyone help me understand WTF is going on in this bzr history?  it says merge and lists "1.1.10 upstream" and "3.1.8 squeeze" as where the merge was pulled from, but clicking either link does't seem to take me to another branch: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/lvm2/maverick/revision/46
[03:30] <psusi> can someone give me a run down on what dh_makeshlibs is for, and why it would bail out because the new upstream sources have new functions in the lib?
[03:55] <ScottK> psusi: What's the exact error with dh_makshlibs?
[03:56] <psusi> ScottK, I forget now... it seemed to complain about there being new symbols in the library, and printed a diff... so like the man page said, I applied the diff after stripping the -1ubuntu1 version from the base version of the new symbols
[03:57] <ScottK> OK.  That's why it raised the error.  Also if there were any missing symbols you need to consider a soname change.
[03:58] <psusi> now i'm trying to figure out the cause of this:
[03:58] <psusi> dh_install --sourcedir=debian/build/install-deb-cluster
[03:58] <psusi> cp: cannot stat `debian/tmp/sbin/clvmd': No such file or directory
[03:58] <psusi> dh_install: cp -a debian/tmp/sbin/clvmd debian/clvm//sbin/ returned exit code 1
[03:58] <psusi> naw, it was only + lines, no -, so I just added the new symbols to the .symbols file
[03:58] <psusi> but what is this file for?
[04:01] <ScottK> That's something that should have been built by the package
[04:02] <psusi> there is no tmp directory under debian/
[04:03]  * psusi beats the lvm2 package with a rubber hose
[04:05] <psusi> ohh, clvmd is under debian/build/install-deb-cluster/usr/sbin
[04:06] <psusi> what the hell... why is it complaining with: cp: cannot stat `debian/tmp/sbin/clvmd': No such file or directory
[04:06] <psusi> when it is invoked as: dh_install --sourcedir=debian/build/install-deb-cluster
[04:07] <ScottK> Is there a .install file?
[04:07] <psusi> yea, there is a clmv.install
[04:08] <psusi> err, clvmd.install rather
[04:08] <ScottK> I'm not sure which path will take precedence.
[04:10] <psusi> clvm.install lists sbin/clvmd.. and apparently debian/rules invokes dh_install --srcdir=debian/build/install-deb-cluster... and there is a debian/build/install-deb-cluster/sbin... oh shit
[04:10] <psusi> the actual file is under usr, but it's looking in /sbin not /usr/sbin
[04:25] <psusi> thank god, finally got the sob to build
[08:14] <dholbach> good morning
[08:18] <abogani2> to you
[11:10] <nperry-work> Hello world, I would like to maintain the openbox package.
[11:11] <nperry-work> I've read all the packaging guidlines
[11:12] <dholbach> nperry-work: just start the work on the package and propose changes for sponsorship
[11:12] <dholbach> https://wiki.ubuntu.com/SponsorshipProcess
[11:12] <dholbach> https://wiki.ubuntu.com/Upstream/Adopt might be interesting too because it contains information about how to work together with Debian and upstream
[11:13] <nperry-work> That was one of my questions, Is it my choice if i prefer to get source from upstream rather then debian
[11:35] <ScottK> nperry-work: It is, but it's strongly encouraged to work with Debian.
[11:36] <ScottK> If you aren't, people who consider to sponsor your work will want to know why not.
[11:41] <tumbleweed> if there are problems with the package in debian, it makes sense to fix them there
[12:19] <didrocks> directhex: hey, do you think it would be hard to add to your ubuntuone music store banshee plugin something similar to rhythmbox's one? (that is to say, detect if you don't have mp3 support installed, and if so, don't show the store right now but a "download codec" button?)
[12:20] <directhex> didrocks, i don't see why not, i assume that's something that can be queried from gstreamer
[12:22] <didrocks> directhex: I don't have enough knowledge right now on mono (didn't touch cs for 7 years :)), are you interested (and have time :-)) to work on that? Otherwise, I'll try. It will just be longer :)
[12:23] <directhex> didrocks, i don't have a huge amount of time to work on it. IME the hard part is knowing your way around the banshee code base (i.e. knowing which bits to poke where), and #banshee are pretty responsive
[12:23] <didrocks> directhex: ok, understood. I'll try to have a shot there :)
[12:24] <directhex> didrocks, the addin is only, like, a dozen lines of actual code. the rest is autogenerated c#, and trying to get bindings integrated into libu1's autofoo build system
[12:25] <didrocks> directhex: yeah, seeing that. The hardest part is to the extension and banshee base classes documentation. Seems poor :/
[15:53] <micahg> mr_pouit: is the xubuntu team planning on backporting Xfce 4.8 to Lucid?
[16:08] <azop> micahg: Is 4.8 even released yet?
[16:09] <mr_pouit> micahg: it's not released, and will probably be delayed of several months
[16:10] <mr_pouit> there are already some 4.7.x packages in the xubuntu-dev ppa though
[16:14] <micahg> mr_pouit: ok, I've been having trouble w/xfce4-power-manager and was hoping for the hal-less version at some point :)
[16:17] <micahg> mr_pouit: so it might not even make maverick?
[16:17] <mr_pouit> micahg: well, the hal-less version in the ppa has some permission troubles with somethingkit (policykit maybe), so it's not better ;P
[16:17] <mr_pouit> micahg: I don't think so
[16:18] <micahg> wow, 3 releases on the same desktop version, I'm not getting my cutting edge addiction filled here :)
[16:20] <micahg> mr_pouit: if I can narrow down the case that I'm having an issue with, I'll file some bugs
[17:03] <dupondje> alot of merges open ... :(
[17:58] <arand> git-buildpackage makes a _amd64.changes but I would like a _source.changes for uploading to PPA and not only building for amd, is that possible with git-buildpackage directly?
[18:10] <tumbleweed> arand: never used git-buildpackage, but does it take -S ?
[18:11] <arand> tumbleweed: Yea, figured it takes all arguments debuild takes, just -S -sa worked great :)
[18:38] <nperry-work> How do i grab the source of a package from debian unstable?
[18:39] <tumbleweed> nperry-work: packages.qa.debian.org/$srcpackage will have links to the dsc
[18:39] <tumbleweed> otherwise you can check it out with UDD
[18:40] <nperry-work> UDD?
[18:40] <tumbleweed> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[18:40] <nperry-work> Thanks, theres a wiki page for everything :)
[18:44] <tumbleweed> fabrice_sp: atlas eventually built
[18:45] <fabrice_sp> tumbleweed, you succeeded to build it with qemu?
[18:45] <tumbleweed> yes
[18:45] <fabrice_sp> or you are speaking about the sse3/i386 mess?
[18:45] <fabrice_sp> oh ok
[18:45] <tumbleweed> yeah, some buildd maintainer input would be useful on that one
[18:46] <tumbleweed> but you can probably replace the failure with an "echo hi buildd maintainer: this build takes a *long* time please wait a few days before killing me" :)
[18:47] <fabrice_sp> or I can upload it, and ping some buildd admin if it spends more than 40 hours
[18:47] <fabrice_sp> yeah :-)
[18:47] <fabrice_sp> how long did he take?
[18:47] <tumbleweed> hard to say because of intervening segfaults
[18:48] <nperry-work> Hmm, bzr working for anyone? getting bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[18:48] <fabrice_sp> ok
[18:48] <tumbleweed> fabrice_sp: maybe on the order of 10 hours
[18:49] <fabrice_sp> ok: I'll upload it then, adding a mention in the changelog that it took 40 hours in Debian
[18:49] <fabrice_sp> also, I've been able to build the package in i386, by desactivating the sse3 package
[19:00] <maxb> nperry-work: The pull-debian-source command may also interest you
[19:26]  * abogani2 waves
[19:26] <abogani2> Anyone could help me to drop a package?
[19:27] <geser> drop?
[19:27] <sebner> nperry-work: pull-debian-source $PACKAGE
[19:27] <sebner> huhu geser :D
[19:28] <geser> Hi sebner :)
[19:34] <abogani2> Ok rephrase: What is the right way to ask removing of a package?
[19:36] <micahg> abogani2: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing Packages
[19:36] <geser> abogani2: file a bug with a rationale why it should get removed and subscribe ubuntu-sponsors
[19:36] <abogani2> micahg, geser : Thanks.
[19:56] <dupondje> Is there a way to get MOTU myself to get merges/syncs done ? :)
[19:57] <micahg> dupondje: https://wiki.ubuntu.com/UbuntuDevelopers#MOTU
[20:03] <dupondje> Any idea if I could make a chance ? :P
[20:12] <geser> dupondje: looking at your LP page, you contribute enough to get Ubuntu membership and you're on track for MOTU
[20:13] <shadeslayer> geser: btw can we change the source package name?
[20:13] <shadeslayer> like the original tarball name?
[20:13] <shadeslayer> will change from qt-creator-2.0.0-rc1-src to qtcreator_2.0.0~rc1
[20:14] <shadeslayer> ( which is in archives )
[20:28] <shadeslayer> hey anyone around to help me with qtcreator?
[20:31] <BlackZ> shadeslayer: and what's the problem?
[20:31] <BlackZ> but I'd wait for a new upstream release to do that
[20:31] <shadeslayer> BlackZ: first of all ive never seen a include folder in debian/ ( what is the purpose of it? ) and then this : http://pastebin.com/zmk1kUVB
[20:32] <shadeslayer> BlackZ: they do have a new release,RC1
[20:32] <NorthernLights> Hello all
[20:32] <BlackZ> shadeslayer: so do that mentioning in the debian/changelog file
[20:32] <shadeslayer> also the packaged version has bug 592786
[20:33] <shadeslayer> which i reported,i might be able to fix that with RC1 so im trying :D
[20:33] <BlackZ> shadeslayer: so try to fix the bug too and put that too in the debian/changelog file
[20:33] <BlackZ> (are you the maintainer of that package?)
[20:33] <shadeslayer> BlackZ: yes but idk what the debian/include does :P
[20:33] <shadeslayer> BlackZ: no
[20:34] <NorthernLights> I'm doing my selfish advertisement for a package i uploaded to REVU. It's called KillRogues!, it's a python application for find and disconnecting rogue machines off a network. The REVU link is: http://revu.ubuntuwire.com/p/killrogues
[20:34] <NorthernLights> If someone had the time to check it that would be great. Thanks.
[20:34] <shadeslayer> BlackZ: ive mentioned it in the changelog but when i build the package after removing a patch that was applied upstream i get those build failures
[20:38] <BlackZ> shadeslayer: you have to remove the patch in a debian/patches file too
[20:38] <BlackZ> tipically called 00list or series
[20:38] <shadeslayer> BlackZ: removed there too
[20:38] <BlackZ> but, why are you removing an upstream patch?
[20:39] <shadeslayer> BlackZ: its not a upstream patch,the patch was applied upstream
[20:39] <shadeslayer> like in the original source
[20:39] <BlackZ> shadeslayer: yeah, and why are you removing it? is there a good reason?
[20:40] <shadeslayer> BlackZ: wow... didnt i just say... it was applied to the source by qtcreator devs,we dont need it anymore :P
[20:40] <shadeslayer> hold on ill paste the error with the patches applied
[20:40] <BlackZ> shadeslayer: so are you part of the upstream development?
[20:41] <shadeslayer> BlackZ: no,but debuild said the patch was already applied and it fails to apply it
[20:42] <BlackZ> shadeslayer: what's the patch name?
[20:42] <shadeslayer> BlackZ: http://pastebin.com/N98QUQnJ
[20:42] <shadeslayer> BlackZ: .kubuntu_02_qtgui_includes.diff
[20:43] <BlackZ> trying to get it
[20:43] <shadeslayer> im still wondering what debian/includes do
[20:49] <BlackZ> shadeslayer: it simply includes for additionally files (sorry for the late answer)
[20:49] <BlackZ> -for
[20:49] <shadeslayer> :)
[20:49] <shadeslayer> BlackZ: anyway to update them headers?
[20:50] <BlackZ> shadeslayer: which headers?
[20:50] <shadeslayer> the ones in debian/include?
[20:50] <shadeslayer> it seems that they are causing the issue
[20:50] <shadeslayer> ( moc has changed too much )
[20:51] <BlackZ> shadeslayer: are you saying the headers are the problem for the debuild?
[20:52] <shadeslayer> BlackZ: i think so,they need to be updated
[20:52] <BlackZ> shadeslayer: I don't think they're the problem
[20:52] <shadeslayer> BlackZ: hmm.. ok any other ideas?
[20:54] <shadeslayer> i really think its a problem with those files...
[20:54] <BlackZ> shadeslayer: I'm able to build it and I've seen the patch, it seems OK
[20:55] <shadeslayer> BlackZ: uh.. are you building beta 1 or rc 1?
[20:55] <shadeslayer> because the errors are with rc1
[20:56] <BlackZ> shadeslayer: the version in maverick (the beta1), I haven't the time for try with the rc1, maybe tomorrow
[20:56] <shadeslayer> :)
[20:56] <BlackZ> however, the most probably reason is that the files are changed in the source
[20:56] <shadeslayer> yes
[20:56] <shadeslayer> the private headers
[20:56] <BlackZ> so the patch is no longer needed
[20:57] <BlackZ> or a new patch is needed based on the source of the program
[20:57] <BlackZ> no, I don't think the problem are the haders, but I will try to build it tomorrow
[20:57] <BlackZ> s/haders/headers
[20:57] <shadeslayer> sure :)
[20:58] <BlackZ> shadeslayer: BTW you could try to ping Riddell
[20:58] <shadeslayer> BlackZ: any particular thing?
[20:58] <shadeslayer> you need to get across?
[20:59] <shadeslayer> BlackZ: or do i just say that you wanted to talk?
[21:00] <BlackZ> shadeslayer: no, but he's in the ubuntu KDE team and he could give you an hand
[21:01] <shadeslayer> BlackZ: ah righty... im talking to lex79 as well in #kubuntu-devel ;)
[21:01] <shadeslayer> he thinks its the old headers too... so im downloading qt4-x11 to freshen up the headers and re build
[21:16] <shadeslayer> BlackZ: any idea if we can use some other script which invokes qmake-qt4 instead of include /usr/share/cdbs/1/class/qmake.mk
[21:16] <shadeslayer> which seems to be invoking qmake-qt3
[21:17] <fabrice_sp> BlackZ, about bug 588519
[21:17] <dobey> can i poke someone to review a REVU upload?
[21:17] <fabrice_sp> BlackZ, did you see https://wiki.ubuntu.com/CompilerFlags ?
[21:18] <fabrice_sp> dobey, paste the revu link. Someone may bite
[21:19] <geser> fabrice_sp: what do you propose to fix this bug?
[21:19] <dobey> http://revu.ubuntuwire.com/p/mocker
[21:19] <BlackZ> fabrice_sp: yeah and I suggested one, but geser was not sure about my solution for fix that
[21:19] <dobey> it's a very trivial python package :)
[21:20] <fabrice_sp> geser, last time I had this error, I added -fno-stack-protector to CFLAGS
[21:20] <BlackZ> fabrice_sp: that's what I suggested :)
[21:20] <fabrice_sp> TBH, I don't understand the fix, so I don't know what to do with it :-)
[21:21] <geser> fabrice_sp: this is always a solution, but as this disables the stack protection I prefer to do this only as a last resort (or if it clear that the right fix e.g. something not linking to libc)
[21:22] <geser> fabrice_sp: the problem is that steam builds on AMD64 fine (with stack protection) but fails on others (like i386)
[21:22] <fabrice_sp> geser, yeah, I know. And why does the proposed change fix the issue? This is what I don't understand
[21:22] <geser> I don't know why it builds on one and fails on other
[21:22] <fabrice_sp> different compilation options?
[21:23]  * fabrice_sp is having this 'builds on amd64 and fails wit i386' with atlas
[21:23] <geser> don't know, and why do it only affects linking
[21:23] <fabrice_sp> maybe stack protection works differetnly on amd64 than i386?
[21:24] <fabrice_sp> kees seems to be the Compilation flags guru. Did you try to speak with him?
[21:25] <geser> I tried but he didn't had an idea either
[21:25] <fabrice_sp> pff
[21:25] <fabrice_sp> I'll sponsor it, and see what happens then
[21:26] <geser> I guess a gcc guru is needed here too. I didn't try to ask doko about this yet
[21:26] <fabrice_sp> by the way, does the same happens in Debian?
[21:27]  * fabrice_sp remembers compialtion options being differetn there
[21:27] <geser> don't know. Does Debian have stack protection enabled?
[21:27] <kees> Debian doesn't enable stack protector by default, no.
[21:28] <fabrice_sp> dobey, if it's a python package, you can try with Debian first: they are very active and very friendly :-)
[21:28] <fabrice_sp> so it does not happen the smae there, then
[21:29] <geser> it might also be caused by the combination of eglibc and gcc version Ubuntu uses. I remeber FTBFS in lucid that didn't affect Debian yet as that eglibc version was only in experimental
[21:29] <dobey> fabrice_sp: right. i think we'll only do that though, when we start getting our things that depend on it into debian. i think right now we just want to have it in universe.
[21:30] <fabrice_sp> dobey, by eperience, I would say it's quicker to get your package in Ubuntu through Debinan than revu :-)
[21:31] <fabrice_sp> s/debinan/Debian/
[21:31] <ScottK> dobey: This is particularly true for Python stuff done through the Python packaging teams.
[21:32] <NorthernLights> dobey: i added a simple comment.
[21:33] <ajmitch> morning
[21:33] <geser> Hi ajmitch
[21:33] <fabrice_sp> evening ajmitch
[21:33] <NorthernLights> fabrice_sp: i had 2 packages into Debian after waiting for months to get someone check it on REVU. Once i decided to go for Debian it took me like 1-2 weeks to get it done
[21:33] <NorthernLights> that was 1-2 years ago so
[21:34] <NorthernLights> i'm now retrying the ubuntu way to see how it goes
[21:34] <fabrice_sp> NorthernLights, it's still the case for python packages
[21:34] <ajmitch> it'll probably still be slow
[21:34] <fabrice_sp> if you find a team for your package, it will be quite quick
[21:34] <fabrice_sp> in Debian, I mean
[21:34] <ajmitch> given the length of the queue on REVU, packages that are just silently uploaded are likely to sit there
[21:34] <NorthernLights> Right
[21:35] <NorthernLights> Debian team was nice to me (although very picky on package "problems" :))
[21:35] <fabrice_sp> yes, just like m.d.o
[21:35] <NorthernLights> python team i meant
[21:35] <fabrice_sp> so we are :-)
[21:35] <ajmitch> that's expected :)
[21:35] <dobey> ajmitch: what is not "silently uploaded" ?
[21:35] <NorthernLights> aha
[21:35] <dobey> ajmitch: poking people in the face? :)
[21:35] <ajmitch> dobey: that helps :)
[21:37] <ajmitch> though for many packages I think debian is still preferable, though I can understand why people don't want to try & maintain in both
[21:37] <NorthernLights> thing with Debian is I find the process old-looking
[21:37] <dobey> well, i'm not a DD, and only have PPU for a few packages in ubuntu
[21:38] <dobey> so eh. but there are other reasons i only want this package in ubuntu right now :)
[21:38] <kees> geser, fabrice_sp: I'm poking at steam now while waiting for a USN to publish.  :)
[21:38] <ajmitch> dobey: so it's a case of finding sponsors for both
[21:38] <ajmitch> yeah I understand, work pressures & all :)
[21:38] <fabrice_sp> kees, cool. Thanks!
[21:38] <dobey> not so much
[21:38] <ajmitch> DPMT are usually helpful & quick
[21:38] <dobey> mostly upstream pressures :)
[21:39]  * ajmitch wishes he could copy & paste properly into virtualbox
[21:39]  * NorthernLights can do it quite well!
[21:39] <ajmitch> across computers, with x2x :)
[21:39] <micahg> ajmitch: why not?
[21:40] <hyperair> synergy!
[21:40] <ajmitch> micahg: dunno, I don't dig into the mysteries of the X clipboard
[21:40] <micahg> ajmitch: I think it WFM
[21:40] <NorthernLights> yeah, synergy server on xp to ubuntu synergy client to maverick ubuntu guest works for me
[21:40] <ajmitch> I just want to be able to copy a .dsc from firefox on one machine into a terminal on a sid vm on my laptop
[21:40] <micahg> ajmitch: do you have the virtualbox addons installed
[21:40] <ajmitch> yes
[21:41] <micahg> ajmitch: oh, a file, use a share
[21:41] <NorthernLights> oh i get it; yep, would be great
[21:41] <ajmitch> not a file, just the URL
[21:41] <NorthernLights> i sometimes find myself trying unconsciounessly too
[21:41] <micahg> ajmitch: that should work
[21:41] <NorthernLights> yep
[21:41] <ajmitch> sure, it should
[21:41] <fabrice_sp> dobey, your watch file does not work
[21:41] <micahg> ajmitch: is seamless integration on?
[21:41]  * ajmitch just wants to look at this mocker package from dobey in sid
[21:42] <hyperair> afaik the clipboard integration doesn't require seamless integration to be turned on
[21:42] <ajmitch> micahg: no, debian is in a window with the additions installed
[21:42] <kees> geser, fabrice_sp: source/libxslt/Makefile.in  s/LD/CC/ in the libxslt.so rule seems to fix it.
[21:43] <dobey> fabrice_sp: ah i see why. thanks
[21:44] <kees> fabrice_sp: er, no, I take that back, one moment
[21:44] <fabrice_sp> ok
[21:44] <fabrice_sp> the proposed fix is s/ld -E/gcc/ in sources/configure
[21:44] <geser> kees: sounds similar to the fix from bug 588519. Do you have an idea why?
[21:44] <kees> fabrice_sp: yeah, that's correct
[21:44] <NorthernLights> I know I already asked but since there's nice people checking a python package... mine is http://revu.ubuntuwire.com/p/killrogues
[21:45] <fabrice_sp> geser, this is what I was typing :-)
[21:45] <kees> geser: gcc is doing something smarter than what ld does.  trying to uncover the root cause now
[21:47] <kees> geser: this is starting to get too far down into compiler fun.  gcc calls collect2 instead of ld in that invocation, but it seems to DTRT.
[21:47] <kees> I will add a note to the CompilerFlags wiki page about ld vs gcc
[21:48] <geser> kees: is it safe to replace "ldd -E -shared" with "gcc -shared"? I don't know enough about linking to know what -E exactly does and therefore was hesitant to sponsor this.
[21:48] <fabrice_sp> so di I :-)
[21:50] <kees> geser: based on what I seein the resulting ELF files, it looks correct.
[21:50] <kees> -E controls how much is being exported, and since the build does finish and links correctly in the end, it looks like gcc -shared is DTRT
[21:51] <kees> hmm, though steam-lib ships a .so.  let me double-check
[21:51] <fabrice_sp> dobey, you should the packaging bug in your changelog
[21:52] <fabrice_sp> close
[21:52]  * fabrice_sp should go to bed :-/
[21:52] <dobey> is there one? :)
[21:52] <NorthernLights> Is it just me or is there a lot of french people in the Debian project?
[21:53] <fabrice_sp> dobey, maybe there should have one?
[21:53]  * fabrice_sp doesn't remember if the policy request to have a bug report
[21:53] <dobey> ah there is one
[21:53] <fabrice_sp> :-)
[21:53] <geser> kees: I guess you don't have an idea why this FTBFS is architecture specific, right? What does ld on AMD64 (or armel) different from ld on i386 (or powerpc) that it once works and fails in the other case.
[21:54] <kees> geser: i think it's related to how the archs expose "hidden" symbols; amd64 is very explicit, so it manages to find the symbol without extra help.
[21:57] <NorthernLights> dobey: clem@frle-0207-virt:~/temp/mocker-0.10.1+r54$ uscan
[21:57] <NorthernLights> mocker: remote site does not even have current version
[21:57] <dobey> fabrice_sp: i've fixed both of those issues now.
[21:57] <dobey> NorthernLights: already fixed
[21:57] <NorthernLights> oops yes i just saw it
[21:57] <fabrice_sp> dobey, ok. I'll have a deeper look tomorrow morning
[21:58] <dobey> fabrice_sp: ok, thanks :)
[21:59] <fabrice_sp> good night all
[22:00] <kees> geser: it looks like steam isn't passing CFLAGS into the configure either.
[22:00] <NorthernLights> dobey, i it still tells me the same
[22:00] <kees> source/libxslt seems to unconditionally reset CFLAGS to -O3 :(
[22:00] <dobey> NorthernLights: eh?
[22:01] <dobey> bother, why is it doing that
[22:01] <NorthernLights> or maybe the previoius package was still in my browser's cache
[22:01]  * NorthernLights is tired
[22:02] <dobey> no
[22:02] <dobey> it's saying that for me too
[22:03] <dobey> but i don't know why
[22:04] <dobey> oh
[22:04] <dobey> because it's a snapshot, not a release
[22:04] <NorthernLights> dobey, your version is 0.10.1+r54 but launchpad only has 0.10.1
[22:04] <NorthernLights> yep
[22:04] <dobey> yes
[22:04] <ajmitch> so it is still active upstream? :)
[22:05] <dobey> mildly, yes
[22:05] <ajmitch> 2 commits in 2 years, I guess that just means it's stable enough
[22:06] <dobey> yeah, though i plan on poking upstream a bit more soon :)
[22:06]  * NorthernLights is going to bed
[22:07] <NorthernLights> see you
[22:29] <dupondje> An own wiki, do we name it with my nick or real name ?
[22:29] <dupondje> wiki-page :)
[22:32] <hyperair> up to you
[22:32] <hyperair> i named my wiki page hyperair
[22:32] <geser> don't know if it's written down somewhere but all the application mails I just checked used real name
[22:32] <hyperair> geser: really?
[22:32]  * micahg used his nick
[22:33]  * micahg hasn't applied yet though (on the list for tonight :) )
[22:36] <ScottK> hyperair and dupondje: The wiki name is listed in your LP profile.  One is proposed if you don't have one.
[22:37] <geser> hyperair: yes, you are one of two exception I can find in the application mails in my mailbox
[23:29] <funkyHat> I'm having a go at fixing this https://bugs.edge.launchpad.net/ubuntu/+source/software-properties/+bug/594368 and I've noticed that running dch-i sets the version to 0.75.10ubuntu1... should I change this as it doesn't appear to be a package that's synced from debian?
[23:32] <arand> funkyHat: I guess it should be 0.75.10-0ubuntu1 for maverick, but consider sending the fix to debian as well, I reckon.
[23:33] <funkyHat> arand: it shouldn't just be 0.75.11?
[23:33] <arand> funkyHat: If it's ubuntu-native, yes.
[23:34] <arand> Althought, probably safer to wait for someone more knowledgable than me...
[23:34] <funkyHat> I'm pretty sure it is, the previous versions are (0.75.10) lucid (0.75.9) lucid (0.75.8) lucid
[23:35] <arand> And that forward to debian, is rather forward upstream, whatever that is.
[23:36] <funkyHat> I think "upstream" is the project on launchpad
[23:37] <arand> funkyHat: Seems to be ubuntu native https://edge.launchpad.net/software-properties then I guess you are correct in the versioning, yes
[23:37] <arand> SInce upstream is in fact ubuntu
[23:54] <funkyHat> Oops... I requested to have it merged to lp:ubuntu/software-properties when it probably should have been lp:software-properties