[00:34] <imbrandon> directhex, anything i can help with on the mono/u1ms bindings ?
[00:34] <imbrandon> i've got time over the next few days to throw at it if needed
[02:06] <lfaraone> If a package is in Debian NEW, can I request a motu-release ACK (for a FFE) for it at that point, or do I still need to go through REVU? (NEW seems to have several weeks of backlog)
[02:10] <persia> lfaraone: Only ftpmasters can pull from NEW, so it needs to go somewhere.
[02:10] <lfaraone> persia: well, it'd also be in mentors.
[02:10] <lifeless> NEW is stalled
[02:10] <persia> lfaraone: But that a package is in NEW counts as one of two developer advocations, in my book.
[02:11] <lfaraone> persia: (and I've had packages synced from NEW before freezes before :) )
[02:11] <persia> Where is bdefreese when one needs him :)
[02:11] <persia> lfaraone: You've never had a package synched from NEW (although it may have appeared that way).
[02:12] <persia> The set of people who can see NEW doesn't happen to include any of the set of people that can perform a sync.
[02:12] <lifeless> syncing from NEW would be bad
[02:13] <persia> It's *not* possible.
[02:13] <persia> Anyway, back to the matter at hand.
[02:13] <persia> There exists a package that was reviewed/advocated by a Debian Developer.
[02:13] <persia> Just needs some Ubuntu Developer to advocate and upload it.
[02:14] <persia> Needs an FFe, same as any new package.
[02:14] <lfaraone> persia: okay, thanks.
[02:14] <persia> If it's already on mentors, no need to separately upload to REVU.  mentors works fine for review.
[02:22] <lfaraone> persia: would you have a chance to advocate http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=groundcontrol then? :)
[02:22] <lfaraone> (so I can file for a FFe)
[02:24] <persia> lfaraone: File for the FFe first.  Subscribe me.  I've reviewed that package enough times before that I'm confident I'll be advocating and uploading with the FFe approved.
[02:34] <Linux000> I am trying to debug a python based application that calls multiple other python files, I was wondering if there was a way to view what python file is calling a certain definition in another file?
[02:34] <persia> Linux000: Do you have a crash, or just undesireable behaviour?
[02:37] <Linux000> The app still runs, but only in a loop, i.e. I run the app, it should launch a graphical window, however it prints an error out to the log without stopping, not sure what to call it
[02:37] <persia> That's a loop :)
[02:37] <lfaraone> persia: done, https://bugs.edge.launchpad.net/ubuntu/+bug/486807
[02:37] <ubottu> Launchpad bug 486807 in ubuntu "[needs-packaging] groundcontrol" [Wishlist,In progress]
[02:37]  * persia isn't good at debugging loops
[02:38] <persia> lfaraone: Cool.  OI've put it on my TODO list.  When it gets ubuntu-release feedback, I'll do something more complicated.
[02:38] <Linux000> Okay, I found what file is causing the loop(I think) I just need to know what process is calling it
[02:39] <persia> Check with the folk in #ubuntu-bugs : they tend to have expertise in debugging.  I don't happen to know the python equivalent of `set -x`
[02:40] <lifeless> there isn't one
[02:40] <lifeless> however
[02:40] <lfaraone> persia: there isn't one, you can only use pdb.
[02:40] <lifeless> python -m pdb <pythonscript>
[02:40] <persia> Linux000: ^^
[02:40] <lifeless> will run in pdb, and when it breaks leave you in jit debugging mode
[02:40] <Linux000> lifeless: Thanks
=== emma_ is now known as emma
[03:32] <mattva01> just a quick question, having an issue with cdbs's debhelper.mk calling dh_installinfo and having it catch a metadata containing file with a .info extension. Is there anyway to alter or turn off this behavior?
[03:38] <mattva01> just a quick question, having an issue with cdbs's debhelper.mk calling dh_installinfo and having it catch a metadata containing file with a .info extension. Is there anyway to alter or turn off this behavior?
[03:38] <mattva01> oops
[04:01] <jayvee> $ virsh -c qemu:///system start CentOS
[04:01] <jayvee> error: Failed to start domain CentOS
[04:01] <jayvee> error: internal error Unable to find cgroup for CentOS
[04:02] <jayvee> This was working yesterday. KVM starts fine standalone, too. Any ideas?
[04:03] <jayvee> oops, thought I was on #ubuntu-server — sorry about that
[04:13] <zooko> Greetings, people of #ubuntu-motu!
[04:21] <zooko> Could someone please test this package: https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350
[04:21] <ubottu> Launchpad bug 529350 in tahoe-lafs "please upgrade Tahoe-LAFS in Lucid to v1.6.1 of Tahoe-LAFS" [Undecided,In progress]
[04:29] <jayvee> greetings zooko
[04:29] <zooko> jayvee: Hi there
[05:04] <jayvee> zooko, do you run ubuntu?
[05:07] <zooko> jayvee: yes, but I don't have an ubuntu machine to hand at the moment.
[05:07] <jayvee> zooko, can I provide an ubuntu vm for you to test in?
[05:08] <jayvee> I'd do more testing, except I have no idea how to work this software
[05:10] <zooko> jayvee: it is easy! http://allmydata.org/source/tahoe-lafs/trunk/docs/running.html
[05:10] <zooko> :-)
[05:10] <zooko> Oh wait, somebody has added a lot of words to that page.
[05:10] <jayvee> I'm reading that, and not getting very far
[05:11] <zooko> Why not?
[05:11] <zooko> Sounds like I need to file a bug report on that page. :_)
[05:13] <jayvee> oh, just the feedback I'm getting is not very descriptive
[05:13] <jayvee> "introducer node probably started"
[05:14] <jayvee> I'm basically expecting to see "tahoe successfully started, browse to this_url to view contents"
[05:14] <jayvee> but maybe I'm just a simpleton
[05:16] <jayvee> 'tahoe run' blocks with no feedback. I presume that's intentional (no news is good news), but a little disconcerting to someone who has never used it before.
[05:18] <jayvee> I ran 'tahoe start .' and 'tahoe run', and yet nothing is listening on port 3456.
[05:19] <jayvee> the documentation (using.html) says that should be the case
[05:20] <zooko> Could you check logs/twistd.log
[05:24] <zooko> http://allmydata.org/trac/tahoe-lafs/ticket/71#comment:17
[05:36] <jayvee> nevow.appserver.NevowSite starting on 3456
[05:37] <jayvee> should be working :/
[05:37] <jayvee> ah, I think I found the problem
[05:37] <jayvee> my localhost is only set to ::1 /etc/hosts
[05:37] <jayvee> and tahoe only binds to 127.0.0.1
[05:38] <jayvee> so of course browsing to localhost:3456 won't work
[05:38] <zooko> jayvee aha! Interesting. Thanks. Will ticket that.
[05:38] <jayvee> I think it stems from the fact that you're using twisted
[05:39] <jayvee> which doesn't support ipv6
[05:39] <zooko> We can control what we bind to.
[05:39] <jayvee> nope, ::1 is ipv6
[05:39] <zooko> I prefer 127.0.0.1 instead of localhost because I've heard reports of the
[05:39] <zooko> Hm.
[05:39] <jayvee> you can't bind to it, as you need an AF_INET6 socket, not AF_INET socket
[05:39] <jayvee> and twisted doesn't support that
[05:39] <jayvee> which is silly, because ipv4 is going to get real real small in the very near future
[05:40] <jayvee> not so much for the localhost issue, but the inter-node connectivity
[05:40] <ScottK> For a reasonably large value of near, sure.
[05:40] <zooko> I see. So what should we do? Perhaps you could open the ticket? On http://tahoe-lafs.org . Just say that you couldn't connect to the wui-wapi port when following the instructions due to this issue.
[05:40] <jayvee> from what I read, tahoe needs an open port on a public IP address on a server node
[05:41] <jayvee> with the ipv4 apocalypse, NATs will make that difficult if not impossible to acheive
[05:41] <zooko> There are a few different issues here.
[05:41] <jayvee> yeah, sorry for confusing this
[05:42] <zooko> The very narrow one, which is not currently ticketed and which I would appreciate you ticketing, is that you got this silent failure to connect your wui-wapi client to the web gateway on port 3456.
[05:42] <zooko> Open that ticket, and maybe we can make it fail louder, or something. At the very least we can close it "wontfix" and then we'll have a ticket to point to.
[05:42] <jayvee> actually, looks like I misunderstood the documentation
[05:42] <jayvee> tahoe run and tahoe start are the same
[05:42] <zooko> Or also we could fix it by twisted learning IPv6...
[05:42] <jayvee> one runs as a daemon, one does not
[05:42] <jayvee> never seen that behaviour before
[05:43] <jayvee> I always see -d or --fork used for those sorts of options
[05:43] <jayvee> or --daemon
[05:43] <zooko> Hm...
[05:43] <jayvee> but that's just a usability issue
[05:43] <zooko> "just" a usability issue, indeed. :-)
[05:44] <jayvee> so I accidentally pressed tab, started typing, and then xchat quit this channel
[05:44] <jayvee> that's an xchat usability issue ;)
[05:44] <zooko> I think that one is *not* exactly http://allmydata.org/trac/tahoe-lafs/ticket/71 but deserves a new ticket of its own which links to http://allmydata.org/trac/tahoe-lafs/ticket/71 .
[05:46] <zooko> Hm... maybe it is this: http://allmydata.org/trac/tahoe-lafs/ticket/355
[05:46] <jayvee> so am I right in guessing that 'tahoe start' and 'tahoe start $HOME/.tahoe' are synonymous?
[05:48] <ajmitch>     
[05:53] <jayvee> zooko, as a point of comparison, this is what upstart gives me
[05:53] <jayvee> $ sudo start mythtv-backend
[05:53] <jayvee> mythtv-backend start/running, process 17060
[05:53] <jayvee> much more satisfying. even printing the PID makes me much more confident.
[06:00] <zooko> jayvee: you are right in so guessing. Also that is stated in the --help usage text isn't it?
[06:01] <jayvee> nope
[06:01] <zooko> re: PID: duly noted: http://allmydata.org/trac/tahoe-lafs/ticket/71#comment:20
[06:02] <jayvee> one other thing is that there is no tahoe man page
[06:02] <jayvee> I take it none has been written upstream?
[06:02] <jayvee> surprised that wasn't picked up by lintian
[06:03] <jayvee> lintian normally warns when there is no man page
[06:08] <zooko> Okay I think I have ticketed all of your observations so far except:
[06:08] <zooko> 1. no man page
[06:09] <zooko> 2. the problem you had with connecting over localhost because you use IPv6
[06:09] <zooko> 3. No doc (that you could find...) saying that tahoe start basedir defaults to $HOME/.tahoe
[06:10] <zooko> 4. You were confused by "tahoe run" vs. "tahoe start" and expected a -d or --fork or --daemon
[06:11] <zooko> I will ticket #1 and #3 because I think I understand them well enough. Will you please ticket #2 and #4?
[06:12] <zooko> http://allmydata.org/trac/tahoe-lafs/ticket/984# no man page
[06:13] <zooko> http://allmydata.org/trac/tahoe-lafs/ticket/985# tahoe start --help should mention that --basedir defaults to $HOME/.tahoe
[06:23] <jayvee> okay, sure
[06:25] <jayvee> hmm, also, I presumed 'tahoe start .' wasn't synonymous with 'tahoe start -C .'
[06:25] <jayvee> maybe I'm just completely of the wrong mindset to be using this program :)
[06:26] <jayvee> zooko, #2 isn't a problem with tahoe
[06:26] <jayvee> it was a problem on my end — my fault
[06:26] <jayvee> not having localhost also resolve to 127.0.0.1 is a bad idea
[06:26] <jayvee> I think I did it at the time to see how much it would break things, and forgot about it
[06:27] <jayvee> what #2 should be is "tahoe-lafs should support IPv6", but given that you're handcuffed by twisted, there is nothing you can do about it
[06:27] <jayvee> you'll have to either wait until twisted supports ipv6, or ditch twisted altogether (which I can't see happening)
[06:40] <zooko> jayvee: that's http://tahoe-lafs.org/trac/tahoe-lafs/ticket/867 (use ipv6)
[06:40] <jayvee> aha
[06:41] <zooko> jayvee: okay, forget about #2 then.
[06:42] <zooko> Now let's see... That thing about "tahoe start ." vs. "tahoe start -C ". I think that's http://allmydata.org/trac/tahoe-lafs/ticket/772 .
[06:43] <zooko> Could you please add a note to that ticket saying that you experienced this issue?
[06:43] <zooko> It looks like David-Sarah assigned it to themselves and put it into the v1.7.0 milestone already, but your comment could help.
[06:43] <zooko> Okay I think I'm just waiting for you to open a ticket for #4 and then I'm done for tonight. :-)
[06:44] <zooko> Thank you very much for the usability testing!
[06:44] <jayvee> unintentional usability testing ;)
[06:45] <jayvee> writing it now
[06:46] <zooko> I suppose that's the best kind. ;-)
=== micahg1 is now known as micahg
[06:48] <jayvee> zooko, what milestone?
[06:48] <jayvee> actually, I'll leave it 'undecided'
[06:50] <zooko> Yeah
[06:50] <zooko> Tag it "usability" and David-Sarah will be sure to notice it. ;-)
[06:50] <jayvee> zooko, http://allmydata.org/trac/tahoe-lafs/ticket/986
[06:51] <jayvee> I haven't seen any problems that I wouldn't expect to be as a result of packaging so far
[06:51] <jayvee> so from my perspective, it's no worse off than 1.6.0 in terms of regressions
[06:52] <jayvee> of couse, I still haven't actually got it working with the public grid yet
[06:52] <jayvee> so my testing isn't exactly thorough so far
[06:53] <jayvee> zooko, I have the introducer set in .tahoe/tahoe.cfg, but "Connected to introducer?: no"
[06:53] <zooko> Heh heh Here is a useful page for testing:
[06:53] <zooko> http://allmydata.org/trac/tahoe-lafs/wiki/TestGrid
[06:53] <jayvee> zooko, yeah, on that
[06:53] <zooko> You can take those hyperlinks and put your host and port num in and see if you can see each of those kinds of file.
[06:54] <zooko> jayvee: okay, didn't connect to introducer. You put into your .cfg something like "introducer.furl = pb://todjw7qkb4dgq4fkeo7cqydcu5vneioh@tahoecs2.allmydata.com:52106/introducer" ?
[06:54] <jayvee> yes
[06:55] <jayvee> except the pb:// URL in quotes
[06:55] <zooko> I think that's wrong.
[06:55] <jayvee> ah
[06:55] <jayvee> I presumed it was Python syntax
[06:55] <zooko> Check the twistd.log and the logs/incidents
[06:55] <zooko> to see if it was trying to tell you that it was wrong.
[06:55] <jayvee> based on the 'None' keyword that was there by default
[06:55] <zooko> Man you are really good at this accidental usability testing.
[06:55] <jayvee> aha, "Connected to introducer?: yes" now
[06:56] <jayvee> None is a reserved word in Python, so I replaced it with equally valid Python syntax :)
[06:56] <zooko> Oh look someone beat you to it: http://allmydata.org/trac/tahoe-lafs/ticket/649 (Validation of configuration settings)
[06:56] <zooko> ndurner
[06:57] <jayvee> heh
[06:57] <zooko> Could you please find the error in logs/incidents?
[06:57] <zooko> Check the timestamps of the files. I guess the most recent one.
[06:57] <zooko> Unless you already discovered a new bug. :-)
[06:58] <zooko> Then run "flogtool dump $LOGFILENAME | less", then see if there is a stack trace saying that it couldn't parse the config file.
[06:59] <jayvee>    File "/home/amduser/trees/tahoe/support/lib/python2.5/site-packages/foolscap-0.4.2-py2.5.egg/foolscap/pb.py", line 741, in getReferenceForName
[06:59] <jayvee>      raise KeyError("unable to find reference for name '%s'" % (name,))
[06:59] <jayvee>  exceptions.KeyError: 'unable to find reference for name \'introducer"\''
[06:59] <zooko> Please cut and paste the stack trace and any other such relevant stuff into http://allmydata.org/trac/tahoe-lafs/ticket/649
[06:59] <zooko> Thank you very much!
[07:00] <zooko> I'll tag that ticket as "usability".
[07:02] <jayvee> zooko, done
[07:05] <jayvee> zooko, what does "To do that you'll need to know which port tahoe is listening on as, by default, it listens on an arbitrary port number." mean?
[07:05] <jayvee> arbitrary means "explicitly set" in my mind
[07:05] <zooko> Is this doc about the port forwarding?
[07:05] <jayvee> so isn't that the exact opposite meaning of what you want?
[07:05] <zooko> It listens on a randomly-selected port number by default.
[07:05] <jayvee> yeah, docs/running.html
[07:05] <jayvee> ah, that's the exact opposite of arbitrary
[07:06] <zooko> But, then it writes it down into its tahoe.cfg so that it will listen on the same one next time
[07:06] <jayvee> you *want* an arbitrary port for port forwarding
[07:06] <jayvee> so in the docs, s/arbitrary/random/
[07:06] <zooko> Unless I am misremembering, the first time you run it, it is random (by your definition), and then the second time it is arbitrary.
[07:06] <jayvee> actually, I got no such port written down in the config. my tahoe.cfg is untouched. :)
[07:06] <zooko> Oh. Hm.
[07:07] <jayvee> actually
[07:07] <zooko> Okay, yeah, you are right.
[07:07] <jayvee> .tahoe/client-port
[07:07] <jayvee> is 60181. is that it?
[07:07] <zooko> Aha! Cool. Sounds right.
[07:07] <zooko> So the docs need to explain about that file. Maybe docs/configuration.txt already does.
[07:07] <jayvee> yeah, it kinda gives the wrong impression
[07:08] <jayvee> there's no harm in saying that on first run it picks a random port and stores it in a file called client.port
[07:08] <jayvee> :)
[07:09] <jayvee> anyways, I'd better let you get to bed, zooko
[07:12] <zooko> You have done a fine job of accidental usability testing. You're still going to ticket your #4 issue, right?
[07:13] <zooko> Could you type up a sentence of English which would go in the appropriate spot to explain that it picks a random port and stores it in that file? You can open a ticket, attach it to some extant ticket, mail it to me, or mail it to tahoe-dev. I'm too sleepy to know which.
[07:14] <zooko> Oh I see you already did #4. Thanks!
[07:14] <jayvee> yeah
[07:14] <jayvee> oops, I forgot to paste you the URL
[07:15] <jayvee> I actually have it in my clipboard still
[07:18] <zooko> Okay, I fall asleep now! Thanks a lot!
[07:19] <jayvee> 'night, zooko
[07:32] <wzssyqa> hi,i am dh $@,and $@ is a command seq,but what is it?
[07:35] <Rhonda> wzssyqa: Can you reword your question? I don't understand it …
[07:35] <wzssyqa> Rhonda: in default rules,there is dh $@,what is it?
[07:36] <Rhonda> That is makefile magic for having every target served by debhelper.
[07:36] <StevenK> $@ expands to the current target name
[07:36] <wzssyqa> o,thanks
[07:37] <wzssyqa> the man dh says that is is a command seq
=== dpm-afk is now known as dpm
[07:38] <Rhonda> People tend to disagree with me, but you just confirmed that that approach isn't really clear or better and more helpful or readable. :)
[07:40] <dholbach> good morning
[08:05]  * Rhonda still wonders where or what is getting discussed with respect to the libsdl issue.
[08:07] <Rhonda> And I also wonder why bug #203158 isn't set to Fix Released yet, won't this enter Lucid? :/
[08:07] <ubottu> Launchpad bug 203158 in pulseaudio "libsdl1.2debian-pulseaudio must be installed as default by libsdl1.2debian" [Undecided,Invalid] https://launchpad.net/bugs/203158
=== noodles785 is now known as noodles775
=== Tonio__ is now known as Tonio_
=== oojah_ is now known as oojah
[11:16] <asac> persia: do you know if with source format 3.0 there is an option to say: "dont even try to create a diff when building sources"?
[11:16] <asac> like debuild -S --ignore-diff
[11:16] <asac> ;)
[11:16] <asac> that would give me an incentive to use it for big packages ;)
[11:16] <asac> rather than embedded tarball
[11:18] <persia> asac: I don't think there is such an option, but I'm not 100% sure.  Someone more familiar with format 3.0 may be able to answer better.
[11:21] <asac> if it wouldnt be perl i would even feel to just implement it ;)
[11:22] <asac> now it needs a few more days of sleep before i can convince myself looking seriously
[11:22] <asac> ;)
[11:24] <persia> asac: dpkg always appreciates more love :)
[11:26] <c_korn> hello. can someone please check if this sync request is correct ? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/533746 requestsync crashed but it created the bug report.
[11:26] <ubottu> Launchpad bug 533746 in scilab "Sync scilab 5.2.1-4 (universe) from Debian unstable (main)" [Undecided,New]
[11:27] <ogra> asac, you can convince yourself to look serious ?
[11:27]  * ogra wishes he could do that sometimes ... but i always look silly
[11:30] <asac> lol
[11:38] <persia> c_korn: Looks good to me.  Please add a note that this is expected to fix a FTBFS on <list of architectures> in the description.
[11:42] <c_korn> persia: done, thanks.
[12:23] <persia> jpds: The ubumirror crontab suggests running as the ubumirror user, but the ubumirror package doesn't create such a user.  Is this a bug, or a design feature to make it not work for some folk?
[12:50] <stefanlsd> There is a FFE that was ack'd thats a sync from debian. Is there a process to sync this, or can i download the debian version and just upload it?
[12:50] <persia> stefanlsd: Subscribe the archive-admins
[12:51] <persia> (same as for any sync)
[12:51] <stefanlsd> persia: thx
[13:02] <jpds> persia: Design.
[13:03] <persia> jpds: Then I won't fix it :)  Thanks.
[13:03] <jpds> persia: Most mirrors use a ubuntu/ftpadm/mirror user.
[13:04] <persia> Makes sense.  And reasonable to assume some intelligence on the part of anyone mirroring large chunks of stuff.
=== asac_ is now known as asac
[13:43] <mok0> james_w: ping
[14:04] <Laney> why did my ubuntu-dev-tools lose credentials?
[14:05] <Laney> ffs
[14:05] <Laney> I need to debug these lockups
=== mathiaz_ is now known as mathiaz
[14:19] <_Andrew> Anyone know how I create a menu item where it opens a web page under the default browser?
[14:20]  * persia thought there was a special format for that in .desktop files
[14:20] <Laney> Is that part of the contract of x-www-browser?
[14:21] <geser> what about xdg-open?
[14:21] <persia> _Andrew: yr Type=Link and URL=...
[14:21] <persia> _Andrew: If that doesn't work, Exec=sensible-browser ${URL}
[14:21] <ogra> or xdg-open ${URL} ;)
[14:21] <persia> http://standards.freedesktop.org/desktop-entry-spec/latest/index.html
[14:22]  * persia has the debian-way hardcoded, and the XDG-way is a continuous learning process
[14:24] <_Andrew> Thanks
[15:20] <wzssyqa> http://paste.ubuntu.com/391821/
[15:21] <wzssyqa> it will compile twice,why?
[15:22] <randomaction> wzssyqa: because clean depends on build-stamp?
[15:22] <wzssyqa> randomaction: o,what should i do?
[15:23] <randomaction> try removing this dependency
[15:23] <wzssyqa> randomaction: i will try
[15:26] <wzssyqa> randomaction: for this file,whit obj will be exesced first?
[15:26] <randomaction> obj?
[15:27] <wzssyqa> clean: etc
[15:27] <persia> wzssyqa: "target" or "rule"
[15:28] <wzssyqa> persia: and now,for http://paste.ubuntu.com/391821/ this file?
[15:28] <randomaction> it depends on how you call it; "debian/rules TARGET" will run TARGET
[15:28] <persia> wzssyqa: What are you asking, precisely?
[15:29] <wzssyqa> randomaction: dpkg-buildpackage -rfakeroot i just run it
[15:29] <wzssyqa> randomaction: then ,which one?
[15:29] <persia> wzssyqa: You'd have to check the source of dpkg-buildpackage to see what it does, but it oughtn't matter.  Try to make each rule do as described at http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[15:31] <randomaction> wzssyqa: see "man dpkg-buildpackage", points 3 and 5
[15:31] <wzssyqa> randomaction: o,thx
[15:32] <randomaction> and I agree with persia: there are certain semantics to these targets
=== yofel_ is now known as yofel
[17:31] <ScottL_> I am trying to update the ubuntustudio-theme package but I'm concerned about using the correct methodology
[17:32] <ScottL_> i'm trying to add a plymouth theme to it
[17:32] <ScottL_> my concern lies with the versioning of the ubuntustudio-theme package
[17:32] <ScottL_> currently it is ubuntustudio-theme-0.73
[17:33] <ScottL_> when I add the plymouth theme, should I leave the source directory as 0.37 and run debuild -S which should give me a diff.gz file or
[17:34] <ScottL_> should I almost treat it as a new package and rename the source folder as 0.83
[17:34] <ScottL_> this is for submitting for a UI Freeze exception to add the plymouth theme
[17:35] <ScottL_> i've backported and packaged for new applications but never updated a package before
[17:40] <randomaction> if this is an Ubuntu-specific native package, you should just increase version number in changelog
[17:40] <randomaction> debuild will rename directory for you
[17:43] <randomaction> and there should be no .diff.gz at all
[17:48] <ScottL_> randomaction: thanks, you answered before I could rewrite the questions in a more "lucid" way - get it, lucid?  hahaha
[17:48] <ScottL_> randomaction: jocularity aside, thanks for the answer, i've been worried about this since last night because I had already changed the version number in the changelog but was concerned about the folder name with version name
[17:49] <randomaction> you're welcome :)
=== jono_ is now known as jono
=== mcasadevall is now known as NCommander
[19:11] <christoph_debian> hm #535274 isn't complete but needs some subscription of relevant persons?
[19:12] <BlackZ> bug #535274
[19:12] <ubottu> Launchpad bug 535274 in cl-irc "Sync cl-irc 1:0.8.1-dfsg-3.1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/535274
[19:16] <BlackZ> chrisccoulson: why isn't the message signed?
[19:16] <BlackZ> christoph_debian: why isn't the message signed?
[19:16] <BlackZ> chrisccoulson: sorry, tab mistake
[19:16] <chrisccoulson> heh ;)
[19:16] <christoph_debian> BlackZ: because I have hard trouble getting that bug through in any way
[19:17] <BlackZ> and * Update for flexistream in unstable (Closes: #567812) <- you can use (LP: #567812) instead.
[19:17] <BlackZ> however it should be signed
[19:18] <christoph_debian> that's what is in debian do I really need an extra upload for ubuntu?
[19:18] <christoph_debian> syncing has always worked
[19:19] <christoph_debian> #567812 is a debian bug not a ubuntu one
[19:19] <BlackZ> ah, then it's ok christoph_debian
[19:21] <geser> BlackZ: what you mean with "signed"?
[19:22] <BlackZ> geser: signed with PGP
[19:25] <BlackZ> christoph_debian: have you check if the package build?
[19:27] <BlackZ> builds*
[19:32] <christoph_debian> BlackZ: jep I've tested it
[19:32] <randomaction> christoph_debian: the bug is OK
[19:33] <christoph_debian> randomaction: jep archive sponsors are nos subscribed as well, however not sure if that was a late result of my requestsync call or of someone's action here in the channel
[19:34] <randomaction> a sponsor will look at it, ack it and subscribe ubuntu-archive
[19:35] <geser> BlackZ: if a bug is filed directly in LP (or via the LP API) there is no signing necessary. Signing is only needed for the e-mail interface
[19:35] <christoph_debian> jep (not the first time I request a sync but the first time requestsync dies with horrible error messages)
[19:36] <geser> a HTTP 412 error? known problem and not only requestsync is affected
[19:36] <randomaction> when it crashes you need to subscribe u-u-s (which geser did for you in this case)
[19:37] <christoph_debian> first it failed because I had a outdated system clock ...
[19:38] <christoph_debian> and then the 412
[19:38] <christoph_debian> :)
=== funkyHat is now known as Sevvvveas
=== Sevvvveas is now known as funkyHat
=== mcasadevall is now known as NCommander
[23:29] <Linux000> Hello, I have a patch for an upstream project that I would like to submit and was wondering how/where to post it?
[23:39] <vorian> Linux000: launchpad.net
[23:40] <vorian> you should be able to find the appropriate package, see if it has a bug your patch fixes, post it to that bug.  If it doesn't have a bug, open a new one and attach your patch
[23:52] <Linux000> vorian: Thanks
[23:52] <vorian> np
[23:52] <vorian> when you submit the patch, make sure to subscribe (not assign) universe-sponsors to the bug
[23:53] <vorian> Linux000: that way someone will look at it
[23:53] <Linux000> Will do
[23:53] <vorian> fantastic
[23:59] <Linux000> the plot thickens, the source isn't in Debian format, hmm
[23:59] <vorian> it doesn't have to be