Re: init script cannot stop pid process
On Wed, Feb 11, 2015 at 10:25:38PM +0100, Mateusz Łukasik wrote: > Hello, > > I make darkhttpd package and have a small issue. > > I prepare init script: > https://github.com/mati75/darkhttpd/blob/master/debian/init and for run > script with start parameter is working fine: This is just a shot in the dark, but how about dropping the --daemon parameter, and telling start-stop-daemon to do the backgrounding? Basically... start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \ --background --exec $DAEMON -- $DARKHTTPD_ROOT $DARKHTTPD_FLAGS || true -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Debian package upstream watching
On 30/05/2013 07:01, T o n g wrote: > Hi, > > Is it the package maintainer's job to watch for upstream releases? > > How does this Debian package upstream watching works *practically*? > >>From http://wiki.debian.org/debian/watch/ I have the impression that I > have to come up with a scheme to call the uscan program on regular basis, > whereas from http://wiki.debian.org/DEHS I have the impression that DEHS > is doing that. The problem is that it publish to the summary mlist > (http://www.debian.org/doc/manuals/developers-reference/resources.html). > I.e., to get a notification of a single upstream package update > notifications, the S/N ratio would be extremely low. > > So, what's the *practically* way to get a notification of a single > upstream package update? I symlink the checked out git repositories of all my maintained packages into a specific directory (~/src/debian/uscan-pkgs), and then have a cron job that does "cd $HOME/src/debian/uscan-pkgs && uscan --report" nightly. If there are no updated packages (and hence no output) I don't get a notification. Otherwise, the output of the uscan command gets sent to my email by cron. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Looking for Sponsor (GTK Manga Downloader)
On 07/05/2013 12:49, Ronny Wegener wrote: > Hi, > > my name is Ronny Wegener, i'm the developer of HakuNeko a GTK based manga > downloader. I would like to publish a source package to the debian repo. I > think it's a nice addition since there is no GUI based manga downloader > available for linux. Also it can complement comix, a manga reader already > part of debian. > > Project URL: http://hakuneko.googlecode.com > > If a sponsor is interested feel free to contact me... > Ronny Wegener > I'm interested. Do you have the source package hosted anywhere? And an ITP? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: haserl (second try)
On 26/06/2011 03:29, Michael Tautschnig wrote: > Hi, > >> On 02/05/2011 02:20, Michael Tautschnig wrote: >>> [...] >> >> Hi Michael, >> >> I've just uploaded a new version of haserl (0.9.29-1), which has the >> copyright >> issues fixed. Could you look through it please? >> > > Sorry for the wait; I've now re-reviewed your package, built it, and uploaded > it. It'll be waiting in NEW and should then hopefully enter the archives. Thanks! :-) -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: haserl (second try)
On 02/05/2011 02:20, Michael Tautschnig wrote: > [...] Hi Michael, I've just uploaded a new version of haserl (0.9.29-1), which has the copyright issues fixed. Could you look through it please? Thanks for your time! -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: haserl (second try)
On 01/05/2011 22:55, Michael Tautschnig wrote: > Hi, > >> I am looking for a sponsor for my package "haserl". >> >> * Package name: haserl >> Version : 0.9.27-1 >> Upstream Author : Nathan Angelacos >> * URL : http://haserl.sourceforge.net >> * License : GPL-2 >> Section : interpreters >> > [...] > > IMHO this is not distributable as-is because all the header files in src/ lack > both copyright and license information. Please persuade upstream to fix this. I'll talk to them about it, but as far as I know, there is nothing in GPL that states that all source files *must* contain the GPL copyright/license header. In fact, I was under the impression that while it is strongly recommended for the license/copyright information for each source file to be documented, if there is no reason to believe that the source file does not come from somewhere else, it is then safe to assume that source files which do not contain explicit license/copyright information are released under the same license/copyright as the global project license/copyright, as mentioned in COPYING. Am I wrong about this? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: alarm-clock-applet (updated package)
On Monday 28,March,2011 10:46 PM, Peter Pentchev wrote: > [...] > Hi, Hi Peter, Thanks for your patches. I've looked through them, and I think I'll accept just the second one (regarding --watchfile). Comments are interleaved below:- > Bearing in mind that I'm not a DD yet and cannot really help you by > uploading the package, what do you think about the attached four patches > that IMHO might improve the packaging a bit further? > > - get the CPPFLAGS, CFLAGS and LDFLAGS variables from the dpkg-buildflags > tool introduced in dpkg-dev 1.15.7 Shouldn't these be automatically exported before the build process? At least, I believe this is what has been used previously. Was there anything wrong with that? > - properly pass --watchfile and not --watchfie to uscan ;) Applied and uploaded to mentors.debian.net, thanks. > - no need to pass the changelog name to dh_installchangelogs since 7.0 Well yeah, but it still didn't detect the ChangeLog, for some reason, so I added it there. I should probably debug this issue and file a bug on debhelper. > - bump the debhelper compatibility level to 8 with no further changes If there's no reason for it, so I'd rather not bump the compat level (and the version of the debhelper build-dep) unnecessarily. > [...] -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
RFS: alarm-clock-applet (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.3.2-1 of my package "alarm-clock-applet". It builds these binary packages: alarm-clock-applet - Alarm Clock applet The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/alarm-clock-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/alarm-clock-applet/alarm-clock-applet_0.3.2-1.dsc - git clone git://git.debian.org/git/collab-maint/alarm-clock-applet.git I would be glad if someone uploaded this package for me. P.S: Please CC me for replies. I'm not subscribed to the list. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
RFS: haserl (second try)
Dear mentors, I am looking for a sponsor for my package "haserl". * Package name: haserl Version : 0.9.27-1 Upstream Author : Nathan Angelacos * URL : http://haserl.sourceforge.net * License : GPL-2 Section : interpreters It builds these binary packages: haserl - CGI scripting program for embedded environments The package appears to be lintian clean. The upload would fix these bugs: 611445 My motivation for maintaining this package is: I'm developing a web interface for configuring an embedded device using Haserl, and having haserl installed as a package makes testing locally much easier. It can also be used for CGI scripting in non-embedded environments. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/h/haserl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/h/haserl/haserl_0.9.27-1.dsc - git clone git://git.debian.org/collab-maint/haserl.git I would be glad if someone uploaded this package for me. P.S. Please CC me in any replies, as I am not subscribed to debian-mentors. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: haserl
On Sunday 30,January,2011 02:30 PM, Paul Tagliamonte wrote: > Howdy fellow Ubuntu-er! Well, hello. > I'm not a DD, but here's my review: > > You have one lintian issue on your dsc ( really upstream source ) -- > no-complete-debconf-translation The debconf one is downstream, but there's nothing I can really do about this, so I'll leave it be. If someone who knows a non-English language feels like translating it, then sure, I'll add it. > You've got a bunch of manual page issues -- hyphen-used-as-minus-sign Fixed and forwarded. > might want to let upstream know so they can fix them both > > > debian/control: > > I see what you are doing with build-depends, but might want to wrap it > on two lines to keep it shorter ( but still readable ). Nothing wrong > with how it is now, just a personal note. Wrap on two lines? Sorry, I don't understand what you mean. Either way, this probably isn't something I would change, as this style really helps with staring at diffs involving build-dep changes that haven't been refined under Emacs or similar utility. > You've got DEP5 / 3, and everything else is pretty tidy. Having a hard > time picking on anything else :) > > [...] -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
RFS: haserl
Dear mentors, I am looking for a sponsor for my package "haserl". * Package name: haserl Version : 0.9.27-1 Upstream Author : Nathan Angelacos * URL : http://haserl.sourceforge.net * License : GPL-2 Section : interpreters It builds these binary packages: haserl - CGI scripting program for embedded environments The package appears to be lintian clean. The upload would fix these bugs: 611445 My motivation for maintaining this package is: I'm developing a web interface for configuring an embedded device using Haserl, and having haserl installed as a package makes testing locally much easier. It can also be used for CGI scripting in non-embedded environments. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/h/haserl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/h/haserl/haserl_0.9.27-1.dsc - git clone git://git.debian.org/collab-maint/haserl.git I would be glad if someone uploaded this package for me. P.S. Please CC me in any replies, as I am not subscribed to debian-mentors. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Build depending on linux architectures only
On Tuesday 02,February,2010 02:38 AM, Helge Kreutzmann wrote: > Hello, > I have a package (linuxinfo) which is by design only sensible on linux > architectures. So far, this was no problem as all official > architectures were linux based. Since now *bsd architectures are > present within debian and others are in the works in and outside > debian (hurd, nexenta) I would like to state in my debian/control, > that a linux architecture (even if it is not (yet) in Debian, like > sh4/avr32) is required for building. > > So is the only option to use the output of > dpkg-architecture -L|grep -v solaris|grep -v openbsd|grep -v netbsd|grep -v > freebsd | grep -v darwin|grep -v hurd ? > > Thanks for pointers & help > > Greetings > > Helge Architecture: linux-any -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Reforming 'orig.tar.gz' with included tar-ball.
On Tuesday 26,January,2010 06:44 PM, Mats Erik Andersson wrote: > Hello all mentors, > > I am in the process of fulfilling an ITA filed on an orphaned package. > However, I now experience a desire to begin patching the upstream > source for compiling errors and spelling errors in the manual page. > > To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file > contain the packaged and compressed upstream tar archive. My personal > taste is to abondon this practice, if for no other reason to simplify > the rules-file. > > Is there some reverence that should prevent me from taking the step > of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream > source archive? I will make the new package conform to "3.0 (quilt)". > AFAIK the orig.tar.gz should be a byte-for-byte copy of the upstream source archive wherever possible, and packaging the upstream source archive within a separate, self-created orig.tar.gz is a practice to be avoided unless there is a very strong reason for it. I believe this holds true for both the 1.0 and 3.0 source formats. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Exact debhelper dependency with format "3.0 (quilt)"
On Sunday 24,January,2010 04:26 AM, Mats Erik Andersson wrote: > Hello all, > > I am converting my first two packages to format "3.0 (quilt)". > Both these will be abandoning the "dh --with quilt $@" rule > for "dh $@" now! > > Hence the build dependency on quilt can be eliminated, but what > about debhelper? Is "debhelper (>= 7.0.50~)" the minimal version > for this source format, or would "7.0.15" as in Lenny suffice? > > Best regards, 7.0.50 is needed if you use override_dh_* rules. Otherwise 7.0.15 should be fine (I think even 7.0.0 would be fine for the dh7 rules style). Grep the debhelper for the debhelper features you need. That should give you the exact version you should put. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
RFS: gtk2-engines-aurora
Dear mentors, I am looking for a sponsor for my package "gtk2-engines-aurora". * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : Richard Stellingwerff * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Section : x11 It builds these binary packages: gtk2-engines-aurora - Aurora gtk+-2.0 theme engine The package appears to be lintian clean. The upload would fix these bugs: 537193 My motivation for maintaining this package is: [fill in]. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora/gtk2-engines-aurora_1.5.1-1.dsc I would be glad if someone uploaded this package for me. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: backup2l (updated package - new upstream release) (2nd try)
On Wednesday 30,December,2009 09:37 PM, Joachim Wiedorn wrote: > Hello, > > Nicolas Alvarez wrote: >> No, Charles is suggesting putting your package files (eg. your rules script) >> in a VCS. > So you mean I should do only the debian directory of the package in an > VCS? Depends on your preference, though I think some VCSes don't have proper support for having the entire upstream tarball contents within. In the case of bzr(-builddeb) and git(-buildpackage), both methods (debian directory alone, or entire source tarball as well) are supported. > Do make this sense for a small package like backup2l? It always makes sense to stick things into a VCS. > As "normal" maintainer (still no DM) I don't can use debian server for > VCS. Is Sourceforge a good idea? Use alioth.debian.org. Anyone can create an account there, and that's where Debian packagers usually host all their Debian packaging VCS repositories. Packaging teams even. See http://wiki.debian.org/Alioth for more information. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: themonospot-*
On Saturday 26,December,2009 10:26 PM, Armando B. wrote: > [...] Hi Armando, Sorry to disappoint you, but the package has already been uploaded to Debian[1] and is currently being maintained by the Debian CLI Applications Team[2], specifically handled by Stefan Ebner. If you are interested in helping out, you should join the team[3][4], and get in touch with Stefan Ebner[5][6]. [1] http://packages.qa.debian.org/t/themonospot.html [2] http://git.debian.org/?p=pkg-cli-apps/packages/themonospot.git;a=summary [3] https://alioth.debian.org/projects/pkg-cli-apps/ [4] #debian-cli @ irc.oftc.net [5] https://alioth.debian.org/users/sebner-guest/ [6] https://launchpad.net/~sebner -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: watch nasty hack
On Monday 07,December,2009 01:01 AM, Jaromír Mikeš wrote: > Hello mentors, > > I having watch file like this: > http://www.kokkinizita.net/linuxaudio/downloads/index.html > jconvolver-(.*)\.tar\.bz2 > > to monitor jconvolver-0.8.4.tar.bz2 , but watch file monitoring > jconvolver-reverbs.tar.bz2 as well and suggesting it as update. > > If modify watch file like this: > http://www.kokkinizita.net/linuxaudio/downloads/index.html > jconvolver-(0.*)\.tar\.bz2 > > This hack is not probably the best solution in case of 1.0.0 release it will > probably stop works. > Anybody knows better solution? > > Thanks for help > > mira > > Try using jconvolver-([0-9.]+)\.tar\.bz2. [0-9.] will match digits and dots, and + means one or more matches. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: DEB_BUILD_OPTIONS=parallel=n work not as expected
This is a good read about GNU Make and the jobserver. http://make.paulandlesley.org/jobserver.html Hopefully this clears up any remaining doubts about -j and --jobserver-fds. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Using ccache with sbuild/schroot
On Saturday 24,October,2009 10:59 PM, Ryan Kavanagh wrote:
> Hi list,
> Has anybody setup ccache in an LVM schroot for sbuild and if so, how? My
> blocking point is that sbuild uses an LVM snapshot of the schroot to build a
> package, which means that any cached compiling would get lost at the end of
> the
> build.
>
> If anybody knows of a way to make this work, or to decrease compile times some
> other way, please let me know :)
>
> Cheers and thanks,
> Ryan
Find a way to bind-mount (mount -o bind / mount --bind) the ccache directory
into the chroot. That way, it won't be lost. In the case of pbuilder, I have
this in my .pbuilderrc:
# ccache stuff
mkdir -p /var/cache/pbuilder/ccache
chmod a+w /var/cache/pbuilder/ccache
export CCACHE_DIR=/var/cache/pbuilder/ccache
export PATH="/usr/lib/ccache:${PATH}"
EXTRAPACKAGES=ccache
BINDMOUNTS=${CCACHE_DIR}
--
Kind regards,
Chow Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: RFS: gtk2-engines-aurora (3rd try)
On Saturday 24,October,2009 07:58 PM, David Bremner wrote: > Chow Loong Jin wrote: > >> [1 ] >> Dear mentors, > >> I am looking for a sponsor for my package "gtk2-engines-aurora". > >> * Package name: gtk2-engines-aurora >> Version : 1.5.1-1 >> Upstream Author : [fill in name and email of upstream] >> * URL : [fill in URL of upstreams web site] >> * License : [fill in] >> Section : x11 > > Perhaps you > My bad, thanks for alerting me to this. * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : Eric Matthews * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Section : x11 -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
RFS: gtk2-engines-aurora (3rd try)
Dear mentors, I am looking for a sponsor for my package "gtk2-engines-aurora". * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : x11 It builds these binary packages: gtk2-engines-aurora - Aurora gtk+-2.0 theme engine The package appears to be lintian clean. The upload would fix these bugs: 537193 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora/gtk2-engines-aurora_1.5.1-1.dsc The package can also be found on git.debian.org: - URL: http://git.debian.org/?p=collab-maint/gtk2-engines-aurora.git - Git repository: git://git.debian.org/collab-maint/gtk2-engines-aurora.git or git+ssh://git.debian.org/git/collab-maint/gtk2-engines-aurora.git I would be glad if someone uploaded this package for me. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: Using symbols files for C++ libraries?
On Friday 16,October,2009 10:54 PM, Felipe Sateler wrote: > Is there a way to do that without going insane? Some sort of wildcards > or shortcuts to the mangled symbols would be great (specially since it > seems the mangling is different on different archs). > I agree with this. Packaging sigx nearly drove me nuts. In the end I removed the symbols files anyway since it wasn't practical to maintain them. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: NMU for libkarma (Rio Karma tools)?
On Thursday 15,October,2009 08:30 AM, Charles Plessy wrote: > Le Wed, Oct 14, 2009 at 03:54:02PM -0500, Boyd Stephen Smith Jr. a écrit : >> On Wednesday 14 October 2009 15:42:21 Harald Dunkel wrote: >>> >>> I want to do an NMU _because_ the package is poorly maintained. libkarma >>> has to be rescued. There is no alternative to this package. >> >> There is a established procedure for taking maintainership for a package >> from >> a non-responsive maintainer. If you'd like to take maintainership, please >> start that process. In the meantime a suitable NMU should be prepared until >> (if) you become the maintainer. >> >> If you don't have time, I wonder if this is a good place for collab-maint to >> step in? > > Hi Harald, > > your NMU would increase the quality of the current package, but would not make > it better maintained, since it is de facto abandonned. Such packages are > indeed > in danger of being removed from Debian. We have to be realistic and do what > our > manpower allows us to. > > If you really think that libkarma has to be rescued (and there are for sure > good reasons), but do not want to maintain it, just lead this package to a new > home, for instance as indicated by Boyd Stephen, and do not hesitate to ask > for > help on this list. Such “QA” work is also really welcome and appreciated, as > bugfixing is. They are two sides of the same coin. > > I hope this does not sound too bureaucratic, but this is a much more long-term > solution to a problem which is not that the package is outdated, but that it > is > abandonned. > > Have a nice day, > Just FYI, libkarma-cil be a build-dependency of Banshee, eventhough the karma-sharp.pc file has been broken for ages and Banshee hadn't actually had Karma support since before 1.4.3 (current version=1.5.1) due to this. If nobody else is willing to take care of it, how about putting it under the Debian CLI Libraries Team? That would take care of the whole libkarma being unmaintained issue. If Harald would join the team, he can maintain it there, and if he's busy someone else, myself included, could fill in for him. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: script-with-language-extension
On Monday 05,October,2009 09:43 AM, Jaromír Mikeš wrote: > BTW: error message for lv2rack is: > --- > $ lv2rack > Traceback (most recent call last): > File "/usr/bin/lv2rack", line 52, in > import zynjacku as zynjacku > -- > > I got warning from other mailing list that this package ships a python module > but it is not compatible > with the python policy. I hope that I solved it but using python-support. > Not sure if these two thing are connected. > > regards > > mira > > You should probably try reading the Debian Python New Policy[1] and getting help from #debian-python on OFTC or debian-pyt...@lists.debian.org. [1] http://wiki.debian.org/DebianPython/NewPolicy -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: script-with-language-extension
On Monday 05,October,2009 08:48 AM, Jaromír Mikeš wrote: > I did it, but it breaks functionality ... there exist also symlinks with same > name and in same location. > > usr/bin/lv2rack > usr/bin/zynjacku > usr/bin/zynspect > -- > usr/bin/lv2rack.py > usr/bin/zynjacku.py > usr/bin/zynspect.py > > Hmmm what about remove these symlink first and then remove suffix? > I am going to try it. How about just mv /usr/bin/lv2rack.py /usr/bin/lv2rack and so on? `lintian-info -t script-with-language-extension` is a good read as to why stuff in /usr/bin/ shouldn't have language extensions (.py, .pl, .sh, etc), by the way. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Skipping the upload of *.deb and *.changes files to m.d.n
On Tuesday 22,September,2009 08:50 PM, José Manuel Santamaría Lema wrote: > Hi, > > I'm a novice and I uploaded some times packages to m.d.n. According to the > home page, binary packages are discarded keeping only the source package. > However every time that I upload a package, _all_ files are uploaded, > including > those that will be discarded by m.d.n. I checked the dput and dupload docs > and > I didn't found any way to avoid the upload of *.deb and *.changes files in > order to save a bit of my time and my bandwith. > > So, I have uploaded to my alioth account a modified version of dput: > http://alioth.debian.org/~santa-guest/dput_0.9.5.1+santa1.dsc > > I checked a bit this list and the dput bug reports, it seems very weird for > me > that nobody complained about this issue. What do you think? > > Cheers, J.M. > > .changes needs to be signed and uploaded. If you wish to save bandwidth, generate your .changes file using debuild -S (builds a source package). -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Test of a package on a specific architecture
On Saturday 12,September,2009 03:35 PM, Pietro Battiston wrote: > Il giorno ven, 11/09/2009 alle 21.31 +0200, Jérémy Lal ha scritto: >> VirtualBox supports 64 bits guests on 32 bits hosts, >> provided you have a cpu that supports virtualization. >> > > Are there any 32 bit cpus around which support virtualization?! Are there any that don't? -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: codelite
On Monday 17,August,2009 04:46 AM, George Danchev wrote: > [...] > >>>> I'm not >>>> actually familiar with Code::Blocks, but I do feel that it would be nice >>> >>> Roughly Code::Blocks resembles MSVC face and look, and in my humble >>> opinion intentionally targets that user base. Nothing wrong with that of >>> course. >>> >>>> to have all of them in Debian (and Ubuntu) to provide more choice to the >>>> end-user. There are bound to be those not satisfied with Code::Blocks >>>> and love CodeLite[1], and vice versa. >>> >>> I'm afraid that if we go that way, we could flood the Debian archive even >>> more with lots of large and hard to maintain packages which tend to be >>> neglected in not so distant future. >> >> Perhaps a team should be started up to maintain different IDEs' packages >> then? I'm sure that would help avoid a situation where the packages are >> neglected. > > Yes, that would be a more fault tolerant approach. However, I do not intend > to > take part of teams around any kind of IDE's, at least not for the time being. > >>>> Picking one would probably create >>>> unnecessary hostility between the two IDEs' communities. >>> >>> ... or instead of provoking hostility this could help competition between >>> these alternatives. I really do like competition and multiple >>> alternatives to choose from, however these packages are large and complex >>> and would probably consume a lot of maintainers time while fighting the >>> bug log, therefore I see nothing wrong to apply Occam razor when >>> selecting amongst such expensive alternatives, maintenance-wise. >> >> I understand your point about the maintainers' time, but I don't really >> agree with your whole idea of this helping competition. Choosing only >> one to enter the archives would necessarily mean omitting the other. > > Right on. Since one of them is more mature and with larger user base, it > seems > more reasonable to me to invest my reviewing time with it. Furthermore, > CodeBlocks has already been looked at by several parties. > >> Rather, if we can find one person who's interested in CodeLite, and >> another interested in Code::Blocks, why not allow them to maintain their >> own packages independently (or collaboratively maintain both) rather >> than alienating one in favour of the other? It's their own time and >> effort they're investing after all. > > I'm afraid we would need the same amount of sponsor's time too to cover both > teams who already spent their own time preparing the packages. If we fail to > meet the former, the latter would be a needless waste of `their own' time... > remember the packages are large and complex, hence the waste would be > proportional. Ah yes, I forgot about sponsor time, sorry. > [...] >> Does that mean I should keep firing off RFS emails at intervals to look >> for reviewers? > > Actually, I don't have a good receipt for finding more reviewers other than > poking -mentors list from time to time. See, that is the tricky part: since > I'm much more familiar and prepared to deal with codeblocks package, I would > need a significant amount of time to get around with codelite (it is not just > to take a look at debian/ directory;-), hence I would think trice what would > be the best course to take before even touch the keyboard ;-) This means that > I'd be very happy if another sponsor takes time to review and hopefully > upload > codelite, while I'll take care of codeblocks when packagers enter the scene, > once again. Nonetheless, I promise to take a look at codelite too at some > point, but can't promise to upload. I'll continue poking the list then. Thanks for your time. :-) -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: khdrecord
On Monday 17,August,2009 03:51 AM, Harry RIckards wrote: > Jonathan Wiltshire wrote: >> On Sun, Aug 16, 2009 at 06:59:47PM +0100, Harry RIckards wrote: >>> Also, the current standards version 3.8.2 not 3.7.3. > >> 3.8.3 now ;) > > > When was that updated? > Taken from http://packages.debian.org/changelogs/pool/main/d/debian-policy/debian-policy_3.8.3.0/changelog, -- Russ Allbery Sat, 15 Aug 2009 17:13:26 -0700 -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: codelite
Hi George, On Monday 17,August,2009 02:42 AM, George Danchev wrote: > [...] >> I actually use a series of IDEs/editors hopping from one to another >> depending on my mood or purpose: emacs, geany, codelite. > > That is something I don't really understand, if not done for fun of course > ;-) > Overwhelmed developers usually do not change their tools lightly. Let's put > it > that way: how is codelite better than geany wrt your goals (I don't really > buy > the `mood' argument;-), we are looking for significant differences here? Simply put, CodeLite's more of a project-based IDE, whereas Geany tends more towards a text editor. For individual files, or if I'm lazy to set up a CodeLite project, I use Geany. If I'm in a terminal, I use emacs or vim. >> I'm not >> actually familiar with Code::Blocks, but I do feel that it would be nice > > Roughly Code::Blocks resembles MSVC face and look, and in my humble opinion > intentionally targets that user base. Nothing wrong with that of course. > >> to have all of them in Debian (and Ubuntu) to provide more choice to the >> end-user. There are bound to be those not satisfied with Code::Blocks >> and love CodeLite[1], and vice versa. > > I'm afraid that if we go that way, we could flood the Debian archive even > more > with lots of large and hard to maintain packages which tend to be neglected > in > not so distant future. Perhaps a team should be started up to maintain different IDEs' packages then? I'm sure that would help avoid a situation where the packages are neglected. > >> Picking one would probably create >> unnecessary hostility between the two IDEs' communities. > > ... or instead of provoking hostility this could help competition between > these alternatives. I really do like competition and multiple alternatives to > choose from, however these packages are large and complex and would probably > consume a lot of maintainers time while fighting the bug log, therefore I see > nothing wrong to apply Occam razor when selecting amongst such expensive > alternatives, maintenance-wise. I understand your point about the maintainers' time, but I don't really agree with your whole idea of this helping competition. Choosing only one to enter the archives would necessarily mean omitting the other. Rather, if we can find one person who's interested in CodeLite, and another interested in Code::Blocks, why not allow them to maintain their own packages independently (or collaboratively maintain both) rather than alienating one in favour of the other? It's their own time and effort they're investing after all. > >> By the way, I am the Ubuntu maintainer for CodeLite. I got it into >> Ubuntu via Revu during my early days of packaging (it was my first from >> scratch) before someone (Iain Lane iirc) convinced me that it's better >> to get packages into Debian and let them be synced into Ubuntu. >> >>> [1] ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570 >>> (lots of interested users, but nothing yet) >>> [2] Jen Lody's unofficial packages, I saw some of my colleagues to use >>> happily: http://apt.jenslody.de/ >>> >>> P.S. and yes, I'm not a fan Eclipse CDT nor I have any feeling with MSVC >>> though I use it daily. >> >> [1] http://krnjevic.com/wp/?p=96 > > That is a very good summary, indeed, but for the time being I saw much more > users of codeblocks. This is not that I'm against codelite, it is just that > I'm looking hard for a good way to invest the effort, maintenance-wise. Code::Blocks would be the more mature project of the lot, considering CodeLite started off from a Code::Blocks plugin. Naturally there would be more Code::Blocks users compared to CodeLite users. > >> P.S. If/When you do review the rest of the package, please note that the >> get-orig-source rule is currently failing miserably due to the whole >> sf.net uscan breakage. You'll have to download the tarball first, rename >> it to codelite_.orig.tar.gz and then use this: >> >> debian/rules get-orig-source VERSION= USCAN=echo >> (Overriding USCAN=echo is to disable all invocations of uscan) >> >> Also, if you upload this package, please use the tarball I've uploaded >> into mentors.debian.net, as that's the same one that's used in Ubuntu's >> CodeLite package. If you regenerate the dfsg tarball and use that >> instead, there will be tarball mismatch issues. > > Sure, that is fine. Let's see when I can find some time to look at it more > closely. Meanwhile, engaging more reviewers would be very nice, in fact. Does that mean I should keep firing off RFS emails at intervals to look for reviewers? -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: codelite
Hi George, On Sunday 16,August,2009 10:30 PM, George Danchev wrote: > [...] > I have some questions which might need a broader discussion, before we > proceed > (I don't place any burden on you to answer them, of course, but your opinion > would be appreciated as well): > > It seems like there is a great part of users who are not so happy with the > current C/C++ IDE available in Debian, hence they are packaging more and more > C/C++ IDE's, like codelite and codeblocks [1], which are both already > available in Ubuntu (can't comment on their quality since I've never used > them > [2]). Packaging and _properly maintaining_ such large and complex code bases > is a tremendous effort, since amongst other things they tend to embed almost > any kind of libraries and external projects (except libc;-) to make their > life > "easier". Therefore having a clear view on the following would probably safe > people's time checking unneeded prospective packages and would hopefully add > quality to existing ones: > > Do we really need more C/C++ IDE's? > Which one: a) codelite, b) codeblocks, c) both, d) other? > (a side note: cooperating with Ubuntu's maintainers seems like a win-win > situation to me). I actually use a series of IDEs/editors hopping from one to another depending on my mood or purpose: emacs, geany, codelite. I'm not actually familiar with Code::Blocks, but I do feel that it would be nice to have all of them in Debian (and Ubuntu) to provide more choice to the end-user. There are bound to be those not satisfied with Code::Blocks and love CodeLite[1], and vice versa. Picking one would probably create unnecessary hostility between the two IDEs' communities. By the way, I am the Ubuntu maintainer for CodeLite. I got it into Ubuntu via Revu during my early days of packaging (it was my first from scratch) before someone (Iain Lane iirc) convinced me that it's better to get packages into Debian and let them be synced into Ubuntu. > > [1] ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570 > (lots of interested users, but nothing yet) > [2] Jen Lody's unofficial packages, I saw some of my colleagues to use > happily: > http://apt.jenslody.de/ > > P.S. and yes, I'm not a fan Eclipse CDT nor I have any feeling with MSVC > though I use it daily. > [1] http://krnjevic.com/wp/?p=96 P.S. If/When you do review the rest of the package, please note that the get-orig-source rule is currently failing miserably due to the whole sf.net uscan breakage. You'll have to download the tarball first, rename it to codelite_.orig.tar.gz and then use this: debian/rules get-orig-source VERSION= USCAN=echo (Overriding USCAN=echo is to disable all invocations of uscan) Also, if you upload this package, please use the tarball I've uploaded into mentors.debian.net, as that's the same one that's used in Ubuntu's CodeLite package. If you regenerate the dfsg tarball and use that instead, there will be tarball mismatch issues. Thanks for your time and attention! :-) -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
RFS: codelite
Dear mentors, I am looking for a sponsor for my package "codelite". * Package name: codelite Version : 1.0.2893+dfsg-1 Upstream Author : Eran Ifrah * URL : http://www.codelite.org * License : GPL-2 Section : devel It builds these binary packages: codelite - Powerful and lightweight C/C++ IDE codelite-plugins - Powerful and lightweight C/C++ IDE - plugins codelite-plugins-abbreviation - Powerful and lightweight C/C++ IDE - abbreviation plugin codelite-plugins-codeformatter - Powerful and lightweight C/C++ IDE - CodeFormatter plugin codelite-plugins-continuousbuild - Powerful and lightweight C/C++ IDE - ContinuousBuild plugin codelite-plugins-copyright - Powerful and lightweight C/C++ IDE - Copyright plugin codelite-plugins-cscope - Powerful and lightweight C/C++ IDE - CScope plugin codelite-plugins-externaltools - Powerful and lightweight C/C++ IDE - ExternalTools plugin codelite-plugins-gizmos - Powerful and lightweight C/C++ IDE - Gizmos plugin codelite-plugins-snipwiz - Powerful and lightweight C/C++ IDE - SnipWiz plugin codelite-plugins-subversion - Powerful and lightweight C/C++ IDE - Subversion plugin codelite-plugins-symbolview - Powerful and lightweight C/C++ IDE - SymbolView plugin codelite-plugins-unittestcpp - Powerful and lightweight C/C++ IDE - UnitTest++ plugin codelite-plugins-wxformbuilder - Powerful and lightweight C/C++ IDE - WXFormBuilder plugin The package appears to be lintian clean. The upload would fix these bugs: 516896 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/codelite - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/codelite/codelite_1.0.2893+dfsg-1.dsc In addition, this package is already in Ubuntu -- http://launchpad.net/ubuntu/+source/codelite I would be glad if someone uploaded this package for me. Thanks in advance. Kind regards Chow Loong Jin signature.asc Description: OpenPGP digital signature
RFS: gtk2-engines-aurora (third try)
Dear mentors, I am looking for a sponsor for my package "gtk2-engines-aurora". * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : Eric Matthews * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Section : x11 It builds these binary packages: gtk2-engines-aurora - Aurora gtk+-2.0 theme engine The package appears to be lintian clean. The upload would fix these bugs: 537193 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora/gtk2-engines-aurora_1.5.1-1.dsc I would be glad if someone uploaded this package for me. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: pbuilder: The following packages have unmet dependencies
On Monday 03,August,2009 06:04 PM, mathieu.malate...@gmail.com wrote: > Hi there, > > I am trying to build a package within pbuilder, but I keep getting: > > $ sudo pbuilder --update > W: /home/mathieu/.pbuilderrc does not exist > ... > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > aptitude: Depends: libapt-pkg-libc6.9-6-4.7 >Depends: libept0 (>= 0.5.26+b1) but it is not going to be > installed > E: Broken packages > Copying back the cached apt archive contents > -> unmounting dev/pts filesystem > -> unmounting proc filesystem > -> cleaning the build env-> removing directory > /var/cache/pbuilder/build//12451 and its subdirectories > > > I tried: > > $ sudo pbuilder --login > W: /home/mathieu/.pbuilderrc does not exist > Building the build Environment > -> extracting base tarball [/var/cache/pbuilder/base.tgz] > -> creating local configuration > -> copying local configuration > -> mounting /proc filesystem > -> mounting /dev/pts filesystem > -> policy-rc.d already exists > Obtaining the cached apt archive contents > -> entering the shell > File extracted to: /var/cache/pbuilder/build//15330 > > r...@gotlib:/# apt-get install aptitude > Reading package lists... Done > Building dependency tree Reading state information... Done > aptitude is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > > Thanks for hints It means aptitude is broken again and you'll have to wait for someone to fix it before you can update your pbuilder. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: problem with git-buildpackage ... I'm missing something
On Friday 31,July,2009 11:55 PM, Pietro Abate wrote: > dpkg-deb: building package `libminisat-ocaml' in > `../libminisat-ocaml_0.3_amd64.deb'. > dpkg-deb: building package `libminisat-ocaml-dev' in > `../libminisat-ocaml-dev_0.3_amd64.deb'. > dpkg-genchanges >../ocaml-minisat_0.3_amd64.changes > dpkg-genchanges: including full source code in upload > dpkg-buildpackage: full upload; Debian-native package (full source is > included) Ah, I see it now. Debian (normal, i.e. non-native) packages have a version that looks like this: -. Assuming that this is the first Debian release of ocaml-minisat 0.3, then your version number should be 0.3-1. However, since your version 0.3 (without the dash, and the debian revision) it gets generated as a debian native package instead, and git-buildpackage ignores your upstream directory. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: ldconfig symlink issue
On Wednesday 29,July,2009 12:38 AM, Harry Rickards wrote: > I apologize for this question, as it's probably easy to answer for > someone experienced in packaging libraries. > > When packaging a shared library, I can't seem to create the symlinks > correctly. If I let the Makefile create the symlinks I get > ldconfig-symlink-is-not-a-symlink, however if I remove the lines that > make the symlinks I get ldconfig-symlink-missing-for-shlib from lintian. > > Again, I apologize for this being a noob question. > A library package should contain the following: /usr/lib/libfoo.so.X (link) => libfoo.so.X.Y.Z /usr/lib/libfoo.so.X.Y.Z (regular file) A library -dev package should contain the following: /usr/lib/libfoo.so (link) => libfoo.so.X.Y.Z and optionally: /usr/lib/libfoo.a (regular file) /usr/lib/libfoo.la (regular file) If I am not mistaken, ldconfig-symlink-is-not-a-symlink arises from a package that contains a file /usr/lib/libfoo.so.X, rather than a symlink, as I've shown above, while ldconfig-symlink-missing-from-shlib arises from a package that does not contain the /usr/lib/libfoo.so.X symlink. You can get more information about a lintian tag by running: $ lintian-info -t http://www.debian.org/doc/debian-policy/ch-sharedlibs.html is a good read, by the way. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: gtk2-engines-aurora (2nd try)
On Sunday 26,July,2009 04:46 AM, Maximiliano Curia wrote: > Left alone my comments, both issues are upstream annoyances. > > Could you please try to convince upstream to publish his releases in an > uscan friendlier manner? Also without the tar inside tar structure? > I've contacted upstream sometime back, before my first RFS request. There was no reply. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: RFS: gtk2-engines-aurora (2nd try)
On Sunday 26,July,2009 03:38 AM, Maximiliano Curia wrote: > My comments are: > - Small typo in debian/control nautral instead of natural > - Doesn't make any sense to have an empty (though commented) watch file > - To have a tar.gz and a tar.bz2 inside the orig.tar.gz is quite ugly, you >are already re building the orig.tar.gz, it might be better to rebuild it >fully, decompressing them all, and avoiding the need of the >ln -s debian aurora-1.5/debian hack. Thanks for your comments. - Typo: fixed - debian/watch: left alone, as per Daniel's comment - The tarball-in-tarball structure is admittedly ugly, but not unheard of, and even though I'm already rebuilding the orig.tar.gz, I'm not unpacking the source bzip2 tarball, just bunzipping it and gzipping it. The symlink hack works rather well, and I don't foresee any trouble that could come from it. I'm rather curious to hear the opinion of a DD though. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
RFS: gtk2-engines-aurora (2nd try)
Dear mentors, I am looking for a sponsor for my package "gtk2-engines-aurora". * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : Eric Matthews * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Section : x11 It builds these binary packages: gtk2-engines-aurora - Aurora gtk+-2.0 theme engine The package appears to be lintian clean. The upload would fix these bugs: 537193 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora/gtk2-engines-aurora_1.5.1-1.dsc I would be glad if someone uploaded this package for me. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: DEB_BUILD_OPTIONS set but dh_strip doesn't notice that?
I forgot to mention earlier, but generally rather than not stripping binaries, you should consider creating a debug package, like foo-dbg or something. Then when you strip the package, do: dh_strip --dbg-package=foo-dbg -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: DEB_BUILD_OPTIONS set but dh_strip doesn't notice that?
On Thursday 16,July,2009 05:41 PM, sobtwmxt wrote: > I have set > > DEB_BUILD_OPTIONS := debug nostrip > > at the beginning of debian/rules. The binaries in debian/pkgName/ > still get stripped. > > 1) Can it be that my DEB_BUILD_OPTIONS are not exported, which causes > dh_strip to strip it? > 2) what should I do, or look, in order to have the binaries not > stripped? You'll need to export it. Something like this: export DEB_BUILD_OPTIONS = debug nostrip -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
RFS: gtk2-engines-aurora
Dear mentors, I am looking for a sponsor for my package "gtk2-engines-aurora". * Package name: gtk2-engines-aurora Version : 1.5.1-1 Upstream Author : Eric Matthews * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Section : x11 It builds these binary packages: gtk2-engines-aurora - Aurora gtk+-2.0 theme engine The package appears to be lintian clean. The upload would fix these bugs: 537193 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtk2-engines-aurora/gtk2-engines-aurora_1.5.1-1.dsc I would be glad if someone uploaded this package for me. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: Help with svn-buildpackage
On Sunday 12,July,2009 09:14 PM, Charles Plessy wrote: > it seems that you are looking for ‘pristine-tar’. Using a repository where all > the sources are checked out as well as the pristine-tar delta, you can > regenerate a binary-identical tarball. Actually, this is implemented for git > repositories in the tool ‘git-buildpackage’. I know it is not Subversion, but > if you do not use the mergeWithUpstream mode of svn-buildpackage, it is an > alternative to really consider. Actually git-buildpackage supports mergeWithUpstream mode as well. You just have to omit all the upstream contents in your git repository. On the other hand, however, pristine-tar won't work well with it. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: rules file and missing dh_shlibdeps
On Friday 10,July,2009 05:58 PM, Jonathan Wiltshire wrote: > If your package is architecture dependent, you should keep the call to > sh_libdeps in case the upstream situation ever changes. If it's Arch: > any, you can safely remove the call. 'Arch: any' means architecture dependent. Perhaps you meant 'Arch: all'? -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: CDBS+get_orig_source+zip_file(2 deep)
On Thursday 02,July,2009 08:57 PM, Adrian Perez wrote: > Hello list. > > I'm seeking guidance about implementing a get-orig-source rule in a > package that uses CDBS; the upstream source is in a zip file inside > another zip file, and I need to integrate this rule using uscan and my > watch file. > Any clues? This[1] is an Ubuntu resource, but it's pretty conformant all the same. The unzipping part you'll have to figure out yourself. The unzip and tar manpages would be a good read, I'd reckon. https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: non-native package versions
On Wednesday 01,July,2009 02:23 AM, Juan Jesús Ojeda Croissier wrote: > The problem we have right now is that we don't really use tarballs for > release our apps. We have some packages that we maintain on our VCS > system, we build them from a buildbot[1] with some custom scripts and > then we upload them with reprepro to our repository. I say just do tarball releases. They can't be that hard to do, right? Just identify snapshots of the history that are stable enough for widespread usage, and then tarball it using one of the methods I highlighted in my previous post. Anyway, regarding your custom scripts.. are they for daily builds? They could be retained IMO, while doing a tarball release at appropriate intervals. > > I know we need to chango some things on the packages to get them into > Debian, but I would like to do it in a way that we still can use for > our project. > Is there any way to do all the *.orig.tgz stuff from the rules file? > Maybe there is a way to keep the /debian directory in out VCS and > generate the tarbal from the rules file before be checked if that > exist. > We are open to any idea :-) > You could write a get-orig-source rule in debian/rules for that purpose. But that is complicated, unnecessary, and ugly. Like I've mentioned in my previous post, there are projects (like smuxi) which keep the debian/ folder in their VCS, but release source tarballs without them, so that they may be packaged in each distribution separately. I cannot see how this would disrupt your existing workflow in any way. -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: non-native package versions
On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: > [...] > And also a kind of retorical one (I guess I know already the > answer...), do I really need to separate the app code from the debian > packaging files? isn't there another option? > I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. If you use autotools, this is very easy. Just run `make dist' in the configured source directory. If you don't, well, you're on your own (hint: tar --exclude=debian if all else fails). > [...] -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: autotools cdbs class and autoconf
On Friday 26,June,2009 02:48 AM, Michał Jaszczyk wrote: > 2009/6/25 Chow Loong Jin : >> On Friday 26,June,2009 02:31 AM, Michał Jaszczyk wrote: >>> I'd like to create a package that uses CDBS. I thought I could use the >>> autotools.mk class but it assumes that configure script already >>> exists. But: I put the sources into our svn and I didn't put configure >>> in there because it can be generated from other files. When our >>> automated build system checks out from svn and performs fakeroot >>> debian/rules binary, it fails because there's no configure script in >>> there. >>> >>> What is the recommended way of handling this situation? I could just >>> put configure into svn, but I'd like to avoid that. I could write my >>> own rules that call autoconf and friends instead of using CDBS. But I >>> don't like any of these two solutions. >>> >>> Regards, >>> >> CDBS can call autoconf and automake to generate the configure script if >> you've told it to do so. See the CDBS documentation regarding the >> autotools class[1] for more details. >> >> [1] http://build-common.alioth.debian.org/cdbs-doc.html#id2540579 >> -- >> Regards, >> Chow Loong Jin >> >> > > Do you mean DEB_AUTO_UPDATE_AUTOCONF and > DEB_AUTO_UPDATE_AUTOMAKE? CDBS documentation says that these two > variables are used to specify versions of those tools. And usage of > them is discouraged, why? Because the clean rule in debian/rules is supposed to revert the source tree to the exact state it was before, or at the very least, it must be able to build twice in a row like this: $ fakeroot debian/rules binary $ fakeroot debian/rules clean $ fakeroot debian/rules binary The debs produced by the two `debian/rules binary' calls should be equivalent. Another thing is that you should be able to create a clean source package out of the source directory which has been built from before. By "clean", I mean that the resulting diff.gz will not have any changes to files which are not in debian/. If autoconf and automake are called, it usually changes the configure script, the Makefile.in files, as well as the config.* files, irreversibly unless you back them up and restore them using the clean rule. This can, of course, be worked around by deleting all Makefile.in files in the clean rule. It won't be back to the original state, but at the very least, the build should be reproducible. Also, dpkg-source does not take into account deleted files, so building a source package from a source directory that has already been built from will not pollute the resultant .diff.gz with files that aren't in debian/. -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: drcom-pum
On Thursday 25,June,2009 10:39 PM, Henry Huang wrote: > my dh = 7.0.13 < 7.0.50 > It seems "override" could not take effects. > > How to solve this problem -- i got no idea :( Install a newer debhelper package, and specify in your package's build-depends debhelper (>= 7.0.50). =) > > uscan warning: In debian/watch, > no matching hrefs for watch line > http://www.drcom-client.org/en/downloads/ > http://www.drcom-client.org/downloads/packages/src/drcom-pum-(.*)\.tar\.gz Try this: http://www.drcom-client.org/en/downloads/linux.html \ .*/drcom-pum-(.*)\.tar\.gz > > On Thu, Jun 25, 2009 at 10:18 PM, Peter Pentchev wrote: >> On Thu, Jun 25, 2009 at 04:12:39PM +0200, Jan Hauke Rahm wrote: >>> On Thu, Jun 25, 2009 at 09:54:44PM +0800, Henry Huang wrote: >>>> However, i need to specify the name of init script and drcomclient >>>> manpage as follows: >>>> >>>> dh_installinit --name=drcom >>>> dh_installman --name=drcom >>> >>> No problem with dh7 as well: >>> >>> | #!/usr/bin/make -f >>> | >>> | %: >>> | dh $@ >>> | >>> | override_dh_installinit: >>> | dh_installinit --name=drcom >>> | >>> | override_dh_installman: >>> | dh_installman --name=drcom >> >> Note that, as I said in my reply, the override targets appear in >> debhelper 7.0.50 (or, usually, 7.2.x), not just 7. >> >> G'luck, >> Peter >> >> -- >> Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org >> PGP key:http://people.FreeBSD.org/~roam/roam.key.asc >> Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 >> This sentence was in the past tense. >> > > -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: mount-systray
On Thursday 25,June,2009 09:00 PM, Juan Jesús Ojeda Croissier wrote: > Hummm So, I wasn't wrong :-P Yes you were. > This software was created for a Debian-derived distribution > (Guadalinex). Maybe it's possible to change the packaging or compile > from the sources, but it wasn't the initial idea and it is not > supported by us. It is software for a Debian-derived distributions. There is nothing Debian specific about mounting or unmounting devices. It can be used just as easily on non-Debian systems as it can be on Debian. This already makes it a non-native package. Native packages are stuff like debhelper, lintian, apt, aptitude, etc. These are Debian-specific and a core part of what makes Debian Debian. > > Probably, if more distros (Debian, Ubuntu, LinEx, Molinux and others > Debian-derived distributions) start to use it and we see other distros > like to use it, we'll convert it into upstream project (maybe in > GNOME) and the package will be changed into non-native one. But by now > we can't assure that the code itself will work in another distro. We > haven't tried it, neither we have prepared it for supporting it. You (as the upstream) not having prepared yourself for supporting it on other distributions does not make this package a Debian native package. As Boyd said, "If you can think of *any* reason that openSUSE, Fedora, or Gentoo (users) would want to use the software (albeit with different packaging) you should use normal (non-native) packaging." From what you've said, it would seem that there definitely is a reason for users of other distributions to use it. > > If you guys still see this as a non-native package, we'll change it, > but IMHO, at least right now, it is a native package. IMHO, it is not. :) Matthew Palmer's debian-mentors FAQ[1] is a good read, by the way. Scroll down to the section "What is the difference between a native Debian package and a non-native package?" [1] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Generating lintian-overrides file?
On Thursday 25,June,2009 06:52 PM, Erik de Castro Lopo wrote: > Chow Loong Jin wrote: > >> You could, but I am not aware of any lintian tag specifying the version >> of the package in it. Could you post the output of lintian exactly? > > Sorry, I think you misunderstood. Lintian complains about the file: > > > usr/lib/haskell-packages/ghc6/lib/Cabal-1.6.0.3/ghc-6.10.3/Distribution/License.hi > > The hand generated lintian overrides file contains this: > > libghc6-cabal-dev binary: extra-license-file > usr/lib/haskell-packages/ghc6/lib/Cabal-1.6.0.3/ghc-6.10.3/Distribution/License.hi > > However, every time the compiler version changes (6.10.3 above) or the > package version number changes (1.6.0.3 above) I need to hand edit the > overrides file. > > Hence, I'd like to autogenerate this file. I'm using CDBS, so the normal > debian/rules solutions don't work. > > Erik I see. In that case, you can generate the pkg.lintian-overrides file in any of the CDBS extension rules before dh_lintian is called. dh_lintian is called in binary-install/. So just stick it into any rule before that. -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Generating lintian-overrides file?
On Thursday 25,June,2009 05:35 PM, Erik de Castro Lopo wrote: > Hi all, > > I'm packaging something with has an installable file called License.hi > which is not a license file, but gets caught by the extra-license-file > lintian warning. > > I can add a pkgname.lintian-override file, but the path in the override > file has the package version number embedded in it. > > Is there some way I can autogenerate this lintian-override file? > > Cheers, > Erik You could, but I am not aware of any lintian tag specifying the version of the package in it. Could you post the output of lintian exactly? -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: CDBS - how to source a shell fragement before running ./configure?
On Tuesday 23,June,2009 07:51 PM, Carsten Aulbert wrote: > Hi Peter, > > Peter Eisentraut wrote: > >> It's a bit daring, but the following might work: >> >> DEB_CONFIGURE_INVOKE := . opt/foo/bar.sh ; $(DEB_CONFIGURE_INVOKE) >> >> > I need to add to daringness (Since LD_LIBRARY_PATH needs to be added to > as well at make time): > > DEB_MAKE_INVOKE := . opt/foo/bar.sh ; $(DEB_MAKE_INVOKE) > > then it seems to work, although it makes me shudder quite a bit. > > But thanks a lot for the hint! > > Cheers > > Carsten > Perhaps I'm missing something, but is your script meant to just export environment variables? If that is so, why don't you just add a bunch of export statements at the top of your debian/rules? -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: trouble with packaging
On Tue, 2009-06-02 at 19:25 -0700, Daniel Moerner wrote: > On Tue, Jun 2, 2009 at 10:31 AM, Brendan Martens > wrote: > > Your change worked! : ) Thanks very much. > > So if I understand this correctly... I need to edit debian/rules so that the > > build section works as if I told make install to install to > > debian/program_name, using DESTDIR? > > Yes, you want to install the package into a local location, this being > debian/program_name for modern packages, debian/tmp for some legacy (I > think its debhelper compatability level 4 or earlier but I may be > totally off here) debian/package_name for single-binary packages, debian/tmp for multi-binary packages. dh_install looks into debian/tmp by default, starting from debian/compat >= 7. -- Regards, Chow Loong Jin signature.asc Description: This is a digitally signed message part
RFS: sigx (second attempt)
Dear mentors, I am looking for a sponsor for my package "sigx". * Package name: sigx Version : 2.0.2-1 Upstream Author : kl...@triendl.eu * URL : http://www.assembla.com/spaces/sigx * License : LGPL-2+ Section : devel It builds these binary packages: libsigx-2.0-2 - interthread communication library for C++ - runtime libsigx-2.0-dev - interthread communication for C++ - development files libsigx-2.0-doc - interthread communication for C++ - reference documentation The package appears to be lintian clean. The upload would fix these bugs: 492215 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sigx - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sigx/sigx_2.0.2-1.dsc - gitweb: http://git.debian.org/?p=collab-maint/sigx.git - git clone git://git.debian.org/git/collab-maint/sigx.git I would be glad if someone uploaded this package for me. -- Kind Regards, Chow Loong Jin signature.asc Description: This is a digitally signed message part
RFS: sigx (second attempt)
Dear mentors, I am looking for a sponsor for my package "sigx". * Package name: sigx Version : 2.0.2-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : devel It builds these binary packages: libsigx-2.0-2 - interthread communication library for C++ - runtime libsigx-2.0-dev - interthread communication for C++ - development files libsigx-2.0-doc - interthread communication for C++ - reference documentation The package appears to be lintian clean. The upload would fix these bugs: 492215 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sigx - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sigx/sigx_2.0.2-1.dsc - gitweb: http://git.debian.org/?p=collab-maint/sigx.git - git clone git://git.debian.org/git/collab-maint/sigx.git I would be glad if someone uploaded this package for me. Kind regards Chow Loong Jin -- Regards, Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: make in pbuilder error
On Sat, 2009-04-18 at 21:25 +0200, Jaromír Mikeš wrote: > Hello , > > I have error output in pbuilder in "make" stage of process. > But when I running make command outside pbuilder everything is fine. > I think that I satisfied all dependencies in debian/control file. > > Any advice is very appreciated > > regards > > mira > > /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -g -O2 -version-info > 1:0:0 -Wl,-z,defs -o liblv2dynparamhost1.la -rpath /usr/lib host.lo > host_callbacks.lo audiolock.lo log.lo memory_atomic.lo helpers.lo hint_set.lo > > gcc -shared .libs/host.o .libs/host_callbacks.o .libs/audiolock.o > .libs/log.o .libs/memory_atomic.o .libs/helpers.o .libs/hint_set.o -Wl,-z > -Wl,defs -Wl,-soname -Wl,liblv2dynparamhost1.so.1 -o > .libs/liblv2dynparamhost1.so.1.0.0 > .libs/host.o: In function `lv2dynparam_host_notify_group_disappeared': > /tmp/buildd/lv2dynparam1-2/host/host.c:351: undefined reference to > `dynparam_ui_group_disappeared' > .libs/host.o: In function `lv2dynparam_host_group_hide': > /tmp/buildd/lv2dynparam1-2/host/host.c:672: undefined reference to > `dynparam_ui_parameter_disappeared' > .libs/host.o: In function `lv2dynparam_host_notify_group_appeared': > /tmp/buildd/lv2dynparam1-2/host/host.c:323: undefined reference to > `dynparam_ui_group_appeared' > .libs/host.o: In function `lv2dynparam_host_notify': > /tmp/buildd/lv2dynparam1-2/host/host.c:571: undefined reference to > `dynparam_ui_parameter_appeared' > /tmp/buildd/lv2dynparam1-2/host/host.c:625: undefined reference to > `dynparam_ui_parameter_value_changed' > /tmp/buildd/lv2dynparam1-2/host/host.c:592: undefined reference to > `dynparam_ui_parameter_disappeared' > .libs/audiolock.o: In function `audiolock_enter_audio': > /tmp/buildd/lv2dynparam1-2/host/../audiolock.c:68: undefined reference to > `pthread_mutex_trylock' > collect2: ld returned 1 exit status > > It's not linking. The compile command is missing some flags which are -lpthread, and -lsomethingelse, but I'm not sure what that somethingelse is. Or perhaps it's missing an object file. There's too little information to tell. How about that particular section of output when it actually succeeds? -- Regards, Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: pdebuild, not removing build environment
On Sat, 2009-04-11 at 13:57 +0300, Eric Pozharski wrote: > On Fri, Apr 10, 2009 at 10:14:07AM +0000, Chow Loong Jin wrote: > > On Fri, 2009-04-10 at 11:39 +0300, Eric Pozharski wrote: > > > On Fri, Apr 10, 2009 at 12:36:50AM +0800, Chow Loong Jin wrote: > > > > On Thu, 2009-04-09 at 18:21 +0200, أحمد المحمودي wrote: > > > > > On Thu, Apr 09, 2009 at 04:51:35PM +0200, Gudjon I. Gudjonsson wrote: > > > > > > Sorry if I have missed something obvious but, in case of error > > > > > > during > > > > > > build. How can I keep the pbuilder environment when I use pdebuild. > > > > > > I don't > > > > > > want pdebuild to remove the chroot environment after the error > > > > > > occurs. > > > > > ---end quoted text--- > > > > > > > > > > Well, the only method that I know is do a pbuilder login, then I > > > > > build > > > > > the package (after manually apt-get'ing its Build-Deps), so: > > > > > > > > > > $ pbuilder login > > > > > # apt-get install > > > > > # dpkg-source -x .dsc > > > > > # cd > > > > > # ./debian/rules build (or whatever) > > > > > > > > A hook would save you all that trouble. I have a hook called C00Bash > > > > which looks like this: > > > > 8<= > > > > #!/bin/sh > > > > exec bash > > > > >8= > > > > > > > > After a build (only if there's a failure), it'll drop to a Bash prompt > > > > within the chroot, whereby you can head to /tmp/buildd/ and examine why > > > > things went the way they did. > > > > > > (just my 2cent) Someone interested could develop a hook that after > > > looking for parent processes (it should go far enough) just would kill > > > pbuilder. This must be SIGKILL; otherwise the signal could be trapped. > > > > > > p.s I'm not interested -- so I'm not that someone. > > > > > Just replace "exec bash" with "killall -9 pbuilder". But seriously it's > > pointless. If you keep the Bash prompt from that hook I posted earlier > > open, you can poke around inside the chroot, and if you wish, you could > > do the killing of pbuilder yourself, as it'll wait for you to close that > > prompt. > > Exactly. But OP wanted to keep tree (for unknown reason). > > Probably to inspect it post-fail. Which is doable with the bash hook =) -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: pdebuild, not removing build environment
On Fri, 2009-04-10 at 11:39 +0300, Eric Pozharski wrote: > On Fri, Apr 10, 2009 at 12:36:50AM +0800, Chow Loong Jin wrote: > > On Thu, 2009-04-09 at 18:21 +0200, أحمد المحمودي wrote: > > > On Thu, Apr 09, 2009 at 04:51:35PM +0200, Gudjon I. Gudjonsson wrote: > > > > Sorry if I have missed something obvious but, in case of error > > > > during > > > > build. How can I keep the pbuilder environment when I use pdebuild. I > > > > don't > > > > want pdebuild to remove the chroot environment after the error occurs. > > > ---end quoted text--- > > > > > > Well, the only method that I know is do a pbuilder login, then I build > > > the package (after manually apt-get'ing its Build-Deps), so: > > > > > > $ pbuilder login > > > # apt-get install > > > # dpkg-source -x .dsc > > > # cd > > > # ./debian/rules build (or whatever) > > > > A hook would save you all that trouble. I have a hook called C00Bash > > which looks like this: > > 8<= > > #!/bin/sh > > exec bash > > >8= > > > > After a build (only if there's a failure), it'll drop to a Bash prompt > > within the chroot, whereby you can head to /tmp/buildd/ and examine why > > things went the way they did. > > (just my 2cent) Someone interested could develop a hook that after > looking for parent processes (it should go far enough) just would kill > pbuilder. This must be SIGKILL; otherwise the signal could be trapped. > > p.s I'm not interested -- so I'm not that someone. > Just replace "exec bash" with "killall -9 pbuilder". But seriously it's pointless. If you keep the Bash prompt from that hook I posted earlier open, you can poke around inside the chroot, and if you wish, you could do the killing of pbuilder yourself, as it'll wait for you to close that prompt. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: pdebuild, not removing build environment
On Thu, 2009-04-09 at 18:21 +0200, أحمد المحمودي wrote: > Hello, > > On Thu, Apr 09, 2009 at 04:51:35PM +0200, Gudjon I. Gudjonsson wrote: > > Sorry if I have missed something obvious but, in case of error during > > build. How can I keep the pbuilder environment when I use pdebuild. I don't > > want pdebuild to remove the chroot environment after the error occurs. > ---end quoted text--- > > Well, the only method that I know is do a pbuilder login, then I build > the package (after manually apt-get'ing its Build-Deps), so: > > $ pbuilder login > # apt-get install > # dpkg-source -x .dsc > # cd > # ./debian/rules build (or whatever) A hook would save you all that trouble. I have a hook called C00Bash which looks like this: 8<= #!/bin/sh exec bash >8= After a build (only if there's a failure), it'll drop to a Bash prompt within the chroot, whereby you can head to /tmp/buildd/ and examine why things went the way they did. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: pdebuild, not removing build environment
On Thu, 2009-04-09 at 16:51 +0200, Gudjon I. Gudjonsson wrote: > Hi > Sorry if I have missed something obvious but, in case of error during > build. How can I keep the pbuilder environment when I use pdebuild. I don't > want pdebuild to remove the chroot environment after the error occurs. Not possible. At least, it's not documented in the manpage, or I've missed it out. If you want, you can spawn a shell if build fails, before pbuilder wipes out using a hook. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: upload to git.debian.org
On Sun, 2009-04-05 at 18:25 +0800, Chow Loong Jin wrote: > alioth:~$ cd /git/pkg-multimedia > alioth:/git/pkg-multmedia$ ./setup-repository > alioth:/git/pkg-multimedia$ ^D > local:~$ git clone ssh://usern...@git.debian.org/git/.git > local:~$ cd > ## do stuff! No wait, not git clone. You have to push to ssh://usern...@git.debian.org/git/.git. Basically setup-repository does the whole git init --bare thing for you. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: upload to git.debian.org
On Sun, 2009-04-05 at 12:16 +0200, Grammostola Rosea wrote: > Chow Loong Jin wrote: > > On Sun, 2009-04-05 at 12:03 +0200, David Paleino wrote: > > > >> On Sun, 05 Apr 2009 17:34:17 +0800, Chow Loong Jin wrote: > >> > >> > >>> In most cases I think a setup-repository script exists > >>> in /git/projectname. I know it does for pkg-cli-* and collab-maint. > >>> > >> It only exists on collab-maint, and copied multiple times over /git/*/. It > >> was > >> me who adapted it for pkg-cli-* ;) > >> > >> David > >> > >> > > The following have it: > > bash-completion/setup-repository > > collab-maint/setup-repository > > pkg-boinc/setup-repository > > pkg-cli-apps/setup-repository > > pkg-cli-libs/setup-repository > > pkg-games/setup-repository > > pkg-multimedia/setup-repository > > pkg-perl/setup-repository > > pkg-pnet/setup-repository > > pkg-xorg/setup-repository > > > > The thread was regarding pkg-multimedia to begin with, and it has a > > setup-repository =) > > > > So I can use such a script for pkg-multimedia? Why is it useful and how > to use it? > > \r > > alioth:~$ cd /git/pkg-multimedia alioth:/git/pkg-multmedia$ ./setup-repository alioth:/git/pkg-multimedia$ ^D local:~$ git clone ssh://usern...@git.debian.org/git/.git local:~$ cd ## do stuff! -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: upload to git.debian.org
On Sun, 2009-04-05 at 12:03 +0200, David Paleino wrote: > On Sun, 05 Apr 2009 17:34:17 +0800, Chow Loong Jin wrote: > > > In most cases I think a setup-repository script exists > > in /git/projectname. I know it does for pkg-cli-* and collab-maint. > > It only exists on collab-maint, and copied multiple times over /git/*/. It was > me who adapted it for pkg-cli-* ;) > > David > The following have it: bash-completion/setup-repository collab-maint/setup-repository pkg-boinc/setup-repository pkg-cli-apps/setup-repository pkg-cli-libs/setup-repository pkg-games/setup-repository pkg-multimedia/setup-repository pkg-perl/setup-repository pkg-pnet/setup-repository pkg-xorg/setup-repository The thread was regarding pkg-multimedia to begin with, and it has a setup-repository =) -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: upload to git.debian.org
On Sun, 2009-04-05 at 11:26 +0200, Grammostola Rosea wrote: > Lionel Elie Mamane wrote: > > On Sun, Apr 05, 2009 at 10:37:40AM +0200, David Paleino wrote: > > > >> On Sun, 05 Apr 2009 10:19:19 +0200, Grammostola Rosea wrote: > >> > > > > > >>> The Debian Multimedia Team likes to have packages on git.debian.org, > >>> http://git.debian.org/git/pkg-multimedia/ . > >>> > > > > > >> Here's how to have a git repository [0] created by the Alioth admins: > >> > > > > > >> http://wiki.debian.org/Alioth/Git > >> > > > > Yes, but the only situation where they have to get involved is a > > directory for a repository for a new project; if you intend to put it > > in pkg-multimedia, you need to: > > > > 1) be a member of the pkg-multimedia project > > > > 2) ssh git.debian.org > > cd /git/pkg-multimedia/ > > mkdir NEWDIR.git > > cd NEWDIR.git > > git init --bare --shared=all > > sensible-editor description > > > > (replace NEWDIR by something descriptive, such as the name of the > > package) > > > > Or you can use a personal git in the beginning of a package, before it > > goes under the umbrella of a project. To do that: > > > > ssh git.debian.org > > mkdir public_git > > cd public_git > > mkdir NEWDIR.git > > cd NEWDIR.git > > git init --bare --shared=all > > sensible-editor description > > > > > Ah, I think this is what I'm looking for. > > Thanks. > > \r > > In most cases I think a setup-repository script exists in /git/projectname. I know it does for pkg-cli-* and collab-maint. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: /doc and/or manpage
On Fri, 2009-04-03 at 20:35 +0200, Grammostola Rosea wrote: > Jan Beyer wrote: > > Und es begab sich am 03.04.2009 17:55, dass Grammostola Rosea schrieb: > > > >> I have included a rumor.1 file in my /debian folder, but when building > >> it and install it, I got no manpage... > >> > > You're also calling dh_installman in debian/rules? > > > > Jan > > > > > I use cdbs, so I don't know how it is managed... > > \r > > You need a package.manpages file listing all your manpages. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: warning messages
On Thu, 2009-04-02 at 19:51 +0200, Jaromír Mikeš wrote:
> Hello mentors,
>
> I have some warning messages during build a package.
> Can somebody please look at them if they are serious?
>
> ###
>
> dpkg-shlibdeps: warning: symbol dlsym used by
> debian/libslv2-9/usr/lib/libslv2.so.9.1.1 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol dlopen used by
> debian/libslv2-9/usr/lib/libslv2.so.9.1.1 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol dlclose used by
> debian/libslv2-9/usr/lib/libslv2.so.9.1.1 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol dlerror used by
> debian/libslv2-9/usr/lib/libslv2.so.9.1.1 found in none of the libraries.
^^ Not sure about these.
> dpkg-shlibdeps: warning: dependency on librasqal.so.1 could be avoided if
> "debian/libslv2-9/usr/lib/libslv2.so.9.1.1" were not uselessly linked against
> it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on librasqal.so.1 could be avoided if
> "debian/slv2/usr/bin/lv2_simple_jack_host debian/slv2/usr/bin/lv2_inspect
> debian/slv2/usr/bin/lv2_list debian/slv2/usr/bin/lv2_jack_host" were not
> uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on librdf.so.0 could be avoided if
> "debian/slv2/usr/bin/lv2_simple_jack_host debian/slv2/usr/bin/lv2_inspect
> debian/slv2/usr/bin/lv2_list debian/slv2/usr/bin/lv2_jack_host" were not
> uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libraptor.so.1 could be avoided if
> "debian/slv2/usr/bin/lv2_simple_jack_host debian/slv2/usr/bin/lv2_inspect
> debian/slv2/usr/bin/lv2_list debian/slv2/usr/bin/lv2_jack_host" were not
> uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if
> "debian/slv2/usr/bin/lv2_simple_jack_host debian/slv2/usr/bin/lv2_jack_host"
> were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if
> "debian/slv2/usr/bin/lv2_simple_jack_host debian/slv2/usr/bin/lv2_jack_host"
> were not uselessly linked against it (they use none of its symbols).
^^ Refer to the thread about -Wl,--as-needed in debian-mentors.
> dh_gencontrol
> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
^^ Can be safely ignored. Basically means that the said libraries do not
have any shared lib dependencies.
--
Chow Loong Jin
signature.asc
Description: This is a digitally signed message part
Re: pbuilder and building a package twice in a row with hook-skript?
On Thu, 2009-04-02 at 15:07 +1100, Ben Finney wrote: > > I'm not asking about buildd, but ‘pbuilder’. > > Do the ‘B*’ hooks get run once per package, or once after all packages > are built? How does a hook know which package is being built, and what > identifier is available for use inside the hook? > I'd test it if I were you. And sorry for wording it wrongly, but I also meant pbuilder. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Using a pbuilder hook to test install/remove process
On Thu, 2009-04-02 at 11:32 +1100, Ben Finney wrote: > I've been made aware of ‘piuparts’. Would it make sense to have a hook > to run this command, on the newly-built package, inside the ‘pbuilder’ > chroot? How would such a hook program get access to the file name of > the binary package? I think you should look at the lintian hook example in /usr/share/doc/pbuilder/examples. That could possibly be copied and modified to use piuparts. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: pbuilder and building a package twice in a row with hook-skript?
On Thu, 2009-04-02 at 10:26 +1100, Ben Finney wrote: > I'm still stumbling my way around with customising ‘pbuilder’. Is the > ‘for’ loop necessary in the above hook? Or am I right in thinking > these hook programs will be run once per package anyway? No, it is needed, since it's all built in the same buildd I should think. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: double slash
On Wed, 2009-04-01 at 21:13 +0200, Jaromír Mikeš wrote: > > Od: Russ Allbery > > > Jaromír Mikeš writes: > > > > /tmp/buildd/slv2-0.6.2/debian/slv2/usr/include//slv2/pluginclass.h > > > > > > Can be double slash behind include problem? > > > > As mentioned already, this isn't a problem. If you were curious why it's > > happening, it's generally because upstream has written their makefiles to > > install files into: > > > > $(DESTDIR)/$(prefix) > > > > instead of: > > > > $(DESTDIR)$(prefix) > > Thank you ... good to know it is not a problem. > > I am building library with four packages. > And I need to spread installed files to packages using packagename.install > files. > > I am trying using: > > dh_install -i --sourcedir=debian/slv2 > and > dh_install -s --sourcedir=debian/svl2 > > > I am getting error: > cp: cannot stat `debian/svl2//usr/share/doc/slv2': No such file or directory > dh_install: cp returned exit code 1 > > Path is from my packagename.install file. > > But I can see from install process that files like this was installed. > > e.g. > /tmp/buildd/slv2-0.6.2/debian/slv2/usr/share/doc/slv2/files.html > > Any idea what can be wrong? > > regards > > mira > > It could have been clobbered. I think you should spawn a shell just before the buildd is wiped (if you're using a pbuilder, use a hook) and poke around the said folder. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: double slash
On Wed, 2009-04-01 at 11:16 -0700, Russ Allbery wrote: > Jaromír Mikeš writes: > > > I am building library with four packages. And I need to spread > > installed files to packages using packagename.install files. > > > > I have a problem here with this. I notice that install process yielding > > files like: > > > > /tmp/buildd/slv2-0.6.2/debian/slv2/usr/include//slv2/pluginclass.h > > > > Can be double slash behind include problem? > > As mentioned already, this isn't a problem. If you were curious why it's > happening, it's generally because upstream has written their makefiles to > install files into: > > $(DESTDIR)/$(prefix) > > instead of: > > $(DESTDIR)$(prefix) > > I used to write my makefiles that way too. It's hard to shake the feeling > that there should be a slash in there. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> > > Looking at where the extra / is, I'd think more like: pkgincludedir = $(includedir)/slv2 rather than pkgincludedir = $(includedir)slv2 -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: double slash
On Wed, 2009-04-01 at 19:11 +0200, Jaromír Mikeš wrote: > Hello mentors, > > I am building library with four packages. > And I need to spread installed files to packages using packagename.install > files. > > I have a problem here with this. I notice that install process yielding files > like: > > /tmp/buildd/slv2-0.6.2/debian/slv2/usr/include//slv2/pluginclass.h > > Can be double slash behind include problem? Doesn't matter. It'll still resolve to the same path. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: How to get an sponsor (need a bit more info)
On Tue, 2009-03-31 at 21:00 +0200, Grammostola Rosea wrote: > Hi, > > O, I've uploaded an packages and requested for an sponsor, also mailed > it to the list. What is next? Wait and see? But what if potential > sponsors are not satisfied with my package? Can I get some comments, or > does this mean I sit and wait for nothing? It's my first package so, > would be nice if I get feedback if it needs improvements... > > \r > > From what I can tell... Wait until a sponsor has seen your package. If there is a problem, the sponsor should contact you, and if there isn't, it'll be uploaded, after which you will be contacted by your sponsor to notify you that it has been uploaded. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: copyright, authors of little files in app
On Mon, 2009-03-30 at 15:23 +0400, Dmitry E. Oboukhov wrote: > > I had been rejected from NEW-stage a few times because some copyright > records was not included into the debian/copyright. Since last reject > I have been doing "grep -ir '(c)' ." in src-tree and add results into > debian/copyright. It works very well :) I think 'licensecheck' which is in the devscripts package would serve you well. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
RFS: remuco-server (edited to fill in missing information)
Dear mentors, I am looking for a sponsor for my package "remuco-server". * Package name: remuco-server Version : 0.8.0.1-1 Upstream Author : Oben Sonne * URL : http://remuco.sf.net/ * License : GPL-3 Section : sound It builds these binary packages: remuco-amarok - duplex remote control for media players - Amarok adapter remuco-audacious - duplex remote control for media players - Audacious adapter remuco-banshee - duplex remote control for media players - Banshee adapter remuco-base - duplex remote control for media players - base remuco-rhythmbox - duplex remote control for media players - Rhythmbox adapter remuco-totem - duplex remote control for media players - Rhythmbox adapter remuco-xmms2 - duplex remote control for media players - Rhythmbox adapter The package appears to be lintian clean. The upload would fix these bugs: 416379 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/remuco-server - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/remuco-server/remuco-server_0.8.0.1-1.dsc The package can also be found in git: - clone: git://git.debian.org/git/collab-maint/remuco-server.git - browse: http://git.debian.org/?p=collab-maint/remuco-server.git I would be glad if someone uploaded this package for me. Some additional information: "remuco-server" is a source package that does not contain the precompiled binary .jar that was discussed previously here and in debian-legal. The .jar was released separately in "remuco-client", which I will be packaging separately in hopes of getting it into contrib. Kind regards -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
RFS: remuco-server
Dear mentors, I am looking for a sponsor for my package "remuco-server". * Package name: remuco-server Version : 0.8.0.1-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : sound It builds these binary packages: remuco-amarok - duplex remote control for media players - Amarok adapter remuco-audacious - duplex remote control for media players - Audacious adapter remuco-banshee - duplex remote control for media players - Banshee adapter remuco-base - duplex remote control for media players - base remuco-rhythmbox - duplex remote control for media players - Rhythmbox adapter remuco-totem - duplex remote control for media players - Rhythmbox adapter remuco-xmms2 - duplex remote control for media players - Rhythmbox adapter The package appears to be lintian clean. The upload would fix these bugs: 416379 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/remuco-server - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/remuco-server/remuco-server_0.8.0.1-1.dsc The package can also be found in git: - clone: git://git.debian.org/git/collab-maint/remuco-server.git - browse: http://git.debian.org/?p=collab-maint/remuco-server.git I would be glad if someone uploaded this package for me. Some additional information: "remuco-server" is a source package that does not contain the precompiled binary .jar that was discussed previously here and in debian-legal. The .jar was released separately in "remuco-client", which I will be packaging separately in hopes of getting it into contrib. Kind regards -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Fri, 2009-03-27 at 14:43 +0100, gregor herrmann wrote: > On Fri, 27 Mar 2009 17:30:35 +0800, Chow Loong Jin wrote: > > > > AFAICS the source package contains the source for > > > gnapplet but it's not built but the pre-compiled .sis is installed > > > into /usr/share/doc/gammu/symbian/. > > I see. And gammu is in main? > > Yes, that's what `apt-cache policy gammu' tells me :) Ah yes, thanks. > > > Then perhaps this case would be fine too, > > because the next remuco tarball which upstream is releasing should > > contain the .jar file as well as the sources for it. I'll just install > > the said .jar into /usr/share/doc/remuco-base then. > > I suppose that's ok, but I'd check with the ftp-masters before > uploading. > Alright, who should I contact? ftpmas...@debian.org? Either way, I'd still need to look for a sponsor, but that'll be after upstream releases a new tarball with the sources for the .jar -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Fri, 2009-03-27 at 02:10 +0100, gregor herrmann wrote: > > Another precedent (and quite similar, since it's also an application > for a mobile phone, just symbian instead of java) is gnapplet.sis, > shipped in gammu. AFAICS the source package contains the source for > gnapplet but it's not built but the pre-compiled .sis is installed > into /usr/share/doc/gammu/symbian/. > I see. And gammu is in main? Then perhaps this case would be fine too, because the next remuco tarball which upstream is releasing should contain the .jar file as well as the sources for it. I'll just install the said .jar into /usr/share/doc/remuco-base then. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Thu, 2009-03-26 at 10:53 -0700, Russ Allbery wrote: > That would mean it should go into contrib, which is for DFSG-free > things > that can't be built or used without non-free bits. I'm actually considering using a postinst script to tell the user that there is a .jar that they need to download and upload to their phone, and possibly wget it as well. Either that or put details about this in README.Debian. Supposing I do either one of the above, would it still go into contrib, or can it go into main? -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Thu, 2009-03-26 at 18:15 +0100, Thibaut Paumard wrote: > Hi, > > you could provide the .jar in non-free, and the DFSG free part which > actually runs on the host could Suggest this non-free package. You > need to provide a mean to upload it to the cellphone from the Debian > box. > > Then of course you could try and see whether the .jar can be build > by > a DFSG free compiler. I know close to nothing about this, so I > couldn't tell how likely it is. > > Distributing non-DFSG-free software in main, even if it is not > supposed to run on the Debian host and can be considered data... > will > probably be rejected. > > Regards, Thibaut. > Hi, Regarding the DFSG-compliance of this .jar, I've looked through the DFSG, and don't see where this could be a problem. DFSG mainly prohibits distribution of binaries without sources. This is a binary with the source, but cannot be compiled due to a non-free build-dependency. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
distributing precompiled binaries
Hi all, I've recently encountered an issue while packaging remuco (Bug #416379). Remuco is a duplex remote control application (mobile phones <=> media players). The mobile phone portion is written in Java, whereas the portion that runs on the media player computer is written in Python. For the Python part, the sources are completely distributed, and no binaries are in the tarball. However, for the Java part, only the .jar is distributed in the tarball. I have contacted the upstream developer about this issue, and he will be releasing another tarball with the sources for the Java portion. The problem begins here: The Java portion has a build-dependency on Sun Microsystem's WTK[1], and it is not free[2]. However, this is just a build dependency, and not a runtime dependency. In fact, the .jar isn't even supposed to run on the target machine, it's supposed to be uploaded to the mobile device. Hence, my question: Is it okay (within DFSG) for upstream to distribute the said .jar file, together with the sources for this .jar file, and for this said .jar file to be copied straight into a .deb and distributed as-is? Thanks in advance. [1] http://java.sun.com/products/sjwtoolkit/ [2] https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewLicense-Start -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
RFS: sigx
Dear mentors, I am looking for a sponsor for my package "sigx". * Package name: sigx Version : 2.0.2-1 Upstream Author : kl...@triend.eu * URL : http://www.assembla.com/spaces/sigx * License : LGPL-2+ Section : devel It builds these binary packages: libsigx-2.0-2 - interthread communication library for C++ - runtime libsigx-2.0-dev - interthread communication for C++ - development files libsigx-2.0-doc - interthread communication for C++ - reference documentation The package appears to be lintian clean. The upload would fix these bugs: 492215 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sigx - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sigx/sigx_2.0.2-1.dsc The package can also be found in the collab-maint git repository: - git://git.debian.org/git/collab-maint/sigx.git -- for cloning (for rw access, use git+ssh://) - http://git.debian.org/?p=collab-maint/sigx.git -- for gitweb An earlier version of this package can also be found on Ubuntu: - https://launchpad.net/ubuntu/+source/sigx I would be glad if someone uploaded this package for me. Kind regards Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building localy
On Mon, 2009-03-23 at 23:38 +0100, Jaromír Mikeš wrote: > > Od: Chow Loong Jin > > > I don't get it. debhelper should already pull in the appropriate perl. I > > cannot even begin to imagine how you borked up your perl installation to > > that extent. > > Neither me ... installation of ubuntu based distro is quite new here > installed few packages from sid coz testing new packages. > But not too much ... I am afraid of doing crazy things. > ;( > > mira > > You're packaging for what exactly? Sid? Jaunty? Intrepid? -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building localy
On Mon, 2009-03-23 at 17:26 -0500, Kumar Appaiah wrote: > 2009/3/23 Jaromír Mikeš: > > If I will install newer perl from sid it will probably break my ubuntu here. > > I can't build in pbuilder coz missining dependencies. > > Can I somehow install manually dependencies to pbuilder chroot? > > The first section here might help: > http://wiki.debian.org/PbuilderTricks > > Kumar > -- > Kumar > > I don't get it. debhelper should already pull in the appropriate perl. I cannot even begin to imagine how you borked up your perl installation to that extent. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building localy
On Mon, 2009-03-23 at 23:07 +0100, Jaromír Mikeš wrote: > > No I will use -fakeroot Actually I thought it was -rfakeroot -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Sat, 2009-03-21 at 14:00 -0430, Muammar El Khatib wrote: > > On Sun, Mar 22, 2009 at 1:18 PM, Chow Loong Jin wrote: > >> > >> 1) "It's known not to work on FreeBSD and probably does not work on other > >> non-Linux targets." > >> > >> 2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502083 > >> > >> 3) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320697 > > But Debian is not BSD, it's a GNU/Linux distribution is it not? Also, > > No, Debian is not BSD. But we have this > http://www.debian.org/ports/kfreebsd-gnu/: > > "Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C > library on top of FreeBSD's kernel, coupled with the regular Debian package > set." > > Now, as you can see at #502083 and #320697 the use of the flag has gotten > problems before. > > > I'm not too sure about the whole breaking-on-other-archs issue. I've got > > some packages with the ltmain.sh as needed patch, and -Wl,--as-needed in > > LDFLAGS, and they built on all the target architectures[1]. > > > > Well, I am not sure either because it is the first time I face this problem. > But, If I've read well in #502083 there says: > > "--as-needed is only used on arm and armel builds, while it should > be exactly opposite :( Incidentally it also shows that --as-needed is ok > for arm (but not for armel)." > > While in arm it was ok, in armel the use of --as-needed flag didn't work. So, > the use of such a flag could be _problematic_. > > > [1] https://launchpad.net/ubuntu/jaunty/+source/geanyvc/0.4-0ubuntu1 > > Well, this package is not into Debian archive yet, there is only an ITP. I > know > that Debian supports 12 architectures (http://www.debian.org/releases/stable/) > while Ubuntu only supports 6 > https://help.ubuntu.com/8.10/installation-guide/i386/hardware-supported.html > so > I think your argument about geanyvc does not apply at all for Debian. > Ah, my bad. Thanks for clarifying. Either way isn't that bug marked as fixed? Which would mean all the issues discussed in the bug are also fixed? -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Sat, 2009-03-21 at 13:08 -0430, Muammar El Khatib wrote: > Hi, > > Thank you so much to all of you for answering the mail and all of my doubts. > I'll ignore the warnings in the meanwhile and contact Upstream and GTK+ > maintainers later. > > I don't think that using --as-needed flag would be a good option, IMHO. I > believe that If I passed this flag it would not work in all architectures, so > it > will make quickplot brake on some of them. The fact that makes me strong on > this > argument, It's that linking a binary correctly is something that does not only > depends on how the binary is being linked at compilation time, it also depends > on how its dependencies are linked, too. Another reason would be one that I > read > in one of the links that Paul sent: > > 1) "It's known not to work on FreeBSD and probably does not work on other > non-Linux targets." > > 2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502083 > > 3) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320697 But Debian is not BSD, it's a GNU/Linux distribution is it not? Also, I'm not too sure about the whole breaking-on-other-archs issue. I've got some packages with the ltmain.sh as needed patch, and -Wl,--as-needed in LDFLAGS, and they built on all the target architectures[1]. [1] https://launchpad.net/ubuntu/jaunty/+source/geanyvc/0.4-0ubuntu1 -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Fri, 2009-03-20 at 13:53 +0900, Paul Wise wrote: > On Fri, Mar 20, 2009 at 12:03 AM, Miguel Landaeta wrote: > > On Thu, Mar 19, 2009 at 11:58 PM, Paul Wise wrote: > >> A workaround is to add -Wl,--as-needed to LDFLAGS, Gentoo has a > >> document about that here: > >> > >> http://www.gentoo.org/proj/en/qa/asneeded.xml > >> > >> Please note that using --as-needed can cause other (worse) problems. > > > > Just curiosity, what kind of problems can be caused from using --as-needed? > > My memory of this is vague, searching the BTS I found these though: > > http://bugs.debian.org/379748 > http://udrepper.livejournal.com/11056.html > http://udrepper.livejournal.com/10946.html > http://bugs.debian.org/502083 > http://bugs.debian.org/320697 > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > In that case would I be right in summarizing this up as --as-needed causes issues only when dlopen is used where the dlopen'd library requires symbols that are linked in via -lsomelibrary? -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: RFS: nautilus-share (updated package + bugfixes)
0.7.2-3 now. Fixed icon names in 04_use_correct_icon.patch. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: RFS: nautilus-share (updated package + bugfixes)
On Wed, 2009-03-18 at 01:17 +0800, Chow Loong Jin wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.7.2-1 > of my package "nautilus-share". > > It builds these binary packages: > nautilus-share - Nautilus extension to share folder using Samba > > The package appears to be lintian clean. > > The upload would fix these bugs: 475230, 500443, 501938 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/n/nautilus-share > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/n/nautilus-share/nautilus-share_0.7.2-1.dsc > > I would be glad if someone uploaded this package for me. > > Kind regards > Chow Loong Jin I've just uploaded another revision (0.7.2-2), so anyone who is willing to sponsor me should look at that version instead. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Thu, 2009-03-19 at 13:28 +0900, Paul Wise wrote: > On Thu, Mar 19, 2009 at 11:34 AM, Muammar El Khatib > wrote: > > > Could somebody help me with this? I'll appreciate any argument and > > thoughts from all of you. > > This is usually due to GTK+ and friends using Requires instead of > Requires.private in /usr/lib/pkgconfig/*.pc: > > http://bugs.debian.org/456335 > > This causes applications using GTK+ to link to more libraries than is > nessecary. > > I don't think this problem will be solved any time soon, I suggest ignoring > it. > > A workaround is to add -Wl,--as-needed to LDFLAGS, Gentoo has a > document about that here: > > http://www.gentoo.org/proj/en/qa/asneeded.xml > > Please note that using --as-needed can cause other (worse) problems. > > If you want to push for this to be fixed the right way, talk to the > GTK+ maintainers in Debian and upstream. > > http://packages.qa.debian.org/g/gtk+2.0.html > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > Regarding -Wl,--as-needed, sometimes you may need to patch ltmain.sh accordingly. The packaging of Banshee has a good example of this in debian/patches/99_ltmain_as-needed.patch. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building library from source
On Thu, 2009-03-19 at 04:06 +0100, Jaromír Mikeš wrote: > > Od: Jonathan Wiltshire > > > > Can somebody publish for me list of script from successfully build > > > library? > > > Or rules file? > > > > apt-get source > > Thank you that helped me to learn new things. > But unfortunately problem persist. Now I know that *.so* and *.h files are > definitely created in debian/temp. > But they are not installed then. > > Please look at output from pbuilder (attachment) and help me investigate why. > > I tried probably combination of options for dh_install (--autodest , > --list-missing, --sourcedir=debian/temp) > > I also have warning from "dpkg-buildpackage -S" that file can't to be singed > > signfile zita-convolver_1.0.0-1.dsc > gpg: skipped "Debian Multimedia Maintainers > ": secret key not > available > gpg: [stdin]: clearsign failed: secret key not available > > regards > > mira > > Regarding the GPG issue, when you upload (entry in debian/changelog) sign off as yourself, not as pkg-multimedia-maintain...@lists.alioth.debian.org. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building library from source
On Thu, 2009-03-19 at 00:21 +0100, Jaromír Mikeš wrote: > > Od: Jaromír Mikeš > > > Problem is that library installing just .docs files no .so files. > > I've checked everything many times. > > There are two files in debian/ mylib.install and mylib-dev.install > > mylib.install looks like from template: > > usr/lib/lib*.so.* > > mylib-dev.install looks like from template: > > usr/include/* > usr/lib/lib*.a > usr/lib/lib*.so > usr/lib/pkgconfig/* > usr/lib/*.la > usr/share/pkgconfig/* > > My question is ... Should I try replace Asterisks by something meaningful by > myself of should I expect this from some script? > Sorry for silly question I didn't found answer in docs or web. > > regards > > mira > > I'd suggest that you attempt to build it outside the pbuilder environment, then look at the contents of debian/tmp. It should show you what files you should match. The asterisks are fine. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: Building library from source
On Wed, 2009-03-18 at 17:42 +0100, Jaromír Mikeš wrote:
> Hello,
>
> I build new library from source building process run with one warning
> message.
> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
> Despite of this packages are build.
> Lintian ...clean output.
> Problem is that library installing just .docs files no .so files.
> I've checked everything many times.
>
> What I forgot to check?
>
> regards
>
> mira
>
>
Oh sorry, if you're not installing .so files, then remove
${shlibs:Depends}.
--
Chow Loong Jin
signature.asc
Description: This is a digitally signed message part
Re: Building library from source
On Wed, 2009-03-18 at 17:42 +0100, Jaromír Mikeš wrote:
> Hello,
>
> I build new library from source building process run with one warning
> message.
> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
> Despite of this packages are build.
> Lintian ...clean output.
> Problem is that library installing just .docs files no .so files.
> I've checked everything many times.
>
> What I forgot to check?
>
> regards
>
> mira
>
>
I think you probably need to run dh_shlibdeps in debian/rules.
--
Chow Loong Jin
signature.asc
Description: This is a digitally signed message part
RFS: nautilus-share (updated package + bugfixes)
Dear mentors, I am looking for a sponsor for the new version 0.7.2-1 of my package "nautilus-share". It builds these binary packages: nautilus-share - Nautilus extension to share folder using Samba The package appears to be lintian clean. The upload would fix these bugs: 475230, 500443, 501938 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/nautilus-share - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/nautilus-share/nautilus-share_0.7.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: quilt[Solved]... bug?
On Tue, 2009-03-17 at 07:27 +0100, Jaromír Mikeš wrote: > > Původní zpráva > > Od: Jaromír Mikeš > > > Described in different way: > > > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt new makefile.patch > > Patch makefile.patch is now on top > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt edit > 4) '/home/mira/jnoise/jnoise-0.4.0/Makefile' > > File /home/mira/jnoise/jnoise-0.4.0/Makefile added to patch makefile.patch > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt refresh > > Refreshed patch makefile.patch > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt applied > > makefile.patch > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt pop -a > > Removing patch makefile.patch > 12) Restoring home/mira/jnoise/jnoise-0.4.0/Makefile > > > > No patches applied > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt applied > > No patches applied > > m...@64studio:~/jnoise/jnoise-0.4.0$ quilt push > > Applying patch makefile.patch > 19)patching file home/mira/jnoise/jnoise-0.4.0/Makefile > > > > Now at patch makefile.patch > > m...@64studio:~/jnoise/jnoise-0.4.0$ > > > > So I was switching by " quilt pop -a" and by "quilt push" between states > > patched > > unpatched. > > But edited makefile was in both states edited :( > > What happened? I am used sometimes just write command like "gedit" and then > "drag and drop" file to terminal to be showed by e.g. "gedit". > You can see it in lines 4, 12 and 19 ...but quilt not accept behavior like > this!!! > If I am pwd in root dir of my package and write: quilt edit Makefile ... all > is ok! > When I write "quilt edit" and then "drag and drop" file quilt create in > my_package_root_dir new dirs like > /path/to/my/Makefile. > I don't know other command line program not accepting "drag and drop" ... > I know d'n'd is not standard way how to do it, but it took one day to me to > discover it :( > > Thank you all for patience and will to help. > > Best regards > > mira > > I'm not sure, maybe quilt doesn't support full paths? Either way you can always use tab completion. Type the first few characters and then press tab and it'll be completed for you. I think that's possibly faster than drag-dropping especially when the stuff is in the same directory. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: manual pages
On Mon, 2009-03-16 at 14:53 +0100, Jaromír Mikeš wrote: > Hello, > > having problem to build package with manual pages. > I edited and rename manpage.1.ex > jnoise.1 > Also uncomment line "dh_installman" in debian/rules "binary-indep" section > > But when I install package there are not man pages,also lintian complain ... > > W: jnoise: binary-without-manpage usr/bin/jnoise > > Thanks for advise > > mira > > You need to add debian/jnoise.1 into debian/packagename.manpages. If it doesn't exist, create it. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
