[00:16] Will someone explain to me what DESTDIR in a makefile does? [00:16] SoftwareExplorer: It's typically used to identify the location into which the software should be installed. [00:17] so if I make it so that when a person runs make install it usually copies a file to /usr/lib/gtk-2.0/modules/, were should it copy to ? [00:18] $(DESTDIR)/usr/lib/gtk-2.0/modules/librgba.so [00:18] ? [00:19] SoftwareExplorer, DESTDIR is useful to override the behaviour you've otherwise been encouraging. For example, if you compile with "--prefix=/usr", then things like pkg-config files will have that prefix burned in - but when building a package, you cannot touch /usr, so your package build would break [00:19] SoftwareExplorer, so you'd use "DESTDIR=debian/tmp make install" to make "make install" override into a different prefix [00:19] whilst still burning in data relating to --prefix=/usr [00:21] So, is DESTDIR to help you with where to put the file once it's compiled, or give you a temporary place to run gcc and build the file? [00:24] the former [00:25] DESTDIR is the place "make install" installs to [00:25] DESTDIR is the "DESTination DIRectory" [00:27] I put the makefile I'm working on at http://paste.ubuntu.com/375816/. Would you mind looking at it and telling me if I'm doing it right? [00:29] SoftwareExplorer: Looks reasonable. Does it work? [00:29] no, that's wrong [00:29] Why? [00:29] you shouldn't force /usr [00:29] i.e. DESTDIR=/opt should go into /opt, not /opt/usr/ [00:29] Ah, that would be ${DESTDIR}/${PREFIX}/... though. [00:30] So how do I tell it that it should put it in /usr/lib/gtk-2.0/modules by default? [00:31] Set PREFIX to usr [00:32] Oh, and use PREFIX ?= so that it can be overridden by directhex's user who wants to install in /opt/ [00:35] persia: How does the computer know that the program is in /opt ? The main reason I'm trying to write a makefile is so that I can make a .deb out of a single .c file, and this is the first time I've tried to do a makefile. [00:36] The user would run `DESTDIR=/opt PREFIX="" make install` [00:39] So that would override whatever I set it to in the makefile? [00:47] Ok, here's the new version of the makefile. http://paste.ubuntu.com/375827/ I'm not sure if I did the PREFIX part right. [00:51] SoftwareExplorer: "PREFIX ?=usr/" and "${DESTDIR}/${PREFIX}/lib/gtk-2.0/modules/" [00:52] Ok, thanks so much for the help. That clears up a lot of confusion. [00:53] gpodder package in universe has bugs and is an older version, ppa has current version without bugs, how does one go about getting the packaged patched or updated? [00:53] https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886 [00:53] Ubuntu bug 508886 in gpodder "gpodder crashed with AttributeError in set_attributes()" [Undecided,Fix released] [00:53] !update [00:53] For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes - see also http://www.ubuntu.com/getubuntu/upgrading [00:53] Darn! [00:55] https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate [00:56] Question: If I want to fix a bug in a package - firefox-vimperator in this case - what's the procedure? Attach a debdiff to the bug report? Submit an updated package to REVU? [00:58] mr_steve: Attach a debdiff to the bug report, and subscribe "ubuntu-universe-sponsors" [00:58] I'm not sure if I was clear, I know how to upgrade my packages to the latest version. I want to who to speak to get a newer version into the archive. [00:59] lexual: File a bug against the package and attach the diff.gz file from the upgrade. [01:00] persia, thanks [01:01] persia: there is a bug already and it has links to *.dsc and ppa of updated package. [01:01] https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886 [01:01] Ubuntu bug 508886 in gpodder "gpodder crashed with AttributeError in set_attributes()" [Undecided,Confirmed] [01:03] lexual: Does that .dsc link to something that builds and solves the bug for lucid? [01:05] according to ppa person it does, give me a few minutes and I will test on my system. [01:11] https://launchpad.net/~thp/+archive/gpodder/+packages [01:11] persia: I have just installed ppa package and it solved the crash problem. [01:12] OK. Update the bug with a comment about that, and subscribe ubuntu-universe-sponsors [01:14] persia: done [01:15] lexual: One of the developers will double-check, and either upload or explain if something else is needed. [01:15] Thanks a lot for investgating that. [01:15] persia: great, thanks for your help. [02:02] lintian seems not to accept XSBC-Original-Maintainer .. in the control file ... neither in the .dsc file [02:02] should i consider that warning ? [02:17] paissad: Um, Which lintian message do you get from that? [02:18] persia, W: pms-linux source: unknown-field-in-dsc original-maintainer [02:18] I: pms-linux: unknown-field-in-control original-maintainer [02:19] Which lintian are you running? [02:20] persia, Lintian v2.3.2ubuntu1 [02:20] http://pastebin.com/f3ac76ed3 [02:21] Ah, what *version* is your package? [02:21] pms-linux_1.20.392-1_all.deb [02:22] OK. I think that's an issue in lintian, but maybe not: specifically I suspect that lintian is checking the version number to determine if "Original-Maintainer" is a valid control file entry. [02:22] Try again with 1.20.392-0ubuntu1 and see if you get the same result. [02:23] ok [02:30] persia, indeed, if i append 0ubuntu1 instead of 1, i have no warning ^^ [02:30] Right. I think it's a bug, but I suspect that many people disagree with me. I know why it's that way, and it's not important. [02:31] So, basically, if you're preparing a package for Ubuntu, use Original-Maintainer, and if you're preparing a package for Debian, don't. [02:31] persia, i think that -1 or 0ubuntu1 should be both accepted [02:32] Why? [02:32] And Where? [02:33] persia, i just think that lintian should not return any warning because we choose to append -1 instead of -0ubuntu1 when we enter Original-Maintainer: [02:33] Heh, neither do I :) [02:34] But the reason it does that is that a new upload to Debian should have -1, and using Original-Maintainer in Debian is a bug. [02:34] ok [02:34] And a new upload to Ubuntu should have -0ubuntu1, and not using Original-Maintainer in Ubuntu is a bug. [02:35] lol [03:06] persia, if you're still around, i'll probably upload the diff in around half an hour or so. this build is taking unusually long; i'm sure that in the end it'll be successful, but naturally, i don't want to waste your time. [03:06] tsmithe: Thanks for your concern: I'm looking forward to the new shiny bits :) [03:09] cool. annoyingly, though, because i've not got around to getting pisa in a state that the debian python folk think is acceptable (and because they're so hostile), manuals are still only provided online, and the local ones are deleted, because i can't build the pdfs. [03:09] (pisa you can see at https://launchpad.net/~mscore-ubuntu/+archive/ppa/+sourcepub/893784/+listing-archive-extra) [03:09] however, that's immaterial, really. another cool development is that the 0.9.6 release includes another free soundfont :) [03:10] and it's a lot smaller than fluid [03:11] tsmithe: You can't get pisa into Debian? [03:11] Another soundfont? Excellent! [03:11] Is it separable, or only available with mscore installed? [03:11] i provide it as a separate binary package [03:12] Lovely. [03:12] as for pisa.. well, when i tried to talk to the python team about it, they seemed fairly hostile. i can't remember what their objections were, but it was something to do with eggs. [03:12] soundfont? [03:12] persia, in any case, they didn't have very good documentation [03:12] hyperair, yes? [03:12] what's a soundfont? O_o [03:13] it's like a font, but with banks of sound samples, rather than glyphs [03:13] so you can use midi calls to reference those sounds, and make music [03:14] (think timidity/freepats etc?) [03:14] Well, freepats is a particularly unfortunate example :) [03:14] yes, that's why i chose it :) [03:15] ooh cool [03:16] hyperair, having a free soundfont was necessary to make musescore (a notation program that i maintain) worthwhile, but coincidentally it also allows more applications better sound. i'm glad now that we don't only have one 120mb one. [03:17] i still think we're not quite at the same stage that exists on windows, with a centralised midi server thingy, but i think we're getting there thanks to some gstreamer support and a nicer pulseaudio. [03:19] 120MB huh. that's big. [03:20] tsmithe: If you have any ideas to improve the gstreamer support, I'd like to hear about it. The wildmidi integration feels like a bi of a hack, and lots of users complain about things that aren't quite bugs. [03:21] hyperair, it had lots of samples :) the new one has fewer (though i think it still provides the whole gm set) [03:21] persia, well, i think wildmidi is the main weakness. it's a nice library from what i've seen, but its development seems to have stalled. [03:21] Yeah, well. [03:21] does it still not support sf2? [03:22] I've not uploaded a new version since way back when. [03:22] * persia checks upstream [03:22] looks like it doesn't, according to the site [03:22] Yeah, but I should probably update it. [03:23] There's a note on the homepage about visiting the IRC channel to abuse them about the hackiness of 0.2.2 :) [03:23] mm [03:23] its main advantage it its lightness, i think, which is good. i don't know how its performance compares to fluidsynth, which is still my favourite [03:23] but, of course, fluidsynth has to run as a daemon, which i'm not sure is ideal. [03:23] 3.0 has sf2 support. I'm not sure I'll get it into Lucid, but I should be able to get it into squeeze. [03:24] does 3.0 exist, then? i thought it was just a plan. [03:25] i think an ideal situation could involve a very minimal daemon that opens an alsa midi port. if something tries to play, it just builds the right gstreamer pipe, all the while opening another port to allow two things to use it at once. [03:26] then of course, i suppose gstreamer could do as musescore does, and link against libfluidsynth rather than libwildmidi [03:26] of course, i don't know how feasible this is, but it's certainly too much work for me at least until the summer [03:26] Oh good. I'm not as bad a maintainer as I thought from the homepage. Yeah, neither 2.3 or 3.0 has been released. [03:27] thought so.. that's what i meant by "stalled" :s [03:28] There's been a few stalled attempts to write some glue that provides a midi sink and gstreamer source. They all seem to either get overambitious (and turn into softsynths) or not get completed. [03:29] i think anything i started would quickly fall into the latter category. as the adage goes, it's easier said than done. [03:29] (though i think it could be "easy". but you couldn't avoid "time-consuming") [03:30] Well, it wouldn't be that hard to build a gstreamer module that wrapped fluidsynth. [03:30] But that would be kinda heavy to provide by default. [03:30] (part of why I liked wildmidi) [03:31] yes. but would it be excessively heavy? i know fluid is very configurable, and to me it has always *sounded nicer* [03:32] Fluid is lovely, but it does require a fair bit of processor and RAM. [03:33] do we know why that is? [03:33] (i've never read the code) [03:36] I don't offhand. I've always assumed it was because it was good at what it did. [03:37] Remember that fluid has all those built-in effects engines and what not. [03:38] i know.. can they be turned off? as a hypothetical default, to lighten the load, that could be attractive. [03:40] I don't know. [03:40] But since we're talking about a theoretical project you don't expect to have time to complete, I'm not sure how much it matters yet :) [03:42] no. you're right, and i must admit that was the thought that occurred in my head [03:45] heh [03:46] ok, pbuilder finally done. time to open the bug. [03:52] persia, https://bugs.launchpad.net/ubuntu/+source/mscore/+bug/521584 [03:52] Ubuntu bug 521584 in mscore "Please upload musescore 0.9.6~beta1+dfsg-0ubuntu1" [Undecided,New] [03:52] tsmithe: Thanks. I'll grab it in a bit. [03:54] * jdong wonders if it's actually feasible to backport enough of dpkg bits to support source 3.0 [03:55] persia, thanks a lot. [03:55] hi jdong [03:55] but, i'm off to bed. it's 4am again :s [03:55] hey tsmithe :) [03:56] ciao! got a lot of music and reading to do tomorrow; gotta get some rest [03:57] jdong: Wait for the next merge: there's still some 3.0 bits that lucid doesn't support. [04:06] Could someone review http://revu.tauware.de/p/turnin-ng please? turnin-ng_1.0.1-0ubuntu1_{source,i386}.changes are lintian clean. [04:07] ah :) good to know [06:36] I'm having trouble building a package because a directory it installs to doesn't exist in my minimal pbuilder environment. The error I get is at http://paste.ubuntu.com/375971/. How should I handle this ? A mkdir -p in the makefile? Some other part of the packaging? Or should I be looking for the package that makes that directory and depending on it? [06:53] SoftwareExplorer, the makefile should create the directory it requires to make the cp. Perhaps install would be better than a cp [06:57] In my google ings since I asked, I read a little about install. I have a few questions though. What's the difference between install -d and install -D, i.e. which one gets closest to what cp librgba.so /usr/lib/gtk-2.0/modules/ would do? [06:59] SoftwareExplorer: man install for info on the arguments to it. install -d foo just creates the directory foo; install -D SRC DEST "create all leading components of DEST except the last, then copy SOURCE to DEST" [07:01] SoftwareExplorer: So (guessing a lot) you might want to do something like: install librgba.so /usr/lib/gtk-2.0/modules/librgba.so [07:01] Sorry, make that: install -D librgba.so /usr/lib/gtk-2.0/modules/librgba.so [07:01] jmarsden: Ok, thanks. I was looking at the man page, but I didn't get the synopsis part. [07:03] jmarsden: Thank you! It worked. [07:03] The synopsis in every man page is a list of the ways to use the command. So if you use install -d all you put after that is a directory, ... [07:03] Good! [07:05] So, another question. For the uninstall, there's no uninstall command, so is rm the way to do it? [07:06] Well, at least when I did man uninstall I got an error about no manpage [07:06] SoftwareExplorer: You need an "uninstall" target in your makefile, for a Ubuntu package? Why? [07:07] How is your debian/rules file going to use that makefile target? [07:07] Well, this is the first package I've tried. [07:08] So I'm learning lots as I go. [07:08] SoftwareExplorer: So you have read and understood the Packaging Guide, right. And does it mention the need for an uninstall target? [07:09] What gave you the idea that you need one? Is there some packaging documentation out there suggesting one? [07:09] No. [07:09] Then... why are you asking me about one? :) [07:10] https://wiki.ubuntu.com/PackagingGuide/Complete is the guide for doing Ubuntu packaging. Follow it, and you should be fine. [07:10] Because I guessed that if the package uses a makefile to install, then it probably uses a makefile to uninstall. [07:10] it should, but it's not mandatory [07:11] opps: I was thinking about a clean target [07:11] uninstall: no. It's been handeld by the package management tools [07:11] fabrice_sp: Right. [07:12] So it's something like dpkg keeps track of files installed by a package and deletes them when the package is removed? [07:12] yeap [07:13] Your rules file installs files into the *package*, not onto the system. [07:13] I see. [07:15] Thanks for the help, and I guess I have lots more "homework" to read. :) [07:54] My package finaly got into universe repository. Will I get e-mail automaticaly when someone reports a bug or do I have to subscribe somewhere ?? [08:00] It seems that I can't update bzr on my lucid because bzr-gtk has a bzr dependency of (>> 2.1~) which apparently is less than the new bzr's 2.1.0~rc2-1 [08:02] Is bzr-gtk really incompatible with bzr 2.1.0~rc2, or is it just be too cautious [08:03] jariq: https://launchpad.net/ubuntu/+source/ipwatchd/+subscribe [08:04] jariq: Do the same for the second package. [08:05] iulian: thx [08:47] fabrice_sp: Thanks for uploading blends :). [08:47] fabrice_sp: I'm going to also report bug in debian. [09:10] l3on, thanks to you to work on the merge ;-) [09:35] I'm looking for an advocate or two for http://revu.ubuntuwire.com/p/sqlite3-pcre If you fancy giving this package some love on this day of romance, I'd much appreciate it. [09:39] can someone help me with an error when I try to package. Its something to do with the patch. I have an idea whats wrong, but I'm not sure how to correct it [09:42] this is the error message I get http://pastebin.com/d1cede653 [09:57] nigelb: your pastebin link doesn't work [09:57] randomaction, oops, hold on. pasting again [10:05] I lost the logs, building again to reproduce error [10:08] here's the paste http://paste.ubuntu.com/376060/ [10:11] yes, the patch doesn't apply [10:12] the thing is one file the patch is supposed to apply is not exiting at the end [10:12] but I dont see how [10:12] I did a quilt push and then patched [10:13] so, all patches should have applied [10:15] s/exiting/existing [10:15] maybe it's deleted in the clean target? [10:17] Hi all... I'm building debian-med... In the build log I see: [10:17] Missing or avoided packages: [10:17] and then a list of packages... [10:18] is it an error?... What means "Missing or avoided packages" in pbuilder ? [10:18] -> http://paste.ubuntu.com/376066/ [10:20] l3on: built fine [10:22] is MoM fixed? [10:26] ari-tczew: thank you. [10:27] ari-tczew: "is MoM fixed?" to me ? [10:29] l3on, nope, generally to MOTU / developers [10:30] bdrung, geser, persia: ping [10:52] hello, sombody can review this packet? http://revu.ubuntuwire.com/p/autotrash thanks [10:55] ari-tczew: MoM is fixed [10:59] geser: second question about fakesync... do we should include previous ubuntu's revision in debian/changelog? [10:59] like in merge [11:01] IMHO no, as we would do a normal sync if we didn't need that fakesync [11:02] geser: third question about fakesync... issue is mismatching tarball, so why we can't replace tarball with debian? [11:07] the current packages in the archive reference the Ubuntu .orig.tar.gz with its md5sum and when you replace it with one with a different md5sum you break those old .dsc files === ogra_ is now known as ogra [11:08] so need to just repace all 3 files - diff.gz, .dsc, tarball [11:09] do all modifications outside the debian directory require the use of dpatch or quilt? what if it's just minor, debian-specific changes to the build system or something? [11:09] persia: do you will work on bug 294593 ? [11:09] Launchpad bug 294593 in lash "Please merge lash 0.5.4-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294593 [11:11] ari-tczew: how for all published (and mirrored) revisions? remember that you can fetch old versions from LP. All the tools assume that once a file got published it doesn't change anymore === k0p_ is now known as k0p [12:02] hi all, http://revu.ubuntuwire.com/p/pms-linux ... the package is lintian warning|error free ! [12:41] paissad: that contains loads and loads of binaries, many without sources and/or licenses... [12:41] jcastro, o0 [12:41] jcfp, [12:43] jcfp, i don't see what's the matter mate, ... the licence of this soft is GPLv2 .. i don't know what you really mean ^^ [12:45] paissad: you can't ship binaries (.dll) without source. I'm wondering if you even testbuilt it because sunjava is not present anymore in lucid [12:45] jcfp, are talking about this http://revu.ubuntuwire.com/report.py/legal?upid=7743 ? [12:45] paissad: see sebner's comment. I'm talking about the link to revu you posted 43 minutes ago [12:46] sebner, i've tested the package in karmic & jaunty & debian ... not lucid ... i mentioned lucid because it's said that other distrib are not accepted anylonger [12:46] paissad: yeah, you only can upload to the current -devel version which is lucid and I doubt your package will build there [12:47] sebner, though i have to test it in lucid ? .. [12:47] why would that not work ? [12:48] paissad: Because sun-java is not available anymore. You have to test if it builds and run with openjdk [12:48] sebner, ok [12:49] Can someone carry through the bzr-gtk sync from sid? I added a debdiff to bug #521353 to update it dh7, it was giving me a bunch of problems with pbuilder, now it doesn't. [12:49] Launchpad bug 521353 in bzr-gtk "Sync bzr-gtk 0.97.0+bzr674-3 (universe) from Debian unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/521353 [12:50] jcfp, btw, i built the software from the svn source, but i've removed windows binaries during clean target in the debian/rules file .. and the soft is licenced under GPLv2 .. what's wrong with that [12:50] i'm just confused [12:50] ripps: don't add any unecessary changes to Debian packages and especially not to syncs! [12:51] paissad: you better create a get-orig-source rule which removes the binaries beforehand [12:51] sebner: have you got expierence in fix FTBFS causing by gcc, right? [12:52] ari-tczew: O_o, not really. What's the issue [12:52] ? [12:53] ripps: does bzr-gtk from Debian unstable build for you in lucid? (see also Debian bug #569415) [12:53] Debian bug 569415 in src:bzr-gtk "bzr-gtk: FTBFS: cp: cannot stat `debian/tmp/usr/lib/nautilus/extensions-2.0': No such file or directory" [Serious,Open] http://bugs.debian.org/569415 [12:53] sebner, yeah, how can i build the orig.tar.gz source without windows binaries files ? ... i just ran dh_make -f ../$pakage$version.tar.gz && debuild -uc -us --lintian-opts -iIEvm -pedantic --color always [12:53] sebner: I worked on merge libjdic-java and it got ftbfs, clean debian revision too got ftbfs [12:53] geser: yeah, that's one of the things I fixed in the debdiff [12:53] paissad: you better take a look at the Packaging Guide [12:54] sebner: I can open new bug and include my merge-propose, but it's need ftbfs fix [12:54] sebner, i did mate ;) [12:54] sebner, i wil do it manually ^^ [12:54] will* [12:54] paissad: that's not allowed afaik [12:55] ari-tczew: hmmm, pastebin the error [12:56] sebner, hmm well, if i download from the svn source .. knowing that that source contains windows binaries ( binaries i absolutely don't need for the packaging) ... if i'm not allowed to remove those binaries before compressing the source .... what must i do then ? [12:57] what's the command for get pbuilder buildlog, verbose? [12:57] I'm building from .dsc [12:58] paissad: well, you are allowed to remove it but with a get-orig-source so every person that fetches the sources through your package gets the same results [12:58] ari-tczew: --logfile [13:01] sebner, ok, i will remove those "fucking" files before compressing the source (tar+gzip) and after that i run dh_make and so on [13:01] are we ok ? [13:02] paissad: you can do that but you still need a get-orig-source rule because you are removing stuff for *this* upload *manually* [13:02] sebner, oh, i did not know about this "get-orig-source" rule ... lmgt [13:07] sebner: http://s1.plikos.pl/11e3/f30af66d18095996ca4d3c886ed16287/buildlog.txt [13:08] ari-tczew: next time please use pastebin ;) [13:08] geser: I just emailed a version of the debdiff to the debian bug. I'm not very familiar with debian's email interface, how long until it the page updates with the email? [13:09] a few minutes, you usually get a confirmation mail when your mail got processed [13:09] sebner: pastebin hangs my web browser [13:09] this is a large file [13:10] ari-tczew: well, not everyone wants to download something from a polish upload service ;) You might have more luck asking in #ubuntu-mozillateam as it seems this is a xulrunner issue [13:15] i don't see any info about get-orig-source rule in maintainer guide (debian|ubuntu) .. may someone help me ? [13:16] paissad: get-orig-source is a target in debian/rules that automates the cleanup so that anyone can simply run ./debian/rules get-orig-source and get a clean tarball free of unwanted binaries (jar, exe, dll, etc.). [13:16] ok ... thanks [13:17] jcfp, and i guess that target should be called before clean target ! [13:17] paissad: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball [13:18] paissad: it's not needed to remove the binaries in the clean target when they are not present (get-orig-source gives you a clean tarball) [13:18] ok [13:21] ari-tczew: pong [13:29] bdrung: about debian/changelog in fakesync... so get changelog file from Debian and add dch -i "Fake sync due to..." right? [13:29] ari-tczew: yes [13:30] ok, so fakesyncs are waiting for sponsor :D [13:32] ari-tczew: mind our new policy :P (See -devel ML) [13:33] sebner: -devel ML? [13:33] ari-tczew: ubuntu-devel Mailinglist. We use now XfacesyncY in the changelog [13:34] wrrrrrr [13:34] so I need to change all debdiffs [13:34] ari-tczew: well, it's not that fix so just go with your debdiffs for now ;D [13:35] ari-tczew: It will be a requirement at some point in the future though [13:35] sebner: stricte start oficial using -XfakesyncY with new development cycle? not now? [13:37] ari-tczew: well, yesterday there was a dicussion if we should use XubuntuY or XbuildY and the think the most appropriate it XfakesyncY. Don't know when we'll really use it. As FF nears and not that many syncs/fakesyncs will occur you might be right with lucid+1 [13:38] ari-tczew: there is still some discussion going on so you might want to ask persia as he is the mastermind behind this :D [13:39] sebner: I know about yesterday discussion, because I just started discussion :-] [13:39] heh [13:39] ari-tczew: yeah but it's now on the ML as well [13:39] what is "lucid+1" ? [13:40] ari-tczew: Ubuntu 10.10 ;) [13:41] sebner: so do I need to refresh all my debdiffs, or not? [13:41] ari-tczew: Do as you wish as nothing is official yet [13:42] so I don't change debdiffs, just waiting for sponsors [13:47] sebner: we had here a very long discussion about fakesyncs yesterday (you can read the log if you have an hour) [13:48] bdrung: I participated too ;) [13:49] ups :) [13:49] bdrung: as it's on the ML to gather some more feedback I was just not sure how official it is now [13:51] sebner: i think we should wait some time (one or two weak). if there are no vetos, it's official. then we should create the wiki documentation. [13:51] bdrung: aye [13:52] sebner: a response from an archive-admin would be good (because they have to modify their scripts) [13:52] bdrung: pitti agreed already [13:52] k [13:53] sebner: so XfakesyncY wouldn't do any harm (compared to using XubuntuY)? [13:54] sebner: give it some more time. at least the next week so the other devs have time to read it [13:54] geser: sure [13:54] bdrung: I guess [13:55] geser: bdrung but fakesync won't get autosynced if I understood it right? [13:55] you probably need to look into the scripts to know for sure [13:56] geser: where do i find the script? [13:57] bdrung: some parts are in https://code.edge.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk and some in LP itself [13:57] geser: I just read it and I guessed but I'm not 100% sure [13:57] geser: oh, I thought you spoke about persias proposal. Nothing is implemented yet?! [13:59] sebner: the proposal intend to autosync on new upstream versions and there wasn't enough time since yesterday to created patches for the existing code [14:01] geser: so there are super cool features planned where you can tell the difference between new upstream and new debian version and work accordingly? [14:01] geser: i found nothing related in ubuntu-archive-tools [14:02] bdrung: I don't have an clear overview how the autosync work in detail myself yet [14:03] bdrung: some scripts are in scripts/ftpmaster-tools in the LP code. those are the server-side parts from the archive admin scripts [14:03] geser: can i branch this code somewhere? [14:04] geser: with the XfakesyncY in the name, the sync script could sync in all cases. [14:05] bdrung: only in case of new upstream :P [14:06] bdrung: https://dev.launchpad.net/Getting [14:06] sebner: no. in the other case the script can do something similar to my fakesync script (get debian source, extract it, replace the source tarball, dch -i "fakesync") [14:06] bdrung: interesting approach [14:07] bdrung: if you only want to look at the code branch lp:launchpad/devel [14:07] bdrung: sync-source.py from http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files/head%3A/scripts/ftpmaster-tools/ might be a good start for looking [14:12] What are the reasons for a package to dissappear from the list at revu.ubuntuwire.com ? [14:15] bdrung: could you take a look @ http://pastebin.ubuntu.com/376172/ is it possible to causing ftbfs by gcc ? [14:17] ari-tczew: it's not the fault of gcc. The problem starts with "No such file or directory". a package could be missing or a parameter is not set correctly. [14:18] ari-tczew: unlikely, see like 1550+: gtkmozembed_internal.h:25:27: error: nsIWebBrowser.h: No such file or directory [14:19] gusnan: Does it show up on the front page? [14:20] gusnan: What is the name of the package you're interested in? [14:20] iulian, no - it does show up if I have a "direct" link though. [14:20] It my own package "sciteproj" [14:21] ari-tczew: looking at line 1546 those absolute paths for -include and -I look suspicious [14:21] it's there at /p/sciteproj , but not in the list on the front-page. [14:21] Ah. [14:21] Hmm. [14:24] gusnan: It seems that the package has been archived. I've just unarchived it and should show up on the front page. [14:24] thanks! [14:26] I don't have time for waste time to fix this FTBFS, I can open a new bug and include my merge-propose diff [14:26] maybe someone want to take this one and fix FTBFS [14:32] bug 521712 [14:32] Launchpad bug 521712 in libjdic-java "Merge libjdic-java 0.9.5-6 (multiverse) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521712 [14:37] main -> multiverse? that sounds odd [14:38] libjdic-java in in universe since jaunty [14:38] if it's disturb you, feel free to change it [14:43] ari-tczew: Rather, please explain why it should now be in multiverse [14:46] persia: omfg, I don't want to move into multiverse, just I always look @ Component: multiverse [14:46] https://launchpad.net/ubuntu/+source/libjdic-java [14:46] enough? [14:47] That's a bug in launchpad (because it's not in multiverse). Please report it. [14:48] persia: see the footnote [14:48] persia: regards for you, because it's not me find this bug and I can't describe what about this issue [14:49] geser: Where is that encoded within the package though? [14:49] geser: Or is it just stuck until the next upload? [14:50] ari-tczew: Fair enough. Do you understand why it's a bug? [14:50] as far as I understand it the "package information" is the data of the last upload, not the current one (e.g. if the page gets promoted/demoted since then) [14:50] s/page/package/ [14:51] geser: That makes sense, but LP *knows* the current value. Oh well, still buggy :) [14:51] the last libjdic-java upload went to multiverse and the package got moved to universe after that [14:51] RIght. [14:52] yes, the page itself is correct because of the footnote, but not very useful in that form [14:53] persia: how do you checking package component? [14:54] ari-tczew: I look at the table on the page you mentioned [14:54] ari-tczew: apt-cache show ${PACKAGE} | grep ^Section: provides a hint for a current apt-cache. rmadison provides a hint for other environments. [14:54] ah, I SEE [14:56] persia: could you report bug to launchpad? because you found it [14:56] ari-tczew: doing so now [14:57] persia: what about bug 294593 ? do you will work on it? [14:57] Launchpad bug 294593 in lash "Please merge lash 0.5.4-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294593 [14:57] I'll try it again. It completely failed the last few times I tried. [14:58] would be nice [14:59] ari-tczew: It's causing some bug? [15:00] persia: probably not, just I want to clean up repositories before FFe [15:01] This merge isn't affected by FF. [15:01] No new upstream. No significant changes in Debian. [15:02] persia: so is it can be merged while FFe? without any special reasons? [15:02] ari-tczew: Well, check the changelogs in Ubuntu and Debian, and check the differences. I don't see anything (and I strongly dislike trying to merge around tarball-in-tarball) [15:03] persia: but what about fakesyncs? can I prepare debdiff while FFe? [15:04] ari-tczew: bug 499329 needs an merge and maybe a refresh to use the latest mozilla-devscripts features [15:04] Launchpad bug 499329 in foxyproxy "Merge foxyproxy 2.18.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/499329 [15:07] bdrung: so this is a job for dhillon-v10 [15:08] wrrrr, java in firefox 3.6 doesn't work? I can't play on-line java games. [15:09] [lucid] [15:09] ari-tczew: less distraction for you :) [15:11] geser: what do you think about? [15:11]