[00:08] <ScottK> jdong: I just did my first Debian backport.
[00:08] <ScottK> ;-)
[00:10] <jdong> lol
[00:25]  * bobbo is about to go insane at dh_desktop
[00:26] <bobbo> where should the .desktop file be when you are calling dh_desktop from debian/rules?
[00:27] <ScottK> It should be wherever you tell debian/rules to find it.
[00:27] <bobbo> ScottK; ah! I was just running it without any args
[00:27] <bobbo> and it wasnt doing anything
[00:28] <ScottK> bobbo: In general man dh_* will have some useful information for you when you run into such problems again.
[00:28] <bobbo> ScottK; legend thanks
[00:29] <persia> bobbo: dh_desktop doesn't install the .desktop files: you need to install them independently.
[00:30] <bobbo> persia; so dh_install the desktop file to usr/share/applications then run dh_desktop?
[00:30] <persia> bobbo: Exactly
[00:31] <bobbo> persia; thankyou sooo much :)
[00:46] <bddebian> Heya gang
[00:48] <geser> Hi bddebian
[00:50] <bddebian> Heya geser
[01:00] <HighNo> persia: hm, how do I include patches in a debhelper style package that has no patches yet?
[01:01] <persia> HighNo: Firstly, best to ask questions generally, rather than to specific people, just to speed response.  Secondly, if you're sure there are no patches (based on lsdiff -z foo.dsc), you get to pick a patch system.  I recommend checking other packages by the same maintainer to select one most likely to be adopted by Debian.
[01:02] <emgent> hello people
[01:03] <bddebian> Hi emgent
[01:09] <HighNo> hm, what would be the ubuntu package version of glotski_0.2-5build1 ?
[01:10] <StevenK>  glotski_0.2-5ubuntu1
[01:10] <HighNo> thx
[01:14] <bddebian> Upstream version is 0.2 most likely Debian Revision 5 the build1 is the "Ubuntu release"  Meaning it was rebuilt probably for some build-dep transition
[01:40] <HighNo> ok, I did at least fix 4 packages, have done absolutely nothing regarding household and did not learn for upcoming exam. I need a little cheer up before I go to bed. :-)
[01:41] <persia> HighNo: There's still plenty of time tomorrow :)
[01:42] <bddebian> heh
[01:47] <HighNo> persia: great!
[01:50] <HighNo> Can anyone please rationally explain why we all are doing this?
[01:50] <HighNo> :-)
[01:50] <bddebian> Nope
[01:50] <persia> HighNo: Define "this" :)
[01:51] <bddebian> persia: How's my attal? ;-)
[01:51] <persia> bddebian: nemiver hasn't given me the answers I want yet :(
[01:52] <bddebian> nemiver?
[01:52] <pochu> #define this
[01:52] <pochu> ?
[01:52] <HighNo> persia: today I did nothing I ought to do, learned about gtk1.2 to gtk2 transitions, fixed 4 packages doing that, dumped 4 others for being too complex and now I am tired... <= this :-/
[01:52] <persia> bddebian: My gdb foo isn't very strong, and I still rely on GUI
[01:53] <bddebian> persia: Ah :-)
[01:53] <persia> HighNo: Ah.  There are several papers written about that.  Most experts seem to agree it has something to do with either the appreciation others give, or as part of participation in a gift economy as a quid-pro-quo for using free software.
[01:56] <HighNo> persia: I guess it's just love - there's nothing rational about it... don't answer to this one, let me keep this love thing in my mind, makes me feel warm about my work today :-)
[01:56] <persia> HighNo: That works too (and similarly, there are several papers written about that) :)
[01:56] <HighNo> hehe
[01:58] <HighNo> I read about that 5-a-day thing and I liked the idea though I know I am too slow at the moment to get 5 done at a reasonable time. I wish I could help more (and would get money for it - so I could live from just doing this :-) )
[02:01] <HighNo> Ok, I'll leave now. I have to study so I'll pass my exam - and I could do some other paid work too... gn8
[02:02] <persia> HighNo: Thanks for helping with the transition.  Good luck on your exam.
[02:03] <HighNo> persia: if I get bored studying I'll look for some more packages to help with...
[02:03] <HighNo> bye
[02:13] <frenchy> I'm an Ubuntu user but I maintain a package in Debian so that it can be synced into Ubuntu ... it was the easiest way to get started.  The issue is, I never use Debian, because it's harder to get stuff working and I'm lazy.  Do I have to become a MOTU before I'm allowed to upload to Ubuntu?  Is there any other way?
[02:16] <pochu> you can use the sponsors queue, but no, there's no other way for you to upload directly without sponsoring
[02:18] <frenchy> pochu: Thanks, I'm not a DD and I use sponser/uploader for Debian already.  I didn't know that there was an equivalent for Ubuntu.
[02:18] <frenchy> !sponser
[02:18] <ubotu> Sorry, I don't know anything about sponser - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[02:19] <|rojanu|> here https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/ubuntu-upload.html you can read
[02:19] <frenchy> |rojanu|: Ta
[02:19] <ScottK> persia: Would you please have a look at Bug #194509 and give your opinion on if this is a good then and if you think it ought to have an FFe?
[02:19] <ubotu> Launchpad bug 194509 in jabref "should include icedtea-java7-jre as an alternative dependency to allow inclusion and building into purely free distribution such as gobuntu" [Undecided,Fix committed] https://launchpad.net/bugs/194509
[02:21] <pochu> frenchy: https://wiki.ubuntu.com/SponsorshipProcess
[02:21] <frenchy> |rojanu|: There's no mention of the sponser queue on that page.  Is it just a case of uploading
[02:21] <frenchy> pochu: Ta
[02:21] <pochu> anytime
[02:27] <persia> ScottK: I'm not 100% happy with the debdiff (no maintainer mangling, build-dep on icedtea-java7-jdk should be optional), but I can't see how it would affect Feature Freeze.
[02:27] <ScottK> persia: Thanks.  Would you please comment on the bug.
[02:28] <persia> ScottK:  Sure: leaving standard sponsor rejection.  Any suggestions re: the ubuntu-motu@ thread?
[02:29] <ScottK> I'll take care of that.
[02:29] <persia> Thanks.
[02:33] <persia> Bah.  Easier to just fix and upload.
[02:44] <ScottK> persia: My next Java question is do we want Iced Tea 1.6? Bug #195300
[02:44] <ubotu> Launchpad bug 195300 in icedtea-java7 "IcedTea 1.6 is now available" [Wishlist,Incomplete] https://launchpad.net/bugs/195300
[02:45] <persia> I think we want OpenJDK, but I don't know the status thereof.  Better to ask slytherin, doko, or man-di
[02:47] <ScottK> OK.  Hopefully you just did.
[02:47] <ScottK> THanks.
[05:30] <jdong> http://fedoraproject.org/wiki/FWN/Issue121?action=show&redirect=FWN%2FLatestIssue#head-ceb67569d30fe439a8b6aa24529b4b1a28898b3a
[05:30] <jdong> I thought that was an interesting discussion
[05:31] <jdong> the fallout when Fedora decided to push out a non-backports-compatible unison update to its stable release
[05:31] <jdong> s/backports/backwards/
[05:31] <Fujitsu> Hahahahaha.
[05:31] <Fujitsu> Fools.
[05:31] <persia> jdong: I've been fiddling with the new version.  Which do you think we want for hardy?
[05:32] <jdong> persia: I don't know enough about unison to comment specifically, but my gut feeling would be the newer
[05:32] <persia> jdong: It's incompatible, which is why it's not been updated.
[05:32] <jdong> persia: given that post-release providing users with a newer unison would be a bigger pain than now while Hardy users are limited.
[05:33] <jdong> it does seem like Unison likes to break compatibility every other day ;-)
[05:33] <persia> Hmm.  I and suppose with Hardy LTS, it's the best time to break it.  OK.  I'll finish up, and push to motu-release soon then.
[05:33] <Fujitsu> I'd really like a new stable rdiff-backup for Hardy :(
[05:33] <persia> No, they have a new versioning scheme: X.Y.Z, where incompatibiilities only happen for increasing Y.
[05:34] <jdong> persia: I hope they don't increase Y frequently?
[05:34] <jdong> Else it's kinda like "ffmpeg has a new versioning scheme YYYYMMDD where incompatibilities only happen for increasing D" :D
[05:35] <persia> jdong: Well, at least they have Z now.  Used to just be X.Y, so everything was always incompatible.
[05:35] <persia> (or maybe 2/3  but there was no easy way to tell)
[05:37] <ScottK> Is unison being actively developed again?  Last I looked it was pretty dead.
[05:39] <persia> Upstream isn't pushing development anymore (the research project is finished), but patches get accepted, and there is still a bit of use.
[05:39] <persia> http://tech.groups.yahoo.com/group/unison-announce/ is probably a good indication of update frequency.
[05:39] <jdong> I think I've been using git/bzr as my "unison" for a while...
[05:40] <ScottK> Unison was developed at the university that I attended (long after I left of course).
[05:40] <persia> jdong: You clearly don't have high data turnover needs.  Start playing with gigabytes of data that gets completely replaced one a month or so, and you'll want something else.
[05:40] <jdong> persia: yeah, you're right, my needs have been small scale so far
[05:41] <jdong> I totally see the merit of unison
[05:41] <persia> (mind you, unison still had the bug that it hangs for >15,000 files in a directory, last I checked)
[05:42] <ScottK> Kind of knocks it our for maildir syncs then.
[05:43] <persia> ScottK: Do you run hot-hot redundant mailservers with dual active copies of maildirs?  If so, you might have a great test case to fix the bug.
[05:43] <ScottK> persia: I don't.  I use maildir on my workstation and periodically rsync.
[05:43] <ScottK> our/out btw.
[05:44] <ScottK> jdong: I just queued up postfix 2.5.1 backports for Gutsy/Feisty/Edgy/Dapper (last 3 were source backports).
[05:44] <persia> Ah.  Yes, that changes the meaning considerably :)
[05:45] <jdong> ScottK: cool
[05:46] <jdong> ScottK: whenever you feel bold enough, I've got dscs for the firefox+xulrunner backports ready to go
[05:46] <ScottK> Actually I last used unison when I was still on Windows.
[05:48] <ScottK> jdong: Not tonight.  I was up until almost 4AM last night trying to understand why libpythonize0 was trying to dlopen libpython2.5.so and not libpython2.5.so.1 without success.
[05:49] <ScottK> I can't stay up so late tonight.
[05:49] <jdong> ScottK: get your rest :)
[05:49] <ScottK> I got as far as figuring out it was probably something libtool related and gave up.
[05:50] <ScottK> The good news is our fearless release manager has taken up the cause and assigned the bug to himself.
[05:51] <jdong> do you guys have any idea if there exists a disk buffer type piping utility for Linux?
[05:52] <jdong> I'm thinking something like "expensive_input_resource | buffer cache_file | inexpensive_slow_output"
[05:53] <jdong> i.e. something that allows the thing before the pipe to be buffered/queued to a filesystem backed cache, so that it can be slowly slurped up by some other pipe
[05:54] <jdong> I would benefit from something like that for some media encoding that I'm doing where a 80GB input video gets compressed down to 8-10GB and I'd rather not require so much free diskspace; the process runs like 0.75x realtime so in reality I should only need around 20% the storage
[06:00] <persia> jdong: Filesystem-backed cache?  That's just using the storage, no?  If you want lower-latency storage, /dev/shm mounted as tmpfs is the common tool, perhaps pushing swap if needed.
[06:01] <jdong> persia: right, it's using storage but only the amount of storage necessary to "pick up the slack"
[06:01] <jdong> i.e. allow left-hand-side to output as fast as it can, and right-hand-side to intake as slow as it can
[06:02] <persia> jdong: Ah.  That's harder.  All the techniques I know generally push to RAM, figuring it's the vm's responsibility to decide when/if it should be on disk.
[06:03] <jdong> persia: I'm thinking about implementing a circular buffer on-disk using sparse files....
[06:04] <jdong> just need to figure out how to "punch sparse holes" arbitrarily in a file
[06:07] <persia> jdong: Just be careful with that sort of game.  More and more people run solid state these days (if only with an IDE->CF converter) and may not want the on-disk cache.  Also, remember that the kernel cache mechanism has a somewhat lazy write, so you may end up not having the contents in the file when it actually commits to the physical disk.
[06:07] <persia> (and bypassing the kernel file cache makes everything much slower...)
[06:32] <Hobbsee> \sh_away: ping
[06:54]  * superm1 wonders if emdebian will work properly on an ubuntu box.  Here we go :)
[07:04] <Gunner_Sr> I am trying to get the following package - "libapache2-mod-wsgi" does anyone know where I can get it from for Ubuntu?
[07:06] <persia> Gunner_Sr: apt-get source (or aptitude download) ought work for hardy.  Otherwise, consider the LP page.
[07:08] <Gunner_Sr> persia: I am on gusty..
[07:08] <warp10> Good morning
[07:09] <persia> Gunner_Sr: In that case, you'll need to download from LP.  https://launchpad.net/ubuntu/+source/...
[07:10] <Gunner_Sr> persia: does it need lib6c 2.7 or higher?
[07:11] <persia> Gunner_Sr: You really don't want to use the binary package.  You can try backporting the source.
[07:11] <Gunner_Sr> persia: ah, ok
[07:28] <Gunner_Sr> persia: how do I combine the diff with the main tar?
[07:33] <persia> Gunner_Sr: dpkg-source -x foo.dsc
[07:37] <Gunner_Sr> persia: thanks
[07:38] <gmatht> Is there any documentation on "control.modules.in" anywhere?
[07:45] <Gunner_Sr> persia: what is the best way to install the main tar and then combine the dsc?
[07:46] <persia> Gunner_Sr: What are you trying to accomplish?
[07:47] <persia> gmatht: It can be used a few different ways: there is typically something in debian/rules that generates debian/control.
[07:49] <Gunner_Sr> I want to install libapache2-mod-wsgi on a server to support multiple sites on trac.
[07:49] <Gunner_Sr> persia: I want to install libapache2-mod-wsgi on a server to support multiple sites on trac.
[07:51] <persia> Gunner_Sr: OK (and no need to repeat yourself).  Steps are 1) download the source (all three files), 2) unpack the source, 3) build a binary, 4) install a binary.  Steps 1 & 4 are typically self-explanatory.
[07:51] <Iulian> Can someone please check my new debdiff for bug #196871 before submitting it to the report - http://paste.ubuntu.com/5183/ ?
[07:51] <ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Wishlist,In progress] https://launchpad.net/bugs/196871
[07:51] <gmatht> Well, I am trying to build a kernel module compcache which is automatically named compcache-_KVER_
[07:51] <persia> Step 2 is optional, depending on your build system.  If you are using something like pbuilder, prevu, sbuild, etc. you ought be able to call that directly on the .dsc.  If not, dpkg-source -x foo.dsc is likely the easiest.
[07:52] <gmatht> However control.modules.in just seems to be ignored when I do debuild -S or debuild -b.
[07:53] <persia> Step 3 is the aforementioned call to any of several utilities, or in their absence, you can try `debuild -b` from the unpacked source directory.  The first time, it will probably complain that you need to install the build dependencies.
[07:54] <persia> Iulian: Note that if you choose to bump the standards version, you are expected to get the package lintian and linda clean for that standards version.  Also, it might be worth checking to see if the debian/menu file needs a matching update, even if you decide not to bump the standards version.
[07:55] <gmatht> I am using the default deb_helper script and also looking at the script at: http://permalink.gmane.org/gmane.linux.debian.packages.voip.devel/183
[07:55] <persia> Iulian: Other than that, it looks sane, although I don't tend to be that verbose in changelogs (given that it uses up disk space for every user installing the package).  For this, I'd just add three lines, one about the .desktop file, one about the Homepage entry, and (optionally), one about the standards version.
[07:56] <Iulian> persia: I don't get any warnings from lintian and linda. I will take a look at debian/menu file to see what I can do there.
[07:57] <persia> gmatht: The kernel is a somewhat special case.  While someone may answer here, this is the quietest time of the day on the quietest day of the week for this channel.  You might also want to try in #ubuntu-kernel, although I don't know if they are active at this time.
[07:57] <Iulian> persia: Ok, I will remove some lines from changelog.
[07:57] <gmatht> Ah I see. Yes, there was a dh_gencontrol buried in the rules. I'll have a look at that. Thanks.
[07:57] <persia> Iulian: check with all the flags (e.g. lintian -iIv and linda -v -f long -t E,I,W,X)* some things can slip by (and it's not important to update the standards-version, just to make sure it is correct).
[07:58] <Iulian> persia: Ok, thanks a lot.
[07:58] <Amaranth> persia: If you want to be verbose about a change that's what revision control is for :)
[07:58] <Gunner_Sr> persia: thanks, I will do that.
[07:58] <Amaranth> 2 page commit messages ftw
[08:01] <persia> Amaranth: You have my complete agreement.  I like upstream changelogs to summarise the commit logs to indicate things interesting to users, casual developers, bug hunters, and distribution maintainers.  I like distribution changelogs to summaries the upstream changelogs to indicate changes significant for end-users, policy updates, or significant packaging changes.
[08:04] <Iulian> persia: This is what I get from lintian and linda now: http://paste.ubuntu.com/5184/
[08:04] <Iulian> persia: And about the debian/menu file I think it's ok.
[08:05] <persia> Iulian: You're probably safe for the standards-version update then (although it ultimately depends on your sponsor, and how familiar they are with policy)
[08:07] <Iulian> persia: Btw, in debian/menu file I have: longtitle="High-speed shoot 'em up game". Should it start with a verb?
[08:08] <Iulian> Or it's necessary only in .desktop file?
[08:11] <persia> Iulian: I don't see any specific guideline.  Definition seems to be "For people that like descriptive titles (about one line) It is probably best to include this in your menu entries, while the window-managers don't (by default) put it in the menus.  That way, people who want descriptive titles can turn them on, but others don't need to use them."
[08:12] <persia> Iulian: Also, isn't there supposed to be a Version=1.0 in the .desktop file?
[08:13] <persia> Iulian: For extra points, consider migrating the entire package to dh_install instead of still using dh_movefiles in a couple places.
[08:14] <persia> (alternately, you may want to install the .desktop file with dh_movefiles)
[08:16] <Iulian> persia: Didn't know about that, I've added Version=1.0 right now.
[08:17] <Iulian> persia: I'll take a look in debian/rules file to see what I can change. Although I'm not so sure I can do it.
[08:18] <persia> Iulian: OK.  The current form works, and I doubt anyone will force you to learn dh_movefiles, but 1) it's good practice to use the installation systems already in place in a package, and 2) packages are encouraged to use dh_install rather than dh_movefiles.
[08:19] <Iulian> persia: To be honest, I don't know anything about dh_movefiles. Where should I change dh_install with dh_movefiles?
[08:21] <persia> Iulian: It's not quite that simple.  Both those programs take care of installing files into the appropriate package directories for building the binary packages, but they do it in different ways.  The current rules file calls dh_movefiles.  The manpages are your best guidance.
[08:22] <Iulian> persia: Ok, will go to read the manpage then.
[08:28] <persia> Iulian: Good luck.  If you get stuck, skip it for next time, and look for another bug.
[08:29] <Iulian> persia: Thanks, I have three files in debian/rules - dh_movefiles -p zblast-svgalib; zblast-x11 and zblast-data
[08:29] <gmatht> Is it bad to use `uname -r` in a source deb?
[08:30] <Iulian> persia: Should I remove them? if yes where I have to call dh_install?
[08:30] <persia> gmatht: Yes.  You care about the kernel you intend to compile against, rather than the kernel the buildd happens to be running.
[08:30] <persia> Iulian: If you replace the dh_movefiles calls with dh_install calls, you also need to update the other files in debian/ to be changed.
[08:31] <persia> More specifically, you'd need to change the debian/*.files files to debian/*.install files, and update the syntax to the new format.  You likely want to include your .desktop file while you do so.
[08:32] <persia> The simpler way is just to ask for the .desktop file to be installed in the relevant debian/package.files file, rather than directly in rules (leaving dh_movefiles).
[08:34] <Iulian> persia: Ok, will take care of that right now.
[08:43] <Iulian> persia: One more thing, do I have to include the .desktop file in all debian/*.install files? What is the command for that?
[08:43] <gmatht> Is there a standard way of over-riding uname. Fiddle with path? Just patch the upstream Makefiles?
[08:43] <persia> Iulian: I generally use vi, and no, only for the package in which you want to install the .desktop file.
[08:44] <Iulian> persia: I have three files: zblast-data.files; zblast-x11.files and zblast-svgalib.files
[08:44] <persia> gmatht: That's the sort of specific question you want to ask in #ubuntu-kernel (sorry)
[08:45] <persia> Iulian: OK.  Do you understand what they do?  If so, which one do you want to edit to install your .desktop file?
[08:46] <Iulian> persia: Well, all .files are install one specific file
[08:47] <Iulian> persia: Maybe zblast-data.files ? because the other two files are installing the man pages.
[08:47] <persia> Iulian: Only one file each?  That's not a lot of extra files.
[08:47] <Iulian> persia: Yes.
[08:48] <persia> Hmm.  Sounds like this could use a bit of work.  manpages are usually installed with dh_installman these days.
[08:48] <persia> Given the complexity, I'll suggest you not try to migrate to dh_install just yet.  In which package do you want the .desktop file (or do you want all three?)
[08:49] <Iulian> persia: I don't know exactly, maybe the data one because like I said the other two file are installing the manpage.
[08:50] <Iulian> persia: the data files contains only this line: usr/share/games/zblast
[08:50] <persia> Iulian: OK.  Let's take a step back.  There are a few different binary packages for this source package.  Which one seems like the right choice for the .desktop file?
[08:50] <Iulian> persia: Let me see.
[08:52] <Iulian> persia: Maybe zblast-data
[08:53] <persia> Iulian: You say "Maybe", so I'll ask "Why?"
[08:54] <Iulian> persia: I was looking in debian/control and svgalib and x11 are depending on zblast-data. Anyway I don't think it has something to do with the .desktop file
[08:55] <Iulian> persia: Uh, I'm a bit confused about it.
[08:55] <persia> Iulian: Does the .desktop file work for both zblast-x11 and zblast-svgalib?
[08:56] <Iulian> persia: I don't know exactly, where should I look?
[08:57] <persia> Iulian: Well, what does the ,desktop file do?
[08:57] <Iulian> persia: Creating a desktop file in the menus.
[08:58] <persia> Iulian: Right.  It creates a menu entry.  Now, what happens when the user selects the menu entry?
[08:59] <Iulian> persia: Uhmm, the .desktop file should have something from where it can be called.
[09:01] <persia> OK, and which entry in the .desktop file specifies that?
[09:01] <Iulian> persia: Exec
[09:02] <persia> Exactly.  Now, if there are two packages (-x11 and -svgalib) for a program, how can we determine if they can share a single .desktop entry?
[09:04] <Iulian> persia: Unfortunately, I don't know to answer that question.
[09:05] <Iulian> Uhmm
[09:05] <persia> OK.  We've determined that a .desktop file specifies what program the menu system should call in the Exec= key, right?  So, if this file needs to work for two packages, what must be true for those two packages?
[09:08] <Iulian> persia: I don't have a clue. What about the Terminal=false from the .desktop file?
[09:09] <Iulian> Ahh, it has nothing to do with that.
[09:10] <persia> OK.  In order for two programs to have one .desktop file, the menu system needs to be able to call both of them in the same manner, so they must both provide an executable file that matches the Exec= string in the .desktop file.
[09:11] <persia> This can be a standard conflicting file (with Conflicts:), a defined alternative, or a shell script in the common package that selects one of them at runtime.  The mechanism doesn't really matter.
[09:12] <persia> Iulian: Does that make sense?
[09:13] <Iulian> persia: Yeah... but I'm wondering where to provide the executable file for both programs.
[09:14] <persia> Iulian: OK.  So, getting back to specifics, if you look at the zblast-* packages, do they need different Exec= keys, or can they use the same one?  (dpkg --contents may help, as may inspection of the maintainer scripts)
[09:17] <Iulian> persia: I don't have the deb package yet to use dpkg --contents. Is there another way to look for it?
[09:17] <persia> You can examine the upstream build system, but you might just want to download the previously built binary packages with `aptitude download zblast-x11` to investigate.
[09:18] <persia> (or just run a quick build locally, and investigate)
[09:20] <Iulian> persia: I don't see nothing there which can be useful.
[09:20] <Iulian> I'm a bit confused, sorry.
[09:21] <persia> Iulian: OK.  Let's ask this differently.  If a user installs the zblast-x11 package, how should they launch zblast?
[09:21] <Iulian> persia: They should have an entry in the menus, because that's why we're making a .desktop file
[09:22] <persia> Iulian: OK.  How should they run it today, before there is an entry in the menus?
[09:22] <Iulian> persia: From terminal.
[09:22] <RainCT> Morning
[09:22] <persia> Iulian: OK.  And what command should they use?
[09:23] <Iulian> persia: Ahhh, gotcha!
[09:23] <Iulian> persia: Wait a second please
[09:23] <persia> :)
[09:23] <Iulian> zblast-x11
[09:23] <Iulian> Right?
[09:23] <minghua> I'd like a second pair of eyes to look at the sync request bug #197562 to make sure everything is correct, since I haven't done this for quite a while.
[09:23] <ubotu> Launchpad bug 197562 in xfonts-wqy "Please sync xfonts-wqy 0.9.9-3 from Debian unstable main to hardy universe" [Undecided,New] https://launchpad.net/bugs/197562
[09:24] <persia> Iulian: I've no idea: I've never installed or used the package.
[09:24] <Iulian> persia: In this case I will go and install it and check.
[09:24] <persia> minghua: Looks safe to me.
[09:25] <persia> Iulian: Just to let you know, so you can queue your downloads, my next question would be "How does the user launch zblast-svgalib?".
[09:25] <minghua> persia: Thanks!
[09:27] <Iulian> persia: Hmm, weird - svgalib: Cannot get I/O permissions.
[09:29] <Iulian> persia: Found it, xzb
[09:29] <Iulian> persia: They should run xzb from terminal in order to play the game.
[09:29] <persia> Iulian: For both packages?
[09:30] <Iulian> Humm
[09:31] <Iulian> persia: Not really, only xzb, so...
[09:31] <persia> Iulian: You've confused me.  Is `xzb` for -x11 or for -svgalib?
[09:32] <Iulian> x11
[09:32] <persia> OK.  What does -svgalib use?
[09:33] <Iulian> persia: In the description it says there are two versions, -x11 and -svgalib and this package is using the -x11 one.
[09:34] <persia> Iulian: Aren't there two different binary packages, one for each variant?
[09:34] <Iulian> persia: Yes
[09:35] <Iulian> persia: There are two in debian/control - -x11 and -svgalib
[09:35] <persia> OK.  So, the user should start the program contained in the zblast-x11 package by calling `xzb`.  How should the user start the program contained in the zblast-svgalib package?
[09:37] <Iulian> persia: The same command, it doesn't mention in the description of the zblast-svgalib package what cmd you have to use.
[09:39] <Iulian> persia: So, I think both packages are using the same exec.
[09:40] <persia> Iulian: In that case, can they share the same .desktop file?
[09:41] <Iulian> persia: Yes, why not? They don't mention anything about two different commands.
[09:42] <persia> Iulian: So, if both executable packages can share the same .desktop file, in which of the three binary packages produced by the source should the .desktop file be installed?
[09:43] <Iulian> persia: zblast-x11
[09:44] <persia> Iulian: How does that help users who install zblast-svgalib?
[09:46] <Iulian> persia: In the description they mention there are two versions but I couldn't find anything to run the second version (-svgalib). So I think -x11 should be the right one.
[09:47] <Iulian> Don't have a clue what zblast-svgalib is about.
[09:47] <Iulian> Or how to run it.
[09:47] <persia> Iulian: Now I'm confused.  I thought you said earlier that `xzb` would launch zblast-svgalib.
[09:48] <persia> Going back to look at that package, what does it install in /usr/bin ?
[09:49] <Iulian> persia: How do I check it?
[09:49]  * Iulian shrugs
[09:50] <persia> Iulian: You can either install the package, and use dpkg -L or you can use dpkg --contents on the binary .deb.
[09:51] <Iulian> persia: From dpkg --contents I get only the dirs.
[09:52] <persia> No files?  The package is empty?
[09:53] <Iulian> persia: No, it isn't. http://paste.ubuntu.com/5186/
[09:54] <persia> Iulian: That's the contents of zblast-x11.  Wasn't there a zblast-svga package?
[09:54] <persia> (this may be made more confusing because zblast-svgalib is only available for i386)
[09:55] <Iulian> persia: I've downloaded with `aptitude download zblast-x11`
[09:55] <Iulian> persia: I'm on i386
[09:55] <persia> Iulian: OK.  Now download with aptitude download zblast-svgalib
[09:56] <Iulian> persia: Here http://paste.ubuntu.com/5187/
[09:57] <persia> Iulian: Looking at those side-by-side, which are the executable files in each package?
[09:57] <persia> (skipping directories)
[09:58] <Iulian> persia: -x11 is using xzb and -svgalib xblast
[09:58] <persia> Iulian: OK.  So, if they are separate executables, can they share a single .desktop file?
[09:59] <Iulian> persia: I don't see any reason why they can't.
[09:59] <Iulian> persia: So, my answer is yes.
[09:59] <persia> Iulian: Let's review.  How does a .desktop file specify which program to run?
[10:00] <Iulian> persia: I'm so stupid.
[10:00] <Iulian> persia: From .desktop file. Exec=xzb
[10:00] <persia> Iulian: No.  Everyone has to learn it once :)
[10:00] <persia> OK.  So, if the .desktop file is calling xzb, does that work for both zblast-x11 and zblast-svgalib?
[10:01] <Iulian> persia: Yea, but I'm bothering you too much with my stupid questions. :)
[10:01] <Iulian> persia: No, they doesn't work
[10:02] <persia> Iulian: I think of it as you putting up with me refusing to supply an answer, and just asking questions back in answer to your questions :)
[10:02] <persia> OK.  So, in which package does the .desktop file with Exec=xzb need to be installed?
[10:02] <Iulian> In zblast-x11
[10:02] <persia> Why?
[10:03] <warp10> Anyone knows how frequently is http://people.ubuntu.com/~ubuntu-archive/NBS/ rebuilt? 6 hours, maybe?
[10:03] <persia> warp10: roughly 6 hours, but it gets stuck sometimes.  Complain on #ubuntu-devel if it hasn't been updated for a long time (but first check the archives to make sure).
[10:04] <Iulian> persia: Because of what I can see from dpkg --contents
[10:04] <Iulian> persia: If it was svgalib, it should have /usr/games/xzb too.
[10:05] <RainCT> can someone tell me what the pushd/popd is doing here please http://paste.ubuntu.com/5188/plain/?
[10:05] <persia> warp10: Also note that sometimes one NBS package will depend on another, which can confuse a transition.  Further, if a package has an alternate dependency, it will still show (but doesn't always need fixing).  Lastly, removals are manual, which can confuse the results.
[10:05] <Iulian> persia: I'm sorry, I will be back in 10 minutes.
[10:06] <persia> RainCT: Pushd adds a directory onto the stack, and sets the new working directory.  popd returns to the working directory.  The behaviour depends on the definition of . (and whether that is supposed to be make or shell)
[10:06] <warp10> persia: thank you. I will add that to the NBS wiki page. I added the other example, and the page is almost ready to be reviewed.
[10:06] <persia> Iulian: Right.  Good answer.  Please add the .desktop file there.  Thanks for working through the problem step-by-step.
[10:07] <RainCT> persia: I know pushd/popd, but don't understand what that line is for (it's make)... And, Ubuntu's buildd use bash?
[10:08] <RainCT> well, never mind, that isn't the problem anyway
[10:09] <persia> RainCT: No, they oughtn't use bash.  That's not make syntax, it's an embedded shell script.  Best solution is to rewrite in make, but rewriting to be dash-compatible works too.  It specifically changes from the working directory $(CURDIR) to the calling directory (anywhere, really) and then pops back to the working directory.
[10:10] <hellboy195> persia: 2012 is right. I simply can't read the calendar -.-
[10:11] <persia> hellboy195: Next step is to determine which Ubuntu releases will be supported for that event, and make sure the fix has been applied to all those releases.
[10:12] <RainCT> persia: thanks
[10:12] <hellboy195> persia: I suppose gutsy won't be supported until 2012 and every release since hardy will have that fix!?
[10:14] <persia> RainCT: For make syntax, just set a variable to be the results of the find.  Use that variable as a dependency of another rule, and set up a dynamic rule to process each of the directories with meinproc $(basename $@).  Be sure to also add the dynamic rule to .PHONY.
[10:15] <RainCT> Hey bobbo
[10:16] <bobbo> Hi RainCT
[10:17] <Iulian> persia: I'm back. I won't change dh_movefiles with dh_install so the files should be *.files. Now how should I add the .desktop file?
[10:17] <Iulian> persia: I should add it in zblast-x11.files right?
[10:17] <persia> Iulian: You've already read the dh_movefiles manpage?
[10:17] <persia> Yes.
[10:18] <persia> hellboy195: I think so (I haven't done the math).  Perhaps no SRU is required then :)
[10:18] <Iulian> persia: Yes, from what I understood is that dh_install is much better than dh_movefiles but I will leave it just like that for now.
[10:18] <hellboy195> persia: to make you happy I will double check ;)
[10:18] <persia> Iulian: No worries.  Changing the entire package to not use dh_movefiles is a larger project.
[10:19] <Iulian> persia: What is the syntax for adding the .desktop file to zblast-x11.files ?
[10:19] <warp10> persia (and all): https://wiki.ubuntu.com/MOTU/NBS is ready to be reviewed. Any comment will be greatly appreciated.
[10:19] <persia> hellboy195: No need.  I trust you (in the worst case, we can complain to you in 2012 if it is still broken)
[10:19]  * persia edits the NBS wiki page
[10:20] <hellboy195> persia: haha :)
[10:24] <persia> warp10: I've added a few minor grammar changes.  Larger items I saw include: no discussion of how illuminator FTBFS and no investigation of the libpetsc2.3.2 NBS effort.  It would be good to expand on these for the example.
[10:26] <Iulian> persia: Please see my last question (you missed it) :)
[10:26] <persia> Iulian: I've never used dh_movefiles.  Please check the manpage, and try a couple things.  (also, no need to repeat: I'm just slow often)
[10:27] <Iulian> persia: Okay, sorry. Anyway, you ROCK! Thanks for helping me.
[10:27]  * Iulian hugs persia
[10:29] <bobbo> RainCT; do you want the new debdiff for Bug #196870?
[10:29] <ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,Confirmed] https://launchpad.net/bugs/196870
[10:30] <RainCT> bobbo: have you fixed the description already?
[10:30] <bobbo> RainCT; i *knew* there was something i had forgotten :)
[10:34]  * RainCT wonders if there is a build server which Ubuntu developers could use somewhere :P
[10:35] <bobbo> RainCT would something like "A utility that wraps around pon and poff" be better?
[10:36] <RainCT> bobbo: I suggest "graphical wrapper around pon and poff" (or perhaps even remove the reference to "pon" and "poff" and explain what it actually does for the end user)
[10:36] <RAOF> RainCT: There was going to be/was/is the ubuntuwire servers that were build boxes for MOTU.
[10:37] <warp10> persia: regarding the FTFBS I'm adding a snippet from http://paste.ubuntu.com/5160/. About libpetsc, I didn't really understood what you would like to see there. Can you elaborate, please?
[10:37] <Iulian> Anyone knows how can I add a .desktop file to *.files ?
[10:39] <RainCT> RAOF: thanks, I'm asking in #ubuntuwire then :)
[10:39] <RainCT> Iulian: can you paste the content of a .files file somewhere?
[10:40] <RAOF> RainCT: Also, if you're after an AMD64 to test bitness problems, I have been known to issue shell accounts to one of my boxes.
[10:40] <Iulian> RainCT: This is the only line: "usr/games/xzb usr/share/man/man6/xzb.6"
[10:41] <bobbo> Is ubuntuwire down for anyone else?
[10:41] <persia> warp10: Well, in the text it mentions that the libpetsc2.3.2 package needs to be cleared before the libmpich1.0c2 can be completed.  There's no further mention of libpetsc2.3.2 or http://people.ubuntu.com/~ubuntu-archive/NBS/libpetsc2.3.2 (or the results of the investigation)
[10:41] <persia> bobbo: For everyone
[10:42] <bobbo> persia; ah thanks
[10:42] <RainCT> Iulian: I see. You have to copy the .desktop file into debian/tmp/usr/share/applications/ and then add " usr/share/applications/desktop_file_name.desktop" to the end of the line in the .files
[10:43]  * persia understands why dh_install is preferred over dh_movefiles: only one step
[10:43] <warp10> persia: ah, I understand now. Ok, I will provide something for that too. What about the libminc0 example? everything ok?
[10:43] <RainCT> persia: it only accepts stuff from inside debian/tmp
[10:43] <RainCT> persia: and it has to be placed in the right directory there
[10:43] <persia> warp10: Sure.  You've uploaded that candidate already?
[10:43] <RainCT> (at least that's what I understood from the manpage)
[10:43] <RAOF> RainCT: What, dh_install?
[10:44] <persia> RainCT: Which is handy for splitting packages, but annoying for installing extra files.
[10:44] <persia> RAOF: dh_movefiles
[10:44] <RainCT> RAOF: well, I'm just looking for some server where I didn't have to wait several hours for dependencies to download -.-
[10:44] <bobbo> RainCT; fixed description; http://bobbo.mooo.com/~bobbo/gpppon_0.2-4ubuntu1.debdiff
[10:44] <persia> Iulian: never mind.  $(INSTALL) is likely easier to read, if dh_movefiles is really that awkward.
[10:44] <RAOF> Ah, right.  I don't think I've touched a package using dh_movefiles, and I've certainly never deliberately used it :)
[10:45] <Iulian> RainCT: I've added $(INSTALL) debian/zblast.desktop /usr/share/applications in debian/rules and dh_desktop in binary-arch like you said yesterday
[10:45] <warp10> persia: I didn't yet, I will take care of it once I'm done with the wiki.
[10:45] <persia> warp10: Best hurry before someone else does it :)
[10:46] <RainCT> Iulian: that should work
[10:46] <Iulian> persia: Yes, so I don't have to add it in *.files file right?
[10:46] <persia> Iulian: Right.
[10:46] <Iulian> RainCT: Ok, making now a new debdiff.
[10:47] <warp10> persia: looks like not so much people likes NBS, so I'm not really scared for that :)
[10:47] <RainCT> Iulian: just to be sure, $(INSTALL) = dh_install?
[10:48] <Iulian> RainCT: Where can I check that?
[10:49] <RainCT> Iulian: there should be an INSTALL= somewhere at the top of debian/rules
[10:50]  * persia suspects $(INSTALL) to be /usr/bin/install
[10:51] <Iulian> RainCT: http://paste.ubuntu.com/5189/
[10:51] <Iulian> That's my debian/rules file.
[10:52] <RainCT> just to be sure, if a (beside this) bugfix release has "experimental support for CMake build system", it still doesn't need a FFe, or?
[10:52] <RainCT> bobbo: building & uploading :)
[10:52] <bobbo> RainCT; thanks :)
[10:53] <RainCT> Iulian: better replace $(INSTALL) with dh_instal
[10:53] <Iulian> RainCT: Okay
[10:54] <RainCT> *dh_install
[11:05] <Exfil> Hello All
[11:12] <Iulian> RainCT: Can you please take a look at http://paste.ubuntu.com/5190/ to see if I missed something?
[11:21] <RainCT> Iulian: looks good, just remove the changes to the *.files files from the diff
[11:22] <Iulian> RainCT: Ok
[11:25] <Iulian> RainCT: Done, see http://launchpadlibrarian.net/12350200/zblast_1.3-2.3ubuntu1.debdiff
[11:26] <Iulian> RainCT: Do I have to subscribe again u-u-s?
[11:35] <RainCT> bobbo: http://paste.ubuntu.com/5191/plain
[11:35] <RainCT> bobbo: want to fix those?
[11:36] <bobbo> RainCT; looks a bit of a mission but yeh i could give it a go
[11:43] <Iulian> It's pretty weird that you can't use caps in descriptions.
[11:46] <azeem> can somebody please dget http://people.debian.org/~mbanck/opensync_0.22-2.dsc and tell me whether it builds fine in hardy?
[11:47] <persia> hellboy195: Take a look at the latest traffic in bug #196854: maybe it does need an SUR.
[11:47] <ubotu> Launchpad bug 196854 in fail2ban "fail2ban doesn't handle leap years" [Undecided,Fix released] https://launchpad.net/bugs/196854
[11:47] <persia> s/SUR/SRU/
[11:48] <bobbo> RainCT; for lintian error "copyright-lists-upstream-authors-with-dh_make-boilerplate" what should i put in the changelog?
[11:52] <RainCT> bobbo: «Change "Author(s)" to "Author" to make lintian happy.» or something like tha
[11:52] <RainCT> +t
[11:52] <bobbo> ty
[11:54] <persia> azeem: Builds fine.  Not tested further in any way.
[11:55] <azeem> thanks
[11:56] <bobbo> RainCT; fixed them. http://bobbo.mooo.com/~bobbo/gpppon_0.2-4ubuntu1.debdiff
[12:03] <Hobbsee> RAOF: ROCK ON!  i didn't know gnome-do was in ubuntu
[12:05] <StevenK> Failed to build or is in NEW, though.
[12:05] <StevenK>   gnome-do | 0.3.2.1-0ubuntu1 | hardy/universe | all
[12:05] <StevenK>   gnome-do | 0.3.2.1-0ubuntu2 | hardy/universe | source
[12:07] <Hobbsee> wfm
[12:07] <Hobbsee> oh, your cache is out of dae
[12:12] <StevenK> I should hope not, since that's rmadison
[12:12] <Hobbsee> that's otu of date too then
[12:12] <Hobbsee> was only accepted at 19.25 local
[12:14] <StevenK> Ahh
[12:14] <afflux> morning
[12:15] <afflux> RainCT: The maintainer of gnome-arts is already set to ubuntu-motu (bug 197078)
[12:15] <ubotu> Launchpad bug 197078 in gnome-art "candidate for version 0.2-8ubuntu2" [Medium,New] https://launchpad.net/bugs/197078
[12:15] <afflux> *gnome-art
[12:16] <RainCT> afflux: oops sorry
[12:16] <afflux> no problem :)
[12:17] <afflux> anyway, gnome-art has no upstream development anymore 2005
[12:17] <afflux> +since
[12:21] <RainCT> afflux: I guess you have already tried if it works right with the patches?
[12:22] <afflux> it works for me
[12:22] <RainCT> afflux: ok, I'll upload it then :)
[12:23] <HighNo> Hi, guys. Offtopic question: does anyone know how to send an Xevent (keystroke) to any application via either python or commandline?
[12:24] <Iulian> RainCT: When you have some time, please review my new debdiff. I'm going outside for ~30min. Please ping me when you're done. :)
[12:25] <RainCT> Iulian: sure, I'm building it right now :)
[12:27] <hellboy195> persia: I'll take care of it later :)
[12:29] <RainCT> Iulian: the dh_install line doesn't work as it has multiple binaries -.-
[12:29] <persia> (rather, it needs the -p argument)
[12:30] <RainCT> Iulian: and please remove the "upstream webpage: http://www.svgalib.org/rus/zblast/" things from debian/control (and change the changelog to say that you moved the Homepage field to the source stanza instead of that you added it)
[12:33] <RainCT> afflux: uploaded :)
[12:33] <afflux> RainCT: tyvm :)
[12:34] <Iulian> RainCT: I'm changing it now, how you'd like to be the changelog?
[12:35] <Iulian> About the Homepage field.
[12:35] <RainCT> Iulian: I normally write "* Move Homepage field to Source stanza."
[12:37] <Iulian> Ok, thanks.
[12:47] <Iulian> RainCT: It should be fine now - http://launchpadlibrarian.net/12350803/zblast_1.3-2.3ubuntu1.debdiff
[12:50] <RainCT> dh_install -p debian/zblast.desktop /usr/share/applications
[12:50] <RainCT> Iulian: -p should be followed by the package name, like -pzblast-x11
[12:51] <Iulian> Ahh
[12:51] <RainCT> Iulian: the .desktop should go into the -x11, or? (I'll just change it, no need to create a new debdiff)
[12:51] <Iulian> It should be dh_install -p debian/zblast.desktop /usr/share/applications
[12:52] <Iulian> dh_install -p zblast-x11 ...
[12:52] <Iulian> RainCT: Yes, that's right.
[13:06] <james_w> thanks warp10, persia for the wiki page.
[13:07] <bobbo> RainCT: thanks for uploading gpppon :)
[13:09] <Iulian> RainCT: Next time I will build it myself so you don't have to do my work. :)
[13:12] <Hobbsee> \sh_away: i think they're mindlessly copying planet...
[13:13] <Hobbsee> \sh_away: because they've got your latest post on there too...
[13:14] <Hobbsee> \sh_away: planet.ubuntulinux.org too
[13:29] <emgent> heya
[13:30] <Iulian> Hi
[14:07] <RainCT> james_w: thanks for looking at those crashes :)
[14:07]  * RainCT is away again
[14:09] <james_w> RainCT: no problem. I saw you had glanced at them, so I stopped where I did.
[14:09] <james_w> quite a coincidence they were both yours wasn't it?
[14:22] <Iulian> RainCT: Thanks for uploading it.
[14:23] <RainCT> Iulian: np, thanks for the debdiff :)
[17:13] <emgent> geser, ping
[17:15] <pochu> Hi MOTUs!
[17:17] <geser> emgent: pong
[17:19] <Exfiltrate> HEllo pochu
[17:24] <pochu> hey Exfiltrate
[17:27] <Exfiltrate> whats goin on
[17:28] <Exfiltrate> Flare183: Cant decide on a nick
[17:28] <Nafallo> ehrm
[17:28] <Nafallo> nick flood
[17:28] <Nafallo> please stop
[17:28] <FlareFlare> ok
[17:28] <Exfiltrate> thanks
[17:28] <Exfiltrate> how is everyone doin?
[18:59] <bmhm> hi
[18:59] <bmhm> where do i find this release? https://bugs.launchpad.net/gutsy-backports/+bug/192751
[19:00] <ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Wishlist,Fix released]
[19:00] <bmhm> It has NOT been released...
[19:02] <geser> bmhm: https://edge.launchpad.net/ubuntu/gutsy/+queue
[19:03] <geser> bmhm: it waits for an archive admin to accept it into gutsy-backports
[19:03] <bmhm> :-(
[19:03] <bmhm> it takes sooooooo long... :P
[19:04] <bmhm> but i can download it now, thanks geser
[19:04] <geser> bmhm: you usually won't find an archive admin working during weekend
[19:05] <bmhm> geser: 29th was friday for me, but well they got probably more important work to do.
[19:06] <_emet_> is it bad form to use a python postint script instead of a shell script?
[19:07] <geser> bmhm: it was added friday evening (18:15 UTC) to the queue
[19:07] <bmhm> oh
[19:07] <bmhm> ok I don't work at that time ;)
[19:17] <afflux> Is there anything special to do with "new upstream version" bugs for bug-fixing-only releases since featurefreeze?
[19:18] <afflux> special to do when filing such a bug, that is
[19:19] <jdong> if you're reasonably confident it's bugfix-only, then probably not
[19:19] <pochu> afflux: no need to file a bug. just upload, but put in debian/changelog what has changed / what is fixed
[19:20] <afflux> pochu: I can't upload, I'm not a motu
[19:20] <afflux> jdong: except the bug-fixes, it only contains some synced  translations from rosetta
[19:20] <pochu> afflux: ah, ok. Then put something so the MOTU understands it's a bug fix only release (probably a changelog.diff) :)
[19:22] <afflux> pochu: good, thank you
[20:28] <mib_b7kf8rdn> Has anyone tried to use ketchup to get the latest -rt kernel (2.6-rt)... it seems that ketchup breaks quite frequently and I wonder if it is even still maintained... it looks like the ketchup wiki (www.selenic.com/ketchup/wiki) is filled with spam and it stopped at release 0.9.8.
[20:50] <emgent> jdstrand, ping
[21:12] <fmarier> I've got a Perl 5.10 build fix for a package in hardy, should I bother asking for a sync with the Debian package (which has the fix) or is it unnecessary since hardy only has Perl 5.8?
[21:12] <fmarier> The only change: http://pastebin.com/m168ef0ab
[21:22] <ScottK> It's unnecessary for Hardy.
[21:22] <ScottK> If the Debian package has the bug you ought to file the patch with the Debian in their BTS.
[21:23] <ScottK> Then we'll get it automatically for the Ibex.  Debian will likely do the Perl 5.10 transition before we do.
[21:32] <warp10> If I am packaging a software from scratch, and need to patch the source (adding a patchsystem), do I need to add an entry in debian/changelog?
[21:38] <ScottK> warp10: Yes.  Your debian/changelog should describe how you are patching the upstream code.
[21:39] <warp10> ScottK: Ok, thank you.
[21:54] <ScottK> Someone who hasn't just totally given up on the idea of filing bugs against Launchpad might want to suggest that they try out their new "builds as soon as you upload it" PPA feature with an empty PPA.
[21:55] <ScottK> It's just barely possible that they didn't really design or test this particular feature very completely.
[21:55] <hellboy195> ScottK: ^^, so far it worked for me with i386 and amd64 very good
[21:56] <ScottK> hellboy195: First upload to an empty PPA since the last LP release?
[21:56] <hellboy195> ScottK: ah, not to an empty. You found a bug?
[21:56] <ScottK> Yes.  Since no packages are published, there is no release.tgz, soyuz looks for it, and the build fails.
[21:57] <ScottK> Typical half designed half tested LP feature development.
[21:58] <RainCT> good night
[21:58] <hellboy195> ScottK: as I said. LP should go opensource and you agreed me :)
[21:58] <hellboy195> RainCT: gn8
[22:01] <ScottK> hellboy195: With some community governance too.  Just releasing the code isn't sufficient.
[22:02] <ScottK> But as I started with ...
[22:02] <ScottK> I've sworn off reporting launchpad bugs as bad for my health, so someone else may want to report that.
[22:03] <hellboy195> ScottK: If it isn't urgent I would do it tomorrow, I'm going to bed soon ..
[22:05] <ScottK> hellboy195: For me, no Launchpad bugs are urgent.
[22:05] <ScottK> ;-)
[22:06] <hellboy195> hrhr, bad ScottK :P
[22:09] <hellboy195> ScottK: bug #196782 ?
[22:09] <ubotu> Launchpad bug 196782 in soyuz "First build in a new PPA fails" [Low,Triaged] https://launchpad.net/bugs/196782
[22:10]  * ScottK just barely avoids making a really snide comment in that bug.
[22:10] <hellboy195> ScottK: but it's the right one?
[22:10] <ScottK> Yes
[22:10] <hellboy195> :)
[22:10] <hellboy195> problem solved
[22:10] <hellboy195> no one has to report it ^^
[22:11] <ScottK> Yes.  Thanks.
[22:11] <hellboy195> nvm. gn8 folks :)
[22:11] <ScottK> I need to avoid even looking.  Their snide attitude to releasing shoddy software just drives me nuts.
[22:34] <RAOF> Hobbsee: Yeah; gnome-do has been one of my pet licensing annoyances.  Hooray for being a part of upstream!