[00:06] <geser> micahg: once you get the "xubuntu" package set into this collection, the FTBFS will list it
[00:51] <micahg> geser: great, thanks
[01:06] <pting> is there a command to preseed user/group ids? i want to sync up all the system user/group ids
[01:06] <pting> nvm, i'll check with #ubuntu-server
[03:50] <micahg> is bzr mark-uploaded the same as debcommit -r?
[04:17] <lifeless> micahg: no, sadly.
[04:17] <micahg> lifeless: so I need to do mark-uploaded before or after debcommit -r?
[04:18] <micahg> hmm, it says I already marked it uploaded and I used debcommit -r
[04:32] <lifeless> ah, perhaps its been fixed
[05:25] <micahg> ebroder: so, I should've just uploaded those builds w/version issues?
[05:25] <ebroder> doko uploaded them a few hours ago. He fixed the version before uploading
[05:25] <micahg> ebroder: ah, ok
[05:26] <ebroder> I'm generally in favor of just making minor fixes yourself and pointing them out to the contributor after the fact, instead of making them go through another round of bikeshedding, but opinions vary
[05:28] <micahg> I did that earlier tonight for ofono, I fixed up the changelog entry a little
[07:03] <dholbach> good morning!
[09:38] <AnAnt> Hello, I am getting this build failure on natty: http://launchpadlibrarian.net/60640251/buildlog_ubuntu-natty-i386.drawtiming_0.7.1-2_FAILEDTOBUILD.txt.gz  , yet it builds fine in maverick. Note that both natty & maverick have the save version of graphicsmagick.
[09:38] <AnAnt> build fails during linking
[09:38] <AnAnt> any clues ?
[09:53] <evaluate> AnAnt, I'm a newb with packaging myself, but are you sure you only need 'graphicsmagick-imagemagick-compat' in the Build-Depends?
[09:56] <mr_pouit> AnAnt: probably the linking order (the .o files are after the libs)
[10:00] <evaluate> AnAnt, I didn't look at the source files, but I guess you are using the functions from Magick++.h. If that's true, you might want to also include libgraphicsmagick++1-dev in the Build-Depends: http://packages.ubuntu.com/natty/libgraphicsmagick++1-dev/filelist
[10:00] <mr_pouit> AnAnt: in src/Makefile.am, you should not pass the libs through drawtiming_LDFLAGS, but drawtiming_LDADD iirc
[10:01] <evaluate> mr_pouit, just curios, where can you see the source files? :-)
[10:02] <mr_pouit> evaluate: http://git.debian.org/?p=collab-maint/drawtiming.git for example
[10:04] <evaluate> mr_pouit, thanks :-)
[10:06] <evaluate> anyway, I guess including libgraphicsmagick++1-dev in the Build-Depends might fix the problem...
[10:06] <evaluate> just my 0.02...
[10:09] <evaluate> and yeah, the libs should normally be passed to LDADD and not LDFLAGS...
[10:32] <AnAnt> evaluate: that build-dep worked for several cycles
[10:33] <AnAnt> mr_pouit: the linking command line is the same in both natty & maverick
[10:33] <AnAnt> actually I think it may have to do with doko's email: "gcc in natty now passes --as-needed by default to the linker"
[10:33] <evaluate> AnAnt, if it works in some cases, doesn't make it correct. If your package needs libgraphicsmagick++1-dev to build correctly, you should include that in the Build-Depends
[10:36] <evaluate> the same goes with the passing the libs to LDADD
[10:44] <mr_pouit> AnAnt: indeed
[10:56] <AnAnt> mr_pouit: seems, you got the right clue indeed
[11:07] <Riddell> menesis: ping
[11:08] <Riddell> menesis: how does schooltool-common relate to schooltool?
[11:25] <AnAnt> mr_pouit: thanks
[11:34] <menesis> Riddell: it contains some scripts to be shared between schooltool instances.
[11:34] <menesis> Riddell: it was uploaded unintentionally. I plan to redo schooltool server packaging and will likely drop the schooltool-common package.
[11:35] <Riddell> menesis: so I should reject it?
[11:35] <menesis> yes
[11:36] <Riddell> k, good thing I asked..
[12:29] <Zhenech> guys, what's the ubuntu way of doing a "binNMU" (yes I know there is no such thing in Ubuntu)? just need a package rebuilt without further changes on all arches in maverick and natty
[12:50] <Riddell> Zhenech: just upload it
[12:50] <Riddell> or if you don't have upload rights find someone who does
[12:51] <Riddell> for maverick it needs a SRU
[12:52] <Zhenech> thanks to qscintille the package just segfaults after starting using, so getting an SRU permission should be easy :)
[12:56] <mhall119> Riddell: got a minute?
[12:56] <Riddell> mhall119: what's up?
[12:56] <mhall119> couple of things about xdg-launcher
[12:57] <mhall119> I've actually got the package depends fixed in later versions, but was told I didn't need to continue uploading new versions to revu
[12:57] <mhall119> about the name, it uses the xdg-menus, so I thought it would be okay to call it that
[12:58] <mhall119> I didn't know xdg- was a package namespace
[12:58] <Riddell> mhall119: there's no formal namespace, but there are a load of scripts from xdg that are used for cross desktop purposes and I fear this could get confused as one of them
[12:58] <mhall119> or at least not a reserved namespace
[13:00] <mhall119> I didn't want to call it qimo-launcher, because it's more general than just Qimo
[13:01] <mhall119> so is a name change really necessary?  I've already got a project by that name registered with LP
[13:02] <mhall119> or is it just the name of the /usr/bin/xdg-launcher file that you're concerned about?
[13:03] <Riddell> I'm concerned about both the package name and the binary file name
[13:04] <mhall119> the only xdg-* package names I see on Maverick are xdg-utils and xdg-user-dirs
[13:04] <Riddell> yes, and this sounds a lot like it's related to xdg-utils
[13:04] <Riddell> it could be an alternative name for xdg-open
[13:05] <maco> it sounds like a cross-DE version of gnome-open or whatever the kde command for that is
[13:05]  * maco should probably learn that command, now that she's a kde user
[13:05] <mhall119> okay, so what if I called it xdg-launcher-panel?
[13:05] <mhall119> or xdg-panel-launcher
[13:06] <Riddell> that sounds like it's a script from the XDG group to launch a panel
[13:06] <maco> mhall119: panel-xdg-launcher!
[13:07] <maco> then the xdg is in the middle instead of looking like a prefix
[13:07] <Riddell> I'd think application-launcher-panel or application-menu-panel is more along the lines
[13:07] <c2tarun> i wanted to install gnome into my chroot env. i just want to know the difference between gnome-session and ubuntu-desktop. can anyone please tell ?
[13:07] <maco> im afraid you're surrounded by kde users at the moment
[13:08] <cdbs> gnome-session is a package part of the GNOME desktop, ubuntu-desktop is a metapackage that installs all gnome packages
[13:08] <cdbs> maco: I am here nevertheless :D
[13:08] <maco> you were hiding!
[13:08] <cdbs> hiding since you people were discussion KDE :D
[13:09] <Riddell> actually we're discussing a gnome panel replacement
[13:09]  * maco sighs in the general direction of that unfinished gnome-panel patch that will never be finished
[13:09] <mhall119> it's not a replacement for gnome-panel, it's just a simple panel with XDG Menu entry launchers
[13:09] <maco> ooh good for xmonad users!
[13:10] <cdbs> maco: If the discussion is about Ubuntu Desktop Edition, then, as you know, we no longer need gnome-panel
[13:10] <mhall119> maco: depends on what functionality they need
[13:10] <cdbs> Unity is working well at such an early stage
[13:10] <mhall119> it's written to replace the bottom Xfce panel in Qimo
[13:10] <maco> cdbs: oh no that was an offhand about a patch i was working on a few weeks before switching to kde, to let the panel have a gradient without that stupid repeating png issue
[13:10] <Riddell> mhall119: the term "XDG Menu" is horribly geeky and exposes an implementation detail.  I always call it the application menu
[13:11] <maco> cdbs: it was almost 2 years ago now...and what with unity and gnome-3, itll never be
[13:11] <cdbs> maco: you used to develop for ubuntu-desktop and gnome packages ? ;)
[13:11] <mhall119> I think maco hacks on anything she can get her hands on
[13:11] <maco> mhall119: nah just the broken stuff!
[13:11] <mhall119> like I said
[13:11] <maco> cdbs: ive been doing gtk stuff since 2007
[13:12] <cdbs> ah, I am pretty new in the open-source scene, though I had been developing a few Windoze apps earlier
[13:12] <maco> switched to kde in 2009 and just started qt earlier this year
[13:12] <mhall119> Riddell: so is the hangup mostly on the xdg- part, not the -launcher part?
[13:12] <Riddell> mhall119: yes
[13:12] <cdbs> I got to understand the joy of developing when I moved to open-source :D
[13:13] <mhall119> Riddell: on both package, /usr/bin/xdg-launcher and /usr/share/pyshared/xdglauncher.py
[13:13] <Riddell> cdbs: you might be new but your nick is already obsolete, shouldn't it be debhelper7 now? :)
[13:13] <cdbs> Riddell: registered :(
[13:13]  * maco snickers
[13:13] <cdbs> I settled with this one because it wasn't registered yet
[13:13] <Riddell> mhall119: yes
[13:13] <mhall119> :(
[13:14] <mhall119> okay, so I'll have to go re-name everything
[13:14] <mhall119> is there any kind of naming guidelines or do's and don'ts, so I don't have this happen again?
[13:14] <Riddell> don't use names used by other groups :)
[13:31] <ScottK> cdbs: How's courier coming?
[13:31] <cdbs> ScottK: lol, the upload JUST got accepted
[13:31] <ScottK> cdbs: Great.
[13:31] <cdbs> the moment I got the mail, I was like : Lets tell ScottK
[13:31] <cdbs> :D
[13:32] <ScottK> We all make mistakes, it's what you do about fixing them that counts.
[13:32] <cdbs> if you are subscribed to natty-changes, you would have the mail there
[13:32] <cdbs> ScottK: yup, I agree
[13:32] <cdbs> soryr for the late response, I am busy in school work nowadays
[13:33] <c2tarun> cdbs: to install the desktop should i install ubuntu-desktop or gnome-session will just do it?
[13:33] <cdbs> c2tarun: ubuntu-desktop is what I would recommend, but that would mean installing a large number of packages
[13:34] <c2tarun> cdbs: ok  i m installing gnome-session right now, if needed can i remove it and reinstall ubuntu-desktop
[13:34] <cdbs> c2tarun: if you want ubuntu-desktop, you would simply need to install that
[13:35] <cdbs> no need to remove -session
[13:37] <c2tarun> cdbs: thanks :)
[14:12] <c2tarun> cdbs: i installed gnome-session and exported display to a Xnest screen, now when i tried to start gnome-session i got this error   http://paste.ubuntu.com/543606/   can you please take a look
[14:15] <c2tarun> cdbs: i installed gnome-session and exported display to a Xnest screen, now when i tried to start gnome-session i got this error   http://paste.ubuntu.com/543606/   can you please take a look
[14:22] <cdbs> c2tarun: sorry, I can't help
[14:23] <cdbs> c2tarun: ask that in #ubuntu
[14:40] <DiegoTc> hi guys
[15:43] <hmca> hello , i'm having some problems upgrading my system to python 2.7 under ubuntu, it's a server.... http://pastebin.com/KVbjW8Bt
[15:45] <ScottK> hmca: Ask doko on #ubuntu-devel about that.
[15:46] <hmca> ScottK:thkx
[15:48] <hrw> hi
[15:48] <ScottK> tumbleweed: If the remaining change in https://launchpad.net/ubuntu/+source/claws-mail/3.7.8-1ubuntu1 was "debian/pacthes/series, removing buggy messages from M-o-M" - Why didn't you just sync?
[15:48] <ScottK> Hello hrw
[15:48] <hrw> how much ftfbs page is current?
[15:49] <tumbleweed> ScottK: aarrgh, he got the changelog wrong, I reviewed that one about 5 ttimes today on IRC and thought it was finally right
[15:50] <tumbleweed> ScottK: the body of the patch is right, though
[15:50] <ScottK> tumbleweed: OK.
[15:51] <ScottK> hrw: It's ~current as of today.  I think it refreshes every 6 hours.
[15:51] <hrw> thx
[15:59] <geser> hrw, ScottK: http://qa.ubuntuwire.org/ftbfs/ refreshes hourly
[15:59] <ScottK> geser: Thanks.
[16:00] <hrw> thx geser
[16:12] <hrw> can someone take a look at shadow package? it ftfbs on every arch in natty
[16:13] <hrw> patch 495_stdout-encrypted-password does not apply - http://pastebin.com/jdSXLcbG is my version of it but I am not sure is it proper
[16:14] <ScottK> hrw: I guess talk to ogra.  He uploaded it.
[16:14] <hrw> ScottK: ogra is on holidays now
[16:14] <hrw> but will try to catch him next time
[16:14] <ScottK> OK.  Someone on his team.  Looks like a bit of a mess to sort due to patches not applying.
[17:50] <ari-tczew> ScottK: where can I find steps to backport?
[17:50] <ScottK> !backports | ari-tczew
[18:07] <ari-tczew> ScottK: do I have to upload my backported package to my PPA? or rather upload to Backports PPA is enough?
[18:08] <ScottK> ari-tczew: Neither are required if you are testing it yourself.  As long as the bug says it builds/installs/runs and you've attached any needed debdiff (usually not needed), that's enough.
[18:10] <ari-tczew> ScottK: do I have to prepare a debdiff to modify debian/changelog?
[18:11] <ScottK> ari-tczew: Not if that's all that
[18:11] <ScottK> is needed
[18:11] <ari-tczew> perhaps yes
[18:12] <ari-tczew> ScottK: do I have to affect source package in Ubuntu? (I mean about bug created in maverick-backports)
[18:12] <ScottK> No.  It's preferred you don't.
[18:20] <evaluate> if I have a package that was uploaded to debian, do I need to wait for it to get out of NEW to request a sync in ubuntu or can I request a sync even if it's in NEW?
[18:21] <ebroder> evaluate: It needs to make it out of NEW. But once that's done, it should automatically get synced to Ubuntu
[18:21] <evaluate> ebroder, ok :-)
[18:21] <ebroder> (Assuming it comes out of NEW before our DebianImportFreeze, which is some time around Christmas)
[18:21] <ebroder> (And after DIF, you can just request a sync)
[18:21] <evaluate> ebroder, hmm, not sure, it seemsto take pretty long now that debian is in freeze itself...
[18:22] <ebroder> evaluate: The ftpmasters have been letting packages into unstable during freeze, although that may stop now that Debian is in deep freeze
[18:24] <ScottK> They don't generally stop it, it's just a low priority for their work.
[18:27] <evaluate> well, since they're approaching the release, I'm not sure they'll do anymore imports until that point, also not sure if they'll make it before christmas, since it's only a week...
[18:28] <ebroder> evaluate: That's fine. After DIF, there's sort of a sliding scale in terms of how hard it is to get new packages synced in. Immediately afterwards, it's a manual process, but easy to do. As we work towards beta and RC, it gets harder
[18:30] <evaluate> ebroder, well, that's my fear, that the package won't get into natty either...
[18:33] <ScottK> evaluate: There's no problem getting a sync from Debian up to feature freeze, so we've got time.
[18:35] <evaluate> ScottK, yeah, I sure hope they're done until Feb. 24...
[18:37] <evaluate> btw, does anyone know if there are any plans to include a perl API for the Application Indicator?
[18:40] <ScottK> evaluate: #ayatana is probably a better channel for that question.
[18:40] <evaluate> ScottK, ok :-)
[21:11] <ari-tczew> ScottK: which version should do I use? ~backport1 and target to maverick or ~maverick1?
[21:13] <ebroder> ari-tczew: You know you don't upload the actual backport, right?
[21:14] <ari-tczew> ebroder: I don't understand.
[21:14] <ebroder> ari-tczew: What exactly are you doing?
[21:14] <ebroder> Are you testing or actually trying to upload?
[21:14] <ari-tczew> ebroder: prepare upload to my PPA for testing
[21:14] <ari-tczew> (a backport)
[21:15] <ari-tczew> and I must know what I have to use before ~ppa1
[21:15] <ebroder> ari-tczew: Ah, ok. Just checking. We use ~maverick1. But check out backportpackage in lp:~broder/ubuntu-dev-tools/backportpackage
[21:15] <ScottK> ari-tczew: For a test for a backport I recommend ~maverick1~ppa1.
[21:16] <ari-tczew> ebroder: how it works?
[21:16] <ebroder> ari-tczew: ./backportpackage --from natty --to maverick --upload ppa:ari-tczew/ppa source_package
[21:17] <ari-tczew> ebroder: hmm... it seems to be not in current ubuntu-dev-tools binary. I have to download script and put it into ~/bin
[21:17] <ebroder> ari-tczew: Yes, that's why I gave you the bzr branch to get it from
[22:52] <ari-tczew> ebroder: http://paste.ubuntu.com/543831/
[22:53] <ebroder> ari-tczew: There are some changes to the Python modules ubuntu-dev-tools ships that you need. It's probably easier to have a checkout of my branch and run backportpackage with that as your working directory
[22:54] <ebroder> You could put a wrapper script in your ~/bin that does cd ~/checkout; exec ./backportpackage "$@"
[22:54] <ari-tczew> ebroder: ehh... no have time
[23:00] <tumbleweed> Riddell: re bug 689310, KUBUNTU_NO_DELETE_POT=1 makes zero difference (or am I doing something wrong?)
[23:29] <Riddell> tumbleweed: /usr/lib/kubuntu-desktop-i18n/debhelper/kubuntu-debhelper-langpack-clean.sh says it does rm -rf po/*.pot
[23:30] <Riddell> of course it only does that on the build daemons
[23:30] <tumbleweed> Riddell: I tested in a launchpad chroot
[23:31] <tumbleweed> I do saw that code, I just don't see it actually having any benefit
[23:31] <tumbleweed> s/do//
[23:32] <Riddell> well it's arguable but if it deletes the file it'll make a debian-1.2.3.diff patch and that could get messy
[23:32] <tumbleweed> that's what I tested, look at the debdiff on the bug
[23:32] <tumbleweed> it creates that either way
[23:33] <tumbleweed> so, either KUBUNTU_NO_DELETE_POT isn't what this package needs, or it's not working as expected
[23:39] <Riddell> tumbleweed: you ended up with a great big ugly krename-4.0.4/debian/patches/debian-changes-4.0.4-2+no+delete+pot1 file
[23:39] <tumbleweed> Riddell: and an almost identical +unchanged1 file
[23:40] <tumbleweed> same size, different timestamps
[23:40] <Riddell> hmm well, best convince JontheEchidna, he's the one who added it
[23:41] <tumbleweed> heh, I'll prod him. I don't like maintaining a delta just for cleaning correctly, esp when it doesn't clean correctly
[23:41] <JontheEchidna> KUBUNTU_NO_DELETE_POT=1 is no longer needed, as pkg-kde-tools no longer does l10n stripping for universe packages in the archive
[23:42] <Riddell> i lose
[23:42] <Riddell> reopen the bug then
[23:42] <tumbleweed> hehe, thanks for keeping an eye out, though