[10:44] <norsetto> morning all
[10:46] <soren> pkern: For one thing, the amount of places you need to change stuff to add an extra configuration option is positively *insane*.
[10:47] <pkern> Moin siretart.
[10:48] <pkern> soren: Looking at a loop, thinking "wow, this leaks" isn't fun. \:
[10:48] <siretart> pkern: I'm currently on low bandwith, so I cannot really testbuild nor upload big packages like gnucash ATM. If you have a bit time, you could review my merge in the hbci branch and upload it to our PPA
[10:49] <pkern> siretart: Aye, will do later.
[10:49] <pkern> Currently on high bandwidth, but I should go studying a bit. But when I get demotivated again I'll do it.
[10:50] <siretart> pkern: oh, I didn't want to distract yourself from your exam :)
[10:51] <pkern> siretart: ;)
[10:51] <Hobbsee> hi norsetto
[10:51] <norsetto> Hobbsee: hey
[10:56] <sladen> lamont: (sorry, at a conference) back to the clock issue.
[10:57] <sladen> lamont: even when the time on the clock is wrong, it's never more than 24hours out, and only in an integer number of hours, and not generally minutes (other than general clock drift)
[10:57] <norsetto> This is interesting, I used to be able to edit pages on https://help.ubuntu.com/ and now I'm not anymore.
[10:58] <sladen> lamont: so the possible "future" values of the value of  ~ +1,+2,+3,+4,+5...+13 hours
[10:58] <sladen> lamont: and those are the 13 possible values that will cause the premature fsck
[11:04] <huats> 'ning norsetto
[11:05] <norsetto> huats: 'ning
[11:06] <huats> norsetto:  :-)
[11:08] <norsetto> huats: I just got an invitation to a signature session with Regis Loisel. You know him?
[11:08] <huats> norsetto: no
[11:08] <huats> norsetto: oh yes
[11:08] <huats> norsetto: I have heard about him
[11:09] <norsetto> huats: ok, so you are not a bd fan
[11:09] <huats> norsetto: but I am not a big fan of bd
[11:09] <huats> norsetto: but as far as I know he is a very talented man
[11:11] <norsetto> huats: I'm glad you are looking at all bugs, if I see yet another .desktop bug I think I'm going to explode
[11:12] <huats> :-)
[11:12] <huats> norsetto: unfortunatly I am not looking at all bugs...
[11:12] <norsetto> huats: NO! Not another one!!
[11:13] <huats> norsetto: but if you seen another .desktop just let me know, I'll try to take care of it... I don't want you to explode
[11:13] <norsetto> huats: yeah, its going to take a while to clean that up
[11:15] <huats> norsetto: I am afraid too
[11:21] <norsetto> Kopfgeldjaeger: what do you mean by your last comment on avidemux? That you remove the package or just the last upload?
[11:24] <norsetto> Kopfgeldjaeger: what do you mean by your last comment on avidemux? That you remove the package or just the last upload?
[11:42] <lucas> soren: -T sets tags, not usertags
[11:46] <soren> lucas: I see. Well, fix reportbug then. :)
[01:21] <norsetto> any revu admin around?
[01:26] <bluekuja> norsetto: need a resync?
[01:26] <norsetto> bluekuja: hey, no, just wanted to check if I have ssh access enabled
[01:27] <bluekuja> norsetto: oh ok then
[01:27] <bluekuja> :)
[01:27] <bluekuja> you may need siretart then
[01:27] <norsetto> bluekuja: yeah, thx
[01:28] <norsetto> bluekuja: actually, you do have ssh access already?
[01:28] <bluekuja> norsetto: yep
[01:28] <bluekuja> norsetto: is your account active'
[01:28] <bluekuja> e.g created
[01:29] <norsetto> bluekuja: can you run some revu-report for me?
[01:29] <bluekuja> norsetto: yeah, let me log in
[01:29] <norsetto> bluekuja: is it a different one form the use I use to dput/review?
[01:30] <bluekuja> norsetto: I dont get what you mean
[01:31] <norsetto> bluekuja: I mean, its just one account right?
[01:31] <ScottK> siretart: Why did you put gnucash in bzr?
[01:31] <norsetto> morning scottk
[01:31] <ScottK> siretart: Unless I absolutely can't avoid it, I don't use bzr.
[01:31] <ScottK> morning norsetto
[01:31] <bluekuja> norsetto: if you are talking about sparky, yes
[01:32] <norsetto> bluekuja: yep
[01:32] <bluekuja> norsetto: for sparky you need siretart to create an account for you
[01:32] <norsetto> bluekuja: did you have to ask for something special to have ssh enabled? becuase I have an account already
[01:33] <bluekuja> norsetto: nope, I was able to login with ssh right after having my account enabled
[01:33] <bluekuja> on the system
[01:33] <norsetto> bluekuja: hmmmm, there must be some problem on my side then
[01:33] <bluekuja> norsetto: which message do you get?
[01:33] <norsetto> bluekuja: Permission denied (publickey).
[01:34] <bluekuja> norsetto: strange, is your key on LP?
[01:34] <norsetto> bluekuja: yes, I can dput and login through the web interface with no problem
[01:35] <bluekuja> norsetto: which web interface?
[01:35] <norsetto> bluekuja: what command are you using to login?
[01:35] <bluekuja> norsetto: revu?
[01:36] <bluekuja> norsetto: maybe you enter a bad login name
[01:36] <norsetto> bluekuja: the usual, what is it revu.tauware.de
[01:36] <bluekuja> norsetto: ssh -l login-name host
[01:36] <bluekuja> host is sparky.ubuntuwire.com
[01:37] <norsetto> bluekuja: ok, let me try that
[01:37] <bluekuja> norsetto: the host you was trying to use it's wrong, that's why^^
[01:37] <norsetto> bluekuja: same problem
[01:37] <bluekuja> mmm
[01:38] <norsetto> bluekuja: some IP too .....
[01:38] <norsetto> s/some/same
[01:38] <siretart> ScottK: because its easier for me to maintain the -hbci branch this way
[01:38] <ScottK> siretart: What's the -hbci branch?
[01:39] <bluekuja> siretart: can you investigate norsetto's account on sparky?
[01:39] <siretart> ScottK: see http://launchpad.net/~gnucash/+archive
[01:39] <norsetto> siretart: sorry to bother, just I'm getting a Permission denied (publickey) if I try to ssh to revu
[01:40] <pkern> siretart: See Jabber.
[01:40] <bluekuja> norsetto: call it sparky, revu is just hosted there
[01:40] <siretart> siretart@sparky:~$ id norsetto
[01:40] <siretart> id: norsetto: No such user
[01:40] <bluekuja> ^^
[01:40] <ScottK> siretart: It doesn't say what hbci is?
[01:41] <pkern> siretart: Currently testbuilding gnucash. Hm, just finished.
[01:41] <pkern> siretart: Should I upload it or do you have other changes to integrate?
[01:41] <siretart> pkern: please upload
[01:41] <pkern> siretart: (quilt was not properly activated)
[01:41] <pkern> siretart: That's not the HBCI branch.
[01:41] <pkern> ScottK: German homebanking standard.
[01:41] <ScottK> Ah.
[01:41] <siretart> ScottK: banks usually offer their customers online access to their accounts via hbci
[01:41] <ScottK> I see.
[01:42] <ScottK> That makes sense.
[01:42] <ScottK> Is there a reason that can't be integrated into Ubuntu's Gnucash?
[01:42] <pkern> ScottK: OpenSSL linking
[01:42] <ScottK> Ah.
[01:42] <pkern> siretart: Hm, dch fails on that branch because the packaging is not in debian/
[01:42] <ScottK> It's not clear to me how that's allowed in a PPA, but not in the regular archive?
[01:43] <pkern> ScottK: It's not clear to me neither.
[01:43] <siretart> pkern: apt-get install bzr-builddeb && bzr bd -S
[01:43] <pkern> siretart: Yep but it's about updating the changelog.
[01:43] <pkern> Our existing toolchain helps on such issues.
[01:43] <siretart> pkern: 3 solutions:
[01:44] <pkern> Name it `debian'?
[01:44] <siretart> a) ln -s . debian, b) dch -i -c changelog, c) use emacs
[01:44] <siretart> I choose c) :)
[01:44] <pkern> Haha@a
[01:44] <pkern> I go for b), even if zsh completion breaks.
[01:45] <siretart> yes, I used to go with a), but I've settled on b) for now
[01:48] <norsetto> siretart: ok, so what should I do? My usual login is cesare.tirabassi@gmail.com
[01:49] <pkern> siretart: uploaded. How to merge the ubuntu branch into ubuntu.hbci?
[01:54] <pkern> siretart: Done, now testbuilding.
[01:54] <bluefoxicy> does anyone know when the gutsy partners distro goes live
[01:54] <bluefoxicy> err. repo
[01:58] <bluefoxicy> hrm, all it has is opera... but I want vmware server
[01:59] <sladen> bluefoxicy: http://archive.canonical.com/ubuntu/dists/gutsy/
[01:59] <sladen> I want a Pony!
[02:00] <bluefoxicy> hrm, pony?
[02:00] <bluefoxicy> I knew open source developers were into some strange stuff but...
[02:01] <siretart> pkern: err, bzr merge <urltoubuntubranch>?
[02:01] <siretart> norsetto: looking into it
[02:01] <pkern> siretart: Yep got that. ;)
[02:01] <siretart> norsetto: what do you need the account on sparky for?
[02:03] <ScottK> StevenK: I was curious if you had any more specific suggestions on the razor bug?
[02:03] <StevenK> Waaah
[02:03] <StevenK> No, none
[02:06] <ScottK> StevenK: OK.  Thanks for looking.
[02:06] <StevenK> ScottK: Sorry, I'm just trying to do (and keep track of) too many things at once.
[02:06] <ScottK> I understand.
[02:12] <siretart> norsetto?
[02:17] <fernando> moin all
[02:32] <norsetto> siretart: sorry, was having lunch
[02:33] <norsetto> siretart: just to run revu-report, even though this might not be possible anymore on sparky?
[02:37] <trunx> hi
[02:46] <siretart> norsetto: you should be able to login now
[02:46] <siretart> norsetto: revu-report? what's that? ;)
[02:49] <Fujitsu> siretart: pitti's cryptsetup patch (or at least your upload) makes my laptop boot, thanks!
[02:50] <norsetto> siretart: thx :-)
[02:51] <siretart> Fujitsu: yay. so the merge works! thanks for the feedback!
[02:52] <siretart> Fujitsu: wie now even have a working partman-crypto-auto now on the alternate installer, so we have now lvm on crypted PVs working out-of-the-box now :)
[02:58] <norsetto> siretart: sorry, still can't get in .....
[03:00] <asisak> Hey MOTUs
[03:00] <asisak> Can some MOTU UVF ack my Tor update besides ScottK?
[03:01] <soren> link, plesae.
[03:01] <soren> please, even.
[03:01] <asisak> soren: bug 137032
[03:01] <ubotu> Launchpad bug 137032 in tor "[UVFe]  please update tor 0.1.2.17 from debian sid" [Wishlist,In progress]  https://launchpad.net/bugs/137032
[03:02] <soren> What was the outcome of the discussion on the mailing lists?
[03:02] <soren> Didn't we decide to remove it unless someone stepped up to that plate and promised to maintain it forever and ever?
[03:04] <asisak> Yep. I want to promise to maintain it in Gutsy.
[03:04] <asisak> And eventually in Hardy.
[03:04] <asisak> Maybe in Feisty as well.
[03:04] <jdong> clamav suffers similar fate
[03:04] <asisak> Maybe we also have to update it in dapper till Hardy gets out.
[03:06] <asisak> Yeah.
[03:09] <lamont> it would appear (from 3 seconds of research) that amd64 is going to require 20070826-1, which is later than what gutsy has.
[03:10] <norsetto> asisak: hi there
[03:10] <asisak> hey norsetto
[03:10] <lamont> so... do we want a new version of mlton available in gutsy on amd64, hppa, ppc, sparc (as well as i386), or do we want the current version on hppa, ppc, sparc, and amd64 in hardy?
[03:10] <lamont> ScottK: ??
[03:11] <siretart> Oct  3 16:08:48 sparky sshd[27585] : Invalid user cesare.tirabassi@gmail.com from 79.17.75.227
[03:12] <siretart> norsetto: no, just use your launchpad id, not your email as username
[03:12] <Hobbsee> lamont: how big are the changes?
[03:12] <Hobbsee> lamont: and does it break anything else?
[03:12] <lamont> Hobbsee: I'm struggling to care enough to look....  bootstrapping things doesn't exactly provide me with lots of fun and joy....
[03:13] <lamont> hence the "who was it who cared about mlton?" question
[03:13] <Hobbsee> i doubt anyone cares about it, if it's that old
[03:13] <Hobbsee> lamont: looks like it was a sync - so no one in ubuntu
[03:13] <lamont> debian cared enough to get amd64 in in august of this year...
[03:14] <lamont> Hobbsee: the issue for ubuntu is that it self-build-depends
[03:14] <Hobbsee> lamont: classy.
[03:14] <Hobbsee> lamont: i'm happy to +1 that, if it's that broken.
[03:14] <norsetto> siretart: thats what I did (I tried all combinations actually)
[03:15] <lamont> Hobbsee: oh, that we need to bootstrap it is understood.  the question of the day is, do we care enough about mlton/amd64 in gutsy to take a new upstream version in order to get it, or does it get to wait until hardy.
[03:15] <norsetto> siretart: ssh -l norsetto sparky.ubuntuwire.com
[03:15] <norsetto> siretart: Permission denied (publickey).
[03:15] <lamont> I really don't care which way - it's bootstrapping pain now, or later
[03:17] <lamont> grep-dctrl -FBuild-Depends,Build-Depends-Indep -sPackage mlton /var/lib/apt/lists/....Sources
[03:17] <siretart> Hobbsee:         grep-dctrl -F Build-Depends -s Package $1 -n /var/lib/apt/lists/*_Sources
[03:17] <lamont> and the only package in universe that build-depends mlton is..... <drumroll>  mlton
[03:18] <StevenK> Yay!
[03:19] <Hobbsee> lamont: lets sync it now then.  if anything starts using it, it'll be more useful to have a vaguely newer version.
[03:20] <siretart> norsetto: I'm a bit confused now. I see not attempts of logins in the auth.log.. hmmm
[03:22] <Zombie> I need a shorewall.conf file,
[03:22] <Zombie> Anyone hav e one?
[03:23] <norsetto> siretart: if you are confused imagine how I am ....
[03:25] <lamont> Hobbsee: I think I'll see if 20060826 builds on amd64 first
[03:25] <Hobbsee> lamont: cool
[03:29] <asisak> soren: what do you think about tor? Do you want to wait till I send my letter to ubuntu-devel and tor gets accepted / rejected?
[03:29] <Zombie> Anyone have a default shorewall.conf file?\
[03:29] <Zombie> Please?
[03:30] <soren> asisak: Ah, sorry, I didn't see your reply there. I have 132 irssi windows, so if people don't write my name somewhere on the line, I sometimes miss it. :)
[03:30] <soren> asisak: If you intend to maintain it, I'll ack it.
[03:31] <siretart> norsetto: and you are really using the ssh key you have registered with launchpad?
[03:31] <norsetto> siretart: I only have the one
[03:32] <soren> asisak: Done
[03:33] <Zombie> Does anyuone know how to restore shorewall.conf to its original state using apt?
[03:34] <Hobbsee> Zombie: this is about packaging.  not about shorewall.  the fact that no one replied the first time you asked propbably means they dont use it.
[03:34] <asisak> soren: np. Thanks, even :)!
[03:34] <zul> besides this isnt a shorewall support or a support channel even
[03:34] <siretart> Zombie: try https://answers.edge.launchpad.net/ubuntu/+source/shorewall/+addquestion - or an appropriate irc channel
[03:35] <Fujitsu> siretart: Does sparky have the usual Ubuntuwire key syncing script?
[03:35] <siretart> Fujitsu: in principal yes, however, I copy'n'paste the relevant lines in a rootshell
[03:35] <siretart> Fujitsu: too sad that nobody steps in for ubuntuwire :(
[03:36] <Fujitsu> siretart: You mean you wrote his authorized_keys by hand, and it still doesn't work!?
[03:36] <norsetto> the ineffable norsetto ....
[03:36] <siretart> I've downloaded it from https://launchpad.net/~norsetto/+sshkeys
[03:37] <asisak> soren: should I subscribe archive people now?
[03:37] <asisak> (Since it is a sync, acked by MOTU UVF)
[03:37] <siretart> root@sparky:~# ls -l ~norsetto/.ssh/
[03:37] <siretart> -rwx------ 1 norsetto ubuntu-dev 606 Oct  3 16:27 authorized_keys
[03:37] <soren> asisak: Yes.
[03:37] <Fujitsu> siretart: What does auth.log say?
[03:38] <siretart> Fujitsu: norsetto let's move this to #ubuntuwire, please
[03:52] <\sh> moins
[03:52] <pkern> What's ubuntuwire? ;)
[03:56] <siretart> pkern: it was an attempt to have something like the debian project machines in ubuntu
[03:57] <lucas> "was"?
[03:57] <siretart> pkern: atm, there is only one public machine left: sparky. the main problem are admin volunteers, I think
[03:57] <lucas> ah ok
[03:57] <siretart> well, I'm the local admin for sparky, since it is hosted at my work-place
[03:58] <asisak> hey \sh
[03:58] <siretart> but I don't have time to keep the account script up-to-date, and create accounts on request only
[03:58] <Hobbsee> hiya \sh
[03:58] <Fujitsu> siretart: Why is the account script broken now? (I wrote it)
[03:59] <\sh> hey Hobbsee asisak siretart
[03:59] <siretart> huhu Shoragan
[03:59] <siretart> huhu \sh
[04:04] <\sh> Nafallo, last gajim upload brought me a annoying feature..:(
[04:05] <\sh> Nafallo, chat messages coming from remote  are now displayed under the name of the buddy...my messages are still displayed next to my name
[04:16] <Nafallo> \sh: hmm, how do you mean?
[04:17] <Nafallo> \sh: oh. I don't use remote...
[04:18] <\sh> Nafallo, no...when a message comes from a buddy...it's not displayed next to the name...but under the name
[04:18] <\sh> while self typed messages are still displayed next to my name
[04:18] <lamont> http://launchpadlibrarian.net/9692173/buildlog_ubuntu-gutsy-hppa.xserver-xorg-input-microtouch_1%3A1.1.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[04:18] <lamont> dies on i386/gutsy as well...
[04:18] <lamont> and is only one of several xserver-xorg-* packages in that state
[04:18] <Nafallo> \sh: ah. statusmessages?
[04:19] <\sh> Nafallo, give me a sec for showing you a screenshot
[04:19] <Nafallo> \sh: thanks :-).
[04:27] <bddebian> Heya gang
[04:27] <sladen> hey yeah bddebian
[04:27] <bddebian> Hello sladen
[04:27] <asisak> hey bddebian
[04:28] <bddebian> Hello asisak
[04:29] <norsetto> Hola bddebian
[04:29] <lamont> make[4] : *** [mlton-compile]  Error 1
[04:30] <lamont> so much for current gutsy mlton working on amd64
[04:30] <bddebian> Hello norsetto
[04:31] <\sh> wtf is mlton?
[04:31] <lamont> \sh: some compiler crack
[04:31] <dfiloni> Hi norsetto
[04:31] <lamont> or was that crack compiler?
[04:32] <norsetto> dfiloni: hi there
[04:32] <siretart> ML considered crack?
[04:32] <lamont> the only reason I can see why we should even consider grabbing new mlton is (1) no one cares about  it (2) it'd let me bootstrap amd64 while I'm bootstrapping sparc/ppc/hppa instead of later
[04:33] <lamont> siretart: nah.. I just have _absolutely_ no clue what mlton is....
[04:33] <lamont> nor do I care to.
[04:33] <lamont> then again, I gather that ML is one of them thar computor languages
[04:33] <zul> hyuck hyuck
[04:33] <lamont> which sums up my knowledge of it.
[04:34] <lamont> (and if I'm mistaken in that gathering, I don't really care, either...)
[04:34] <lamont> it definitely fits into my "I frequently don't want to know about a package I uploaded 5 minutes ago" category
[04:35] <\sh> lamont, what's the error message?
[04:36] <lamont> \sh: you have a ronne login?
[04:36] <\sh> lamont, I don't have any login, just to my machine...
[04:36] <lamont> ok
[04:37] <lamont> Error: ../lib/mlton/basic/file-desc.sml 14.32.
[04:37] <lamont>   Function applied to incorrect argument.
[04:37] <lamont>     expects: _ * (_ -> [word] )
[04:37] <lamont>     but got: _ * (_ -> [Word64.word] )
[04:37] <lamont>     in: o (Word.layout, fdToWord)
[04:37] <lamont> which is to say, 20070826-1 contained fixes to make it build on amd64
[04:37] <siretart> lamont: ah, so I expect you love the 'last uploader is responsible' policy ;)
[04:37] <bddebian> heh
[04:37] <lamont> siretart: what policy?
[04:38] <\sh> lamont, why not sync it in with an UVE? it could be better then a broken package now ;)
[04:38] <lamont> mind you, I do live by that policy to some extent... if my upload broke things, then I care.  if it didn't, then I reassign the bug to keybuk. :-)
[04:38] <lamont> \sh: it's a non-existant package now
[04:38] <lamont> mlton is dep-wait mlton in LP for gutsy
[04:39] <\sh> oh nice
[04:39] <\sh> so it needs a little bootstrap kick
[04:39] <lamont> so today's fun is "bootstrap it on hppa/ppc/sparc", let motu decide if they want to sync something newer, if they do, deal with amd64
[04:39] <lamont> mind you, I'd prefer that it _NOT_ be synced until after I bootstrap the 3
[04:40] <lamont> although I don't care _that_ much
[04:40] <lamont> I am likely to upload -1build1 when all is done to force a rebuild-with-LP-debs for sanity and love
[04:42] <siretart> lamont: so you can inject binaries into the archive bypassing the lp buildds?
[04:42] <lamont> no
[04:42] <lamont> I can accomplish something that is effectively the same thing
[04:42] <pkern> siretart: Well, I don't get why Canonical doesn't offer them for core devs.
[04:43] <lamont> pkern: policy is that all binaries published on {archive,ports}.u.c were built from source on the buildds
[04:43] <lamont> siretart: what I can do is push a new build chroot which points to a bootstrapping archive which has non-LP bits in it
[04:43] <lamont> and from there, it's "lamont the human autobuilder" to the rescue
[04:44] <\sh> sounds like a new title of an marvel comic..."Lamont, the Autobuilder" ,-)
[04:44] <pkern> lamont: Actually that was unrelated to his current question, but even for this point my observation still holds. It's actually impossible for Non-Canonical people to bootstrap a compiler?
[04:44] <ion_> :-)
[04:45] <lamont> pkern: uh... I'm not sure how to answer that question... I am not canonical
[04:45] <lamont> but I am special.  My mommy told me so.
[04:45] <pkern> lamont: Hah (:
[04:45] <pkern> siretart: That was re development machines.
[04:45] <siretart> lamont: proll and openhackware FTBFS on i386, but can be build on sparc/powerpc. do you think you can get them into the archive?
[04:46] <lamont> siretart: why do they ftbfs?
[04:46] <lamont> are they arch-all?
[04:46] <\sh> pkern, which could be a good thing...so the support-responsibility is still doko^Wcanonical
[04:46] <siretart> lamont: because they are written in arch-specific assembly and are arch all
[04:46] <siretart> lamont: qemu is using them as firmware for booting
[04:46] <lamont> um... if they have arch-specific assembly in them, they are most certainly not arch-all.
[04:47] <lamont> the standard, uh, hack for that is to build source on the right architecure, and have the uploaded source contain the built binary blob
[04:47] <siretart> well, they are, since qemu is avaiable on any arch
[04:47] <siretart> it is not executed, nor installed to /usr/bin/ or something
[04:47] <lamont> which makes me wanna vomit
[04:47] <siretart> it is executable code, which can be interpreted with qemu
[04:48] <lamont> arch all that is ftbfs on other than $magic_arch is not arch all.
[04:48] <siretart> yes. it wouldn't be a problem at all if we could upload manually compiled arch: all packages like in debian
[04:48] <pkern> \sh: I talk about non-standard compilers like... uh... ghc or such things. ;)
[04:48] <lamont> source should be fixed (to include a binary blob, which can have source there as well)
[04:48] <siretart> lamont: I talked to the debian maintainer, and he refuses to fix it.
[04:48] <lamont> fork
[04:48] <pkern> But well one could upload ghc-bin or so and use that. :-P
[04:48] <\sh> pkern, well, for this we have our buildd admins like infinity ;)
[04:48] <siretart> and I'm not going to invest energy to make it cross-compilable
[04:49] <siretart> I'd rather direct users to install the binary package (arch all) from debian
[04:49] <lamont> pkern: there are abusive ways to inject binaries into the archive that could be done by anyone with upload privs.  I expect that such abuse would be likely to get their upload privs revoked.
[04:49] <\sh> anyways...I'm leaving now for real work...updating paper CV and writing some mails to some companies for a new jon
[04:49] <lamont> siretart: it doesn't need to be cross-compilable
[04:49] <\sh> s/jon/job/
[04:50] <lamont> make it an arch all package who's sparc-requiring build happens in the clean target, and who's build target just uudecodes the blob
[04:50] <\sh> cu later :)
[04:50] <lamont> pkern: the official way to bootstrap something circular is: 1) provide an archive with binaries that work 2) whack infinity/lamont and get it done
[04:52] <pkern> lamont: Ok.
[04:52] <lamont> pkern: of course, sometimes it can take months for someone to figure out step 2.
[04:53] <siretart> lamont: which effectively means to ship a precompiled uuencoded binary in the source. :/
[04:53] <lamont> siretart: ssssshhhh!!
[04:53] <lamont> but _with_ source.
[04:53] <lamont> see plao
[04:53] <lamont> er, palo
[04:54] <pkern> Hah. There goes the policy of injecting binaries. (=
[04:55] <lamont> pkern: that's not injecting binaries.  that's delivering blobs
[04:55] <lamont> and restricted is _ALL_ about taht
[04:55] <lamont> that
[04:55] <siretart> and you're sure the archive admins are okay with that?
[04:56] <lamont> palo is in main
[04:56] <lamont> siretart: the correct way is to get the debian maintainer to do that
[04:56] <siretart> lamont: been there, tried that, lost, went home
[05:17] <lamont> siretart: that's a good idea
[05:26] <asisak> see you later
[05:28] <release_dude> anyone here to answer questions on package update policies ?
[05:29] <bddebian> I just have to re-iterate something.  Even though I get frustrated and feel pretty useless at times, the MOTU community rocks!
[05:30] <release_dude> I would like to know the correct procedure to get a new version of the gnumed-client package into Ubuntu Feisty
[05:30] <jdong> new version? Backports is your only route.
[05:30] <jdong> what is the nature of the update?
[05:31] <release_dude> the version in Feisty is pretty useless for anyone but developers. The version in Gutsy is the first one to be usable by doctors
[05:31] <release_dude> I am from the GNUmed team
[05:32] <release_dude> and get contacted often by people using feisty
[05:32] <release_dude> they ask me why gnumed sucks so bad
[05:32] <jdong> release_dude: that sounds like a candidate for backporting then. I've got to run now, but if you want to file a backport request on it I'd be happy to look.
[05:32] <jdong> release_dude: due to the nature of Ubuntu's stable-release policy, the chances of getting an updated version into any other feisty update channel is nearly zero
[05:32] <release_dude> thanks for the answer
[05:33] <release_dude> this is too bad
[05:33] <release_dude> People get frustrated
[05:33] <release_dude> and tell me our software sucks, too bad
[05:33] <jdong> release_dude: I understand your frustration, but at the same time it's difficult to balance a constant stream of updates with minimizing breaking of stable releases
[05:34] <release_dude> I understand
[05:34] <release_dude> I guess telling people to upgrade a otherwise stable distro is no way out, thanks anyway
[05:42] <release_dude> jdong: https://bugs.launchpad.net/feisty-backports/+bug/118438 has been file some time ago
[05:42] <ubotu> Launchpad bug 118438 in feisty-backports "please backport gnumed from gutsy to feisty" [Undecided,New] 
[06:04] <Linuturk> What is the procedure for requesting a new package to enter the Universe. There is currently a package called ocsinventory-agent comitted to the gutsy Universe. It's counterpart, oscinventory-server is not in the universe at this time. Would it be possible to make an exception for the server component of this server application? The deb packages already exist in Debian Testing as of August.
[06:08] <lamont> Linuturk: it'll automatically be in hardy, if that helps any
[06:10] <Linuturk> lamont: well, in a wierd way, I'm trying to get this backported to feisty eventually. I'm running a feisty server at this time, and I'm migrating an existing oscinventory installation from an old testing box to a production server. I'd like all the benefits that come with having an actual package instead of compiling it from source again.
[06:13] <lamont> yeah.  sadly, the time for new packages, even in universe, is well past.  Then again, it is universe we're talking about....
[06:18] <ScottK> lamont: You are a MOTU by inheritence.
[06:19] <ScottK> Linuturk: There is, at this point, not enough time to get a new pacakge through all the reviews needed.
[06:22] <Linuturk> ScottK: What do you recommend? Wait for Hardy?
[06:22] <ScottK> Linuturk: Yes.  Once it's in the Hardy repository it can be backported from there.
[06:25] <leonel> the security updates for  backports  how it's done ?  like any other package in universe ?
[06:27] <Linuturk> Can it be backported from Hardy Devel ScottK ? When is that repo usually setup?
[06:28] <ScottK> Usually a few weeks after the previous release.
[06:32] <Linuturk> thank you guys for the info
[06:46] <lamont> ScottK: I'm not a policy-maker for universe
[06:46] <ScottK> True.
[06:46] <lamont> I'm just a rampaging uploader from time to time...
[06:49] <zul> lamont: we all are
[06:52] <lamont> ScottK: thoughts on mlton/amd64?  I'm going to assume it's a hardy thing
[06:53] <ScottK> lamont: Since it's FTBFS on all archs except i386 now, I think the downside risk is low.  My inclination (without having looked at the amount of code churn in the newer version) would be to go for it.
[06:54] <ScottK> Err. Depwait, not FTBFS
[06:54] <lamont> it's dep-wait mlton
[06:54] <lamont> as in Build-Depends: $SELF
[06:55] <ScottK> Then there's always the removal option.
[06:55] <ScottK> Since the package is IMO broken by design.
[06:55] <lamont> well, gcc build-depends gcc
[06:55] <lamont> and X build-depends X
[06:55] <ScottK> lamont: I'm deeply ambivalent.
[06:55] <siretart> and mono build-depends mono
[06:56] <siretart> we have a lot of self-builddepending crap in our archive
[06:56] <lamont> it's normal for compilers and X to build-depend on themselves...
[06:56] <ScottK> OK.
[06:56] <lamont> then again, after the breakup into xorg bite-sized pieces, it's possible that X doesn't build-depend itself anymore
[06:56] <lamont> oh, and let's not forget ecj build-depends ecj...  to hppa's great pain atm
[06:57] <lamont> anyway, lunchtime for me.
[08:28] <DaveMorris> I've been packaging up opensg for ubuntu in my ppa, and it's almost done.  Now the question is, is it best to use the release which was in 04, or take the active branch which is in cvs and do a release each 6 months?
[08:29] <minghua> DaveMorris: Is there any reason you can't do both?
[08:30] <DaveMorris> I can, I was wondering what fitted with the ubuntu way so it can be included in the main repo's
[08:31] <minghua> Oh.  Then I don't know.  Depends on the nature of the software and the package, generally speaking.
[08:32] <gnomefreak> is flashplugin-nonfree something we can update in dapper? its giving the same md5sum error that feisty and gutsy were giving when they upgraded the tarball upstream
[08:37] <ScottK> gnomefreak: Seems to me that pacakge doesn't work meets the SRU criteria.
[08:37] <ScottK> DaveMorris: How come they don't release?
[08:37] <gnomefreak> ScottK: it does?
[08:37] <gnomefreak> its not a security update
[08:38] <gnomefreak> ok ill grab it and have it fixed by end of day
[08:38] <ScottK> gnomefreak: SRU, not security.
[08:38] <gnomefreak> yeah caught that :(
[08:40] <kiko-afk> hey there
[08:41] <geser> Hi kiko
[08:41] <kiko> I'm curious if anyone would be interested in packaging OGMRip
[08:41] <kiko> it's a DVD-ripping app for GNOME
[08:41] <kiko> https://edge.launchpad.net/ogmrip/
[08:42] <kiko> the author contacted me and I was checking to see if anyone would like to pick it up
[08:42] <kiko> it has a previous packaging available at getdeb.org apparently
[08:43] <DaveMorris> ScottK: it started as a research project, and I guess they are only fixing bugs now, whilst working on version 2 - which has major changes
[08:45] <Lutin> gnomefreak: updated E packages available
[08:47] <ScottK> DaveMorris: The svn snapshot...  Is it bugfixes to the stable branch or a snapshot of unstable development software?
[08:48] <DaveMorris> stable branch
[08:56] <jdong> Mez_: remind me in 24hrs to poke you to sponsor a prevu fix for Gutsy.... need to add a 1-liner to whitelist gutsy as a valid target
[08:57] <bddebian> Anyone know what replaces gtk-config in gtk2?  Does it use pkg-config?
[08:57] <zul> i think so but best ask in -desktop
[08:58] <bddebian> Gah, too many damn channels :-)
[08:58] <geser> Hi bddebian
[08:58] <bddebian> Thx zul
[08:58] <bddebian> Heya geser
[09:00] <geser> bddebian: have you tried looking inside libgtk2.0-dev?
[09:03] <bddebian> geser: A little but as you know, I'm kinda braindead :-)
[09:06] <jdong> can some kind soul sponsor http://severance.gotdns.org/~jdong/debdiffs/prevu-gutsy.debdiff into gutsy? One-line fix for Prevu under Gutsy, test built and installed and run.
[09:07] <zul> jdong: for universe or main?
[09:08] <jdong> zul: universe
[09:08] <zul> jdong: ping me in a couple of hours say around 8 and ill do it
[09:08] <jdong> zul: ok, will do, thanks.
[09:17] <bluekuja> jdong: heya
[09:18] <bluekuja> jdong: still need sponsorship?
[09:18] <jdong> bluekuja: yes sir
[09:18] <bluekuja> jdong: grabbing source ;)
[09:18] <bluekuja> give me two minutes
[09:18] <jdong> thanks
[09:18] <gnomefreak> Lutin: ty i got them a bit ago :)
[09:19] <Lutin> gnomefreak: hehe, cool
[09:25] <bluekuja> jdong: uploaded ;)
[09:26] <jdong> bluekuja: thank you
[09:26] <bluekuja> jdong: you're really welcome ;)
[09:36] <DktrKranz> keescook, could you answer a couple of questions regarding bug 137070 ?
[09:36] <ubotu> Launchpad bug 137070 in bind "BIND version 8 generates cryptographically weak DNS query identifiers" [Medium,Triaged]  https://launchpad.net/bugs/137070
[10:10] <bddebian> Later gang
[10:33] <gnomefreak> anyone happen to have a dapper chroot? for some reason dpkg fails to do anything :(
[10:41] <leonel>  gnomefreak   want me to try some thing in dapper ?
[10:41] <leonel> or dapper chroot ?
[10:42] <gnomefreak> leonel: if you have one built what version of dpkg is there
[10:42] <gnomefreak> should be ubuntu 6 or ubuntu7
[10:42] <leonel> 1.13.11ubuntu6
[10:43] <gnomefreak> leonel: does it work?
[10:43] <gnomefreak> seems like a stupid question but ubuntu6 is failing badly here
[10:43] <gnomefreak> dpkg: syntax error: unknown group `Debian-exim' in statoverride file
[10:43] <gnomefreak> E: Sub-process /usr/bin/dpkg returned an error code (2
[10:44] <gnomefreak> please tell me you dont see that
[10:45] <leonel> well I don't have exim ... let me install something
[10:45] <gnomefreak> leonel: i dont think i have it either :(
[10:45] <gnomefreak> nope package exim isnt installed here
[10:46] <gnomefreak> ah yes it is its exim4
[10:47] <gnomefreak> well without dpkg there isnt much i can do to remove it
[10:47] <Kopfgeldjaeger> good night
[10:48] <gnomefreak> i guess this means im redoing my chroot
[10:48] <leonel> gnomefreak:  no problems  installing  libclamav1_0.88.2-1ubuntu1.3_i386.deb  with dpkg
[10:48] <gnomefreak> night Kopfgeldjaeger
[10:48] <minghua> Sounds like a broken chroot.
[10:48] <gnomefreak> its most likely due to installing subversion-tools
[10:48] <gnomefreak> minghua: its brand new
[10:49] <gnomefreak> oh well start over sounds best
[10:50] <gnomefreak> brb
[11:13] <keescook> DktrKranz: sure! what's up?
[11:17] <DktrKranz> keescook, that package does not have a patch system, and patch provided upstream is quite large (> 20k). Is it legal to apply it upstream or it is better to apply it in another way?
[11:17] <DktrKranz> erm...inline, not upstream
[11:32] <keescook> DktrKranz: without a patch system, inline is really the simplest way to go.  Note that almost no one uses "bind", they normally use bind9.  Since it's a large (and non-obvious) patch, it'd need to be tested.
[11:33] <DktrKranz> that's the second question...since no one uses bind, I need to discover how to test it
[11:33] <pwnguin> bind is just bind8
[11:33] <pwnguin> afaict
[11:33] <DktrKranz> pwnguin, yeo
[11:33] <DktrKranz> *yep
[11:34] <pwnguin> im not even sure why its in universe
[11:34] <DktrKranz> it has been removed from gutsy, but is still present in < gutsy
[11:34] <pwnguin> ah
[11:34] <pwnguin> i recall someone filing a bug about bind not being bind9
[11:35] <DktrKranz> bind8 has been marked as EoS
[11:35] <DktrKranz> that was last patch provided (IIRC)
[11:35] <pwnguin> so you want to backport some patches to bind that aren't upstream?
[11:36] <DktrKranz> they are upstream
[11:36] <DktrKranz> the last ones :)
[11:36] <pwnguin> i see
[11:36] <pwnguin> as far as patching
[11:36] <pwnguin> i favor quilt / dpatch
[11:37] <pwnguin> its nice to have the patches small and seperate
[11:37] <DktrKranz> that's a single, big, patch
[11:38] <DktrKranz> it was > 40k, but code was about a half
[11:38] <pwnguin> have you looked at debian's package?
[11:39] <DktrKranz> there's a bug open
[11:39] <DktrKranz> but no fix has been provided so far
[11:39] <pwnguin> ok
[11:39] <geser> DktrKranz: based on that bind8 got removed from gutsy and new patches aren't expected anymore I wouldn't add a patch system only for this patch
[11:39] <pwnguin> that' a good point
[11:39] <DktrKranz> and bind8 was removed from debian too...
[11:40] <pwnguin> esp if it's already upstream
[11:40] <DktrKranz> geser, this is true even if this patch would go into a security update
[11:41] <DktrKranz> I remember someone (pitti?) who suggested me non to introduce patch systems on SRUs
[11:41] <geser> adding a patch system won't make the patch easier to understand
[11:42] <geser> hopefully nobody will need to touch that package again, so there is no need to make it better than needed
[11:43] <ScottK> DktrKranz: Yes.  That's what he's told me too.
[11:43] <pwnguin> but in the general case, it does make it easier for debian to take back work if you've got explicit patches to review. obviously your case is non-standard
[11:43] <DktrKranz> and if someone does, it will be for stable releases (gutsy removed it)
[11:46] <DktrKranz> well, it is quite trivial for debian maintainer to get a patch for this, if he wants to
[11:46] <lamont> ScottK: just to make sure, you're good with syncing the latest mlton from sid under the "What Evah..." clause?
[11:46] <ScottK> lamont: I am.  You need another apathetic motu-uvf too.
[11:47] <ScottK> zul is probably good for that.
[11:50] <lamont> zul: where are you when I need your apathy???
[11:51] <lamont> mind you, I don't want to actually sync it until after sparc/ppc build the older version
[11:57] <DktrKranz> night all
[12:18] <gnomefreak> for dapper proposed what should i prepend to version? the docs say dont use ~proposed but the example gived uses ~proposed
[12:19] <gnomefreak> it ends in ~dapper1 atm
[12:20] <minghua> Prepend?  Or do you mean append?
[12:21] <gnomefreak> append
[12:21] <gnomefreak> sorry thought i typed that
[12:22] <gnomefreak> so should i use ~dapper2 since its now ~dapper1?
[12:33] <ScottK> gnomefreak: Just use the version number you want it to have when it hits dapper-updates.
[12:33] <gnomefreak> ok
[12:34] <gnomefreak> this is odd since its in backports
[12:34] <gnomefreak> someone backported it and it is borked as were feisty edgy and gutsy
[12:36] <gnomefreak> would ~6.06.1 be greater than ~dapper1
[12:36] <gnomefreak> either that or i use dapper2 and its put in updates instead of backport
[12:37] <Fujitsu> gnomefreak: backports are independent from everything else. What are you trying to upload to? dapper-updates, or dapper-backports?
[12:38] <gnomefreak> proposed
[12:38] <gnomefreak> backports has flashplugin-nonfree (9.0.31.0.1ubuntu1~dapper1)