[00:16] <geser> stgraber: Hi, can you "sandbox" be used to mimic the no-net-access from buildds in pbuilder?
[00:23] <stgraber> geser: I'm not sure how it's done on the buildds, but the no-network option of sandbox basically gives you a system where you only see a loopback device, so it might do the trick.
[00:24] <geser> that would be enough, till I had no idea how to "disable" net inside the pbuilder but not my host
[00:24] <stgraber> do you know if you can change the call to "chroot" in pbuilder to start another command ?
[00:26] <stgraber> if so, you could simply replace that call by: "/usr/bin/sandbox-helper nonetwork" followed by the usual parameters (path to the chroot and command)
[00:26] <geser> I might need to make my own "pbuilder" but it should be doable
[00:26] <geser> and having pbuilder itself using a tmpfs is no problem?
[00:27] <stgraber> well, if you replace "chroot" by "/usr/bin/sandbox-helper nonetwork" it'll only use the namespace switching part of sandbox, it won't create a tmpfs or anything. It'll just behave exactly like chroot.
[00:29] <geser> I guess the sandbox and the host don't share the lo device, right? as I use apt-cacher-ng to download the debs
[00:30] <geser> perhaps I can only "sandbox" the package building itself (and not the build-dep installation too). Will have to check the pbuilder shell scripts
[00:33] <stgraber> indeed, that's two separate lo
[00:52] <geser> do I need sudo inside the pbuilder?
[00:55] <geser> stgraber: http://paste.ubuntu.com/540131/ the first line is the old call, the second line what I replace it with and the third the error I get
[00:56] <geser> I don't know where the sudo comes from
[01:06] <stgraber> geser: ah right, I forgot about this part of sandbox-helper, it's usually started as root using sudo and then it sudo back to the original user
[01:10] <stgraber> geser: so, in theory (though it's slight hackish), if you can manage to get sudo installed in the chroot and make sure SUDO_USER=root in your environment, it should work fine
[01:10] <stgraber> as it'll basically do "chroot <target> sudo -u root <cmd>" in the new namespace (yeah, as I said, hackish)
[01:13] <geser> a sandbox-raw (without the chroot call) would be nice so I could use it for pbuilder (simply add it before the chroot call)
[01:16] <geser> btw: wouldn't using "chroot --userspec=${SUDOUSER}" allow you to do it without sudo? (not that it would help me for pbuilder)
[01:18] <geser> a --nonetwork option to chroot would be nice
[01:21] <stgraber> ah, didn't know of userspec, that'll help quite a bit indeed. I'll do that in the next release.
[01:21] <stgraber> I'm trying to build you a stripped down version that does what you want
[01:22] <geser> just noticed it myself by looking at the chroot manpage if perhaps it already has a --no-network option :)
[01:29] <stgraber> geser: http://paste.ubuntu.com/540135/
[01:30] <stgraber> geser: gcc sandbox-raw.c -o sandbox-raw
[01:30] <stgraber> geser: then you can call it with: ./sandbox-raw chroot <path> <cmd>
[01:30] <stgraber> needs to run as root
[01:33] <stgraber> the code is now in lp:~stgraber/+junk/sandbox too (though not added to the Makefile)
[01:35] <geser> thanks
[01:36] <geser> my patched pbuilder doesn't error out anymore, but for some reason which I don't know yet it behaves now different
[01:37] <stgraber> how so ?
[01:38] <stgraber> I'm not familiar with exactly how pbuilder works, but if you want it to work properly, you'll need to make sure it mounts /proc from inside the chroot, not from the outside
[01:38] <stgraber> otherwise you'll get a /proc from the wrong namespace
[01:39] <geser> that's the output I get http://paste.ubuntu.com/540136/
[01:40] <geser> with sandbox-raw
[01:40] <stgraber> ouch, that's really weird
[01:41] <stgraber> would be interesting to know where that "can't read xvt_2.1-20_amd64.changes!" comes from and exactly what failed there
[01:41] <geser> that's one of my pbuilder hooks which gets run after a successfull builds, but this doesn't look like a successful build
[01:42] <stgraber> yeah, it just stopped after the first step ...
[01:42] <geser> the same without sandbox-raw http://paste.ubuntu.com/540137/ (the FTBFS is expected)
[01:44] <geser> and the only change I did was to the following line in pbuilder: 'echo "$DPKG_COMMANDLINE" | $CHROOTEXEC $SUTOUSER' adding sandbox-raw before the $CHROOTEXEC
[01:46] <stgraber> http://paste.ubuntu.com/540138/
[01:46] <stgraber> can you try this one instead ?
[01:46] <stgraber> it's even more stripped down to only do the network namespace part and keep all the rest as it's
[01:50] <geser> stgraber: that one works better as I get the expected FTBFS
[01:51] <stgraber> cool, can you try doing something that needs network access during the build process ?
[01:53] <geser> I've modified my pbuilder to also run my hooks with sandbox-raw. One of the hooks starts a shell if the package FTBFS and I tried now to install a package with this shell: "Network is unreachable" :)
[01:54] <stgraber> cool
[01:54] <geser> yeah
[01:55] <stgraber> ok, current code is in rev38 of sandbox and has been renamed to sandbox-raw-nonetwork (yeah, long but at least we know what it does ;))
=== ssj6akshat|sleep is now known as ssj6akshat
[03:58] <c2tarun> are there any defined coding standards for source codes (except proper indentation) that one has to follow before uploading a package??
[03:59] <ssj6akshat> c2tarun, hey, fixed that bug?
[04:01] <c2tarun> ssj6akshat: not yet :(
[04:02] <ssj6akshat> k
[04:50] <c2tarun> can anyone please help me with the packages having source code in .cs format.
[05:01] <RAOF> c2tarun: Sounds like a C# app.  What's your question?
[05:02] <c2tarun> RAOF: i was looking at the source code of tomboy and found that its code is in cd format. how can i make changes to that code and check on ubuntu that it is working. i think c# is not supported by ubuntu
[05:03]  * micahg coughs...mono
[05:04] <c2tarun> very sorry micahg, my net is not working properly so i cant look about mono. i'll come back ASAP, please be there/
[05:06] <RAOF> c2tarun: The package build system itself is a demonstration of how to build it.
[05:07] <RAOF> If you've got the build-dependencies of the tomboy package, you've got all the dependencies required to build it.  Beyond that, it's fairly standard autofoo.
[05:08] <c2tarun> RAOF: sorry i m not getting properly of what you are saying. are you saying that all i need to do the desired changes and go to the standard package building procedure and it will work??
[05:09] <RAOF> Yes.  Because the tomboy package is an Ubuntu package; it builds on the build daemons like any other package.
[05:10] <c2tarun> wow... thanks :) if that worked this will be my first contribution ( though its not a bug, its in wishlist :P).
[05:24] <MTecknology> How can I force myself to be dropped into the pbuilder environment after it finishes building with or without errors?
[05:26] <nigelb> MTecknology: there is a hook for that
[05:26] <paultag> MTecknology: you mean --login   ?
[05:26] <paultag> MTecknology: you should not log in, you can cause a lot of issues in the resulting deb
[05:27] <nigelb> paultag: that's for debugging and I've done that before
[05:27] <paultag> MTecknology: calling login gets you in the image, then gets rid of the stuff you did, you should not login when you're building a deb
[05:27] <paultag> nigelb: yeah, I know
[05:27] <paultag> nigelb: :)
[05:27] <nigelb> :)
[05:27] <paultag> nigelb: did you get my PMs?
[05:27] <MTecknology> I plan on purposely breaking things in there :P
[05:27] <paultag> nigelb: I did some good stuff
[05:27] <nigelb> paultag: I did, I did :)
[05:28] <nigelb> MTecknology: https://wiki.ubuntu.com/PbuilderHowto#Running a Shell When Build Fails (Intro to Hook Scripts)
[05:28] <paultag> nigelb: whana see the demo I did?
[05:28] <MTecknology> thanks :)
[05:28] <nigelb> np :)
[05:28] <nigelb> paultag: sure :D
[05:29] <MTecknology> using --login didn't drop me in after the build
[05:30] <paultag> MTecknology: sudo pbuilder --login    ?
[05:30] <MTecknology> sudo pbuilder-dist lucid ../nginx_0.8.53-2.dsc --login
[05:31] <paultag> can't do that
[05:31] <paultag> you'll break the deb
[05:32] <MTecknology> I guess I'm looking for C10Shell then - just making it happen whether the build fails or not
[05:34] <MTecknology> paultag: btw- I'm just trying to poke around in there - not expecting the package to end up nice and pretty and usable
[05:34] <paultag> MTecknology: k
[05:35] <MTecknology> is the C in there significant? like - if build 'C'rashes then run anything C*?
[05:38] <MTecknology> I bet if I do a tiny bit of digging I find out :P
[06:46] <dholbach> good morning!
[06:46] <c2tarun> dholbach: good morning
[06:46] <dholbach> hi c2tarun
[06:47] <c2tarun> dholbach: i mailed you on launchpad yesterday and requested for a classroom session. you checked that ???
[06:48] <dholbach> c2tarun, I got your email on sunday evening
[06:48] <c2tarun> ok u thought something about that. something about live fixing of a small bug
[06:48] <dholbach> c2tarun, and I forwarded it to the packaging training coordinators - we're in the process of setting up a few sessions
[06:48] <dholbach> so stay tuned
[06:49] <c2tarun> dholbach: wow...  thanks a lot :)
[07:49] <ari-tczew> ttx: could you sponsor for me bug 684874 and bug 682898 ?
[07:50] <ubottu> Launchpad bug 684874 in rabbitmq-server (Ubuntu) "Merge rabbitmq-server 2.2.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/684874
[07:50] <ubottu> Launchpad bug 682898 in gwt (Ubuntu) "Fakesync gwt 1.6.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/682898
[07:50] <ttx> ari-tczew: not right now. I'll have a look in a few days
[07:50] <ari-tczew> ok
=== freeflyi1g is now known as freeflying
[09:24] <geser> MTecknology: yes the 'C' does matter, see the explanation for --hookdir in "man pbuilder". From a quick look at the manpage, it seems like you need a "C" hook (like C10shell) and a "B" hook (like B10shell). [the '10' is for ordering of similar hooks and the 'shell' a short description]
[09:59] <lucas> geser: the local mirror on UDD is out of sync again. I've notified the people in charge.
[10:00] <micahg> lucas: BTW, thank you for the efforts WRT to the rebuild
[10:01] <lucas> heh :) you're welcome
[10:26]  * geser did his 2000th upload
[11:13] <\sh> moins
[11:14] <micahg> \sh: greetings, are congratulations in order?
[11:14] <\sh> micahg: sure :)
[11:15] <micahg> \sh: well, congratulations :)
[11:15] <\sh> micahg: thx a lot :)
[11:15] <\sh> micahg: since this morning it's also official in germany...and now I have a lot of work to do :) changing name etc.
[11:16] <micahg> \sh: not yours I hope ;)
[11:17] <\sh> micahg: of course...I'm not "Stephan Hermann" anymore :) I'm now known as "Stephan Adig" :)
[11:17]  * micahg is confused, 21st century chivalry?
[11:18] <\sh> micahg: I took the name of my wife :)
[11:19] <geser> don't forget to change your IRC nick :)
[11:19] <nigelb> heh
[11:19] <nigelb> \sh: congrats :)
[11:20] <micahg> \sh: well, in any case, congrats and I'm signing off before I put my foot any further in my mouth :)
[11:20] <\sh> geser: hmmm...we'll see :)
[11:20] <\sh> nigelb: thx :)
[11:21] <nigelb> micahg: Your awake times confuse me awfully most of the time.
[11:21] <micahg> nigelb: my circadian rhythm feels the same way ;)
[11:22] <nigelb> lol
[11:22] <nigelb> Isn't your circadian rhythm more like a circadian rap? :p
[11:22] <evaluate> Hello
[11:23] <nigelb> hi
[11:23] <evaluate> I have submitted a package to debian but it takes awfully long for it to get included (if at all) so I thought I'd also submit it to ubuntu (because that's what I'm using myself).
[11:24] <nigelb> Do you have a bug number for that?
[11:25] <nigelb> A debian bug number that is
[11:25] <evaluate> I have got feedback from the debian-mentors mailing list and the package seems to be fine with the exception of one warning, which isn;t critical though. Now, before I submit it to ubuntu, is there anything else I need to take care of beside bumping the version (from *-1 to *-0ubuntu1) and changing the distro from unstable to maverick?
[11:25] <evaluate> nigelb, sure, just a second
[11:25] <dapal> evaluate: is it a NEW package? If yes, it should wait in the NEW queue (given we're frozen, it'll take a while)
[11:26] <evaluate> dapal, what do you mean with "we're frozen"?
[11:26] <dapal> we == Debian, sorry
[11:27] <nigelb> dapal: I think its a patch.
[11:27] <evaluate> nigelb, ITP #6031318
[11:27] <nigelb> debian bug 6031318
[11:27] <ubottu> Error: Debian bug 6031318 could not be found
[11:27] <nigelb> evaluate: are you sure that number is correct?
[11:27] <nigelb> dapal: gah, I read wrong, sorry!
[11:27] <evaluate> dapal, nigelb, it's new. But shouldn't it be allowed to be uploaded to sid regardless of the testing freeze?
[11:28] <dapal> evaluate: yes, but the ftpteam is busy in catching RC bugs, rather than processing NEW
[11:28] <dapal> evaluate: even though they sometimes do batch processing
[11:28] <dapal> (during the Freeze, I mean)
[11:29] <evaluate> nigelb, this should be it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603131
[11:29] <evaluate> dapal, I understand that, but I find one month for such a small package a little too long...
[11:29] <nigelb> I saw this on debian-mentors recently
[11:29] <nigelb> the thing is, really, we'd rather have you maintain this in debian
[11:29] <dapal> evaluate: DktrKranz is in the ftpteam, ping him ;)
[11:29] <dapal> evaluate: (or bribe him :D)
[11:29] <evaluate> I mean, a couple of people have already said that the package is fine, I don't think it would be such a immense effort for it to be uploaded. I find all of this pure bureaucracy...
[11:30] <nigelb> bribing with network equipment might work :p
[11:30] <dapal> evaluate: the problem is not "uploading" the package; is someone from the ftpteam steal time from RC hunting and reviewing it :)
[11:30] <evaluate> nigelb, I would also love to maintain it in debian, but it just seems to take too long...
[11:30] <nigelb> I think it should unfreeze before ubuntu releases
[11:31] <dapal> nigelb: I hope so :)
[11:31] <dapal> latest rumours say before christams
[11:31] <evaluate> dapal, well, like I said, a couple of people have already reviewed it and they said it's fine...
[11:31] <dapal> evaluate: maybe they were not DDs? I am, let me check it and eventually upload
[11:31] <nigelb> there you go, a sponsor :p
[11:31] <evaluate> dapal, that would be awesome, thank you very much :-)
[11:32] <geser> evaluate: I don't want to disappoint you but getting a new package into Ubuntu through REVU isn't fast either
[11:32] <evaluate> dapal, if you want I could link you to the threads on the debian-mentors mailing list...
[11:32] <dapal> evaluate: nope, I read d-mentors
[11:32] <evaluate> dapal, ohh, ok.
[11:33] <evaluate> geser, well, I thought it might be faster than uploading through debian. Also, this step will be necessary anyway, for the package to be synced over from debian to ubuntu, won't it?
[11:35] <evaluate> dapal, if you would like to sponsor it, please let me know so I make another package so that the debian package is in sync with the upstream (I just did another release a couple of hours ago)
[11:35] <geser> if the package is in Debian, syncing it over is easy (REVU is only for new package not in Debian)
[11:35] <evaluate> geser, ohh, I thought it would be the same process, as I saw that I would also need to request a sync for the package to get into ubuntu
[11:37] <dapal> evaluate: yes, I'll sponsor it. Since you're going to make a new package, would you mind adding a desktop file too?
[11:38] <dapal> evaluate: i.e. debian/clipit.desktop , to be installed in /usr/share/applications/
[11:38] <evaluate> dapal, there is a desktop file in the source package already...
[11:39] <dapal> ah, sorry, missed it :)
[11:39] <evaluate> dapal, so is it ok like this?
[11:40] <dapal> wait, compiling :)
[11:40] <evaluate> sure
[11:40] <dapal> it looks ok though, let me finish to be sure ;)
[11:47] <dapal> evaluate: ok, please make a new package, I'll upload it
[11:56] <evaluate> dapal, sure, I just seem to have a little problem. I added 'Applet indicator' support for it in the latest version and it seems that the package name differs on debian to what it is on ubuntu. On ubuntu I have added 'libappindicator-dev' as dependency, but on debian I can't find this package. Is the debian package named libindicator-dev the same as the ubuntu libappindicator-dev one?
[11:56] <dapal> evaluate: let me check
[11:57] <dapal> uhm, nope, they're not the same
[11:57] <dapal> there's some ongoing work in Debian regarding appindicator, IIRC
[11:58] <dapal> I'll search on d-mentors
[11:58] <evaluate> dapal, so should I remove the dependency on libappindicator and let it build without the application indicator support?
[11:58] <dapal> evaluate: initially, yes. Then you'll need to make a ubuntu merge (-1ubuntu1), re-adding the Build-Depends
[12:00] <dapal> oh, we have indicator-applet, but not indicator-application
[12:00] <dapal> weird names :)
[12:03] <dapal> evaluate: going away, will be back here later today. Would you please send me a mail (dapal@d.o) when you have your package ready? Thanks
[12:04] <evaluate> dapal, sure, I'll have it ready in the next half hour or so, will ping you on e-mail. Thanks again! :-)
[12:04] <dapal> evaluate: you're welcome -- if you also need assistance with the ubuntu merge, I can help you (but I'm not a MOTU (yet, planning it), so you need another sponsor)
[12:04] <dapal> read you later :)
[12:31] <DktrKranz> evaluate: during freeze, we usually process Debian NEW queue at a slower pace, but we can accept a package anytime (and I'm potentially turning into a drunk man given how many beers people owe me already :P)
[12:32] <evaluate> DktrKranz, well, like I said, I can understand that things are going at a slower pace, but it just seemed a bit long for me (maybe I'm just not used to the debian pace... :-)
[12:32] <evaluate> anyway, the reason I rush this a bit is because I think that getting the package into debian and into ubuntu might get it a larger userbase ans thus faster bug reports...
[12:33] <DktrKranz> evaluate: btw, which package are we talking about?
[12:33] <evaluate> DktrKranz, the name is 'clipit'
[12:33] <evaluate> DktrKranz, dapal already said he would upload it after I repackaged the new upstream version, just so you know if you missed that...
[12:34] <DktrKranz> ah, not yet in NEW
[12:34] <DktrKranz> I thought it was already
[13:10] <geser> evaluate: sponsoring a sync request is much easier as it's mainly checking if the package builds in Ubuntu (you only need to find one sponsor for it and there are enough MOTUs working on the sponsoring queue), for REVU you need to find two MOTUs who ACK your package after looking for packaging errors (similar to debian-mentors) but only a few MOTUs do reviewing on REVU
[13:11] <evaluate> geser, ok, I get it.
[13:11] <evaluate> If it gets uploaded to debian It'll hopefully then be easier to get it into ubuntu too
[13:12] <evaluate> I mean, the only changes it would need, would be the libappindicator ones. Also, I have a PPA in which the package builds just fine, that should also be a proof that it works on ubuntu too...
[13:19] <ari-tczew> cjwatson: you did an upload of system-tools-backends, but I got ACK of sync previous. ehhh, what's next?
[13:23] <cjwatson> ari-tczew: I don't understand your commenet
[13:23] <cjwatson> *comment
=== Aquina is now known as Kathrin
[13:23] <ari-tczew> cjwatson: bug 685528
[13:23] <ubottu> Launchpad bug 685528 in system-tools-backends (Ubuntu) "Sync system-tools-backends 2.10.1-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/685528
[13:24] <ari-tczew> you did an upload
[13:24] <cjwatson> ari-tczew: oh, that'll have to be a merge then
[13:24] <ari-tczew> and my sync has been expired
[13:24] <ari-tczew> I'm not satisfied
[13:24] <cjwatson> that's life
[13:32] <cjwatson> I'm sorry that I didn't happen to spot the sync request, but I don't always read through all recent bug reports on a package before uploading it, particularly when my attention is focused on something entirely different
[13:36] <ari-tczew> cjwatson: OK, I'll forget about this one. I know that you didn't want do bad.
[13:36] <ari-tczew> cjwatson: I'd like to discuss with you about merge-o-matic.
[13:38] <cjwatson> the experimental thing?  right.  I'm not quite sure what would be involved in setting up an entire separate set of pages for that (particularly since the current focus on experimental is largely temporary, and will subside again after the squeeze release).  I think it would be confusing because you'd have to look in two places.  My feeling is that I'd rather use the existing facilities to tell MoM to attempt to merge just ...
[13:38] <cjwatson> ... certain packages from experimental; that's an override file and I'm happy to add things too do
[13:38] <cjwatson> er, *things to it
[13:42] <ari-tczew> cjwatson: hmm, that's not I expected directly
[13:42] <ari-tczew> :(
=== xfaf is now known as zul
[13:44] <ari-tczew> bdrung: FYI, I gave comment for Kmos unban request.
[13:46] <bdrung> ari-tczew: you comment doesn't help much
[13:47] <ari-tczew> cjwatson: I don't think so that people will must have a look into 2 places. Just last time I have to merge one package with experimental to resolve DEPWAIT and I had to create patches manually. If DEPWAIT wouldn't exist, propably I never would look on merge this package with experimental
[13:47] <ari-tczew> bdrung: I know, nothing help much
[13:51] <cjwatson> ari-tczew: I don't generally think that people should merge from experimental unless there's a specific reason to do so
[13:52] <ari-tczew> cjwatson: from my point of view, now Debian is frozen. some packages have been upgraded to new upstream release and uploaded to experimental. If contributors want to get some new upstream releases, then can go with experimental.
[13:53] <cjwatson> ari-tczew: not all of experimental follows that though
[13:54] <cjwatson> ari-tczew: I don't want to encourage people to upload things to Ubuntu which from Debian's point of view are essentially random junk.  They should be inspecting it in more detail
[13:55] <cjwatson> so I'd rather that they explicitly ask for MoM to follow a package from experimental
[13:56] <ari-tczew> cjwatson: ok another case. what do you think, parsing binary package under source is necessary/useful?
[13:56] <cjwatson> can you give me an example?
[13:57] <ari-tczew> cjwatson: universe: source package chromium-browser, binary: chromium-browser, chromium-browser-dbg, chromium-browser-l10n, chromium-browser-inspector
[13:58] <cjwatson> you mean the fact that it's listed in the Package field?  I do find that useful for searching sometimes, yes
[13:58] <cjwatson> I know it's kind of long in a few cases
[13:59]  * ari-tczew is seeing that today has only bad ideas
[14:00] <cjwatson> there's a difference between "ideas Colin disagrees with" and "bad ideas". :)
[14:00] <ari-tczew> cjwatson: ok, if you want to create department for MoM/experimental, would be nice to get a tool which will create merge parcel from experimental, available under command like 'grab-merge XXX experimental'
[14:01] <cjwatson> out of interest, have you considered using bzr merge-package lp:debian/experimental/XXX?
[14:01] <cjwatson> (I know it doesn't work for everything)
[14:02] <ari-tczew> as you said: it doesn't work for everything
[14:02] <ari-tczew> and I hate merging with bzr
[14:02] <ari-tczew> it just sucks, if it requires anyway dput
[14:02] <cjwatson> hm, works well for me
[14:12] <ari-tczew> Adri2000: are you on merge filezilla?
[14:14] <tumbleweed> ari-tczew: whether or not you like UDD, being able to merge locally with UDD means we don't *need* a central MOM for experimental. Although that would be handy if we had a way to mark packages as "should be synced/merged from experimental" (which I've wanted to do in the past)
[14:14] <cjwatson> tumbleweed: we do, although it needs MoM admin action - file a bug on merge-o-matic if you want a package marked that way
[14:14] <tumbleweed> cjwatson: does it apply to auto-syncing?
[14:15] <cjwatson> tumbleweed: no
[14:15] <cjwatson> that one does still require manual requests
[14:16] <tumbleweed> most such needs are temporary (either a package is experimenting with something that we want/have, or debian is in freeze)
[14:19] <mr_pouit> ari-tczew: filezilla was uploaded only yesterday to unstable, so you should really wait...
[14:31] <Adri2000> ari-tczew: yep, will do it
[14:31] <ricotz> mr_pouit, hi, i hope you will have some time to look into elementary-icon-theme 2.6 ;)
[14:32] <Adri2000> ari-tczew: comment added
[14:45] <hrw> hi
[15:09] <ari-tczew> mr_pouit: btw, wait for?
[15:15] <cdbs> ari-tczew: from that sentence, I think that you just merged an XFCE package?
[15:15] <cdbs> ari-tczew: MOTUs are expected to deal mostly with unseeded packages, its best to leave seeded packages to their devs
[15:15] <ari-tczew> cdbs: I don't understand what are you talking about
[15:16] <cdbs> ari-tczew: ah, sorry, my fault
[15:17] <ari-tczew> :]
[15:20] <mr_pouit> ari-tczew: you ask Adri2000 about filezilla, but I wrote it has only been uploaded yesterday. So I meant there's no reason to rush (and it's probably better to wait a few days ;)
[15:21] <mr_pouit> (but well, I'm just speaking, you do what you prefer)
[15:21] <ari-tczew> mr_pouit: what could give these days?
[15:21] <ari-tczew> (not in filezilla case, it's explained)
[15:24] <mr_pouit> (especially in filezilla's case, a rc bug can be reported)
=== dholbach_ is now known as dholbach
=== ulysses is now known as emovaldi
[16:21] <udienz> hiya all
[16:21] <udienz> i try to solving #549365
[16:21] <udienz> !bug #549365
[16:21] <ubottu> Launchpad bug 549365 in light-themes (Ubuntu) "Terminals have a translucent background" [Wishlist,Fix committed] https://launchpad.net/bugs/549365
[16:21] <udienz> please reviewing itu
[16:22] <udienz> i wsih i can help MOTU team
[16:36] <hrw> bug 686054 reported
[16:36] <ubottu> Launchpad bug 686054 in plasma-widget-fancytasks (Ubuntu) "crashes plasma with 4.5.80 packages" [Undecided,New] https://launchpad.net/bugs/686054
=== emovaldi is now known as ulysses
[16:41] <hrw> ops
[17:36] <evaluate> hello dapal. I just sent you another mail, not sure what went wrong with the first one...
[17:38] <dapal> evaluate: got it :)
[17:38] <dapal> evaluate: can't find 0x521767F1 on keyservers though ;)
[17:38] <dapal> evaluate: however, I'm getting the mentors package
[17:39] <evaluate> dapal, hmm, awkward. It should at least be on keyservers.ubuntu.com.
[17:39] <evaluate> dapal, sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 521767F1
[17:39] <dapal> apt-key? :p
[17:39] <dapal> gpg --keyserver ... --recv-keys, better
[17:40] <dapal> would you mind sending it to pgp.mit.edu and subkeys.pgp.net too? They're commonly used keyservers :)
[17:40] <evaluate> dapal, ohh. I copied that over from my instructions on how to install my PPA :p
[17:40] <evaluate> sure, I'm checking that out right now
[17:45] <evaluate> dapal, it seems that I also had keyserver.pgp.com and pgp.mit.edu in the servers list and I also added subkeys.pgp.net now, as you suggested, thank you!
[17:45] <dapal> evaluate: np, I'm compiling it again
[17:46] <evaluate> also, sorry if I'm doing stuff wrong, I'm not really familiar with encryption yet, as I only just started using it when I started packaging my program for debian and ubuntu :-)
[17:47] <evaluate> dapal, did the decryption work with that key?
[17:48] <dapal> evaluate: yup :)
[17:48] <evaluate> awesome :D
=== yofel_ is now known as yofel
[17:50] <dapal> evaluate: uploaded, thanks for your contribution :)
[17:51] <dapal> evaluate: feel free to ping me for future uploads
[17:51] <evaluate> dapal, thank you very, very much
[17:52] <evaluate> dapal, sure, I also had one more question if you have the time. Would it be wrong to use the debian-mentors mailing list to get reviews of future packages before I send them to you?
[17:52] <dapal> evaluate: usually, when one gets a "long-term sponsor", it's safe to send the url to the .dsc directly to the sponsor
[17:53] <dapal> however, it wouldn't be *wrong*
[17:53] <dapal> it would be unpolite (i.e. wasting other sponsors' time)
[17:53] <paultag> evaluate: just mark it a RFC not an RFS, unless you want someone else to upload it
[17:53] <paultag> :)
[17:53] <dapal> or, yes. :)
[17:53] <dapal> paultag: +1 :)
[17:55] <evaluate> dapal, ok, I understand. Like I said, I'm new to this and don't really know how it all works.
[17:56] <dapal> everyone has been "new to this" (except a couple of people, really), don't hesitate to ask :)
[17:56] <paultag> +1 dapal :)
[17:56] <paultag> evaluate: I just started working with Debian upstream, and d-m is actually a really nice place
[17:56] <evaluate> dapal, should I send an e-mail to the debian-mentors mailing list saying that I found a sponsor?
[17:56] <dapal> evaluate: I'll do that myself :)
[17:57] <evaluate> dapal, ok, thank you very much :-)
[17:57] <evaluate> paultag, yeah, people are really nice and helpful, the only "bad" experience I had with it is that it's a bit slow for my taste, but that's probably because of the current freeze status...
[17:58] <dapal> evaluate: that's the reason, yes. Most people are busy catching RC bugs
[17:58] <dapal> evaluate: other people, who aren't able to do any more RC bugs (like me :D), will sponsor things ;)
[17:58] <paultag> evaluate: true, true
[17:59] <paultag> I've taken a shine to starting to review, it's quite fun
[18:09] <evaluate> do you have experience with alioth.debian.org? I'm curios because I have submited a new project to host the debian/* files of clipit there and I didn't get an answer yet (I submited it on 30.11 so it's around a week), is it normal to take this long?
[18:10] <dapal> evaluate: why would you need a new project?
[18:11] <dapal> evaluate: you'd just need to ask membership for collab-maint ; http://wiki.debian.org/Alioth/PackagingProject
[18:11] <evaluate> dapal, well, I don't know. This is how I did on sourceforge, I thought that would also be the way to go on alioth (I couldn't find much info on how alioth actually works...)
[18:11] <dapal> evaluate: (despite of the name, you can use it even if you're the only maintainer)
[18:12] <dapal> evaluate: now you know :) -- ask for membership to the collab-maint project, and say that you want to maintain your debian/ there (maybe also say that's it's currently NEW)
[18:12] <dapal> evaluate: a new project usually takes longer than just membership to an existing one
[18:12] <evaluate> dapal, ok, got it, thank you!
[18:13] <dapal> the former depends on alioth admins, the alioth on collab-maint's admins, who should be quicker :)
[18:14] <paultag> evaluate: oh, are you the one working on clipit?
[18:15] <evaluate> paultag, yes, why?
[18:15] <paultag> evaluate: I've been reading your mail and looking at your work
[18:15] <paultag> evaluate: great job :)
[18:15] <evaluate> ohh, thank you very much!
[18:15] <paultag> I remember people by their packages, not by name, sorry :)
[18:15] <paultag> whoh
[18:15] <paultag> that came out way wrong
[18:16] <paultag> /clear
[18:29] <evaluate> hmm, it seems I hve been added to the collab-maint project (although I didn't get any notification about it). Does collab-maint only use SVN?
[18:31] <paultag> evaluate: narp. I'm using git on my projects
[18:33] <evaluate> hmm, I can only see SVN listed on the project page... too bad there's barely any information out there on how to use alioth...
[18:33] <paultag> +1
[18:34] <paultag> Well, shucks. It's coffee time. BBL
[18:34] <paultag> evaluate: well met, keep up the great work
[18:34] <evaluate> paultag, thanks! see you around :-)
[18:35] <evaluate> guess I'll go over to oftc.net's #alioth, hopefully they have some useful links
=== hannesw_ is now known as hannesw
[20:36] <hrw> does someone know is it possible to APT pin hosts not only releases/packages?
[20:37] <micahg> hrw: yes, o=foo
[20:37] <hrw> micahg: o=Ubuntu in both
[20:38] <micahg> hrw: no, o= is for the host
[20:38] <micahg> or rather site
[20:38] <micahg> err..repository :-/
[20:40] <hrw> micahg: http://pastebin.com/kd68CUzU
[20:40] <micahg> hrw: ok, what are you trying to do?
[20:41] <hrw> micahg: set ports.ubuntu.com as lowest priority so apt will fetch arch=all from de.archive.ubuntu.com
[20:42] <micahg> errr..apt's not set up for that AFAIK
[20:42] <micahg> hrw: oops, yes, you can :)
[20:43] <hrw> o=host?
[20:43] <hrw> will have to try
[20:43] <micahg> hrw: try this in /etc/apt/preferences, http://pastebin.ubuntu.com/540421/
[20:45] <hrw> nope
[20:46] <micahg> hrw: yeah, I think pinning is just for versions
[20:46] <james_w> put the site you prefer first in the list
[20:47] <james_w> if the site you prefer is dependent on the package that is being fetched then you are SOL I think
[20:48] <hrw> works
[20:48] <hrw> added main with pri 999 and then ports with pri 50
[20:48] <hrw> thanks
[20:49] <hrw> no more waiting for 100MB of files from slow ports.ubuntu.com when they are on fast link to mirrorred archive
[23:02] <ari-tczew> lucas: could you check whether UDD merges works fine?
[23:14] <lucas> ari-tczew: they were (as geser already noticed). the problem was a mirroring problem to UDD, which is fixed now, so the data should be refreshed very soon now
[23:15] <lucas> (I'm doing a manual sync)
[23:18] <ari-tczew> ok