[00:00] <ricotz> hmm
[00:00] <ricotz> gilir_, would be great if have some time now
[00:11] <RAOF> micahg, ricotz: Looks good to me now.
[00:11] <ricotz> RAOF, thanks
[00:11]  * micahg verifies again
[00:11] <ricotz> RAOF, doesnt a sponsor count as motu ;)
[00:12] <RAOF> I'd count my go as an ACK, as that's the spirit of the policy, but it's micahg's call. :)
[00:14] <ricotz> that would be great :)
[00:15] <micahg> ricotz: if it's down to the wire, I'll count it, we still have 18 hrs though
[00:16] <ricotz> micahg, it still needs a NEW review, so it would be great if you could upload it
[00:16] <micahg> ricotz: NEW review is fine, anything upload by FF is good
[00:17] <ricotz> micahg, so please do it :)
[00:23] <micahg> ricotz: what I was saying was as long as we upload before FF, we're good, I'd still prefer one more ACK, or a DMB member saying that I can count RAOF's ACK
[00:23] <maco> micahg: email me a link and i'll look when i get home
[00:24] <micahg> maco: ok, thanks :)
[00:24] <ricotz> micahg, alright
[00:25] <ricotz> RAOF, micahg, thank you very much
[00:25] <micahg> ricotz: you're welcome, in the mean time, could you please file a needs-packaging bug in Ubuntu and close it in the changelog?
[00:25] <ricotz> maco, that sounds great :)
[00:26] <ricotz> micahg, ok
[00:38] <ricotz> micahg, https://bugs.launchpad.net/ubuntu/+bug/724040
[00:43] <matttbe> Hello,
[00:43] <matttbe> With fabounet we are two members of the Cairo-Dock project and we want to update the version of Cairo-Dock in Ubuntu Natty.
[00:43] <matttbe> There are 2 bugs reports: https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/723994 and https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/723995
[00:43] <matttbe> Two bzr branches are ready to be merged into ubuntu branches
[00:44] <matttbe> This is the merge proposal: pour les branches à merger: https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock/2.3.0-0rc1/+merge/51034
[00:44] <matttbe> And for our plug-ins: https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock-plug-ins/2.3.0-0rc1/+merge/51035
[00:45] <matttbe> so we are just looking for a nice sponsor :)
[00:46] <matttbe> sorry: This is the merge proposal: this is for the cairo-dock API (cairo-dock core) https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock/2.3.0-0rc1/+merge/51034
[00:46] <micahg> matttbe: do you think there will be a release before beta 2?
[00:47] <matttbe> yes sure
[00:47] <micahg> matttbe: ok, I'll take a look later tonight unless someone beats me to it
[00:47] <matttbe> micahg: thank you :)
[00:48] <micahg> matttbe: you're welcome
[00:50] <matttbe> I also need a second sponsoring for another project: latexila: https://code.launchpad.net/~latexila/ubuntu/natty/latexila/2.0.5/+merge/50544
[00:50] <matttbe> this is the bug report: https://bugs.launchpad.net/ubuntu/+source/latexila/+bug/722408
[00:51] <micahg> matttbe: is there an effort to update these things in Debian as well?
[00:52] <matttbe> micahg: for Cairo-Dock yes (except that the maintainer want to change some files... https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564) and for LateXila too
[00:53] <matttbe> for latexila, it's just because gsettings-desktop-schemas package is still not available on Debian Unstable.
[00:53] <matttbe> and the other maintainer want to wait for it on Debian Unstable
[00:53] <micahg> matttbe: maybe it can be uploaded to experimental then so we can sync :)
[00:54] <matttbe> yes but I guess it's too late to do that before the FF
[00:54] <micahg> I'm happy to get the update in before feature freeze, but I think it would be good if we can sync after that
[00:55] <matttbe> ok but I guess that gsettings-desktop-schemas package will be available on Debian Unstable soon
[00:56] <micahg> ok, well, we can sync bug-fixes until at least beta 2, and just to sync I probably wouldn't do past beta
[00:58] <matttbe> ok
[00:59] <matttbe> but about the sync, will it be a SRU?
[00:59] <micahg> matttbe: no, just a regular sync as long as it's bug fix
[00:59] <matttbe> micahg: ok thank you
[01:00] <micahg> matttbe: you can use requestsync when it's ready in Debian
[01:01] <matttbe> ok
[01:03] <matttbe> about Cairo-Dock packages, I hope that its maintainer will update the version just as we want :-/
[01:03] <matttbe> It's just easier to request a sync and then add a patch for Ubuntu...
[01:05] <micahg> matttbe: well, we can merge if there's a patch on top of it as long as it's bug fix
[01:06] <matttbe> ok :)
[01:21] <psusi> ok, when you close a terminal, all processes on it get a SIGHUP and should die right?
[01:21] <c2tarun> I am getting this error while building. I checked and -lncurses is linked there in Makefile. Why I am getting this error?
[01:24] <c2tarun> http://paste.ubuntu.com/571451/ error
[01:24] <c2tarun> I am getting this error http://paste.ubuntu.com/571451/ while building. I checked and -lncurses is linked there in Makefile. Why I am getting this error?
[01:36] <c2tarun> ping
[02:08] <gilir_> micahg, if ricotz need another ACK for dockmanager, he have mine :)
[02:09] <micahg> gilir_: ok, I'll upload in a bit, thanks :)
[02:18] <c2tarun> micahg: ping
[02:19] <micahg> c2tarun: I don't have an answer for you :)
[02:20] <c2tarun> micahg: no prob :)
[02:21] <micahg> gilir_: did you mean 1.9.2 in your bug for gecko-mediaplayer?
[02:22] <gilir_> micahg, I mean the 1.9.X in natty, doesn't remember the correct number :)
[02:22] <micahg> yep, 1.9.2, I saw you did the update to 1.0, does lubuntu actually use gecko-mediaplayer?  (we're dropping xulrunner-1.9.2 from natty before release)
[02:24] <gilir_> we try to use it :)
[02:24] <gilir_> natty will only ship xulrunner 2.0 ?
[02:24] <micahg> gilir_: yes
[02:25] <micahg> in universe if we're lucky :)
[02:26]  * micahg will be back in a bit
[02:26] <ScottK> micahg: Still working on it.  Not yet.
[02:27] <ScottK> Waiting on a Launchpad change, then I can take the proposal to the tech board.
[02:30] <micahg> ScottK: ok, let me know if I can help (can't promise)
[02:30] <ScottK> Will do.
[02:30] <micahg> and I will try again next cycle for ubuntu-backporters :), just too much on my plate right now :)(
[05:41] <maco> micahg: i uploaed it already
[05:41] <micahg> maco: ha, that makes 2 of us then :)
[05:42] <maco> well damn
[05:42] <micahg> they'll reject one, it's ok :)
[07:32] <dholbach> good morning
[07:33] <micahg> good morning dholbach
[07:33] <dholbach> hi micahg
[07:38] <ricotz> micahg, hi, thanks for uploading :) -- but why is dockmanger in the queue twice now?
[07:38] <micahg> ricotz: because maco uploaded before me :)
[07:38] <ricotz> micahg, ok ;)
[08:19] <kklimonda> ah, good to know :)
[08:20] <kklimonda> ups..
[08:20] <kklimonda> good morning
[09:11] <micahg> tumbleweed: I had the same issue as bug 724054 using a backport from natty
[09:11] <tumbleweed> micahg: on which release?
[09:12] <micahg> tumbleweed: maverick
[09:12] <micahg> ii  python-debian                                   0.1.16ubuntu1
[09:13] <micahg> that was with 0.117
[09:17] <tumbleweed> micahg: that import doesn't fail in my maverick chroot
[09:17] <micahg> tumbleweed: I have locale C still for some reason I think
[09:17] <micahg> err, maybe not
[09:17] <micahg> I'm on amd64
[09:20] <tumbleweed> micahg: grabbing a maverick build from https://launchpad.net/~udt-developers/+archive/daily/+packages works for me (although you need maverick-updates enabled to get a recent enough python)
[09:21] <micahg> maybe it was a bug in 0.117, I didn't have the problem in 0.116
[09:24] <tumbleweed> micahg: you will definitly run into "UnboundLocalError: local variable 'ubuntutools' referenced before assignment" in 0.117
[10:06] <c2tarun> micahg: ping
[10:26] <Leon-Wallch> micahg: Did you finished checking package Wallch?
[10:41] <c2tarun> micahg: ping
[10:46] <micahg> Leon-Wallch: yes, I think everything has been fixed
[10:48] <Leon-Wallch> micahg: Nice! So are you able to advocate the package?
[10:49] <micahg> Leon-Wallch: I commented on REVU (I don't have and advocate button for some reason)
[10:49] <tumbleweed> micahg: you need a revu admin to give you advocation abilities
[10:52] <Leon-Wallch> tumbleweed: do you know someone that have those advocation abilities?
[10:52] <tumbleweed> Leon-Wallch: I do, having a look at it now
[10:52] <tumbleweed> micahg's vote still coutns
[10:53] <Leon-Wallch> micahg: Thank you for your help!
[10:53] <micahg> Leon-Wallch: you're welcome
[10:53] <tumbleweed> Leon-Wallch: do you have any plans to maintain this in Debian?
[10:54] <Leon-Wallch> tumbleweed: If Debian has Gnome Desktop, why not?
[10:55] <Laney> that's what I like to hear!
[10:57] <tumbleweed> um, should those icons really be installed into /usr/share/icons/{gnome,oxygen} ? they look like they belong in hicolor
[10:57] <tumbleweed> unix:shortcutfiles.extra is scary
[10:58] <hakermania> tumbleweed: Yes, it is. What do you suggest?
[10:59] <tumbleweed> that's part of the packaging, probably belongs in debian/rules / debian/install
[10:59] <hakermania> tumbleweed: Is it wrong to be there?
[10:59] <tumbleweed> the uptream makefile shouldn't have debian/tmp/$packagename hardcoded into it
[11:00] <c2tarun> micahg: ping
[11:00] <tumbleweed> hakermania: it's not wrong, it'll work. But it'll only work in the context of debian packaging
[11:00] <hakermania> So, should I jsu t copy-paste all the .extras to the debian/rules?
[11:00] <micahg> c2tarun: pong
[11:00] <tumbleweed> hakermania: also, errors won't be detected unless you "set -e" near the beginning
[11:01] <c2tarun> micahg: hi, I need a bit help on bug 724245 you looked on it.
[11:01] <tumbleweed> hakermania: it can probably be done a lot more efficiently than that by dh_install
[11:02] <hakermania> tumbleweed: I need a suggestion here. I'm unexperienced.
[11:02]  * micahg has learned about package review from tumbleweed this morning :)
[11:02] <micahg> c2tarun: I don't see a comment there
[11:03] <tumbleweed> micahg: I don't know how strict we should be on new packages, but my debian mentor always found fault in my work :P
[11:04] <micahg> tumbleweed: even when it was uploaded?
[11:04] <hakermania> tumbeweed: What should I do with the .extras? Move them to debian/rules and place "set -e" at the start of the rules file?
[11:04] <c2tarun> micahg: no it was not about the comment. I want to ask about the log. The error there was a gtk warning, so i guess its due to absence of gnome from my pbuilder? (am i right?)
[11:04] <tumbleweed> micahg: well there are always latent bugs you don't spot
[11:04] <micahg> c2tarun: idk, I haven't seen the logs
[11:05] <c2tarun> micahg: you are Micah Gersten? you posted the build-log? isn't it?
[11:05] <micahg> c2tarun: I think you gave me the wrong bug #
[11:06] <tumbleweed> hakermania: I'd start by making your upstream buildsystem do a sane install when it's not part of a debian package build. And I don't like that it tries to detect whether it's in a debian build or not
[11:06] <c2tarun> micahg: oh very sorry bug 719725 :(
[11:06] <tumbleweed> hakermania: I know we are up against feature freeze and you want to get this in, and that you've been working on getting it in for months
[11:07] <tumbleweed> so I'm tempted to accept it, but I would like to see it get cleane dup
[11:08] <micahg> c2tarun: oh, I have no idea, you might want to look at that test file though and walk through it, maybe someone else can help (might just be there's no X server accessible from pbuilder in which case, that test should probably be disabled)
[11:08] <hakermania> tumleweed: True. So, I will remove all the checks for the debian/ folder. Is this right?
[11:09] <tumbleweed> hakermania: yeah, the debian-specific things really belong in the debian packaging, not the upstream buildsystem
[11:09] <hakermania> OK
[11:10] <c2tarun> micahg: I dont have ubuntu machine, can you please build it on you ubuntu machine and check that whether are you getting the same error or not?
[11:10] <micahg> c2tarun: that was from a natty pbuilder
[11:10] <c2tarun> micahg: I mean ubuntu natty machine :|
[11:12] <c2tarun> micahg: ubuntu natty machine with ubuntu-desktop installed on it.
[11:15] <hakermania> tumbleweed: By telling "sane install" do you mean keeping the part that installs the files into /debian/wallch/path/ or directly into /path (because it checks for debian/, if it is there it installs the files into it, if not, normally in the system)
[11:18] <c2tarun> can anyone help me with this error http://paste.ubuntu.com/571655/
[11:19] <tumbleweed> hakermania: during a debian build, your Makefile will be passed INSTALL_ROOT=debian/wallch (DESTDIR in the gnu build recommendations, but AFAIX INSTALL_ROOT in qmake)
[11:20] <tumbleweed> it should then install into debian/wallch/usr/bin instead of /usr/bin
[11:21] <hakermania> tumbleweed: Go it :) I will place the files into the system normally, but during the build debian/wallch/ will be considered as /  .Thx for the info !
[11:24] <hakermania> tumbleweed: What about the debian/rules file? Should I place the .extras there (+plus placing "set -e" at the beggining) and remove them from the .pro file??
[11:47] <Leon-Wallch> tumbleweed: Are you here?
[11:53] <tumbleweed> hakermania: that'll work, although you can use dh_install to install those for you (read its manpage)
[12:15] <c2tarun> I was looking on this page, there is a package name kftpgrabber, that package build succesfully on natty machine. Why is that package is in that list? I mean when is the last time that list gets updated?
[12:20] <Bachstel1e> c2tarun: afaik, each package is "updated" on every build attempt
[12:21] <Bachstel1e> so if it builds fine now, someone should reques a rebuild of it
[12:21] <Bachstel1e> request*
[12:21] <c2tarun> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[12:21] <c2tarun> here is the list^^
[12:23] <c2tarun> Bachstel1e: ok, so any suggestions for me for that package? as there is no ftbfs bug regarding that package on LP
[12:24] <Bachstel1e> I'm not sure what the proper procedure is in this case (i.e. how you request a rebuild), someone else probably does
[12:24] <geser> c2tarun: kftpgrabber is in the outdated section, which means that a newer package exists in the archive
[12:25] <geser> which might (or might not) have fixed the FTBFS
[12:26] <c2tarun> geser: well the version I pulled from natty archives is the same as the version mentioned in the list.
[12:27] <c2tarun> geser: so there is no newer package. its only this one
[12:27] <geser> c2tarun: you sure? because the archive rebuild was done with 0.8.99~svn1044538-3 and current one is 0.8.99~svn1044538-3ubuntu1
[12:27] <geser> c2tarun: see also https://launchpad.net/ubuntu/+source/kftpgrabber/0.8.99~svn1044538-3ubuntu1
[12:28] <c2tarun> geser: ah very sorry I didn't noticed ubuntu1?
[12:29] <geser> no problem as nothing bad happened
[12:30] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/571688/
[12:32] <hakermania> tumbleweed: I'll edit the rules file. Before or after the "%:  dh $@" should I place the extras?
[12:35] <geser> c2tarun: see line 26: the -lncurses is before the object file (main.o) which uses symbols from the library. And with "ld --as-needed" the order does matter. The fix is to move the "-lncurses" to the end of the linker call
[12:37] <tumbleweed> hakermania: generally blewo
[12:46] <c2tarun> geser: it worked :) thanks
[12:46] <c2tarun> geser: I created a patch in which I edited the Makefile. Is it correct or should I edit Makefile directly?
[12:47] <geser> c2tarun: does the package use a patch-system?
[12:47] <c2tarun> geser: yup, I guess native quilt
[12:48] <geser> c2tarun: I hope you fixed it better than it got fixed in Debian bug #612176
[12:48] <geser> than make a proper patch for the used patch system
[12:49] <c2tarun> geser: I am not getting what are you trying so say?
[12:51] <geser> c2tarun: when you look at the attached patch in that bug, you will see angelabad "fixed" it by moving LDFLAGS to the end of the call
[12:51] <hakermania> tumbleweed: Does this look good to you? : http://paste.ubuntu.com/571700/
[12:52] <tumbleweed> hakermania: doesn't look like a valid make file
[12:52] <tumbleweed> hakermania: #ubuntu-packaging may be a better place to move this...
[12:52] <geser> it fixes it but it's still the wrong fix. A better fix would be to use move "-lncurses" to LIBS and use it at the end of the linker call (and let LDFLAGS where is it and not overwrite it)
[12:52] <c2tarun> geser: yup I did the same :(
[12:56] <c2tarun> geser: sorry I am new so not getting. are you saying about creating any variable of name LIBS adding lncurses to it and add that var to the end of line?
[12:56] <geser> c2tarun: yes
[12:58] <geser> c2tarun: see line 15 of the Makefile, instead of assigning "-lncurses" let it assign to LIBS (a common variable name for that purpose) and add it to the end of line 22 (the $(CC) call)
[12:58] <c2tarun> geser: yup I am working on it. just few minutes
[13:00] <geser> no hurry, it's not a race :) better take the time you need
[13:01] <c2tarun> geser: done :) here is the patch http://paste.ubuntu.com/571702/ can you please take a look.
[13:04] <geser> c2tarun: almost, don't forget to remove the "LDFLAGS=-lncurses" line
[13:05] <geser> it's not needed anymore
[13:06] <c2tarun> geser: ya I thought that as well but what is the diff b/w removing LDFLAGS and adding LIBS at end and moving LDFLAGS at end?
[13:10] <geser> LDFLAGS has an other purpose (like adding library search paths (-L) and other linker options), it's not for adding libs for linking
[13:10] <c2tarun> geser: ok, so its just the convention?
[13:12] <c2tarun> geser: http://paste.ubuntu.com/571704/ can you please take a look now ?
[13:12] <geser> I'm not an expert on this, but in the past most devs got lazy and put libs into LDFLAGS as it worked
[13:14] <geser> c2tarun: let LDFLAGS in the $(CC) like so it uses the "default" LDFLAGS which get set by dpkg-buildpackage: $(CC) $(LDFLAGS) -o $(EXNAME) $(SOURCES:.c=.o) $(LIBS)
[13:14] <geser> just don't overwrite them anymore which was done in the past
[13:18] <c2tarun> geser: new one http://paste.ubuntu.com/571706/
[13:19] <geser> c2tarun: looks good now (only the cosmetic minor issue of the extra newline (line 17 in your paste))
[13:20] <c2tarun> geser: ok, got it. I'll fix it too. What next? I mean what to do now? should I file a bug on LP and upload the patch?
[13:21] <geser> c2tarun: yes, file a bug (for sponsoring; and close it in your changelog entry), prepare a debdiff for sponsoring and as bonus points send your better fix to the Debian bug
[13:24] <c2tarun> geser: ok, and in the changelog entry I should write just added patch FTBFS and bug number?
[13:28] <geser> c2tarun: yes, something like that
[13:30] <c2tarun> geser: thanks :)
[13:30] <hakermania> Can anyone check if this makefile has right syntax? http://paste.ubuntu.com/571714/ (in #ubuntu-packaging I don't get an answer)
[13:37] <Rhonda> If it has right syntax you will notice when you run it. :)
[13:37] <Rhonda> But why not use debian/dirs and debian/install files instead?
[13:38] <Rhonda> If you are using debhelper please use it to its full extend, otherwise it might confuse people working on the package after you.
[13:39] <Rhonda> Also, gzip isn't needed, that's done by dh_compress
[13:45] <hakermania> Rhonda: what is debian/dirs for?
[13:45] <Rhonda> Read up on man dh_installdirs
[13:51] <hakermania> Rhonda: The manpage not very helpful. nothing mentioned about debian/dirs (only package.dirs). In short words, should I place there any directories that my package needs (like /usr/share/wallch) ?
[13:54] <arand_> hakermania: I think it creates those directories in the debian/DEBIAN directory... but I could be wrong...
[13:56] <hakermania> arand_: Thx....But I need to create these dirs into the system, manually. Can dh_installdirs do this? Or should I choose the rules file instead and manually use 'mkdir  -p'
[13:56] <Rhonda> hakermania: package.dirs is the one specific to that binary package, dirs is one that gets applied to all binary packages mentioned in debian/control. And some directories you don't even need to list in there from my understanding, dh_install creates them automatically if it needs them for installing files
[13:58] <hakermania> Rhonda: i will place all I need (3-4), to be sure.
[13:58] <Rhonda> hakermania: Still, this is pretty basic packaging questions, there are often regular packaging tutorials in #ubuntu-classroom, this is really not the channel in which to discuss basic understanding difficulties with how debhelper works.
[13:58] <hakermania> Rhonda: Sorry.
[13:58] <Rhonda> No big deal, just stating. :)
[14:13] <ari-tczew> micahg: Ubuntu Security Team? wth?
[14:17] <Rhonda> !wtf | ari-tczew
[14:20] <ari-tczew> Rhonda: wth is more gentle than wtf
[14:28] <rowinggolfer> I am looking for best practice on packaging the translations created by the rosetta team into a deb package. I note with interest that a debian proposal for a new package architecture for this purpose called  tdeb is gaining momentum, and to be introduced into the next debian release (ie.. the distant future).
[14:29] <rowinggolfer> I wonder if best practice may be to bypass packagin altogether, and have the application (optionally) check for new translations at run time.
[14:30] <rowinggolfer> I have googled, but find no consensus.
[14:31] <hakermania> Rhonda: Can you give me private some help, as here it is not for packaging discussions? I can't see why clean isn't running...Pf...
[14:32] <Rhonda> hakermania: Unfortunately my time is pretty limited right now, including the forseeable future, sorry. :/
[14:32] <hakermania> Rhonda: No problem...
[14:38] <rowinggolfer> ok.. thanks. this may help me. https://wiki.ubuntu.com/Specs/LanguagePackUpdatesSchedule
[14:42] <Rhonda> hakermania: I hope you found this wiki page: https://wiki.ubuntu.com/PackagingGuide
[14:43] <hakermania> Rhonda: Don't bother with me :) I know how it is when you have a job to do and someone disturbs :) I'll find a solution soon.
[14:43] <joaopinto_> Rhonda, I am sorry, but since when is this channel not appropriate for packaging questions ?
[14:44] <ari-tczew> kees: do you will manage with upload nvclock?
[14:44] <joaopinto> hakermania, #ubuntu-classroom is for pre-schedule sessions, not a channel advised to join randomly and ask questions
[14:45] <hakermania> joaopinto: OK
[14:45] <Rhonda> joaopinto: Not in itself, but things like "what does debian/dirs do" are rather expected (and covered in the PackagingGuide), at least from my understanding.
[14:46] <joaopinto> Rhonda, right, which does not invalidate this channel as a valid resource to get such information :)
[14:46] <Rhonda> I didn'
[14:47] <joaopinto> erm, wait, there is an  #ubuntu-packaging ?
[14:47] <Rhonda> I didn't say so, only after a while of questions along the lines that showed lack of some basic knowledge.
[14:47] <joaopinto> hum, I was not aware of #ubuntu-packaging
[14:47] <Rhonda> joaopinto: "(in#ubuntu-packaging I don't get an answer)"
[14:47] <joaopinto> ah :\
[14:48] <Rhonda> That's very unfortunate and I'm sorry for that, and if I'd have the time I'd hang out in there and change it, but time doesn't permit.
[14:49] <hakermania> Does the rules file runs automatically? Because I have an install field and a clean one, none of which doesn't seem to run...
[14:49] <Rhonda> hakermania: dpkg-buildpackage calls them when used with the appropriate options.
[14:49] <Rhonda> Usually though you don'
[14:50] <Rhonda> Usually though you don't even use dpkg-buildpackage directly bug debuild/cowbuilder/pbuilder/similar wrapper tools.
[14:50] <joaopinto> hakermania, which language is the application you are packaging using ?
[14:50] <hakermania> c++
[14:51] <joaopinto> ok, and it provides a working Makefile, which includes an "install" target supporting DESTDIR ?
[14:59] <acarpine> Hi people! I need some help about packagingGuide and fixing bugs...
[14:59] <acarpine> Reading some stuff about packaging and fixing bugs I saw that sometimes the
[14:59] <acarpine> process says to modify the debian/control file (for example with update-maintainer), other time (for example using bzr) doesn't do it.
[14:59] <acarpine> Can someone explain me why?
[15:01] <hrw> morning
[15:01] <joaopinto> acarpine, the process is not linear, you only need to update the maintainer on debian/control for cases it is not already properly set :)
[15:01] <acarpine> good afternoon for me :)
[15:01] <hrw> can someone tell me whom I should talk to about getting mail to devel-permissions moderated?
[15:01] <hrw> acarpine: its 15:01 here, but on irc I use ugt
[15:05] <acarpine> joapinto: ok please let me see if I follow you. If I'm fixing a bug and I'm working on Ubuntu and the debian/control reports only the original dev through the field Maintener I guess I should add the
[15:06] <acarpine> XSBC-Origina-Maintainer field and change the maintainer field
[15:06] <acarpine> correct?
[15:07] <joaopinto> yes, (for example with update-maintainer) ;)
[15:09] <acarpine> joapinto: ok, tks joapinto!
[15:12] <acarpine> hrw: :o Ops...I just discovered a new acronym ugt :)  In this case: good morning everyone!
[15:15] <hakermania> acarpine: Have you got experience with packaging?
[15:15] <acarpine> hakermania: I'm trying to learn now
[15:16] <hakermania> acarpine: Do you know about the debian/rules file?
[15:16] <acarpine> hakermania: I know what the packagingGuide says
[15:17] <acarpine> hakermania: not so much really :)
[15:19] <acarpine> I have another question about fixing bugs
[15:19] <acarpine> In general, how I know the name of the distribution where I have to upload my package?
[15:19] <acarpine> I'm talking about filling the first line of the debian/changelog file <package (version) distribution; urgency=urgency>
[15:20] <hakermania> acarpine: It's the next of the current, AFAIK
[15:21] <hakermania> joaopinto: Do you know about the debian/rules file?
[15:21] <joaopinto> hakermania, you need to be more specific :)
[15:23] <acarpine> hakermania: but always? it sounds a little odd to me. If it is so why dch in my system puts Maverick instead of Natty?
[15:24] <c2tarun> acarpine: because you may be using maverick machine for building and not the natty one. To build for natty you must use natty.
[15:25] <hakermania> acarpine: I don't know. It did it to me too. I'm not lying... See this for example http://revu.ubuntuwire.com/p/bucardo . It has an error because in changelog it doesn;t say natty
[15:27] <joaopinto> acarpine, dch by default uses the release name that you are working on
[15:30] <acarpine> c2tarun: Yes, I'm using Maverick. But I believe I could build also for Natty with pbuilder.
[15:30] <acarpine> I'm wrong?
[15:30] <c2tarun> acarpine: little bit
[15:31] <c2tarun> acarpine: pbuilder is not something on which you are working on. it is something that you are using only for building. You might be using your own system for building and I guess that is maverick.
[15:32] <acarpine> c2tarun: I tryied to use natty for ma base.tgz but I'm not sure...
[15:33] <acarpine> c2tarun: is there a command for to known the release of my base.tgz (pbuilder)?
[15:34] <tarun__> acarpine: I dont know but by default pbuilder builts for latest release and that is natty.
[15:38] <acarpine> c2tarun: So, I'm using Maverick and I use pbuilder for build for natty. So I should be in order, right?
[15:39] <c2tarun> acarpine: well I suggest that create a chroot for natty, try to use it for everything and use pbuilder only for testing. This way it is more comfortable.
[15:42] <joaopinto> I suggest to use schroot/sbuild instead :P
[15:42] <c2tarun> yup this is also a good one :) ^^
[15:44]  * c2tarun never understood schroot exactly
[15:44] <acarpine> c2tarun: you aren't talking about pbuilder's chroot?
[15:45] <c2tarun> acarpine: actually chroot's are same more or less. diff b/w normal and pbuilder chroot is pbuilder clears all the changes you made each time you exit from it. Like installation of all the build-dependencies, updating chroot and many more.
[15:45] <acarpine> c2tarun & joapinto: I mean..."pbuilder create" already creates a base chroot image tar-ball (base.tgz).
[15:47] <c2tarun> acarpine: pbuilder creates a chroot tar-ball, whenever you want to use it, it untars it and uses it. All the changes are removed after use is finished.
[15:47] <c2tarun> acarpine: while chroot is normal chroot which gives you a environment like your system, you can use it for building anytime and it'll save all the changes you made.
[15:51] <joaopinto> c2tarun, chroot can be used with a base chroot (like pbuilder does) can be used by regular (non root) users, unlike chroot
[15:52] <joaopinto> sbuild which is the tool used on the official archive builds is based on schroot
[15:52] <joaopinto> ops, I meant, schroot can be...
[15:53] <c2tarun> joaopinto: actually I wanted to know, what is special about schroot? I mean what is it that schroot can do and normally we cannot?
[15:54] <Rhonda> schroot keeps your environment and makes your home available automatically.
[15:54] <Rhonda> So you can run X11 applications after schroot, and do have the sources in your home still available without extra hoops to jump through.
[15:55] <c2tarun> Rhonda: Creating an account inside chroot will do that job too :) I guess :/
[15:55] <Rhonda> Right, but that means you have root access to start out with.
[15:56] <Rhonda> schroot doesn't give you root access inside the chroot.
[15:56] <joaopinto> c2tarun, not really, that does not bind mount your real /home
[15:56] <Rhonda> And also creating an account doesn't bind your /home more /tmp/.X11-unix
[15:56] <Rhonda> s/more/nor/
[15:57] <c2tarun> joaopinto: actually I don't want my real home to bind mounted :/ thats scary, all I wanted is just one folder from my home binded to one folder in chroot's home :) completely its 3-4 steps I wrote a small script for it ;) just one command now
[15:58] <kklimonda> hmm.. any idea why is it happening: $ pbuilder-dist dapper amd64 create
[15:58] <kklimonda> Unknown distribution: dapper
[15:58] <joaopinto> c2tarun, it is not scary if you need to do real testing with applications using your home contents :)
[15:59] <c2tarun> joaopinto: I copied some of my home contents :) ya but I agree for real testing we have to use our home contents :)
[15:59] <Rhonda> c2tarun: It's not scary if you think in terms of porter boxes like Debian does it. You don't want every Debian Developer to have root access, but still be able to test-build packages in a stable/testing/unstable environment nevertheless.
[16:00] <Rhonda> It's different approaches for different things. To some degree it's like su (requires target user password) versus sudo (requires source user password and can be limited to specific commands)
[16:00]  * c2tarun agree with Rhonda
[16:00] <c2tarun> kklimonda: why dapper?
[16:01] <kklimonda> I want to build package for dapper
[16:01] <kklimonda> why? Because I'm wondering if it still builds
[16:01] <micahg> kklimonda: have fun
[16:02] <kklimonda> micahg: well, I'm not *that* interested with EOL 3 months from now.
[16:02] <kklimonda> but this error is weird
[16:02] <acarpine> c2tarun & joapinto & rhonda: sorry people, I know you are so excited about all this stuff :)...but I actully have only pbuilder that uses a base.tgz (I hope with Natty). So what is your hint?
[16:02] <acarpine> c2tarun & joapinto & rhonda: I don't wanna be pedantic...just I want be sure to well understand :)
[16:05] <c2tarun> acarpine: build a chroot first :)
[16:06] <joaopinto> acarpine, you are ok
[16:07] <c2tarun> !chroot
[16:07] <c2tarun> acarpine: ^^
[16:08] <acarpine> c2tarun & joapinto & rhonda: never laughed so much... :D
[16:08] <acarpine> on an IRC channel
[16:12] <c2tarun> is there anything wrong with in.archives.ubuntu.com. apt-get is not able to connect?
[16:14] <acarpine> c2tarun rhonda joapinto: Anyway I understood that 1) I should be ok, for now, with pbuilder, but if I wanna test package "more in deep" I should check chroot or something similar.
[16:15] <Rhonda> acarpine: Personally I only use cowbuilder for my package building, which is actually more-or-like the same as pbuilder.
[16:15] <Rhonda> acarpine: I just jumped in on the chroot vs. schroot discussion to get the facts straight, that's all. :)
[16:15] <c2tarun> and after the discussion I'll surely give schroot a try ;)
[16:16] <Rhonda> acarpine: And no, you can do deeper inspection also with pbuilder. It has the --login switch.
[16:17] <acarpine> 2) Talking about fixing a bug with Ubuntu, we can say that the distribution where I have to upload my package is always the development release (Natty for now)
[16:17] <Rhonda> Practically yes, unless you have a specific fix that could go in through a SRU (Stable Release Update)
[16:20] <acarpine> Rhonda: just for know...how can I see if it is a specific fix?
[16:21] <acarpine> Rhonda: is there any specific tag?
[16:21] <Rhonda> If the problem that the upload tries to address is of a certain importance like affecting a big number of users in a bad way, is a security related problem and similar.
[16:22] <Rhonda> And then only the actual fix for that issue will get approved for the SRU.
[16:23] <acarpine> rhonda: clear, tks
[16:27] <acarpine> Rhonda c2tarun joapinto: I have to confess that I believe that all this different approaches create a certain amount of ambiguity especially for new contributors. Someone use pbuilder, others cowbuilder and maybe someone pig-builder :)...
[16:28] <Rhonda> pbuilder and cowbuilder are practically the same in the end.
[16:28] <Rhonda> They are even written by the same person. ;)
[16:29] <Rhonda> The difference is that pbuilder uses a tarball that it extracts every time and removes afterwards again (and thus produces a lot of disk I/O), where cowbuilder does do it with a hardlink tree and only actually creates files on write (cow - copy-on-write, and takes more diskspace because the chroot lives readily on your harddisk)
[16:33] <acarpine> Rhonda: yes I read in the manual, but know is more clear.
[16:34] <acarpine> Rhonda c2tarun joapinto: Precisely,...sometime seem that the only way for reach the goal is ask to you people.
[16:34] <acarpine> Rhonda c2tarun joapinto: We are lucky that you are ready to answer! :D tks people
[16:35] <Rhonda> Just keep in mind to not higlight a group of people with every single message - they might get annoyed.
[16:35] <Rhonda> … even though flattering in the hilight messages usually is acceptable. :P
[16:37] <hakermania> tumbleweed: New upload for package wallch + comment about the fixes...
[16:38] <joaopinto> eheh
[17:24]  * Laney rushes to beat FF ;)
[17:27] <chrisccoulson_> quick Laney, get all of those disruptive, break-the-world uploads in now :)
[17:27] <Laney> :-)
[17:28] <Laney> it *is* a Haskell library after all
[17:29] <hakermania> Has Debian 1) GNOME Desktop 2) KDE Deskrop 3) It's up to you
[17:29] <hakermania> ?
[17:33] <micahg> chrisccoulson_: I'm uploading that old conkeror merge, xtaran has some more improvements coming (bug fixes), so I think this is fine for now, I'll keep an eye on nit
[17:35] <chrisccoulson_> micahg - cool, that's ok. although, you can do what you like with conkeror ;)
[17:35] <chrisccoulson_> (except depend on xulrunner-1.9.2) ;)
[17:35] <micahg> chrisccoulson_: the new version in Debian (not the one I'm uploading) claims to work with xul2.0 (will upload later :))
[17:36] <chrisccoulson_> i thought the current one worked? it seemed to work when I tested it (although, I didn't test much)
[18:36] <Rhonda> Is there some PPA for keypass? How to search for that?
[18:40] <geser> Rhonda: https://launchpad.net/ubuntu/+ppas but it doesn't find anything for keypass
[18:41] <Rhonda> bleah
[18:42] <Rhonda> it's keepass, I'm too stupid to search for the real thing
[19:23] <Rhonda> \o/ Laney
[19:24] <Rhonda> … \o/ maco too, of course. :)
[19:25] <maco> :)
[19:28] <Rhonda> maco: It's just that I had more contact with Laney so far, wasn't meant to belittle you. :)
[19:31] <maco> Rhonda: thants fine :) i figured he was your friend
[19:33] <Rhonda> In a rather general, facebook-generation definition of the term, yes. :)
[19:48] <hakermania> Rhonda: Can you advocate packages?
[19:48] <Rhonda> Technically yes, I could.
[19:49] <hakermania> can you see: http://revu.ubuntuwire.com/p/wallch ? It needs advocation from second MOTU :) micahg has already given one :)
[19:50] <micahg> hakermania: actually, I think I have to review it again since there are changes
[19:50]  * micahg thought tumbleweed was going to upload it, oh well
[19:50] <hakermania> micahg: Not a lot of changes.....
[19:51] <micahg> hakermania: I'll look it over again after the xubuntu meeting
[19:51] <hakermania> when is it?
[19:52] <micahg> hakermania: now :)
[19:54]  * Rhonda . o O ( could I get away with claiming that I trust micahg and just ACK it? )
[19:55] <micahg> Rhonda: please don't, I'm still green WRT a few issues
[19:55] <Rhonda> :)
[19:55] <micahg> Rhonda: I have learned a lot since I started packaging, but there's still a ton more for me to learn
[19:58] <hakermania> Rhonda: cruel man xD
[19:58] <ari-tczew> !FF
[19:58] <ari-tczew> !FFe
[19:58] <micahg> !msgthebot > ari-tczew
[20:00] <micahg> hakermania: Rhonda is a woman BTW :)
[20:23] <hakermania> micahg, Rhonda: oooops :-[
[21:04] <hakermania> Good night everyone
[22:02] <ScottK> http://static02.mediaite.com/geekosystem/uploads/2011/02/watson.jpeg
[22:05] <iulian> :-)
[22:10] <ari-tczew> ScottK: this is cjwatson?
[22:10] <micahg> ari-tczew: http://www-943.ibm.com/innovation/us/watson/
[22:10] <ScottK> Different watson.
[22:11] <ari-tczew> ah
[23:07] <alucardni> guys what can we do to include the patch attached to LP Bug #546581 in Glibc? The patch has been in upstream bugzilla for almost 6 months.