[12:37] <pwnguin> psh. just make everyone use gmail ;)
[12:38] <ScottK> pkern: I'm going to ask one of the archive admins how they recommend approaching it as they're the ones that'll have to New the package.
[12:38] <ScottK> pwnguin: Please. No. Not that.
[12:38] <pwnguin> top posting for everyone!
[12:38] <ScottK> Gah.
[12:38] <pkern> ScottK: Aye. Well, it's kind of a hard decision. I don't know how well it performs and it still looks like a moving target.
[12:39] <pwnguin> to be fair, top posting works great in gmail
[12:39] <pwnguin> as does conversation threading
[12:39] <ajmitch> 920 upgraded, 198 newly installed, 20 to remove and 7 not upgraded.
[12:39] <ajmitch> Need to get 940MB/942MB of archives.
[12:39] <ScottK> pkern: Right, but kind of maybe sucks beats completely broken.
[12:39] <ajmitch> yay for etch->sid
[12:39] <RAOF> pwnguin: No, gmail threading sucks.
[12:39] <pkern> ajmitch: I wouldn't want sid ;)
[12:40] <pkern> ;)
[12:40] <ajmitch> pkern: so you don't use gutsy? :)
[12:40] <sistpoty> pkern: I've CC'd you. did your MTA reject it (as I've not configured exim too well and am sending from a dynamic ip)?
[12:40] <imbrandon> wow i dont think i have had a stable system for 2+ years
[12:41] <pkern> sistpoty: Did you send it to<EMAIL_ADDRESS>Then I couldn't check.
[12:41] <pkern> ajmitch: Gutsy is almost stable :-P
[12:41] <ScottK> Except of course when it's not.
[12:42] <pwnguin> thats why i keep a seperate stable partition around
[12:42] <pkern> ScottK: I fixed those bugs that annoyed me, but there still the bloody SLUB kernel.
[12:42] <sistpoty> pkern: yes, I just hit reply-to-all (/me is a kmail user, since the days where I assumed I was the only one *g*)
[12:42] <pwnguin> it'd be nice if someone fixed up the grub automagic kernel stuff to handle two installs
[12:43] <pkern> sistpoty: You should not send from dynamic IPs anyway. But I did not configure dynamic RBLs per se on master, but you might be covered. And there is greylisting of course. ;)
[12:43] <sistpoty> pkern, ScottK: gutsy refers to stable as unstable refers to {RedHat, SuSE, ...} releases *g*
[12:43] <pkern> sistpoty: I didn't see the headers in the archives.
[12:43] <pkern> sistpoty: Gutsy is almost frozen. I also use testing when it's almost frozen.
[12:44] <sistpoty> pkern: I know, but it's convenient, and the wrong hostname is convenient as well (because I needn't touch exim settings *g*)
[12:44] <pkern> ajmitch: I tend to use sid chroots for that and I never felt the need to update a chroot from Etch to Sid. I re-debootstrap in such cases.
[12:44] <soothsayer> What packages do I need to debug nautilus + gnome-vfs?
[12:44] <soothsayer> (Besides nautilus-dbg)
[12:45] <pkern> sistpoty: Setting up SMTP AUTH isn't that hard, there are tutorials for that. But well, you aren't using postfix? ;)
[12:45] <ajmitch> pkern: I generally use sid chroots for that as well, but I did run sid as my main desktop for a few years
[12:45] <ajmitch> until I dist-upgraded from sid to hoary
[12:45] <sistpoty> pkern: I know, but I have a (erm postfix MTA, to smtp to) for lost mails *g+
[12:46] <pkern> ajmitch: Yeah, cross-distribution upgrades :D
[12:46] <pkern> ajmitch: Probably failing badly on epochs
[12:46] <ajmitch> lots of apt pinning fun :)
[12:46] <ajmitch> this was just after hoary opened, too
[12:46] <imbrandon> epochs are kept normaly in ubuntu
[12:47] <pkern> imbrandon: But when they are not made in Debian you get fun.
[12:48] <imbrandon> yea *cough* amarok *cough*
[12:53] <ajmitch> hi bigon
[12:54] <bigon> ajmitch: hi
[12:54] <ajmitch> sistpoty: start up the grill
[12:54] <sistpoty> ajmitch: for whom? pkern?
[12:54] <sistpoty> hi ajmitch btw  ;)
[12:55] <ajmitch> nah, bigon :)
[12:55] <bigon> :o
[12:55] <ajmitch> hello to you too :)
[12:55] <soothsayer> libglib2.0-dbg seems not to be available. Where can I get debug packages for glib?
[12:55] <ajmitch> bigon: you seem to have some good answers on the list there
[12:56] <RAOF> soothsayer: You can get -dbgsym packages for everything from people.ubuntu.com.  wiki.ubuntu.com/Backtrace I think.
[12:56] <sistpoty> ajmitch: just writing the reply.
[12:57] <sistpoty> ajmitch, bigon: and I'm almost in there for a +1... almost
[12:57] <bigon> sistpoty: :)
[12:57] <sistpoty> bigon: so I guess I skip the P.S.: almost... and just send the mail, ok?
[12:57] <ajmitch> bigon: how many of these packages that you work on will move to main?
[12:58] <soothsayer> RAOF: Sorry, I didn't quite understand any of that. Backtrace page doesn't seem to have any information that I need. And people.ubuntu.com?
[12:58] <sistpoty> ajmitch: why don't you ask these questions on the ML? then I wouldn't need to think about questions all the time :P
[12:59] <ajmitch> :P
[12:59] <bigon> ajmitch: I really don't know telepathy is still under heavy development
[01:00] <RAOF> soothsayer: Ah, sorry.  There's an archive on someone's people.ubuntu.com page which contians -dbgsym packages for everything.
[01:00] <RAOF> soothsayer: It may be under "DebuggingProgramCrash" on the wiki.
[01:00] <bigon> the empathy maintainer had asked to be part of the gnome desktop for version 2.22
[01:00] <RAOF> bigon: Cool.  I like the idea of telepathy/empathy.
[01:01] <bigon> :)
[01:01] <RAOF> bigon: Oh, and are you aware that telepathy-butterfly doesn't work at all?
[01:01] <zul> evening
[01:01] <bigon> RAOF: yep :) a new version (rewritten from scratch should go out today)
[01:01] <RAOF> Actually, that's not strictly true.  It works enough to repeatedly connect & disconnect :)
[01:02] <RAOF> Well, that should be a shoe-in for a UVFe :)
[01:02] <sistpoty> bigon: reply sent...
[01:03] <soothsayer> RAOF: Thanks
[01:05] <sistpoty> damn, need to go to bed in -2 hours. gn8 everyone
[01:14] <ajmitch> he wouldn't ask any hard questions
[01:15] <zul> hey ajmitch
[01:17] <ajmitch> hello
[01:18] <soothsayer> RAOF: Those repositories appear to be empty :(
[01:18] <soothsayer> http://people.ubuntu.com/~ubuntu-archive/ddebs/dists/gutsy/main/
[01:18] <RAOF> soothsayer: That's where I get all my ddebs from?
[01:18] <soothsayer> RAOF: Do you have debug packages for libglib2.0?
[01:19] <ajmitch> soothsayer: why do you say they'e empty?
[01:19] <ajmitch> the packages live under pool, not under dists
[01:20] <soothsayer> ajmitch: Ah, oops. Sorry
[01:20] <ajmitch> http://people.ubuntu.com/~ubuntu-archive/ddebs/pool/main/g/glib2.0/
[01:20] <soothsayer> ajmitch: Got it thanks
[01:20] <RAOF> soothsayer: In short, yes :)
[01:21] <ajmitch> as you should :)
[01:21] <pkern> And the sourcedeps ;)
[01:21] <ajmitch> rather than trying to get them individually
[01:21] <pkern> Which were actually quite helpful today.
[01:26] <soothsayer> If a program is invoked before I installed the debugging symbols package, will the debugging symbols not be available to me?
[01:27] <pkern> Oh thanks update-manager... "gutsy-wallpapers: Feisty Wallpapers"
[01:27] <pkern> Maybe that one should have been changed when the package was renamed. (=
[01:29] <pkern> But the wallpapers were already installed but are not listed in Appearance Preferences.
[01:29] <pkern> Hm, is it. nm
[01:50] <bigon> good noght
[01:50] <bigon> s/noght/night
[02:51] <bddebian> Heya gang
[02:52] <pkern> Hey.
[02:52] <bddebian> Hello pkern
[02:55] <bddebian> Anyone know what Lucas Nussbaum's irc nick is?
[02:56] <ajmitch> bddebian: lucas?
[02:56] <bddebian> Ah, OK, thx
[02:56] <bddebian> I don't recall seeing him here, does he come here?
[02:57] <bddebian> BTW Hi ajmitch :-)
[02:59] <ajmitch> yes he comes here
[02:59] <ajmitch> hello
[03:11] <pwnguin> is there a description of the meaning of various groups?
[03:11] <pwnguin> like what does plugdev allow?
[03:46] <bddebian> Hmm, I think slash should probably be removed
[04:13] <pwnguin> is there a description of the meaning of various unix groups?
[04:29] <bddebian> Holy crap there are a lot of unmet deps for ghc6
[04:31] <pwnguin> !info ghc6
[04:31] <ubotu> ghc6: GHC - the Glasgow Haskell Compilation system. In component universe, is optional. Version 6.6-3 (feisty), package size 23676 kB, installed size 111708 kB
[04:52] <Tm_T> happy now?
[04:52] <bddebian> Yep :-)
[05:02] <ScottK> jdong: How would you tell the difference (in LP's speed)?
[05:02] <jdong> ScottK: changelog view lag!
[05:02] <jdong> ;-)
[05:03] <ScottK> Don't get me started on the list of random entries from .changes files that may or may not relate to any particular release you happen to care about and almost certainly isn't complete.
[05:05] <ajmitch> bddebian: look what you've done
[05:08] <bddebian> Doh
[05:13] <ScottK> ajmitch: You should know by now it doesn't take bddebian to get me bitter.
[05:14] <ajmitch> yes, sadly
[05:14] <ScottK> OTOH, I was bitter in #launchpad on Friday and Saturday and some stuff is getting changed as a result, so I'm happy about that.
[05:15] <jdong> yay, bitterness fixes all :)
[05:15] <jdong> at least that used to work in medicine
[05:15] <bddebian> The squeaky wheel gets the grease :-)
[05:16] <bddebian> Hmm, so libapache-filter-perl will build and install but the binary package should probably be renamed and I have no idea if it actually works with apache2..
[05:16] <ScottK> bddebian: IIRC poker-network was having db-common-config trouble and they fixed it in the latest upload.  I don't remember how, but you may want to look at that.
[05:16] <ScottK> IRC reply to your email....
[05:17] <bddebian> ScottK: Heh, I'll check it out, thanks
[05:21] <StevenK> bddebian: I'll look at libapache-filter-perl
[05:21] <bddebian> StevenK: You rock :-)
[05:31] <ScottK> Hello Hobbsee.
[05:34] <Hobbsee> hi ScottK
[05:34] <RAOF> Hey Hobbsee!
[05:34] <Hobbsee> RAOF!
[05:35] <bddebian> Hi Hobbsee :-)
[05:35] <ajmitch> hey Hobbsee
[05:35] <RAOF> Hobbsee: There's been contextless pingage galore.  What's up :)
[05:35] <Hobbsee> hiya bddebian, ajmitch
[05:35] <ajmitch> good to see you're still with us
[05:36] <Hobbsee> RAOF: hehe :)  lastlog miro, and you'll see
[05:36] <RAOF> Hobbsee: I saw you suggesting miro-data as an example.  And my buffers don't go that far back :/
[05:37] <Hobbsee> RAOF: that was it.
[05:37] <Hobbsee> RAOF: thought if you were around to help, that would be good.
[05:37] <bddebian> OK, f**k libapache-mod-limitipconn
[05:37] <RAOF> Oh.  That's all?  Ah.
[05:38] <bddebian> Shouldn't that be vista4halo2? ;-P
[05:38] <Hobbsee> oh dear.  someone shoot him.
[05:38] <Hobbsee> RAOF: yup
[05:40] <StevenK> bddebian: Halo 3 is out.   I actually have enough sight to play games believe it or not.
[05:46] <TheMuso> lol
[05:46] <TheMuso> I am serious;
[05:46] <RAOF> So close!  There's a driver for my laptop's webcam that turns the little LED on, but fails when I try to do anything with it because it tries to allocate some 10GB of buffer memory.
[05:46] <StevenK> Hobbsee: Oh?
[05:46] <Hobbsee> StevenK: "hey, we're following a blind man here!"
[05:47] <StevenK> Yes, I just thought of that. :-)
[05:47] <TheMuso> You guys crack me up.
[05:53] <StevenK> bddebian: Keep talking, I have the FBI on the phone. :-P
[05:54] <TheMuso> StevenK: You are very jovial today.
[05:54] <StevenK> Okay.
[05:55] <StevenK> "Wood chopping for Actors"
[05:55] <bddebian> heh
[05:56] <bddebian> What the hell does Breaks: foo (<< 1.5) mean
[05:57] <StevenK> If it's installed, and foo has a version of << 1.5, foo will break
[05:57] <jdong> exactly what it says
[05:57] <RAOF> And thus, the packages manager should do something about this state of affairs.
[05:59] <StevenK> dpkg in gutsy is good. Breaks and triggers. Yummy
[05:59] <bddebian> So why the heck does it show up in unmet deps?
[05:59] <bddebian> Package python-gnome2-extras version 2.19.1-0ubuntu2 has an unmet dep:
[05:59] <bddebian>  Breaks: glom (< 1.5.1)
[06:00] <RAOF> Heh.
[06:04] <Hobbsee> bddebian: yes you do - to make it better.
[06:04] <bddebian> Yeah except most times I think I make it worse :-)
[06:07] <Hobbsee> then change :P
[06:07] <bddebian> I don't think there's a fix for stupidity ;-P
[06:09] <ajmitch> caution, planning & testing
[06:11] <pwnguin> http://boredandblogging.com/2007/09/25/aluminium-case-badges-coming/
[06:11] <pwnguin> those look pretty sweet
[06:14] <bddebian> ajmitch: That's my cure?
[06:14] <ajmitch> bddebian: I would say to just be quiet & go fix stuff instead
[06:15] <ajmitch> but that wouldn't be as much fun for you
[06:15] <bddebian> Heh
[06:22] <StevenK> Excellent, libapache-mod-filter can die
[06:24] <bddebian> Heh
[06:26] <StevenK> libapache2-mod-perl2 provides a Apache2::Filter, which from a cursory glance does the same sort of things
[06:26] <bddebian> makes sense
[06:27] <bddebian> I think it has an rdepends for libapache-asp-something
[06:28] <StevenK> It does?
[06:28] <StevenK> libapache-asp-perl
[06:28] <StevenK> Gah
[06:28] <bddebian> Which I'm sure is broken too :-)
[06:39] <bddebian> Ah well bed time for bonzo, gnight folks
[07:16] <soren> ScottK: Source backports?
[07:17] <ScottK> Yes
[07:17] <ScottK> If a backport can't be done without changing the package (due to dep issues or something) the changed package for backports needs to be uploaded by a core-dev.
[07:17] <ScottK> A MOTU can't even do it for a Universe package.
[07:18] <asisak> Hey ScottK, soren
[07:18] <asisak> I get "waiting for approval" mails for universe. This is because of some freeze now, right?
[07:18] <ScottK> soren: In fact, I'd like to get Bug #115269 done pretty soon, but it needs a review.
[07:18] <ubotu> Launchpad bug 115269 in ubuntu "[backport]  python-psycopg2 From Feisty to Dapper" [Undecided,Invalid]  https://launchpad.net/bugs/115269
[07:19] <ScottK> asisak: Yes.  They'll get pushed through when an archive admin notices as Universe is not frozen, but the archive is on manual.
[07:19] <asisak> Yes, this is what I was thinking of.
[07:19] <asisak> So it is not a policy, but a mechanism (that is how the archive works now)
[07:21] <sladen> well just *complaining* about it won't help :-
[07:21] <sladen> :-P
[07:21] <ScottK> asisak: Yes.
[07:21] <ScottK> You can't put one component of the archive on manual
[07:21] <Hobbsee> sladen: yes, rm -rf'ing
[07:21] <Hobbsee> does
[07:23] <soren> ScottK: I see. I didn't even know that :)
[07:24] <ScottK> soren: There's all kinds of trouble I can get you in now.
[07:24] <soren> ScottK: <g>
[07:27] <ScottK> Good night all.    Also, it's hard to find actual policy doucments about udev usage.
[09:23] <TheMuso> dholbach: Well thanks.
[09:23] <dholbach> RAOF: marking?
[09:23] <RAOF> Of first year algebra tests.
[09:24] <dholbach> RAOF: udev.... I guess you best ask Keybuk about that
[09:24] <pwnguin> heh
[09:24] <RAOF> Yup indeed :)
[09:24] <pwnguin> i told you
[09:24] <pwnguin> the udev policy is ask keybuk
[09:24] <RAOF> Oh, yeah.  I just thought the udev policy might be contained in more than one brain :)
[09:24] <dholbach> RAOF: you'll be the 2nd one then :)
[09:25] <RAOF> Also, it's hard to find *Debian's* udev policy.
[09:25] <pwnguin> if dh_installudev is broke, shouldnt there be a bug in debhelper about fixing or removing it?
[09:25] <RAOF> Yeah.  It seems all the debian bugs on installudev have been fixed, and there are no launchpad bugs.
[09:26] <pwnguin> but still
[09:26] <pwnguin> its a landmine
[09:26] <RAOF> We could just treat them as conffiles, and let dpkg magic do it's thing.
[09:29] <norsetto> morning folks and folkessines
[09:30] <RAOF> Evening norsetto
[09:30] <pwnguin> i need to actually read the udev documentation
[09:30] <RAOF> Welcome to #ubuntu-motu, your non-stop udev chat channel!
[09:31] <norsetto> raof: lol
[09:31] <pwnguin> because im pretty sure the rules upstream suggested are broke =/
[09:31] <RAOF> pwnguin: For your package, perhaps.  KVM is a nice simple case :)
[09:31] <pwnguin> i could bring up pam instead
[09:32] <pwnguin> well, i dont like the idea of yet another group
[09:32] <RAOF> Oh, you want thinkfinger to work, don't you?
[09:32] <pwnguin> it does
[09:32] <pwnguin> ive very nearly cleared most of the hurdles
[09:33] <pwnguin> gnome-screensaver being the lone holdout
[09:34] <pwnguin> but im not sure about the security implications of leaving it user readable
[10:12] <huats> Hey everyone
[10:14] <dholbach> hey huats
[10:14] <norsetto> huats: hey, just looking at your patch
[10:14] <huats> norsetto: ok thanks
[10:14] <norsetto> huats: what do you mean by menu 2.1.35?
[10:15] <norsetto> dholbach: morning Master
[10:15] <dholbach> norsetto: !
[10:15] <dholbach> how are you doing guys?
[10:15] <huats> norsetto: http://people.debian.org/~terpstra/message/20070705.083355.0374f2de.en.html it deals with the version of menu
[10:16] <norsetto> huats: ok, so that the menu version, its not the policy
[10:17] <huats> I am happy, I have been able to solve the leak problems in my bathroom :-)
[10:17] <huats> dholbach: what abot you
[10:17] <huats> ?
[10:17] <dholbach> huats: I'm great - thanks :)
[10:18] <dholbach> had a nice and early breakfast in the sun this morning
[10:18] <huats> norsetto: yes it is the menu version. but it is how I found it refered
[10:18] <huats> dholbach: really, it was sunny ? you are lucky :-(
[10:18] <norsetto> huats: yeah, bit lousy if you ask me
[10:18] <dholbach> yeah, the weather is just gorgeous in Berlin today
[10:19] <norsetto> dholbach: how's that called, indian summer?
[10:20] <dholbach> norsetto: yeah, something like that :)
[10:20] <pwnguin> how hard are the deadlines for gutsy?
[10:21] <dholbach> http://wiki.ubuntu.com/GutsyReleaseSchedule
[10:21] <huats> dholbach: same name in french
[10:21] <pwnguin> like if i wanted to request a sync from debian of a package not in ubuntu at all at this stage, is that just impossible?
[10:21] <dholbach> we can break freezes but you need to have very good reasons
[10:21] <dholbach> we're in new packages freeze too
[10:21] <norsetto> huats: was the icon in the tarball?
[10:22] <dholbach> people are busy with other things, but if you have a good reason, ask for an exception
[10:22] <dholbach> http://wiki.ubuntu.com/FreezeExceptionProcess
[10:22] <huats> norsetto: in the original tarball ?
[10:22] <pwnguin> ive already done one, so i wont bother anyone then
[10:22] <norsetto> huats: yes
[10:22] <huats> norsetto: no it was not
[10:23] <norsetto> huats: where is it coming then?
[10:23] <huats> norsetto: the package was relying on a gtk stock button... that is provoded by a big gnome package...
[10:24] <huats> norsetto: so after asking around finally riddell tolm me to include the icon in the package
[10:24] <dholbach_> pwnguin: what do you mean by 'I won't bother anyone then'?
[10:24] <huats> norsetto: in order to remove the dependency on that big package
[10:25] <norsetto> huats: ok, so there is no need to mention any copyright or author?
[10:25] <huats> I don't think so...
[10:25] <pwnguin> dholbach: you guys sound busy enough without me pestering about putting games into universe when they're already in my ppa
[10:26] <pwnguin> freeze exists for a reason, after all
[10:26] <dholbach> pwnguin: we'll automatically have it in hardy, but if you think it's worthwhile, you can always try
[10:27] <pwnguin> i think i'll focus on getting thinkfinger into hardy
[10:27] <pwnguin> in a working shape
[10:27] <norsetto> huats: just to be sure, I think it is better to mention something in the changelog
[10:28] <norsetto> huats: what was the package where you got that from?
[10:29] <huats> norsetto: gnome-icon-theme-gperfection2 or gnome-icon-theme (they both provide it)
[10:30] <norsetto> huats: I modified that line with: Add icon "stock_send-fax.xpm" from gnome-icon-theme in /debian
[10:31] <huats> ok
[10:32] <slytherin> Does anyone have enough time to test some theora packages? The packaging may not be very perfect, so I am looking for some feedback.
[10:35] <norsetto> huats: I'm building right now and if everythin is ok I will upload it. I only reworded the changelog and the dpatch description. Thanks for your work!
[10:36] <huats> ok
[10:36] <huats> norsetto: looking to see the reword in orderto improve
[10:36] <huats> :-)
[10:37] <norsetto> huats: don't worry, its just me being anal retentive. btw, you will send this to debian, yes?
[10:38] <huats> norsetto: of course
[10:38] <huats> norsetto: but I will have a word with you about that
[10:39] <norsetto> huats: there we go, I'm not a virgin anymore, my first upload (hope I didn't screw anything .....)
[10:40] <huats> norsetto: hey hey
[10:41] <dholbach> hehe... thanks huats
[10:42] <norsetto> huats: champagne! gazeuse for the abstemious!
[10:43] <huats> norsetto: I'll take one....
[10:44] <dholbach> :-)
[10:48] <huats> Hobbsee: if you have any problem/question with bug #121984, juste ask :-) I am the one who created the debdiff...
[10:48] <ubotu> Launchpad bug 121984 in kdepim "kandy: no icon in kubuntu feisty's kde menu" [Wishlist,In progress]  https://launchpad.net/bugs/121984
[10:51] <Hobbsee> huats: OK.
[10:52] <huats> Hobbsee: and hello by the way :-)
[10:52] <Hobbsee> hiya
[10:54] <Hobbsee> coke's good.
[10:55] <norsetto> huats: what was it you wanted to talk about?
[10:55] <huats> norsetto: oh, that was about the procedure to send something to debian...
[10:55] <huats> norsetto: I have to admit that I found it a bit blurry
[10:59] <norsetto> huats: just send and email to the BTS (which is what I do) or use reportbug
[10:59] <norsetto> huats: here a link that should help: http://www.debian.org/Bugs/Reporting
[10:59] <huats> I definitly have to give a deeper look at that link...
[11:02] <huats> norsetto: but it is a way to report the bug, not to mention the fix...
[11:03] <norsetto> huats: so the problem is the content, not the procedure?
[11:03] <huats> let's say both :-)
[11:04] <huats> if you keep in archive a mail you have already send to BTS can you forward it to me ?
[11:04] <norsetto> huats: I don't think I keep copies of those, let me check
[11:04] <huats> ok
[11:06] <norsetto> huats: no, no local copies, but in this case is pretty simple, just forward them your dpatch patch, the icon and the menu files. Its really up to them how they use them
[11:07] <huats> norsetto: not the changelog ? or the debdiff ?
[11:07] <norsetto> huats: you can mention it to the maintainer, and it would be easier for us if they would use what we used, but more than asking we cannot do
[11:08] <norsetto> huats: what will they do with it?
[11:08] <huats> norsetto: don't know :-)
[11:08] <norsetto> huats: of course you can add a link to the Ubuntu bug report
[11:09] <huats> norsetto: ok
[11:09] <huats> norsetto: I'll do that during lunch break (at least I'll try)
[11:10] <norsetto> huats: please do, its important we keep in sync
[11:10] <huats> of course
[11:21] <norsetto> dholbach: if you are in a cleaning frenzy, you can as well upload the fix to bug 141015; lutin agreed to it
[11:21] <ubotu> Launchpad bug 141015 in ubuntu-dev-tools "Correctly pass path to dch" [Undecided,Incomplete]  https://launchpad.net/bugs/141015
[11:22] <dholbach> lutin could upload it himself then, no? :)
[11:23] <norsetto> dholbach: well, just wanted to profit from your cleaning momentum ;-)
[11:23] <dholbach> hehehe :)
[12:07] <StevenK> WoW 2.2.0 does not want to complete loading under Wine.
[12:08] <pwnguin> sounds like a productivity boost!
[12:09] <StevenK> pwnguin: Shush.
[12:10] <ajmitch> StevenK: wfm
[12:10] <ajmitch> however you're trying to load it at the prime lag time of the day
[12:10] <pwnguin> besides, if you tell the world it even worked in ubuntu, my roommate would bug me to make it work and play with him
[12:10] <ajmitch> and we just had the server go boom for outland on khaz, no npcs, portals back to azeroth, etc
[12:11] <ajmitch> all in all, a quality patch
[12:11] <StevenK> ajmitch: Yeah, but I've never had it just hang at the loading bar and not jump in before
[12:11] <ajmitch> I have
[12:12] <StevenK> And how did you fix it? :-)
[12:12] <ajmitch> gave up & came back a bit later :)
[12:13] <ajmitch> only 100k to go to level 62 :)
[12:14] <ajmitch> pwnguin: oh it generally works very well in ubuntu :)
[12:14] <ajmitch> it's usually blizzard that falls down
[12:15] <StevenK> Mmmmm. I might blame it on Dath'Remar being broken
[12:15] <ajmitch> I would
[12:18] <dholbach> no wonder there are so many open bugs in Ubuntu - WoW works far too well in Ubuntu :)
[12:18] <StevenK> Which does the same thing.  :P
[12:20] <dholbach> jussi01: I seriously haven't
[12:20] <ajmitch> dholbach: stay away from it
[12:20] <dholbach> don't worry about me
[12:21] <StevenK> ajmitch: Then what's the point? :-)
[12:21] <jussi01> lol
[12:21] <ajmitch> StevenK: all these people in shattrath, stuck there because they couldn't get back :)
[12:22] <jussi01> dholbach: its more addictive than heroin
[12:23] <StevenK> ajmitch: Heh
[12:24] <ajmitch> ouch
[12:47] <TheMuso> Ok. About to test my code for ubuntustudio-menu and xdg symlinking stuff.
[12:47] <TheMuso> woops wrong window.
[12:47] <TheMuso> wrong channel even
[12:50] <MenZa> Hi, I was wondering if anyone might be interested in packaging gelemental (GTK periodic table, far better than gperiodic which is currently in the repos) and sticking it in the repositories?
[12:51] <MenZa> (one for the science team here)
[12:54] <norsetto> Menza: why not rasing a [need-packaging]  bug in Launchpad?
[12:54] <MenZa> norsetto: I suppose that's not a bad idea; I'll do so immediately
[12:54] <MenZa> (I wasn't sure how you'd go about requesting packages)
[12:57] <MenZa> norsetto: Under the MOTU team?
[12:57] <norsetto> menza: what do you mean!?
[12:57] <MenZa> Er, nevermind that
[12:58] <norsetto> menza: this is a good example: bug 138761
[12:58] <ubotu> Launchpad bug 138761 in ubuntu "[needs-packaging]  iTest" [Wishlist,Fix committed]  https://launchpad.net/bugs/138761
[01:01] <MenZa> norsetto: I've reported it.
[01:02] <MenZa> Thanks. :)
[01:02] <norsetto> menza: thx to u
[01:02] <MenZa> :)
[01:04] <proppy> hiya
[01:05] <norsetto> menza: next time pls. do not assign it to motu
[01:05] <norsetto> proppy: Ola
[01:05] <MenZa> norsetto: shall do
[01:20] <Lutin> dholbach: I don't really feel like uploading ubuntu-dev-tools for a onliner patch ;)
[01:22] <pkern> dholbach: I hope I had a point in my mail and that it's not too confusing. o_O
[01:47] <huats> norsetto: I have a problem... I have unwillingly removed my efax-gtk working dir.... So I cannot find my patch, the icon, and the menu  anymore.. .Do you still have thata round ?
[01:47] <norsetto> huats: just take it from the package, I think it has been published already
[01:48] <huats> norsetto: ok, I have to recheck
[01:56] <huats> norsetto: ok I have been able to get it thanks
[01:56] <norsetto> huats: np
[02:10] <ScottK> Lutin: I've been looking at the pbuiler-dist script.  I can possibly have a patch to make it work with Debian later today if that'd make ubuntu-dev-tools worth uploading?
[02:13] <Lutin> ScottK: right
[02:14] <ScottK> I'll see what I can do.
[02:14] <Lutin> no need to hurry though
[02:26] <dholbach> Lutin: at least we can commit the patch to the branch, so it'll be contained in the next upload
[02:26] <dholbach> pkern: I'll have a look in a bit
[02:27] <Lutin> dholbach: yep. will do :)
[02:27] <dholbach> rock on
[02:28] <Kopfgeldjaeger> hi
[02:41] <pkern> Uh, thanks dholbach (:
[02:41] <dholbach> pkern: you deserved it :)
[02:42] <pkern> soren: ping
[02:42] <soren> pkern: pong
[02:43] <soren> pkern: I didn't get around to looking at your patch yet, sorry. My TODO list refused to shrink yesterday. :)
[02:43] <pkern> soren: Ok. (:
[02:56] <dfiloni> ciao a tutti
[02:56] <dfiloni> sorry
[02:56] <dfiloni> hi to all
[02:58] <ScottK> dholbach: Got a second to discuss packaging guide (rather than continue to fail to communicate via e-mail)?
[02:58] <dholbach> ScottK: sure
[02:59] <ScottK> The thing I'm trying to figure out is if you think the Ubuntu packaging guide (or whatever we call it) should be a complete guide to how to package or more of a here's the stuff that's different from Debian guide?
[03:02] <dholbach> ScottK: I think we should go through step 1 first: aggregate everything we have and then decide from there on; I'd like it to be a well-rounded guide to get people started, that refers to debian policy, etc for things that we just can't afford to duplicate
[03:02] <dholbach> ScottK: does that make sense?
[03:03] <ScottK> I'm trying to understand where we are headed.  As step 1, that makes sense.
[03:04] <ScottK> I think we should aim to duplicate as little as possible.
[03:04] <ScottK> Which is at odds with your well rounded guide idea.
[03:04] <dholbach> I think it should still be readable
[03:05] <dholbach> and helpful to read it on its own (even if you might not get all the facts 100%)
[03:05] <dholbach> but yeah, given that we're not 200 people who like writing docs, we should duplicate as little as possible
[03:06] <ScottK> I agree there's a balance here.
[03:06] <dholbach> it might not be easy to get the balance right between both goals, but I think that both are quite important
[03:07] <ScottK> I'd suggest we should start with something like "Look at the Debian New Maintainers Guide, but skip sections X, Y, and Z as they don't apply to Ubuntu."
[03:07] <ScottK> Then here's the extra Ubuntu stuff you need to know....
[03:07] <ScottK> As an end goal.
[03:09] <dholbach> I don't think that there's a lot of delta between "debian packaging" and "ubuntu packaging", what I feel we have a need for is having a guide that helps people get started quickly, by playing with the tools, etc
[03:09] <dholbach> ScottK: what do you think about that?
[03:09] <ScottK> I'd suggest something like that that gets people started with merging/fixing with New Maintainers Guide as the starting point for doing new packages.
[03:10] <ScottK> One mistake I think we make is to try and have new packages be the first thing people do.
[03:10] <pkern> Having it in the Wiki creates licence problems with the Debian guide. \:
[03:10] <ScottK> pkern: We don't need to copy it, just link to it.
[03:10] <pkern> i.e. one couldn't copy parts of the Debian guide.
[03:10] <ScottK> One shouldn't
[03:10] <pkern> ScottK: Yeah, ok, if that's clear.
[03:11] <ScottK> Then we'd have to figure out how to stay in sync with updates which is the entire thing to avoid.
[03:11] <pkern> Hm, yep.
[03:12] <pkern> OTOH spreading information over various links disturbes too. Normally you want a continuous document, I guess.
[03:12] <dholbach> ScottK: what problem do you think the UPGIAIW (ubuntu packaging guide in an ideal world) should solve specifically? :)
[03:13] <ScottK> I think it should solve two problems:
[03:13] <dholbach> apart from informing about differences between ubuntu and debian packaging?
[03:13] <ScottK> 1.  Hi, I'm new where do I start to help out.
[03:13] <ScottK> 2.  I want to make a new package for Ubuntu, what do I need to know.
[03:13] <dholbach> ok, that sounds great to me
[03:13] <ScottK> 1. should be pretty self contained.
[03:14] <ScottK> 2.  Should be the read the DNMG - irrelevant bits + here's some Ubuntu stuff.
[03:14] <ScottK> 1 should be about patching, debdiffing, merging, etc.
[03:15] <ion_> Are there any REVU reviewers interested of reviewing my hardware-connected and apt-mark-sync packages online? Ive posted the URLs every once in a while, but theyve gone pretty much unnoticed.
[03:15] <dholbach> ion_: you could ask mvo for the apt-mark-sync package
[03:16] <dholbach> ScottK: I can agree with your ideas about it
[03:16] <ion_> dholbach: Thanks, but why mvo?
[03:16] <dholbach> ScottK: we should try to write a UPGIAIWPhase2 spec about it
[03:16] <ScottK> OK.
[03:17] <dholbach> ion_: he's quite apt with apt
[03:17] <ScottK> ion_: Everyone is pretty much focused on getty Gutsy fixed and out the door right now.  This is not the best time to be asking for new package reviews.
[03:17] <ion_> scottk: I see.
[03:17] <dholbach> ScottK: to sum up the goals and re-review it once we have the merged PackagingGuide in our hands
[03:21] <ScottK> dholbach: Sounds good.  I am still considering coming up for part of UDS, so maybe there we can have a draft.
[03:21] <dholbach> woah nice
[03:29] <_MMA_> ScottK: Md->Boston. 8hr drive or so. Not too bad. :) Or will you fly?
[03:30] <ScottK> _MMA_: Dunno.  It depends on how long I will stay and how much it costs.
[03:40] <pkern> Does anyone know where UDS+1 will be located?
[03:42] <ScottK> Any suggestions for a US mirror that isn't in the Canonical data center?
[03:43] <zul> us.archive.ubuntu.com or something liek that?
[03:43] <soren> se.archive.ubuntu.com
[03:44] <ion_> Yeah, since Sweden is a US state.
[03:44] <soren> No matter where you're connecting from in the world, the Swedish mirror might very easily be faster.
[03:44] <soren> ion_: Suuuure..
[03:44] <ScottK> zul: us.archive.ubuntu.com is timing out for me right now.
[03:45] <ScottK> Nevermind.  Worked that time.
[03:45] <soren> ScottK: Dude. s/us/se/ ftw.
[03:45] <ScottK> Yeah.  Got that.
[03:45] <zul> ca.archive.ubuntu.com also
[03:45] <soren> They've got a pipe the size of... umm.. a really big pipe!
[03:54] <propp1> hi
[03:55] <proppy> I'm having trouble with a cdbs patch I wrote which add autotools support
[03:55] <proppy> the debian/patches remove the upstream Makefile and add configure.ac + Makefile.am
[03:55] <proppy> autoconf/make generate a new Makefile file
[03:56] <proppy> and thus the patch failed to reverse apply
[03:56] <proppy> when calling debuild clean
[03:56] <proppy> any ideas ?
[03:57] <proppy> Maybe I should delete the autoconf generated Makefile in a target somehow
[03:57] <proppy> +clean
[03:57] <imbrandon> erm thunderbird is gonna be a spinoff company ?
[04:08] <proppy> is reverse-config the first target called by debhelper when running debuild clean ?
[04:08] <proppy> is there any target I can use to execute a command just before it ?
[04:08] <StevenK> proppy: It depends on the debian/rules file.
[04:08] <StevenK> proppy: The clean target is the first one run when you run debuild clean
[04:09] <proppy> StevenK: http://unittestcpp.aminche.com/unittest++/debian/rules
[04:10] <proppy> StevenK: when I override the clean target it says that I already got a clean:: ruesl
[04:10] <proppy> are :: rules kind of override ?
[04:11] <proppy> digging into dhelper.mk
[04:12] <StevenK> Ahh. CDBS
[04:13] <StevenK> proppy: There is probably a pre-clean-hook target or so.
[04:13] <soren> StevenK: Nono, it's "Yay! CDBS!".
[04:13] <proppy> StevenK: clean:: testdir testroot cleanbuilddir reverse-config
[04:13] <proppy> found that in buildcore.ml
[04:14] <StevenK> soren: :-P
[04:14] <proppy> is reverse-config called in last or in first ?
[04:15] <soren> proppy: Assume they're all done simultaneously. That way, you can't get it wrong.
[04:17] <proppy> I should figure how to call make distclean or maintainer-clean
[04:17] <proppy> *before* the patch is reverse applied
[04:21] <proppy> soren: I have to figure how to change the order
[04:22] <proppy> soren: cause If I call reverse-config *before* make distclean it fails
[04:22] <proppy> soren: and if call make distclean after having the makefile removed it also failed
[04:23] <soren> proppy: So reverse-config needs distclean to be called first?
[04:23] <proppy> soren: yes i presume the package is build like this
[04:23] <soren> proppy: Then state that in your makefile.
[04:23] <proppy> patch
[04:23] <proppy> autoreconf
[04:23] <soren> reverse-config:: distclean
[04:23] <proppy> ./configure
[04:23] <soren> There.
[04:24] <proppy> I guess is has to be cleaned it the reverse order
[04:24] <proppy> distclean then revert the patch
[04:24] <soren> Yes.
[04:24] <soren> A makefile consists of two major things:
[04:24] <soren> A list of dependencies
[04:25] <soren> a list of ways to generate foo using bar.
[04:25] <soren> What you have right there is a dependency.
[04:25] <soren> reverse-config needs distclean to be done.
[04:25] <soren> Hence..
[04:25] <soren> reverse-config:: distclean
[04:26] <soren> If you want to be able to make presumptions about the order in which anything at all in a makefile happens, you need to specify it in terms of dependencies.
[04:26] <proppy> I see
[04:26] <proppy> like cascaded dependencies?
[04:26] <soren> You could call it that, yes.
[04:27] <soren> A makefile is essentially logical programming.
[04:27] <proppy> I must then figure out which debian rules call distclean
[04:27] <proppy> soren: but I guess there will be some conflict
[04:27] <soren> You tell the interpreter how certain things relate to each other in terms of dependencies and transformation rules.
[04:27] <soren> the interpreter then uses that information to generate whatever you ask it to.
[04:28] <proppy> soren: cause currently without the additionnal reverse-config rules, the clean rules called reverse-config -> then -> distclean
[04:28] <soren> Where's this rules file?
[04:28] <soren> I'd like to see it.
[04:28] <proppy> so if you tell reverse-config :: clean
[04:28] <soren> It makes it easier to explain stuff.
[04:29] <proppy> it will make kindof circular dependency
[04:29] <proppy> sure
[04:29] <proppy> http://unittestcpp.aminche.com/UnitTest++/debian/rules
[04:29] <soren> Ok.
[04:30] <soren> You have two options:
[04:30] <soren> a) Don't use cdbs's autotools magic. That's where the "clean:: distclean" rule is defined, probably.
[04:30] <proppy> thanks for taking a look
[04:31] <soren> b) (a.k.a. the solution you want) add a rule:
[04:31] <soren> cleanbuilddir/packagename:: reverse-config
[04:31] <soren> That ought to do it.
[04:32] <soren> Somewhere in cdbs, there is a:
[04:32] <soren> "clean:: cleanbuilddir" sort of dependency, I believe.
[04:32] <proppy> yep
[04:32] <proppy> (04:13:41 PM) proppy: StevenK: clean:: testdir testroot cleanbuilddir reverse-config
[04:32] <proppy> in buildcore.ml
[04:32] <proppy> mk
[04:33] <soren> Uh... I thought reverse-config was your rule.
[04:34] <proppy> nop it's a debhelper rules I guess
[04:34] <proppy> I just noticed that is the rules which try to revert-apply my autotools patch
[04:34] <proppy> during debuild clean
[04:34] <soren> Ok... I've clearly missed something here.
[04:35] <soren> e.g. the bit where you explain what you're actually trying to do, and what the problem is :)
[04:35] <proppy> ok
[04:35] <proppy> I've got a package with no autotools support
[04:36] <proppy> I add autotools need files with cdbs-simplepatchsys and this patch
[04:36] <soren> Why are you using /usr/share/cdbs/1/class/autotools.mk then?
[04:36] <trunx> hallihallo
[04:36] <proppy> http://unittestcpp.aminche.com/UnitTest++/debian/patches/01-autotools.patch
[04:36] <soren> proppy: What does upstream use to build it?
[04:36] <soren> proppy: A simple makefile?
[04:36] <proppy> a simple Makefile
[04:36] <soren> so... why don't you?
[04:36] <proppy> which my patch do remove
[04:37] <soren> https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528304
[04:37] <proppy> I was interested into providing autotools support
[04:37] <proppy> but the upstream kinda ignored it
[04:37] <soren> Ok...
[04:37] <soren> Ok, let's go with that.
[04:37] <soren> Go on.
[04:38] <proppy> You mean drop the autotools support
[04:38] <proppy> ?
[04:38] <proppy> and go for the native upstream provided solution ?
[04:38] <soren> I wouldn't bother, but if you do, that's fine.
[04:39] <soren> As in: "I wouldn't bother adding autotools support."
[04:39] <soren> ...but I don't know the package. It might make sense.
[04:39] <proppy> I see
[04:40] <proppy> I just though thing will be easier to package if I got autotools
[04:40] <soren> Not necessarily, no.
[04:40] <proppy> yep seems so
[04:40] <soren> If the makefile system is sane, it's pretty easy to use that.
[04:41] <proppy> by Go on you mean go on explain my problem ?
[04:41] <proppy> or Go on and drop autotools ?
[04:41] <proppy> :)
[04:41] <soren> and then there's no point in adding the autotools maintenance overhead.
[04:41] <soren> go on explaining your problem :)
[04:41] <proppy> so once applied 01-autotools.patch
[04:42] <proppy> remove the upstream Makefile
[04:42] <proppy> and create configure.ac Makefile.am and other needed files
[04:42] <soren> http://unittestcpp.aminche.com/UnitTest++/debian/patches/01-autotools.patch 404's
[04:43] <proppy> back
[04:43] <proppy> the the configure rules call autoreconf --install
[04:43] <proppy> which generate ./configure file
[04:43] <jussi01> Hmmm, here is the tail of a build error im getting, anyone got an idea on how to fix it? : http://paste.ubuntu-nl.org/38643/
[04:43] <proppy> and ./configure
[04:43] <proppy> which generate the Makefile
[04:43] <proppy> the package is built
[04:44] <proppy> and when calling clean rules
[04:44] <proppy> it try to reverse apply the patch
[04:44] <proppy> and then call distclean
[04:44] <proppy> which clearly failed
[04:44] <proppy> cause it can't revert apply a patch which is removing a Makefile
[04:45] <soren> proppy: Ah... Eeek.
[04:45] <StevenK> jussi01: It looks like hydrogen is using the older FLAC API
[04:45] <proppy> when another Makefile was generated
[04:45] <proppy> so my guess it the operation has to be called in the reverse order
[04:45] <proppy> they were call before building
[04:45] <proppy> distclean
[04:45] <proppy> then reverse-apply-patch
[04:45] <proppy> does it make sense ?
[04:45] <soren> proppy: Ok, now I see the problem.
[04:46] <jussi01> StevenK: ok. how do I go about fixing it?
[04:46] <proppy> soren: thanks for listenning
[04:47] <soren> proppy: I'm on my way out the door right now, actually. I'll think about your problem until tomorrow.
[04:47] <StevenK> jussi01: Fix the code to not use old include files and old API calls.
[04:47] <soren> Do you have a source package for it I can play with?
[04:47] <proppy> soren: oh thanks
[04:47] <proppy> soren: and sorry for making you late :)
[04:47] <jussi01> :(
[04:47] <proppy> soren: yep sure
[04:48] <proppy> soren: let me generate it
[04:48] <proppy> and then follow instruction on http://unittestcpp.aminche.com/
[04:48] <soren> proppy: Cool. /msg me the link
[04:48] <proppy> then is a web page with the deb line
[04:48] <proppy> just add -src to it
[04:49] <proppy> soren: If you got a public ssh key
[04:49] <proppy> soren: I'll give you root access to the vserver
[04:49] <soren> proppy: Don't do that. I'm evil.
[04:49] <proppy> soren: thanks
[04:52] <bddebian> Heya gang
[05:02] <norsetto> bddebian: hey bd
[05:03] <bddebian> Heya norsetto
[05:03] <mody> hi all, I have problem mounting my USB flash memory of 1 G, can somebody help
[05:04] <norsetto> would anyone know of a good example of a source package with the following binary packages: runtime, shared library and docs?
[05:05] <bddebian> mody: Did you ask in #ubuntu?
[05:06] <mody> bddebian, how to join this channel - should I type /joint @ubuntu - or what
[05:06] <bddebian>  /join #ubuntu, yep :-)
[05:07] <mody> bddebian, thanks - I will try there
[05:08] <proppy> soren: dget http://unittestcpp.aminche.com/unittest++_1.3.0-1.dsc
[05:20] <Kopfgeldjaeger> could someone review (tell me what i could do better) my avidemux package? http://xeve.de/down/demux/
[05:21] <Kopfgeldjaeger> the today svn version does not compile (so it's not absolutely up2date, but from yesterday)
[05:41] <leleobhz> im modifying a package
[05:41] <leleobhz> an i need to fixup the menu entry
[05:41] <leleobhz> change debian/app.desktop and debian/menu.in dont work
[05:41] <leleobhz> how can i fix a menu entry of a package?
[05:42] <ogra> define "fixup" :)
[05:42] <bddebian> You need to modify or add the .desktop file.  We don't use the menu files
[05:42] <ogra> what do you want to achieve, what exactly doesnt work
[05:43] <leleobhz> the package actually create a menu entry
[05:44] <leleobhz> the menu entry call /usr/bin/app
[05:44] <leleobhz> i want it call /usr/bin/aoss /usr/bin/app
[05:44] <leleobhz> let-me paste
[05:45] <leleobhz> http://pastebin.ca/716132
[05:45] <ogra> well, changing the Exec statement in the .desktop file should suffice
[05:45] <leleobhz> but every time i modify the .desktop
[05:45] <ogra> unless it uses a different .desktop file (one that upstream ships) instead of the one in the debian dir
[05:45] <leleobhz> it comes back to original after dpkg-buildpackage
[05:46] <leleobhz> leleobhz@zorg:~/TRABALHO/DEVELOPMENT/COMPILACOES/UBUNTU/pacotes/praat-feisty/praat-4.6.21/debian$ dpkg -L praat | grep desktop
[05:46] <leleobhz> /usr/share/applications/praat.desktop
[05:47] <ogra> is there a debian/praat.desktop.in file ?
[05:47] <leleobhz> leleobhz@zorg:~/TRABALHO/DEVELOPMENT/COMPILACOES/UBUNTU/pacotes/praat-feisty/praat-4.6.21/debian$ ls
[05:47] <leleobhz> changelog  control    dirs.in     manpage.xsl  NEWS     patches    praat.desktop   praat.xpm  watch
[05:47] <leleobhz> compat     copyright  install.in  menu.in      patched  praat.dbk  praat.manpages  rules      What_s_new_.html
[05:48] <ogra> how exactly do you proceed to change it ?
[05:48] <leleobhz> edited praat.desktop directly
[05:48] <ogra> you make your change, build a new source package and buid that ?
[05:48] <ogra> *build
[05:48] <leleobhz> make the change and build with pdebuild
[05:50] <ogra> well, i'd check for another .desktop file in the upstream source
[05:50] <leleobhz> ogra: i only use pdebuilder (dpkg-buildpackage)
[05:51] <leleobhz> leleobhz@zorg:~/TRABALHO/DEVELOPMENT/COMPILACOES/UBUNTU/pacotes/praat-feisty/praat-4.6.21$ find ./ -iname "*.desktop"
[05:51] <leleobhz> ./debian/praat.desktop
[05:51] <leleobhz> ogra: have no other .desktop
[05:51] <ogra> hmm
[05:52] <leleobhz> the makefile original dont create anything about menus
[05:52] <leleobhz> the strange thing is
[05:53] <leleobhz> build/praat:: praat.1
[05:53] <leleobhz>         for i in dirs install menu ; do                                 \
[05:53] <leleobhz>                 $(SUBSTCMD) < $(DEBDIR)/$$i.in > $(DEBDIR)/praat.$$i ;  \
[05:53] <leleobhz>         done
[05:53] <leleobhz> it makes something with the menu.in
[05:54] <bddebian> Are you looking at debian/rules?  More than likely it just installs the .desktop file that exists in debian/
[05:54] <leleobhz> well
[05:55] <leleobhz> this last line are from debian/rules
[05:55] <leleobhz> i think is easy to copy a file to app dir
[05:56] <leleobhz> but i dont understand why the content of praat.desktop are regenerated every time
[05:56] <leleobhz> i compile
[05:56] <bddebian> is this the current ubuntu source package you are using to build with?
[05:57] <leleobhz> more or less
[05:57] <leleobhz> bddebian: ive updated it a loooooooot
[05:58] <leleobhz> today its in version 4.6.24 and the repos version is 4.5.anything
[05:58] <leleobhz> almost 1 year old
[05:58] <bddebian> Gutsy has 4.6.12
[05:58] <leleobhz> its a unnoficial update
[05:58] <leleobhz> bddebian: too old yet
[05:58] <leleobhz> a new version is launched every 15 days or a little more
[05:59] <leleobhz> 4.6.12 is from july 27
[05:59] <bddebian> In the Gutsy source package the .desktop file is static and doesn't get touched.  Whatever is in debian/praat.desktop is what gets installed in /usr/share/applications/praat.desktop
[05:59] <leleobhz> the .24 is from sept 24
[06:00] <leleobhz> strange
[06:00] <bddebian> If you are using an upstream tarball that has a debian/ dir in the original tarball, you are on your own :-)
[06:00] <Kopfgeldjaeger> somebody here with too much time? ;) I'd like to have my avidemux package reviewed (tell me what i could do better)... *.diff.gz, *.orig.tar.gz and *.dsc at http://xeve.de/down/demux/
[06:01] <leleobhz> bddebian: havent
[06:02] <pkern> Kopfgeldjaeger: You should upload it to REVU and ping again (and probably explain what changes you introduced if you want it to be in Gutsy). (Didn't take a look at it, though.)
[06:02] <bddebian> leleobhz: So how did you update from .12 to .24 then?
[06:03] <leleobhz> bddebian: i say, the original tarball of app dont have the debian folder
[06:03] <leleobhz> i aways do uupdate frol a old version
[06:03] <leleobhz> i have some mine patchs, and these files dont change a lot...
[06:03] <Kopfgeldjaeger> pkern: i think its too late for gutsy, but i'd like to see it in gutsy. @REVU: i thought this was only for new packages (i created the package myself, but an older version of avidemux is already in the repositories.)
[06:04] <pkern> Kopfgeldjaeger: It's not only for new packages.
[06:04] <Kopfgeldjaeger> ok :)
[06:25] <ScottK> Kopfgeldjaeger: Did you check to see if Debian had a newer version than Ubuntu?  If so, you'd be well advised to base your work on that.
[06:26] <Kopfgeldjaeger> ScottK: debian does not have avidemux in the repositories, as far as i could see
[06:26] <ScottK> OK.
[06:26] <ScottK> You might work on getting it in there then.
[06:28] <Kopfgeldjaeger> yes, this would be even cooler than only in ubuntu ;) but firstly, it should be reviewed per REVU. i read the packaging tips/other sites on packaging
[06:30] <K0brik> are you publishing software which is not secure?
[06:31] <ScottK> Why do you ask?
[06:31] <K0brik> you're a bunch of crack-hoes if yes
[06:32] <ScottK> If we were, would we admit it?
[06:32] <K0brik> because I'm the big exterminator
[06:33] <ogra1> K0brik, so you want to join the security team ?
[06:34] <K0brik> aren't you enough already?
[06:35] <K0brik> I mean on the team of distributers
[06:35] <K0brik> ors lol
[06:36] <ogra1> K0brik, indeed not
[06:36] <K0brik> wouldn't it be stupid to distribute software which is not considered secure?
[06:36] <ogra1> K0brik, there can never be enough people squashing security bugs
[06:36] <ogra1> ask microsoft ?
[06:37] <K0brik> I doesnt trust microsoft half as much as you
[06:38] <K0brik> ogra1: I know. But arent the various projects giving green light when enough Ubuntu trusted developers has given the review OK stamp?
[06:38] <ogra1> well, all software has bugs all the time ...  we surely wont release with known security holes, but you cant predict the undiscovered ones
[06:38] <K0brik> yes you can
[06:38] <ogra1> thats where help from the community is required to tet and find them
[06:38] <ogra1> *test
[06:39] <K0brik> you can predict it by looking at reviews from trusted developers
[06:40] <ogra1> how would you predict it by that ? if they didnt find a security hole, how would i predict it `?
[06:40] <ogra1> i'm talking about *undiscovered* security flaws
[06:40] <K0brik> predict doesn't have to mean 100% sure but 99%
[06:40] <Kopfgeldjaeger> avidemux does not have copyright statements in the source files... should i write a patch to add them, or...?
[06:41] <ogra1> ask upstream to add them
[06:42] <K0brik> one Ubuntu trusted developer / reviewer could cover anothers faulty OK stamp
[06:44] <K0brik> or maybe it's just standart to publish insecure stuff
[06:44] <K0brik> ard
[06:44] <ogra1> what makes you think that ?
[06:45] <K0brik> your statements about prediction
[06:46] <Kopfgeldjaeger> could a REVU admin "re-sync the REVU uploaders keyring"? i just joined the U.U.C. group
[06:47] <K0brik> not that I care much but bugs are so annoying to have in your face
[06:48] <K0brik> especially fatal security bugs / cracks
[06:48] <bluekuja> Kopfgeldjaeger: re-syncing it
[06:49] <Kopfgeldjaeger> bluekuja: thank you
[06:49] <K0brik> but I respect you for the great work I must admit!
[06:49] <pkern> siretart: The REVU keyring sync is still once a day, right?
[06:49] <bluekuja> Kopfgeldjaeger: np :)
[06:49] <bluekuja> pkern: yup
[06:49] <pkern> bluekuja: ;)
[06:49] <siretart> should be, yes
[06:49] <siretart> bluekuja can check, though
[06:50] <bluekuja> yup, gonna check it after the sync
[06:51] <pkern> bluekuja: Also the point in time would be interesting and could be added to the documentation.
[06:52] <bluekuja> pkern: yeah, you're right. A lot of ppl ask for it
[06:52] <bluekuja> so why dont adding it to the wiki? :)
[06:52] <pkern> bluekuja: Exactly. I mean `wait until tomorrow' doesn't work with different timezones. ;)
[06:53] <bluekuja> eheh yeah :)
[06:53] <bluekuja> pkern: gonna ping you in a while with result
[06:58] <pkern> Is there a Debian-Ubuntu collaboration officer? ;)
[07:01] <bluekuja> Kopfgeldjaeger: done
[07:07] <bluekuja> siretart: where daily hour sync is stored?
[07:08] <bluekuja> e.g which file
[07:08] <pkern> In a cron tab probably.
[07:08] <bluekuja> yeah
[07:08] <bluekuja> was checking around
[07:08] <pkern> Look in /var/spool/cron or /etc/crontab
[07:08] <pkern> Or /etc/cron.daily
[07:08] <joejaxx> Good Afternoon All
[07:08] <pkern> Or /etc/cron.d fwiw
[07:11] <bluekuja> pkern: cant see it inside cron.daily
[07:11] <bluekuja> and /var/spool/cron is permission denied
[07:11] <pkern> Yeah looking at other user's crontab needs root.
[07:11] <bluekuja> yup
[07:12] <pkern> And it isn't in /etc/cron.d nor in /etc/crontab?
[07:12] <pkern> (I hadn't it expected in cron.daily anyway.)
[07:13] <bluekuja> pkern:
[07:13] <bluekuja> .placeholder
[07:13] <bluekuja> cron-apt
[07:13] <bluekuja> postgresql-common
[07:13] <pkern> Oh please.
[07:14] <bluekuja> on cron.d
[07:14] <bluekuja> cant find it
[07:14] <pkern> k
[07:14] <bluekuja> we need siretart :)
[07:15] <bluekuja> pkern: please ?
[07:15] <pkern> No paste here, I expected more to come. ;)
[07:15] <bluekuja> oh^^
[07:15] <bluekuja> you wanted all of them?
[07:15] <bluekuja> in all files?
[07:16] <bluekuja> (cron files)
[07:16] <pkern> No.
[07:16] <pkern> (:
[07:16] <bluekuja> k then
[07:16] <pkern> I would have suggested a grep anyway instead of a ls ;)
[07:16] <bluekuja> pkern: I love that! (:
[07:16] <bluekuja> pkern: yea, was checking if everything was there
[07:17] <bluekuja> before grep
[07:18] <bluekuja> pkern: anyway lets wait him
[07:18] <Kopfgeldjaeger> um.. it seems like only the header files of avidemux dont have a copyright statement. the c/c++ files do.
[07:20] <bluekuja> pkern: do you know debarchiver?
[07:20] <bluekuja> pkern: or well, are you familiar with it?
[07:21] <zul> Kopfgeldjaeger: file a bug with debian please
[07:21] <pkern> bluekuja: Nope, I use reprepro.
[07:21] <bluekuja> pkern: gonna check that
[07:22] <bluekuja> pkern: is that ok?
[07:22] <Kopfgeldjaeger> zul: how do you mean that? debian doesnt have avidemux in the repos, i am creating one...
[07:22] <bluekuja> pkern: it includes a build-machine on it (like a pbuilder)
[07:22] <bluekuja> or just a repo?
[07:24] <pkern> bluekuja: Just a repo.
[07:24] <bluekuja> pkern: I'm trying to get a working build-system-repo
[07:24] <pkern> Try dak ;)
[07:25] <bluekuja> pkern: dak gives you the possibility to build and archive a package?
[07:25] <bluekuja> pkern: :)
[07:26] <bluekuja> pkern: I know that dak is used on debian, I was unsure about the process build-repo
[07:26] <pkern> bluekuja: You may want to ask in #debian-devel on OFTC. I don't know of such a solution. wanna-build/dak of course support that, but they are quite... hard to setup.
[07:26] <bluekuja> yeah
[07:26] <bluekuja> I know
[07:26] <pkern> bluekuja: You could try to setup wanna-build with sbuild.
[07:27] <pkern> bluekuja: But I guess that would be hard, too.
[07:27] <pkern> Especially as sbuild is... strange at best.
[07:27] <bluekuja> pkern: so in fact we havent a perfect solution for this
[07:27] <pkern> Or write some kind of adapter for pbuilder to query wanna-build. Or just write a bloody build queue manager yourself. ;)
[07:27] <pkern> bluekuja: PPA
[07:28] <bluekuja> pkern: yea, needed it on my server
[07:28] <bluekuja> for some tests
[07:28] <bluekuja> pkern: I can use a build software and then sync the result on dak/ftparchiver dir
[07:29] <pkern> Well I know that jd wrote rebuildd, but that's a sightly different target than a wanna-build replacement.
[07:30] <bluekuja> pkern: checking rebuildd
[07:30] <bluekuja> atm
[07:31] <bluekuja> pkern: so is there a way to setup a repo with rebuildd then?
[07:31] <bluekuja> I gonna check the documentation
[07:32] <bluekuja> pkern: it looks pretty nice
[07:32] <bluekuja> pkern: thanks for the hint on this
[07:33] <pkern> I would suggest a different workflow.
[07:33] <pkern> Like taking reprepro for the repo, and a dinstall script to process the incoming directory.
[07:33] <pkern> (Which is called by dput/dupload)
[07:34] <bluekuja> pkern: that looks nice too
[07:34] <pkern> Then add hooks so that the packages are registered to build.
[07:34] <Kopfgeldjaeger> bluekuja: i get an "access forbidden" error when trying to access on of my uploaded files (the others work). it's http://revu.tauware.de/revu1-incoming/avidemux-0709262020/avidemux_2.4~svn20070925-0ubuntu1_source.changes
[07:34] <pkern> And a daemon regularly polls if there is s.th. to do.
[07:34] <pkern> Builds and uploads the binary package.
[07:34] <pkern> That's basically the wanna-build workflow.
[07:34] <pkern> Kopfgeldjaeger: You can't access changes files.
[07:35] <bluekuja> exactly
[07:35] <pkern> Kopfgeldjaeger: Out of the simple reason that they might be signed.
[07:35] <pkern> (Or they are certainly.)
[07:35] <bluekuja> pkern: let me check some wanna-build stuff
[07:36] <Kopfgeldjaeger> oh, ok ;) sorry, i didn't know that. but why is bad to publish the signature? i never heard that
[07:36] <bluekuja> pkern: btw does cowbuilder works fine with rebuildd?
[07:37] <bluekuja> e.g is it well integrated
[07:38] <pkern> bluekuja: Well, when it's able to use pbuilder. I don't know it, I never tried rebuildd. I didn't come around to setup an autobuilding repo for my administration work, yet. Just normal ones.
[07:39] <pkern> Kopfgeldjaeger: I don't know if revu checks the distribution but let's assume I upload a package with unstable in the changes and sign it and upload it to REVU. Then someone could take it and reupload it to Debian because my key is in the ring.
[07:39] <bluekuja> ok, gonna test it for a while then
[07:40] <pkern> (That's why I cripple the distribution field in private archives and prefix it.)
[07:40] <pkern> Kopfgeldjaeger: And if a MOTU would use it to get a package reviewed that package could immediately be uploaded to Ubuntu.
[07:40] <pkern> (So that one is probably nearer to reality.)
[07:43] <Kopfgeldjaeger> ok
[07:52] <Kopfgeldjaeger> the debian/dirs file is for entering needed directories, which will be created while "dpkg-buildpackage"ing it, isn't it? and i can add my files with debian/rules into debian/pkgname/usr/lib/do/not/know then?
[07:56] <tormod> bryce_: why is there both a perlmagick and a libgraphics-magick-perl package?
[07:57] <pkern> Kopfgeldjaeger: There are debian/*.install for that.
[07:58] <Kopfgeldjaeger> pkern: do you have a keyword to search for for such files?
[07:59] <pkern> Kopfgeldjaeger: man dh_install
[08:02] <Kopfgeldjaeger> the examples are a bit short, but thanks. and i need to rename a file
[08:10] <pkern> Kopfgeldjaeger: I would call them concise.
[08:11] <ScottK> Focused even.
[08:11] <Kopfgeldjaeger> pkern: it does not tell how to add, e.g., a desktop file - which is not installed my the upstream makefile - which is one of my 'problems'
[08:15] <jetsaredim> is there a way to get a package that was on feisty brought forward to gutsy?
[08:15] <bryce_> tormod: no idea; why do you ask?
[08:15] <geser> jetsaredim: isn't it in gutsy anymore?
[08:15] <jetsaredim> I'm looking for the vmware-server-kernel-modules package for gutsy
[08:16] <jetsaredim> but she is na longer there
[08:16] <tormod> bryce_: they are pretty much the same but only one works with inkscape
[08:16] <pkern> ttp://archive.canonical.com/ubuntu/pool/main/v/vmware-server/ maybe?
[08:16] <pkern> Hm, that's probably not gutsy.
[08:16] <bryce_> tormod: hmm.
[08:16] <tormod> bryce_: bug 145145
[08:16] <ubotu> Launchpad bug 145145 in inkscape "ill2svg.pl uses Image::Magick instead of Graphics::Magick" [Undecided,New]  https://launchpad.net/bugs/145145
[08:17] <bryce_> tormod, well upstream we've dropped perl support, and even in feisty there really isn't much using it, so if it's an issue, you can drop the inkscape varient
[08:17] <bryce_> oh that
[08:17] <jetsaredim> pkern: that might help - does that just build against the running kernel?
[08:17] <bryce_> that only works for old illustrator docs anyway
[08:18] <bryce_> boy it's a shame we couldn't include a newer inkscape in gutsy; illustrator/pdf support has been completely reworked
[08:18] <pkern> jetsaredim: The -source does, yes. But it's not guaranteed that it builds correctly against the kernel in gutsy.
[08:18] <pkern> jetsaredim: We *may* be syncing vmware-package from Debian for gutsy, which would take care of that.
[08:18] <siretart> bluekuja: pong
[08:18] <tormod> bryce_: yes I tried it on newer illustrator files today :) which one is the "inkscape variant"?
[08:18] <pkern> ScottK: ^
[08:18] <jetsaredim> pkern: any ideas when that will be resolved?
[08:19] <jetsaredim> i really need my vmware setup working - like last week
[08:19] <jetsaredim> :)
[08:19] <pkern> jetsaredim: No.
[08:19] <pkern> jetsaredim: Well Gutsy isn't released yet, so that's no argument.
[08:19] <jetsaredim> well
[08:19] <jetsaredim> the kernel team is listed as the maintainer
[08:19] <bryce_> tormod, according to what you put in the bug report, it sounds like perlmagick would be the inkscape variant
[08:19] <jetsaredim> so i kind of figured that it would have been available on gutsy
[08:20] <ScottK> pkern: I talked to soren about it and he was going to ask around to see what we should do.
[08:20] <jdong> jetsaredim: vmware-server-kernel-modules is probably going to be done post gutsy release if at all
[08:20] <pkern> ScottK: Ok.
[08:20] <jdong> and IIRC it's a -commercial repo thing too
[08:20] <pkern> jdong: It was in multiverse for feisty.
[08:20] <jetsaredim> jdong: any ideas why?
[08:20] <pkern> jdong: At least the modules according to packages.u.c
[08:21] <jdong> it needs an any-any patch currently to bring it to sync with Gutsy's kernel
[08:21] <jetsaredim> yea - the actual user-space package was in commercial
[08:21] <jdong> and probably because it's low-priority for the kernel devs currently
[08:21] <jetsaredim> any-any?
[08:21] <jdong> yes
[08:21] <jdong> they are semi-official external patches to vmware's kernel modules
[08:21] <jetsaredim> ok
[08:21] <jdong> they won't compile against 2.6.22 stock
[08:21] <jetsaredim> ok
[08:22] <ScottK> jdong: What do you think about backporting python-central to Dapper?  It didn't exist at all, so no regression risk.
[08:22] <ScottK> It'd make some other stuff easier....
[08:22] <jetsaredim> jdong: I've patched vmware modules before - maybe I can help
[08:22] <jdong> contributions are welcome...
[08:22] <jetsaredim> I really, really need my vmware setup back
[08:22] <jdong> ScottK: sounds safe to me
[08:23] <jetsaredim> jdong: not quite sure where to start tho?
[08:23] <jdong> jetsaredim: #ubuntu-kernel is more appropriate
[08:23] <jetsaredim> k
[08:24] <tormod> bryce_: so we should drop the inkscape variant and fix inkscape to use the other? This is not so important, but I just want to file the bug to the right package for the moment.
[08:24] <bryce_> tormod, if the two packages really are identical...
[08:24] <bryce_> tormod, I would worry their API's differ, which would require significant rework, which would then get chucked out anyway if/when we get a new inkscape release
[08:26] <tormod> bryce_: ok, I just leave the bug as it is on inkscape and close it once a new inkscape is out.
[08:26] <bryce_> ok sounds good
[08:26] <bryce_> maybe include a summary of our discussion about it, to remind us?
[08:28] <bluekuja> siretart: about daily sync
[08:28] <siretart> yes?
[08:28] <bluekuja> is there a crontab file?
[08:28] <bluekuja> did not find it
[08:29] <siretart> hmmmm
[08:29] <bluekuja> siretart: are you sure it exists?
[08:29] <bluekuja> :D
[08:29] <siretart> not anymore... hmm
[08:30] <bluekuja> hehe
[08:30] <siretart> bluekuja: did you resync an hour ago?
[08:30] <bluekuja> siretart: yup
[08:30] <siretart> ok
[08:32] <siretart> added to revu1's crontab
[08:33] <bluekuja> siretart: great, you rock
[08:33] <bluekuja> siretart: which hour?
[08:33] <siretart> @daily
[08:33] <bluekuja> ok
[08:33] <tormod> bryce, yes I left a comment in the bug report.
[08:33] <bluekuja> siretart: sounds good, thanks for adding it
[08:33] <bluekuja> :)
[08:50] <erable> Hi, I put 2 packages on REVU : http://revu.tauware.de/details.py?upid=304 and http://revu.tauware.de/details.py?upid=301
[08:52] <erable> Can somebody check them ? Thanks
[09:16] <pochu> jdong: could you please retry tracker backport after updating your pbuilder? re: bug 135171. thanks :-)
[09:16] <ubotu> Launchpad bug 135171 in feisty-backports "Please backport tracker 0.6.1-0ubuntu1 from Gutsy to Feisty" [Undecided,New]  https://launchpad.net/bugs/135171
[09:22] <ScottK> pochu: Why don't you wait until they get the final upstream for Gutsy before you do that.  Lots of bugfix goodness coming soon.
[09:24] <pochu> Hmm, right.
[09:24] <pochu> jdong: forget it, following ScottK's good suggestion :)
[09:36] <erable> Hi, I put 2 packages on REVU : http://revu.tauware.de/details.py?upid=304 and http://revu.tauware.de/details.py?upid=301
[09:36] <erable> Can somebody check them ? Thanks
[09:37] <ScottK> erable: Most developers are focused on getting Gutsy bug fixed and shipped right now.  Focus won't shift back to new packages until after Gutsy release.  Someone may review, but be patient.
[09:38] <erable> ScottK: ok, I understand. Excuse-me and good work ;-)
[09:39] <ScottK> erable: No problem, just understand it may be a while.
[10:03] <leleobhz> someone know the pdebuilder?
[10:03] <leleobhz> how it works?
[10:03] <pwnguin> pbuilder?
[10:04] <leleobhz> yep
[10:04] <leleobhz> im getting a strange problem with modifications on my package
[10:04] <leleobhz> my package have a .desktop in the debian/
[10:04] <leleobhz> if i compile it with dpkg-buildpackage
[10:05] <leleobhz> the modifications on .desktop get untouched
[10:05] <leleobhz> if i use pbuilder, it gets the original .desktop
[10:05] <leleobhz> so, how can i "fix" it
[10:05] <leleobhz> cypherbios: ehlo!
[10:06] <cypherbios> hi leleobhz
[10:06] <leleobhz> cypherbios: want package problems for you?
[10:06] <leleobhz> :p
[10:07] <cypherbios> leleobhz: actually I don't, but do I have any choice?
[10:07] <leleobhz> cypherbios: i at least no :p
[10:07] <leleobhz> pwnguin: so, did you know why this occours?
[10:08] <bddebian> leleobhz: Back again eh?  So you update debian/foo.desktop update debian/changelog and bump the version, then do dpkg-buildpackage and then pbuilder build <new version>.dsc and the desktop is the same as before?
[10:09] <leleobhz> bddebian: hmm, ive not atempt to change the version...
[10:11] <bddebian> Well I should qualify that.  Are you doing a source only build with dpkg-buildpackage?
[10:19] <leleobhz> bddebian: (!) ;]
[10:19] <leleobhz> thanks
[10:22] <leleobhz> can i know the cc flags used in a binary file?
[10:40] <so1> hi
[10:40] <so1> will gimp stay at rc2 or will it be updated when the final will be released?
[10:53] <Kmos> so1: it will be updated
[10:54] <Kmos> until gutsy final version
[10:54] <Kmos> i'm pretty sure =)
[11:03] <ScottK> Kmos: Why do you think that?
[11:05] <Kmos> ScottK: gimp 2.4 is in rc3 and should be final soon
[11:05] <ScottK> Right, but why do you think Ubuntu will update?
[11:07] <Kmos> ScottK: I don't know any ubuntu release with gimp in RC
[11:07] <ScottK> Do you know any Ubuntu release where gimp was RC this close to Ubuntu's release?
[11:08] <ScottK> so1: Just in case you can't tell, Kmos really has no idea if it'll be updated or not.  Neither do I.
[11:16] <ScottK> Heh.  http://www.appscout.com/2007/09/excel_cant_multiply.php
[11:19] <ion_> scottk: The OOXML standard probably contains a multiplyLikeExcel2007 tag. :-)
[11:19] <ScottK> Ooh.  Good point.


[03:22] <solefald> Does anyone know of a way to test maas/curtin preseed files via a VM or something? It takes way long to wait for a bare metal system to come up and go through motions, just to bomb on a syntax error at the end
[05:45] <errr> Using 2.0.0+bzr5189-0ubuntu1 is there a way to pull up the snippets history? I rebooted my maas box and when it came up the dhcpd.conf that I had been using for a month was gone and no snippets showed in the UI anymore..
[16:03] <solefald> I am having hell of a time trying to figure out how to escape some things in preseed files. Would someone please send me in the right direction?
[16:03] <solefald> ["curtin", "in-target", "--", "sh", "-c", "sed -i /etc/beegfs/beegfs-client.conf -e \"s/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/\""]
[16:04] <solefald> I have tried a hundred different ways to escape this and it fails every time
[16:04] <solefald> Stdout: b"sed: -e expression #1, char 51: unknown option to `s'\n"
[16:07] <lutostag> solefald: I would write out the expression you want in the command line... in your case ...
[16:08] <lutostag> curtin in-target -- sh -c sed -i /etc/beegfs/beegfs-client.conf -e"s/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/"
[16:08] <lutostag> then use python to do it for you...
[16:09] <solefald> @lutostag thank you. while we are here, what is the difference with writing things like  "curtin in-target -- sh -c sed -i "   and ["curtin", "in-target", "--", "sh", "-c", "blahblah"]?    i see the first method used when you need to echo something out
[16:09] <lutostag> solefald: http://pastebin.ubuntu.com/23379588/
[16:10] <lutostag> solefald: so each item in the list is passed as a separate argument to the command
[16:10] <solefald> hm.. thank you
[16:11] <lutostag> typically you only will have spaces within an item if it is quoted
[16:11] <mup> Bug #1636559 opened: ssh connection drops from deployed node <MAAS:New> <https://launchpad.net/bugs/1636559>
[16:12] <lutostag> solefald: https://stackoverflow.com/questions/11801098/calling-app-from-subprocess-call-with-arguments is the closest explanation I found that might be helpful
[16:13] <solefald> lutostag: thank you for the explanation. Trying it out now
[16:17] <mup> Bug #1636559 changed: ssh connection drops from deployed node <MAAS:New> <https://launchpad.net/bugs/1636559>
[16:20] <mup> Bug #1636559 opened: ssh connection drops from deployed node <MAAS:Incomplete> <https://launchpad.net/bugs/1636559>
[16:36] <lutostag> solefald: ['curtin', 'in-target', '--', 'sh', '-c', 'sed', '-i', '/etc/beegfs/beegfs-client.conf', '-e', 's/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/'] -- looks like I missed a space when I copied your cmd
[16:37] <solefald> yep, saw that. thank you. i just tested and it bombs like that too with invalid sed syntax
[16:38] <lutostag> solefald: my latest?
[16:39] <solefald> yep.
[16:39] <solefald> Installation failed with exception: Unexpected error while running command.
[16:39] <solefald> Command: ['curtin', 'in-target', '--', 'sh', '-c', 'sed', '-i', '/etc/beegfs/beegfs-client.conf', '-e', 's/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/']
[16:39] <solefald> Exit code: 4
[16:39] <solefald> Reason: -
[16:39] <lutostag> solefald: hmm, looks like your sed is off a bit
[16:40] <solefald> yeah is supposed to be sed -i "s/blah/blah/" /path/to/file
[16:40] <lutostag> I would do the sed like $ sed -i 's/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/' /etc/beegfs...
[16:40] <lutostag> yep!
[16:40] <solefald> i've been doing that for years. then i found this page yesterdays
[16:40] <solefald> https://www.stackevolution.com/node/17
[16:40] <solefald> puppet_02_onboot: ["curtin", "in-target", "--", "sh", "-c", "sed -i /etc/default/puppet -e 's/START=no/START=yes/'"]
[16:41] <solefald> which is rather odd, but i decided to try that because everything else i've tried failed.
[16:41] <lutostag> solefald: ah, and I think I got the command wrong again...
[16:42] <solefald> and 's/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/' may need double quotes because of the regex
[16:43] <solefald> also i just tried on the command line and it did not work with (.*) but worked with .*  so im testing that now
[16:43] <lutostag> yeah, I think after all this it should be...
[16:43] <lutostag> ['curtin', 'in-target', '--', 'sh', '-c', 'sed -i "s/^sysMgmtdHost(.*)$/sysMgmtdHost = <IP_ADDRESS>/" /etc/beegfs/beegfs-client.conf']
[16:44] <lutostag> ['curtin', 'in-target', '--', 'sh', '-c', 'sed -i "s/^sysMgmtdHost.*$/sysMgmtdHost = <IP_ADDRESS>/" /etc/beegfs/beegfs-client.conf']
[16:45] <solefald> thank you. this is going to be my next try
[16:45] <solefald> i wish there was a way to validate all of this without having to deploy the box every 5 minutes
[16:51] <lutostag> solefald: without the curtin prefix bit it seems to work...http://pastebin.ubuntu.com/23379738/
[16:51] <lutostag> so should be close
[16:52] <solefald> yep! seems like it worked! let me fix the others. i have like 15 similar lines in there
[17:06] <vmorris> i would like to know how to modify the dns records for the maas region controller itself -- the first interface that it has got picked up and set as the IP in DNS - I would rather it be the address on one of the other interfaces
[17:12] <solefald> lutostag: that worked! now i am trying to figure out what to do with ["curtin", "in-target", "--", "sh", "-c", 'sed -i "s/^connInterfacesFile.*$/connInterfacesFile = /etc/beegfs/interfaces/" /etc/beegfs/beegfs-client.conf']
[17:12] <solefald> because it does not like when i scape / with \   or change / delimiters to @
[17:12] <lutostag> solefald: sed uses whatever directly follows 's' as the delemiter...
[17:13] <lutostag> so I would...
[17:13] <lutostag> ["curtin", "in-target", "--", "sh", "-c", 'sed -i "s_^connInterfacesFile.*$_connInterfacesFile = /etc/beegfs/interfaces_" /etc/beegfs/beegfs-client.conf']
[17:13] <solefald> ill try underscores. @'s did not work
[17:13] <solefald> Command: ['curtin', 'in-target', '--', 'sh', '-c', 'sed -i "s@^connInterfacesFile.*$@connInterfacesFile = /etc/beegfs/interfaces@" /etc/beegfs/beegfs-client.conf']
[17:14] <lutostag> solefald: did the @ work on the command line directly?
[17:14] <solefald> yep
[17:16] <lutostag> hmm, $@ is a thing in bash-land, maybe that made it sad
[17:16] <lutostag> but then again so is $_ ...
[17:18] <vmorris> okay, dpkg-reconfigure maas-region-controller let me change the ip address that maas has configured, but it's still showing up as the old address in the DNS table
[17:22] <lutostag> vmorris: the DNS table where? has the TTL expired?
[17:22] <vmorris> lutostag: the DNS table in the MAAS gui still contains the old IP address for the maas-region server, i've restarted following the dpkg-reconfigure
[17:23] <lutostag> roaksoax: ^^
[17:31] <vmorris> lutostag roaksoax: this is maas 2.0.0+bzr5189-0ubuntu1~16.04.1
[17:45] <vmorris> soooo, i'm just going to edit /etc/bind/maas/zone.maas and reverse since I can't seem to find any appropriate place to edit the thing otherwise
[17:58] <vmorris> just fyi, that didn't help
[18:50] <roaksoax> lamont: ^^
[18:50] <roaksoax> vmorris: i think you'd just need to change settings via API
[18:50] <roaksoax> but lamont may be able to answer that better
[18:55] <lamont> vmorris: it likely requires a restart of the region before DNS updates will have the new address
[18:55] <lamont> which you've done.  hrm
[18:56] <vmorris> lamont: thanks but I tried this
[18:56] <vmorris> lamot: manually altering the records was only temporary, they were restored following the restart as wel
[18:56] <lamont> is there a bug filed?
[18:56] <vmorris> well* soo.. i'm reinstalling the controller without that interface enabled
[18:56] <vmorris> none that i'm aware of
[18:57] <vmorris> it's likely just a symptom of my configuration here
[19:02] <bladernr`> roaksoax, is there a way in MAAS to limit what nodes a user can control?
[19:39] <mup> Bug #1636601 opened: Can 'break' a 'New' node but cannot 'fix' it <docteam> <MAAS:New> <https://launchpad.net/bugs/1636601>
[19:39] <mup> Bug #1636602 opened: Tool to restart all MAAS processes <MAAS:New> <https://launchpad.net/bugs/1636602>
[19:52] <jhegge> yeah
[20:08] <brandor5> Hello everyone: I've got a new instance of maas 2 up and trying to configure nodes... however the ephemeral image loads and just sits there... I see cloud-init trying to talk to meta-data but failing... is that expected?
[20:16] <brandor5> anyone?
[20:18] <brandor5> just poking around it looks like it's getting the wrong cloud-config-url from MAAS... it's using localhost instead of a hostname or ip
[20:19] <roaksoax> bladernr`: nope
[20:19] <roaksoax> brandor5: check /etc/maas/rackd.conf what does it say there ?
[20:20] <brandor5> roaksoax: it is using localhost there... should that be fixed by install?
[20:20] <brandor5> and is there a proper way to fix it other than vi
[20:20] <roaksoax> brandor5: no, if localhost is there, it will chose the value in /etc/maas/regiond.conf under maas_url
[20:21] <roaksoax> brandor5: so you have two options
[20:21] <roaksoax> 1. fix /etc/maas/rackd.conf to point to the proper IP
[20:21] <roaksoax> or
[20:21] <roaksoax> 2. fix /etc/maas/regiond.conf and leave rackd.conf as localhost
[20:21] <roaksoax> brandor5: we reocmmend you do 1
[20:21] <brandor5> roaksoax: awesome, thanks!
[20:23] <brandor5> roaksoax: is there a service that needs to be restarted to take that change in?
[20:29] <roaksoax> brandor5: yes
[20:41] <brandor5> roaksoax: which service :D
[20:45] <brendand> brandor5, probably maas-rackd
[20:45] <brendand> systemctl restart maas-rackds
[20:45] <brendand> (no s at the end)
[20:46] <brandor5> brendand: ah that's it, I'm not used to systemd on ubuntu yet.... was looking for services in /etc/init.d
[20:46] <roaksoax> brandor5: maas-rackd yes
[20:46] <brandor5> thank you
[20:53] <bladernr`> roaksoax, thanks!
[21:02] <solefald> does curtin run late commands in alphabetical order?
[21:05] <solefald> my commands are named like this -  packages_0X_blah: , beegfs_0X_blah:, test_0X_blah:
[22:57] <mup> Bug #1573690 changed: In the domain details pages, sometimes names have links to nodes when they should not <MAAS:Fix Released by lamont> <https://launchpad.net/bugs/1573690>
[23:06] <mup> Bug #1573690 opened: In the domain details pages, sometimes names have links to nodes when they should not <MAAS:Fix Released by lamont> <https://launchpad.net/bugs/1573690>
[23:12] <mup> Bug #1573690 changed: In the domain details pages, sometimes names have links to nodes when they should not <MAAS:Fix Released by lamont> <https://launchpad.net/bugs/1573690>


[15:11] <Daviey> slangasek / cjwatson: When you get a moment, could you consider bug 853255?  Thoughts on a sync+delta or introducing a delta to include a new binary package based on current contrib/ app.  Neither have been tested, that is one for tomorrow.
[15:11] <ubot4> Launchpad bug 853255 in dnsmasq (Ubuntu Oneiric) (and 1 other project) "FFe: Merge dnsmasq 2.58-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/853255
[21:45] <cjwatson> doko: I'd appreciate it if you could review my clang upload - should appear in unapproved soon
[21:48] <cjwatson> WTF, why is lillypilly's mirror so abysmally out of date
[21:49]  * cjwatson RTs
[21:52] <doko> cjwatson, looks fine. but I hate it if upstream's conditionalize on release names rather than features
[21:53] <cjwatson> doko: I know, the configuration handling there is really sucky, I just didn't want to attempt a proper fix at this point
[21:53] <cjwatson> risk of error seemed higher than the stupid fix
[21:55] <stgraber> just uploaded a new ltsp fixing bug 838845 (missing fonts). The fix is simply to install all the same ttf-* packages as a regular ubuntu desktop into the ltsp chroot.
[21:55] <ubot4> Launchpad bug 838845 in ldm (Ubuntu) "Chinese glyphs (and potentially some other languages) aren't rendered properly in ldm (affects: 1) (heat: 5)" [Medium,Triaged] https://launchpad.net/bugs/838845
[21:56] <stgraber> I used wrap-and-sort to make the diff more readable (as the dependency list is pretty long), a clean diff is at: http://paste.ubuntu.com/692570/ (LP will show both wrap-and-sort changes + dependencies changes)
[21:56] <cjwatson> confirmed that that clang change fixes libdispatch
[21:57] <cjwatson> well, confirmed on i386 at least
[22:03] <infinity> stgraber: Sounds vaguely sane.  The reordering of stuff in debian/*.install makes the diff a pain to read, though...
[22:07] <infinity> stgraber: Also, assuming we merge with Debian's ltsp package (do we?), wrap-and-sort's going to make that a bit confusing/painful, unless they do the same.
[22:16] <stgraber> infinity: we don't merge from Debian
[22:16] <stgraber> infinity: http://paste.ubuntu.com/692570/ is the diff after the wrap-and-sort. I also did it in two stage in the bzr branch to make it relatively easy to diff
[22:23] <cjwatson> ScottK: do you think dovecot-metadata-plugin should just be updated to a new upstream to fix bug 831179?  I'm pretty sure http://hg.dovecot.org/dovecot-metadata-plugin/rev/fc360cf4ef81 fixes the FTBFS, but I'm not sure I fancy extracting just the autotools bits
[22:23] <ubot4> Launchpad bug 831179 in dovecot-metadata-plugin (Ubuntu Oneiric) (and 1 other project) "dovecot-metadata-plugin version 0.0.1~hg144-0ubuntu1 failed to build in oneiric (affects: 1) (heat: 4)" [High,Confirmed] https://launchpad.net/bugs/831179
[22:42] <stgraber> infinity: Debian (Vagrant Cascadian) and Ubuntu (me) share part of our packaging and try to reduce our delta from time to time but LTSP is meant to be heavily integrated into the distros so I doubt we'll ever get to the point where we can just sync from Debian (we do for ltspfs, ltsp-docs and hopefully for ldm next cycle)
[22:44] <Laney> libproxy made me a) sad and b) stressed
[22:44] <Laney> not sure I'll finish it in time
[22:48] <stgraber> Laney: what's wrong with it?
[22:48] <Laney> many bindings that I'm not sure how to package correctly
[22:48] <Laney> strange module system
[22:49] <Laney> also it didn't appear to work, but that could have been user error
[22:50] <Laney> stgraber: git://anonscm.debian.org/users/laney/libproxy.git give that a go if you fancy some fun
[22:50] <Laney> my dpkg-shlibdeps hax are wrong and a better solution should be found
[22:53] <Laney> night!


[13:48] <ravage> someone in #ubuntu just asked about the italian mirror being unavailable. i think this may be the cause: https://p.haxxors.com/qpnt7vky.txt
[22:44] <hloeung> ravage, thanks for reporting this. In the future, any chance of filing an RT instead? For now, I've removed it.archive.u.c pointing to ubuntu.mirror.garr.it (confirmed unresponsive for me too)