Somebody please put peless in a debian repository!
Peless is a simple text file lister. It uses gtkmm. GPLed. Somebody please put it in a debian repository. I have already created a .deb file Everything about peless can be found at: http://peless.berlios.de/ I have tested peless on ubuntu 510. I am not an expert on debian style packageing but I did create a .deb file. It works under ubuntu 510. All the debian style files can be found at: ftp://ftp.berlios.de/pub/peless/ubuntu.510/ Thank You. P.S. I am not subscribed to this mailing list, please CC me. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpS51aiH4Ucc.pgp Description: PGP signature
Please find fault with peless, before I try to file an ITR(whatever that is)!
I am trying to get peless into debian, but I have not filed an ITR yet because I probably made mistakes. Please find the following files created under ubuntu 704: ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless-1.100.tar.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100-1.dsc ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100-1_i386.changes ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100.orig.tar.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100-1.diff.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100-1_i386.build ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.100-1_i386.deb Please find fault with these files so I can fix them and get peless into debian. I now have a manpage and a .desktop file. I am worried about the dependancies in the control file. Perhaps they too specific to the ubuntu 7.04 system the files were generated on. But I do not know how to make them more general so that they still work! peless basicly depends on boost 1-33, gtkmm 2.4, gconfmm 2.6, libsigc++ 2.0. It is built with autoconfig, automake tools. I am a tyro with debian, I usually work in opensuse. By the way, when I get the files fixed, how do I file an ITR and what is an ITR anyway? I am the original author of peless. http://peless.berlios.de/ https://developer.berlios.de/projects/peless/ -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpyT2vmwhdae.pgp Description: PGP signature
dependancy question?
The control file for peless says:
---
Source: peless
Section: text
Priority: optional
Maintainer: pelliott <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), autotools-dev, libboost-dev, libboost-dev,
libboost-regex-dev, libgconfmm-2.6-dev, libgtkmm-2.4-dev, libsigc++-2.0-dev,
libboost-filesystem-dev (>= 1.33.1 ) libboost-regex-dev (>= 1.33.1 )
Standards-Version: 3.6.1
Package: peless
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libgtkmm-2.4-1c2a,
libgconfmm-2.6-1c2, libsigc++-2.0-0c2a, libboost-filesystem1.33.1,
libboost-regex1.33.1
Description: Text browser
Peless is a simple text file lister. It only displays files and never modifies
them. It can display multiple files using a tabbed notebook, display
international characters, and search the files for regular expressions or
literal expressions. Users can choose the fonts used to display files.
-
I would like to say that peless depends on boost, libgtkmm 2.4, libgconfmm 2.6,
and libsigc++ 2.0
without being so specific about the versions. But there appears to be no way to
do this, the versions seem to be built into the package names!
But I am a debian tyro, there must be a way around this; What is it?
Thank You.
--
Paul Elliott 1(512)837-1096
[EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/ Austin TX 78758-3117
pgpqCKEP3tV4T.pgp
Description: PGP signature
Re: Please find fault with peless, before I try to file an ITR(whatever that is)!
On Tue, May 15, 2007 at 07:27:00PM +1000, [EMAIL PROTECTED] wrote: > On 5/15/07, Paul Elliott <[EMAIL PROTECTED]> wrote: > >By the way, when I get the files fixed, how do I file an ITR and > >what is an ITR anyway? > > I think you mean ITP, and it means Intent To Package. > > You should read the Using WNPP section at > http://www.debian.org/devel/wnpp/ - it explains how you file an ITP. OK, I read it, and I think I should file an RTP, to get someone else to package it into debian, because I do not understand the nuances of debian right now! Is that correct! That way I will hopefully get someone who knows what they are doing to put it into debian. I have already got it set up to create a .dsc and .deb file. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpBeoEC8hxWT.pgp Description: PGP signature
bugreport, debian, ubuntu
As some of you may have guessed from some of my confused emails the last few days I am the author of peless, and I have been trying to get peless into debian. I am not an experienced debian person. I have been trying to get all my control, rules, changelog, ect, files into shape so the peless will package, so then I can hand it off to an experienced debian packager who I hope to talk into putting peless into debian. To this end, I have been using ubuntu 7.04 as a developement environment. Is that wrong? If so, it could be a problem for me, because I have dialup and it would take a long time to download a distribution dvd. I had this ubuntu CD, (they seem to be everywhere), so I just started to use it. Everyone tells me that ubuntu is a form of debian. Anyway, today I thought I had all my files OK, and I could build a package, so I thought to try to submit a "RFP". I did a "bugreport --email [EMAIL PROTECTED] wnpp" but it never asked me to "Choose the request type:" like it says in this web page: http://www.debian.org/devel/wnpp/ finnaly when it began saying it was going to send the report off to an ubuntu mailing list, I aborted it. Is there a way to file a RFP from ubuntu? What am I doing wrong? Please excuse all the dumb questions. Files: ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.diff.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.dsc ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.build ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.changes ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.deb ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108.orig.tar.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless-1.108.tar.gz -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpelMeE3aqn1.pgp Description: PGP signature
Bug#424843: RFP: peless -- peless is GTK tabbed text file lister.
Package: wnpp Severity: wishlist Peless is a simple text file lister. It only displays files and never modifies them. It can display multiple files using a tabbed notebook, display international characters, and search the files for regular expressions or literal expressions. Users can choose the fonts used to display files. License: GPL The following files were made with ubuntu 7.04 but they probably can be rebuilt in debian: ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.dsc ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.deb ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.diff.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.build ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.changes ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108.orig.tar.gz ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless-1.108.tar.gz -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: peless -- dh_helper
On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote: > [added the list again] > -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=- > > > If I were you, I'd try to make "make install" not strip anything, > > > patching if necessary[1]. The problem with dh_install approach is > > > that you have to check carefully if there is something new to > > > install every now and then, which leads to problems (as already > > > seen). > > > > > The world is nice because it is possible to find many different > > opinions... > > I see your confusion and I understand it. It is not so good feeling to > try to satisfy contradicting requirements. > > I, personally, will not sponsor a package that replaces a perfectly > working "make install" with broken dh_install usage. Even if > dh_install usage is fixed, I still don't like it. This, of course, does > not mean that nobody else will want to sponsor it. > Gentlemen, I am by no means an expert on debian, but as the upstream developer of peless, I have to agree with Mr. Damyan Ivanov on this technical issue. The history of Computers shows that whenever the same piece of data is stored/maintained in more than one place, they inevitably get out of sync, resulting in bugs and problems. As the developer of peless, I must insure that "make" and "make install" work properly. I do this indirectly by making sure that configure.ac and Makefile.am are correct. "make" and "make install" control the way peless is built and the way files are copied to their ultimate destinations. "make" and "make install" definitely must be used for distributions other than debian. Now I glean from the discussions you have been having, that if dh_install is used, then essentially the same information must be maintained somewhere else. History shows that this can not be good. For example, one of the next things I want to do with peless is to make sure peless properly publishes its .pot file as the first step toward making peless multi-lingual. When I do this, I will adjust the auto* control files to make sure that "make" and "make install" do the RIGHT THINGS(tm). But you seem to be telling me that if dh_install is used, that files relevant to dh_install must also be adjusted. This has to be bad. The same data being managed in 2 places, by 2 different people. I am by no means a debian expert, but it seems to me from what I have been able to glean from this discussion that dh_install is associated with a fundamental software management design error. This could be important with packages more critical than peless. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpgT3F4tNXEz.pgp Description: PGP signature
Re: RFS: peless -- dh_helper
On Fri, May 25, 2007 at 05:36:34PM +0200, Giorgio Pioda wrote: > Hello Paul and Damyan > > > On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote: > >> [added the list again] > >> -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=- > >>>> If I were you, I'd try to make "make install" not strip anything, > >>>> patching if necessary[1]. The problem with dh_install approach is > >>>> that you have to check carefully if there is something new to > >>>> install every now and then, which leads to problems (as already > >>>> seen). > >>>> > >>> The world is nice because it is possible to find many different > >>> opinions... > >> I see your confusion and I understand it. It is not so good feeling to > >> try to satisfy contradicting requirements. > >> > >> I, personally, will not sponsor a package that replaces a perfectly > >> working "make install" with broken dh_install usage. Even if > >> dh_install usage is fixed, I still don't like it. This, of course, does > >> not mean that nobody else will want to sponsor it. > >> > > > > Gentlemen, > > > > I am by no means an expert on debian, but as the upstream developer of > > peless, I have to agree with Mr. Damyan Ivanov on this technical issue. > > > > The history of Computers shows that whenever the same piece of data > > is stored/maintained in more than one place, they inevitably get out > > of sync, resulting in bugs and problems. > > > > As the developer of peless, I must insure that "make" and "make install" > > work properly. I do this indirectly by making sure that configure.ac > > and Makefile.am are correct. "make" and "make install" control the > > way peless is built and the way files are copied to their ultimate > > destinations. "make" and "make install" definitely must be used for > > distributions other than debian. Now I glean from the discussions > > you have been having, that if dh_install is used, then essentially > > the same information must be maintained somewhere else. History > > shows that this can not be good. > > Ok, then in that case the configure and make could be improved to have a > clean "nostrip" option which normally is called with > > "make install -s" > > and can be set up in debian/rules together with the noopt option > OK, but first let me understand what I am fixing. What is wrong with "make install" as it is? There is also a "make install-strip". I did not do anything special to create these targets; auto* tools created them. What exactly is wrong with "make install"? Thank you. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpHV5OByPqAt.pgp Description: PGP signature
Re: RFS: peless -- dh_helper
On Fri, May 25, 2007 at 10:55:11PM +0300, Damyan Ivanov wrote: > -=| Giorgio Pioda, Fri, 25 May 2007 21:29:40 +0200 |=- > > http://web.ticino.com/gfwp/debian/peless-1.108/peless_1.108-1.dsc > > Ouch. It seems I've missed something in my previous review :/ > > In debian/copyright it is written that peless is under GPLv2-or-later > and this is in COPYING as well. > > However, gmore.cc, peless.cc, internat.hh, search.cc and search.hh > state something different in their headers. > > This is something that has to be sorted out with upstream author > (Hi, Paul :) ) Ah, and while there, can I gen distribution-neutral > location for the source tarball? Just a wish, but I hope it would not > be a problem. > > The copyright year is also different. > > And something from before: > > * debian/rules still contains commented rows that are never going to be > enabled. Why keep them there? > -- > damJabberID: [EMAIL PROTECTED] OK I will, be comming out with a new version, shortly which will have the following features. 1) .cc .h source code the same except for copyright messages 2) configure.ac and Makefile.am changed to use ax_boost_base.m4 instead of my home brew system. 3) copyright problems fixed, will say gplv2 or later. 4) remove obsolete spec files, but leaving the ones for current distros. I will probably make a release probably Sat or Sun. It will take this long because I still have to verify that the system still builds on Fedora, opensuse, mandrake and ubuntu 7.04. I still do not have a debian sid system for testing, but if ubuntu works other debian based systems will probably work possibly with minor changes. When all this is done I will put a new release on berlios and send you guys an email. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpblHsep1qBJ.pgp Description: PGP signature
Re: RFS: peless -- new upstream release.
On Fri, May 25, 2007 at 03:28:17PM -0500, Paul Elliott wrote:
> OK I will, be comming out with a new version, shortly which will have
> the following features.
>
> 1) .cc .h source code the same except for copyright messages
> 2) configure.ac and Makefile.am changed to use ax_boost_base.m4
>instead of my home brew system.
> 3) copyright problems fixed, will say gplv2 or later.
> 4) remove obsolete spec files, but leaving the ones for current distros.
>
> I will probably make a release probably Sat or Sun.
>
> It will take this long because I still have to verify that the
> system still builds on Fedora, opensuse, mandrake and ubuntu 7.04.
> I still do not have a debian sid system for testing, but if
> ubuntu works other debian based systems will probably work possibly
> with minor changes.
>
> When all this is done I will put a new release on berlios and
> send you guys an email.
OK, there is new version released at berlios in the files section:
http://prdownload.berlios.de/peless/peless-1.125.tar.bz2
It
1) Fixes the copyright notice problem.
2) fixes some problems with fedora spec files. You don't care about this.
3) uses ax_boost_base.m4 instead of my homebrew system to manage boost
ax_boost_base.m4 is documented here:
http://autoconf-archive.cryp.to/ax_boost_base.html
http://www.randspringer.de/boost/
This will require that the rules file be changed. Here is a .diff
--cut here with a chain saw
--- rules.orig 2007-05-27 16:39:28.0 -0500
+++ rules 2007-05-27 16:56:31.0 -0500
@@ -41,7 +41,7 @@
ifneq "$(wildcard /usr/share/misc/config.guess)" ""
cp -f /usr/share/misc/config.guess config.guess
endif
- ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
--with-boost_lib_postfix=$(BOOST) CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
+ ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
--with-boost=/usr --with-boost-filesystem-options=gcc-mt
--with-boost-regex-options=gcc-mt CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
build: build-stamp
--cut here with a chain saw
4) I have hard coded -O2 -g in CPPFLAGS, rather than let auto* tools
figure out what to do.
5) changes to the Install documetentation.
Within one week I plan to have another release that will support translation.
It will not have any new translations, but it will publish a .pot file
so that people can translate peless.
I will have to decide how to handle some parameterized translation
strings and change some c++. I need to decide if peless should use the
compose library:
http://people.iola.dk/olau/compose/
or boost::format.
Thank you for helping to get peless into debian!
--
Paul Elliott 1(512)837-1096
[EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/ Austin TX 78758-3117
pgpC0cSE3GJCn.pgp
Description: PGP signature
repository for packaging project.
Greetings, I am interested in packaging several free software astrology programs for debian. I would like to save my work in a source code repository. I could define a repository on my local machine, but it might be better to use a public server. That way, I could possibly recruit co-packagers. Also if I were to ever unfortunately kick the bucket, my work could be inherited by the debian community. I am not any kind of official debian person; I am just working to package some astrology programs. AliothPackagingProject http://wiki.debian.org/Alioth/PackagingProject suggests that in the case of people like me, a full packaging project is too much; I should just get a svn repository in the collab-maint project. I have an alioth -guest account. How do I get a svn repository in the collab- maint project? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What is autobuilder? Please help me understand this bug.
Recently libswe made it into debian(unstable). Almost immeadiately, I got this bug: > http://wiki.debian.org/Alioth/PackagingProject > Source: libswe > Version: 1.77.00.0004-1 > Severity: serious > Justification: fails to build from source > > Automated builds of libswe are failing because unoconv (used to > produce PDF and HTML documentation) assumes a writable home directory, > which the autobuilders' build environments lack. (Many also lack > loopback network interfaces, which may be an issue as well.) Given > that the documentation winds up in a separate architecture-independent > binary package anyway, I'd suggest arranging to build it only in full > builds, which presumably run in less restrictive environments. > (Relatedly, I'd suggest moving unoconv from Build-Depends to > Build-Depends-Indep.) > > Could you please look into it? My program does indead use unoconv to build documentation. I need to understand this bug so that I can fix it. For instance, libswe just appeared in debian unstable, that means someone must have built it. How does the build environment of the autobuilder's differ from the one that built libswe on its path to unstable? Why is the autobuilder's environment correct? In other words, why is this not a bug against the autobuilder's software? How can I duplicate the autobuilder's builds on my local machine to test this problem? What is a "full" build and can I be sure that a full build will never occur in the autobuilder? If I make a fix to this problem, how can I test that it will work in the autobuilder's evnironment? Thank you for helping a beginning packager fix a bug. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
why does debian packaging think ITP is still open?
If I look at my package thru debian packaging: http://packages.qa.debian.org/libs/libswe.html It thinks my ITP #635672 is still open. However the changelog file contains a entry like this: . > libswe (1.77.00.0001-1) unstable; urgency=low > > * Initial release (Closes: #635672) <635672 is the bug number of your > ITP> * done dh_make much configuring remains to be done. > * remove emacsen-* ... Why does packaging not see this? Have I made a mistake? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Should I split off arch independant part?
The untimate source of my project is a windows programer who GPLed. He thought it would be a good idea to write the documentation in windows word .doc file! Bad move. The only free program that I can find to convert this document source to a civilized format is unoconv together with libreoffice-writer. In the opensuse world loconvert also works. But it also uses libreoffice-writer. I have spent more packager time on building this documentation than building the libarary. It has been suggested that I split off the build process so that the archetecture dependant parts of the program can be built without building the documentation each time. > Given > that the documentation winds up in a separate architecture-independent > binary package anyway, I'd suggest arranging to build it only in full > builds, which presumably run in less restrictive environments. > (Relatedly, I'd suggest moving unoconv from Build-Depends to > Build-Depends-Indep.) This web page http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/ with the confidence inspiring title "Asylum Diaries of a Madman" suggests a workaround whereby this my be accomplished. However the method feels kludgy, counterintuitive, and difficult to understand, and therefore difficult to maintain. It also relies on hairsplitting to remain within the rules. I feel that computer time is much cheaper that human time. Should methods be used to split off the arch indpendant part? What do the true experts think? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Should I split off arch independant part?
On Thursday, February 09, 2012 04:37:55 PM Savvas Radevic wrote: > > If I were you, I'd just convert the .doc to a .pdf. Likewise, your > programmer can do that in seconds with a > plugin<http://www.microsoft.com/download/en/details.aspx?id=7>(and > file > save as.. or export?) or a > program<http://www.softpedia.com/get/Office-tools/PDF/Simpo-PDF-Creator-Lit > e.shtml>(and go file>print) for ms office. > Unfortunately the .doc file is the source, so everything must be rebuilt from source i.e. the .doc file as part of the build process. The next version of the documentation will probably be another .doc file. The .doc is the source because the person writing the documentation prefers to write in .doc format. It would be disingenuous to say that anything other than the .doc is the source. If I were writing the documentation from now on, I would convert once to docbook, or some other civilized format and then say that the .docbook file was the source. But I am not writing the documentation, so I can't do that. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Which git tool should I use?
I am currently packaging several programs for debian. I would like to store my VCS stuff publicly. I have been granted access to collab-maint. Although previously I used svn I have been persuaded to use git. I have spent the last week reading git manuals, but I am a beginner. What tool should I use to create my git info? git-dpm? StGit? Thank You for your response. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202162254.24767.pelli...@blackpatchpanel.com
upload to debian.mentors disappears without a trace.
I have successfully uploaded to debian mentors, it has been more than 30 min. package has not appeared on list, no email message about it of any kind. ls -lt *.upload -rw-r--r-- 1 pelliott pelliott 444 2012-02-19 14:52 maitreya_6.0.5-1_i386.mentors-ftp.upload pelliott@hrnowl:/home/pelliott/develop/astrology/maitreya/lib-maitreya/myredo- sid/mgit$ cat *.upload Successfully uploaded maitreya_6.0.5-1.dsc to mentors.debian.net for mentors- ftp. Successfully uploaded maitreya_6.0.5-1.debian.tar.gz to mentors.debian.net for mentors-ftp. Successfully uploaded maitreya_6.0.5-1_i386.deb to mentors.debian.net for mentors-ftp. Successfully uploaded font-maitreya_6.0.5-1_i386.deb to mentors.debian.net for mentors-ftp. Successfully uploaded maitreya_6.0.5-1_i386.changes to mentors.debian.net for mentors-ftp. pelliott@hrnowl:/home/pelliott/develop/astrology/maitreya/lib-maitreya/myredo- sid/mgit$ -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: upload to debian.mentors disappears without a trace.
On Sunday, February 19, 2012 09:08:39 PM Gabriele Giacone wrote: > On 02/20/2012 03:39 AM, Paul Wise wrote: > > Looks like you are right there. This was a -1 upload sp > > dpkg-buildpackage should have automatically included the orig.tar.gz > > unless Paul explicitly did not include it (using -sd). > > Or a duplicate -1 changelog entry? > > from dpkg-genchanges man: > "By default, the original source will be included only if the upstream > version number (the version without epoch and without Debian revision) > differs from the upstream version number of the previous changelog entry." I had forgotten about the -sa switch the first time packaging for mentors.debian.net something for which the upstream had packaged and distributed outside of debian with the same version number. I still think I should have gotten an error email. Thanks you for all. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Explain to me "any all"
The new standard allows "any all" in the Architecture field. Please explain this new feature. What does it do and under what circumstances should it be used? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
obsolete uploads to debian stable?
Is there any archive where I can get obsolete superseded uploads to debian unstable? I need to get one for historical reasons. Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pyswisseph" * Package name: pyswisseph Version : 1.77.00-0-3 Upstream Author : Stanislas Marquis * URL : http://pyswisseph.chaosorigin.com/ : http://pypi.python.org/pypi/pyswisseph * License : GPLV2+ Section : python It builds those binary packages: python-pyswisseph - Python extension to the Swiss Ephemeris To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pyswisseph Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.77.00-0-3.dsc One can also get all information about the package though its collab-maint git repository: http://git.debian.org/?p=collab-maint/pyswisseph.git git://git.debian.org/git/collab-maint/pyswisseph.git More information about hello can be obtained from http://pypi.python.org/pypi/pyswisseph This python extension module can be tested using openastro.org, a python program that is also being RFSed: http://mentors.debian.net/package/openastro.org Changes since the last upload: * ephe_path should be "/usr/share/libswe/ephe2:/usr/share/libswe/ephe" * upgrade to Standards-Version: 3.9.3 Regards, Paul Elliott -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Bug#661665: RFS: openastro.org/1.1.25-2 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "openastro.org" * Package name: openastro.org Version : 1.1.25-2 Upstream Author : Pelle van der Scheer * URL : http://openastro.org/ : https://launchpad.net/~pellesimon/+archive/ppa : http://pypi.python.org/pypi/OpenAstro.org/1.1.20 * License : GPLV3+ Section : graphics It builds those binary packages: openastro.org - Fully featured Open Source Astrology software To access further information about this package, please visit the following URL: http://mentors.debian.net/package/openastro.org Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.1.25-2.dsc More information about hello can be obtained from http://openastro.org/ One can also get all information about the package though its collab-maint git repository: http://git.debian.org/?p=collab-maint/openastro.git git://git.debian.org/git/collab-maint/openastro.git This python program depends on the python extension module pyswisseph which is also being RFSed: http://mentors.debian.net/package/pyswisseph Changes since the last upload: * correct location for ephe_path is /usr/share/libswe/ephe2:/usr/share/libswe/ephe * upgrade to Standards-Version: 3.9.3 Regards, Paul Elliott -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
documentation for "Convenience copies of code" redundant regeneration?
My package's source tarball contains "Convenience copies of code" which I delete and instead link to the external library. Also in the source tarball is documentation for the convenience library in the form of .pdf and .html copied from the same source by the upsteam. I am the maintainer of the external library, and there, I regenerate this documentation from source, at the cost of considerable trouble. But in the package I am working on I simply delete references to the "Convenience copies of code" and its documentation and refer to it's location in the external package. Question: Must I regenerate this Convenience copies of Documentation from source, only to delete it, and refer to in externally, (where it IS regenerated from source). That is must I do a purely pro forma regeneration from source of something that is just going to be deleted and never used, of something that is regenerated from source in an external package? If it is OK, in this case, to just delete the pdfs and html, where should I note the problem? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
On Wednesday, February 29, 2012 06:49:46 AM Jakub Wilk wrote:
I will look into this and create a new version. It will probably take a while.
On the issue of the pdfs, those pdfs are rebuilt from source in another
package that depends on this package. References to those pdf's should be
refered to that other package. Those pdf are not distributed by this package,
they should have been deleted with the convenience code. In this case of
"Convenience copies of documentation" which is rebuilt from source in another
dependant package, I am not sure if it is good enough to note the other
package where the documentation is rebuilt from source, note the problem and
move on, or if I must turn this package into a dfsg package?
What is your opinion?
> (Please use X-Debbugs-Cc, rather than Cc, when submittig bugs. That way
> the other parties will get the mail with bug number in the subject.)
>
> I don't intend to sponsor this package, but here's my review:
>
> * Paul Elliott , 2012-02-28, 18:32:
> >dget -x
> >http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.
> >77.00-0-3.dsc
>
> Please get rid of “<645551 is the bug number of your ITP>” and “source
> package automatically created by stdeb” cruft from the changelog.
>
> “Vcs-Browser” would be more consistent and more common capitalization
> than “Vcs-browser”.
>
> I'd merge all 3 changelog entries into one, and remove of the stuff from
> it. There's no point mentioning that e.g. you added copyright file in an
> initial release. Of course you did. (But OTOH patches you added might be
> worth mentioning.)
>
> Remove ${python:Breaks}, nothing generates this substitution variable
> anymore.
>
> The package description is very bad. Please see Developer's Reference
> §6.2.3.
>
> The copyright file doesn't say where the upstream sources were obtained.
> This is serious violation of Policy §12.5.
>
> I don't understand your lintian override. Why you can't correct the
> spelling?
>
> You can remove “--buildsystem=python_distutils” from debian/rules; dh is
> able to detect the build system automatically.
>
> Please get rid of the “This file was automatically generated by stdeb”
> comment.
>
> Do not use patches to remove files. Such patches are huge and are very
> likely cause conflicts in the future. Just remove the files in
> debian/rules (but see below).
>
> The patches have “Forwarded: yes”, but were they actually forwarded? If
> yes, to who? They look Debian-specific to me.
>
> Assuming that you meant to use DEP-3 for your patch headers, and as far
> as I understand the specification, you need an empty line before the
> pseudo-header.
>
> Please regenerate pydoc/* at build time.
>
> The binary package name is wrong. It should be python-swisseph, as per
> Python Policy §2.2.
>
> Upstream seems to support Python 3, too. Please consider building a
> separate python3-swisseph package.
>
> The is no source for PDFs in the doc/ directory. You have the following
> options:
> - Ask upstream to include the source in their tarballs.
> - Repackage their tarballs.
> If you choose the latter option, you could also get rid of unneeded
> files that delete-no-longer-need-swe-files patch currently removes.
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203011403.07631.pelli...@blackpatchpanel.com
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
On Thursday, March 01, 2012 05:19:48 PM Jakub Wilk wrote: > * Paul Elliott , 2012-03-01, 14:03: > >On the issue of the pdfs, those pdfs are rebuilt from source in another > >package that depends on this package. > > Personally, I don't buy the “source is in another package” argument. It > might be true for the time being (I didn't check), but next version of > the other package could come with different documentation or simply > without it. The source is not, and is not required to be, distributed anywhere but the source package. The source package will always be available through http://snapshot.debian.org/ if nowhere else. I have already checked, it is there. One possibility, is to rebuild these files from source, and then delete both the source and the results. It is a monument to absurdity, but it satisfies all formal requirements, and may be the easiest choice. I guess I will have to choose between that and a dfsg project. I will decide later. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What happens when an architecture independent package won't build on all architectures?
The fact that a package is architecture independent is no guarantee that the package will build under all architectures. The package can "build depend" on packages that don't exist for some architectures. But if the package once built under any particular architecture, should then run under all architectures. My question is what happens in this case? Will the build system take the build results from one of the "good" architectures, ( that is architectures where the package does build successfully,) and give the results of that build to the bad architectures? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What happens when an architecture independent package won't build on all architectures?
On Thursday, March 01, 2012 11:26:01 PM Paul Wise wrote: > > The Debian buildds do not (yet) build any Architecture: all packages, > they are currently all built on developer machines. > > IIRC there is a plan to build all packages on the buildds but that > isn't yet in place. > > Part of that is adding a Build-Architecture field for packages that > are Architecture: all but can only build on certain architectures. > > I guess the procedures for an Architecture: all package will be > approximately the same as for Architecture: any packages where an > architecture has multiple buildds. Give the package to one of the > available buildds to try and if it fails, give it to another one. When that plan goes into place, will the Architecture: all be built under all the different architectures? I have a package that fails to build under some archetectures, because of the heavy duty dependancies necessary to build an Architecture: all package. I am trying to figure out if it would be a good idea to split that source package in two. I am aware of Build-Depends-Indep and this kludge: http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/ but it feels too kludgy. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
upstream source is a source rpm!
I have an upstream source who did not put his source in a tarball, and then put the tarball in a source rpm, (as would be usual in the rpm world). Instead, he put his source files directly in the source .rpm file! I can unpack this thingy with: rpm2cpio source.rpm | cpio -i But I have questions: Assuming I have the url of the source rpm, how would one write the watch file and get-orig-source: in rules to create a proper .ds tarball? Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note this dependancy anywhere? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Bug#667974: RFS: libreoffice-converter/3.3.34.1+ds-3 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libreoffice-converter" * Package name: libreoffice-converter Version : 3.3.34.1+ds-3 Upstream Author : Petr Mladek Jan Holesovsky * URL : https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter * License : LGPL2.1+ Section : text It builds those binary packages: libreoffice-converter - Commandline Document Converter Using LibreOffice.org To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libreoffice-converter Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3.34.1+ds-3.dsc More information about hello can be obtained from https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter In addition the packaging code can be found in: Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git Vcs-Browser: http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary Changes since the last upload: libreoffice-converter (3.3.34.1+ds-3) unstable; urgency=low * correct webpage in debian/control libreoffice-converter (3.3.34.1+ds-2) unstable; urgency=low * new upstream release 3.3.34.1 libreoffice-converter (3.3.32.1+ds-1) unstable; urgency=low * Initial release (Closes: 663273) * rules make. No Makefile. * enable Vcs fields. git repository in collab-maint Regards, Paul Elliott signature.asc Description: Digital signature
Help with watch file for OBS?
My tarball is on the OBS. I want to write a watch file for it. My procedure to get the file is: look in: https://build.opensuse.org/package/files?package=libreoffice-converter&project=LibreOffice:Unstable For strings that look like: https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice- converter-3.3.tar.bz2?rev=2dffadb97b188c6bc4c0037f1d4c446d&"> The 3.3 is the version number the part that can vary. ?rev=BLAH must be thrown away to get https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice-converter-3.3.tar.bz2 Which can be downloaded with wget. My current watch file reads: >version=3 >opts=filenamemangle=s/(.*)\?rev=.*/$1/ \ >https://build.opensuse.org/package/files?package=libreoffice-converter&project=LibreOffice:Unstable > \ >https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice-converter-(\d\.\d)\.tar\.bz2 It does not find a match. What am I doing wrong? If I can get this working, I will post it so everyone can have watch files for OBS. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
how to create a debian watch file for tarballs hosted on the OBS.
How to create a watch file for a tarball found on the OBS (Open Build Service). First find the Sources package page for the package that uses your tarball. If you do not already know this, perhaps you can search for it here: https://build.opensuse.org/search Once you have found the page for your package, you can click on "Sources". In my example, my package is libreoffice-converter, so I find this page: https://build.opensuse.org/package/files?package=libreoffice-converter&project=LibreOffice%3AUnstable You should find links for the various sources that go to make up the source rpm. And this should include the tarball. If you look at the source for that web page, it will include a link that looks like this: https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice- converter-3.3.tar.bz2?rev=2dffadb97b188c6bc4c0037f1d4c446d&"> The \?rev=BLAH stuff needs to be thrown away. So you create a watch file that looks like this: >version=3 > >opts=filenamemangle=s/\?rev=.*// \ >https://build.opensuse.org/package/files?package=libreoffice-converter&project=LibreOffice:Unstable > \ >https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice-converter-(\d\.\d)\.tar\.bz2\?rev=.* The first line: >opts=filenamemangle=s/\?rev=.*// \ Says we are going to throw away the ?rev= stuff. The second line is the package source page that we found: >https://build.opensuse.org/package/files?package=libreoffice-converter&project=LibreOffice:Unstable > \ The third line is the link target: >https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice-converter-(\d\.\d)\.tar\.bz2\?rev=.* The version part 3.3, has been written as (\d\.\d) so uscan can abstract the version numbers. And it includes the part that will be thrown away "\?rev=.*". Thanks to David Paleino for helping me with this. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Upload to mentors.debina.net disappeared without a trace.
When my upstream started using a tarball instead of putting source directly source rpm. I decided to change my version numbering system. This would result in having new version number less that the old. So I deleted libreoffice-converter from mentors.debian.net. Uploaded new package with ftp. Over 1/2 hour gone by no message from the email notifiication system. Either success or failure. My packages link still does not show the upload. Help. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Bug#668877: RFS: libreoffice-converter/3.3-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libreoffice-converter" * Package name: libreoffice-converter Version : 3.3-1 Upstream Author : Petr Mladek : Mirko Nasato * URL : https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter * License : GNU LGPL v2.1 Section : text It builds those binary packages: libreoffice-converter - Commandline Document Converter Using LibreOffice.org To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libreoffice-converter Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3-1.dsc More information about libreoffice-converter can be obtained from Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git Vcs-Browser: http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary Changes since the last upload: * Initial release. (Closes: 663273) * get rid of old version numbering system * not a ds package anymore. upstream has a tarball! * new watch file * use debian/install * update debian/copyright for new tarball Regards, Paul Elliott signature.asc Description: Digital signature
Re: Upload to mentors.debina.net disappeared without a trace.
On Sunday, April 15, 2012 02:39:49 AM Paul Wise wrote: > The FTP importer was stuck for some reason, I've restarted it, it is > back now and your package was imported: > > http://mentors.debian.net/package/libreoffice-converter > > Please consider using HTTP to upload since it results in immediate > feedback. The following error message shows why I don't use http: > $ dput mentors *.changes > Checking signature on .changes > gpg: Signature made Mon 16 Apr 2012 03:35:24 PM CDT using DSA key ID > 345CDD99 gpg: Good signature from "Paul Elliott > " gpg: aka "Paul Elliott > " > Good signature on > /home/pelliott/develop/git/loconvert/sid/try/libreoffice-converter_3.3-2_i > 386.changes. Checking signature on .dsc > gpg: Signature made Mon 16 Apr 2012 03:35:12 PM CDT using DSA key ID > 345CDD99 gpg: Good signature from "Paul Elliott > " gpg: aka "Paul Elliott > " > Good signature on > /home/pelliott/develop/git/loconvert/sid/try/libreoffice-converter_3.3-2.d > sc. > > Uploading to mentors (via http to mentors.debian.net): > Uploading libreoffice-converter_3.3-2.dsc: done. > Uploading libreoffice-converter_3.3-2.debian.tar.gz: Traceback (most > recent call last): File "/usr/bin/dput", line 926, in > > main() > > File "/usr/bin/dput", line 889, in main > > files_to_upload, debug, 0, progress=progress) > > File "/usr/share/dput/http.py", line 103, in upload > > conn.endheaders() > > File "/usr/lib/python2.7/httplib.py", line 954, in endheaders > > self._send_output(message_body) > > File "/usr/lib/python2.7/httplib.py", line 814, in _send_output > > self.send(msg) > > File "/usr/lib/python2.7/httplib.py", line 776, in send > > self.connect() > > File "/usr/lib/python2.7/httplib.py", line 757, in connect > > self.timeout, self.source_address) > > File "/usr/lib/python2.7/socket.py", line 553, in create_connection > > for res in getaddrinfo(host, port, 0, SOCK_STREAM): > socket.gaierror: [Errno -2] Name or service not known The ftp server may be down but at least the upload works. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
maximal or minimal deletion when creating dfsg tarball?
My package source tarball contains some "convenience copies of code". I have modified the package to use to the external package instead, so this code is now unneeded and unused. Unfortunately, my upsteam's upstream, (ie. the source my upstream copied from), also included some unsourced binaries (documentation in the form of .pdf), with this code. Except for the unsourced binaries, this code is properly licenced. I must remove these, creating a dfsg tarball. It has been suggested by a respected reviewer that while I am removing the unsourced binaries, I remove ALL of the "convenience copies of code". That way the unused code would not confuse anyone. I thought, that when creating a dfsg tarball, one should remove only the files with licensing problems. What is the proper procedure? Remove only the unsourced binaries, or all of the unused code? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Bug#670453: RFS: libreoffice-converter/3.3-1 [ITP] (2nd try)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libreoffice-converter" * Package name: libreoffice-converter Version : 3.3-2 Upstream Author : Petr Mladek : Mirko Nasato * URL : https://build.opensuse.org/package/show?project=3DLibreOffice:Unstable&package=3Dlibreoffice-converter * License : GNU LGPL v2.1 Section : text It builds those binary packages: libreoffice-converter - Commandline Document Converter Using LibreOffice.org To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libreoffice-converter Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3-1.dsc More information about libreoffice-converter can be obtained from Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git Vcs-Browser: http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary Changes since the last upload: * patch from upstreams adds more types * update git Format: field * Initial release. (Closes: 663273) * get rid of old version numbering system * not a ds package anymore. upstream has a tarball! * new watch file * use debian/install * update debian/copyright for new tarball Regards, Paul Elliott signature.asc Description: Digital signature
Bug#671272: RFS: pyswisseph/1.77.00.0+dfsg-2 [ITP]
Package: sponsorship-requests
Severity: normal
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "pyswisseph"
* Package name: pyswisseph
Version : 1.77.00.0+dfsg-2
Upstream Author : Stanislas Marquis
* URL : http://pyswisseph.chaosorigin.com/
: http://pypi.python.org/pypi/pyswisseph
* License : GPLV2+
Section : python
It builds those binary packages:
python-swisseph - Python extension to the Swiss Ephemeris
python-swisseph-docs - Python extension to the Swiss Ephemeris
(common documentation)
python3-swisseph - Python extension to the Swiss Ephemeris (Python 3)
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/pyswisseph
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.77.00.0+dfsg-2.dsc
More information about pyswisseph can be obtained from
http://pypi.python.org/pypi/pyswisseph
http://git.debian.org/?p=collab-maint/pyswisseph.git
git://git.debian.org/git/collab-maint/pyswisseph.git
This python extension module can be tested using openastro.org,
a python program that is also being RFSed:
http://mentors.debian.net/package/openastro.org
Changes since the last upload:
* switch to dfsg package
* change copyright to dep-5, fix copyright file
* Remove ${python:Breaks}, nothing generates this substitution variable
- anymore.
* simplify description.
* remove --buildsystem=python_distutils from debian/rules
- dh is able to detect the build system automatically.
* email message id in Forwarded: line.
* add newline to override file.
* change name to python-swisseph
* rebuild pydoc from source.
* create a documentation package
* create a python3 version of this extension
- using recommendations in:
- http://wiki.debian.org/Python/LibraryStyleGuide
Regards,
Paul Elliott
signature.asc
Description: Digital signature
Bug#671277: RFS: openastro.org/1.1.25+dfsg-4 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "openastro.org" * Package name: openastro.org Version : 1.1.25+dfsg-4 Upstream Author : Pelle van der Scheer * URL : http://openastro.org/ : https://launchpad.net/~pellesimon/+archive/ppa * License : GPLV3+ Section : graphics It builds those binary packages: openastro.org - Fully featured Open Source Astrology software To access further information about this package, please visit the following URL: http://mentors.debian.net/package/openastro.org http://git.debian.org/?p=collab-maint/openastro.git git://git.debian.org/git/collab-maint/openastro.git Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.1.25+dfsg-4.dsc More information about hello can be obtained from http://openastro.org/ This python program depends on the python extension module pyswisseph which is also being RFSed: http://mentors.debian.net/package/pyswisseph Changes since the last upload: * create dfsg package - delete pyswisseph/pyswisseph-1.75.01/doc * change bad permissions before build; use "a-" in command * restore source directory by deleting openastro * upgrade debian/copyright to dep-5 * "debhelper (>= 7.0.50~)" instead of "debhelper (>= 7.0.50)" * use X-Python-Version, not XS-Python-Version * remove XB-Python-Version. * make openastromod private; move /usr/share/openastro.org Regards, Paul Elliott signature.asc Description: Digital signature
Which package owns this bug? Or is it my problem?
When I try to compile my program using make: >g++ -DHAVE_CONFIG_H -I.-pthread -DORBIT2=1 -I/usr/include/atk-1.0 >-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include >-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 >-I/usr/include/gio-unix-2.0/ -I/usr/include/gtkmm-2.4 >-I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 >-I/usr/lib/giomm-2.4/include -I/usr/include/pangomm-1.4 >-I/usr/lib/pangomm-1.4/include -I/usr/include/gtk-2.0 >-I/usr/include/gtk-unix-print-2.0 -I/usr/include/gdkmm-2.4 >-I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 >-I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 >-I/usr/lib/sigc++-2.0/include -I/usr/include/cairomm-1.0 >-I/usr/lib/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/pixman-1 >-I/usr/lib/gtk-2.0/include -I/usr/include/gdk-pixbuf-2.0 >-I/usr/include/gconfmm-2.6 -I/usr/lib/gconfmm-2.6/include >-I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include -O2 -g >-DPELESS_LOCALEDIR=\"/usr/local/share/locale\" -g -O2 -MT peless-peless.o -MD >-MP -MF .deps/peless-peless.Tpo -c -o peless-peless.o `test -f 'peless.cc' || >echo './'`peless.cc >In file included from /usr/include/gtkmm-2.4/gtkmm.h:87:0, > from peless.cc:23: >/usr/include/glibmm-2.4/glibmm.h:82:26: fatal error: glibmmconfig.h: No such >file or directory >compilation terminated. The include file /usr/include/gtkmm-2.4/gtkmm is from the libgtkmm-2.4-dev package. That library has a .pc file: gtkmm-2.4.pc requires atkmm-1.6 and pangomm-1.4 Which in turn requires glibmm-2.4 but glibmm-2.4.pc does not exist. but libglibmm-2.4-dev:i386 is installed. The file glibmmconfig.h exists but is in an archetecture dependant place: /usr/lib/i386-linux-gnu/glibmm-2.4/include/glibmmconfig.h Is this problem a bug in any of the packages I am using? If so, what is the work around? If it is a flaw in my program, what is the most elegant fix? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: Digital signature
Bug#661665: RFS: openastro.org/1.1.25+dfsg-4 [ITP]
On Wednesday, May 09, 2012 08:00:50 AM Ansgar Burchardt wrote:
> forcemerge 661665 671277
> thanks
>
> Hi Paul,
>
> please update the old RFS bug if you address issues from a review (and
> the package wasn't uploaded). It makes it easier to see the whole
> picture in a later review. (Also the older RFS request would still show
> on the bug tracker.)
Yes I believe I have addressed most of the issues refeneced in the review.
I believe I have fixed most these issues with the release indicated by bug
671277, which was merged with this one.
Case by case below:
> Lintian emits:
> P: openastro.org source: debian-control-has-unusual-field-spacing line 5
fixed.
> "debhelper (>= 7.0.50~)" instead of "debhelper (>= 7.0.50)" would be a
> bit more friendly to backporters.
> With dh_python2, you should use X-Python-Version, not XS-Python-Version.
> Also, remove XB-Python-Version.
>
> The package is arch:all, so there's no point including ${shlibs:Depends}
> in Depends, as it won't be ever substituted.
fixed.
> Is there a reason for patching _comments_ in
> 0005-rename-openastro.py-as-required-by.patch? That looks strange.
Soebody might read the comments and be confused.
> When built with restrictive umask (e.g. 027), the package FTBFS:
> | dh_fixperms
I believe I have fixed this issue.
> Then, if I try to build it again it fails with:
> | dpkg-source -b openastro.org-1.1.25
It now builds twice.
> Are the Python modules included in this package supposed to be used by
> other software? If yes, then the package name should be
> python-openastromod. If no, then please move them to a private
> directory.
I have filed a bug against upstream for poor documentation of this module.
Because I believe it is too badly documented to be made public. I have moved
it to a private location for now, and modified openastro script, to find it at
this new location.
> Version number passed to distutils.core.setup() contains a trailing
> newline. Please report his to upstream.
I do not completely understand this. If this problem presists, I will file a
bug against the upstream. Please tell me if this problem still exists!
>
> As the BTS will only show the older report after merging:
>
> The updated package can be found at
>
> dget -x
> http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.
> 1.25+dfsg-4.dsc
>
> Regards,
> Ansgar
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message part.
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
On Wednesday, February 29, 2012 06:49:46 AM Jakub Wilk wrote:
> I don't intend to sponsor this package, but here's my review:
I have addressed these problems with
Bug#671272: RFS: pyswisseph/1.77.00.0+dfsg-2 [ITP]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671272
perhaps this new one should be merged with the old one 661664.
I don't know how to do that, or if I have the privs.
>
> * Paul Elliott , 2012-02-28, 18:32:
> >dget -x
> >http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.
> >77.00-0-3.dsc
>
> Please get rid of “<645551 is the bug number of your ITP>” and “source
> package automatically created by stdeb” cruft from the changelog.
done
>
> “Vcs-Browser” would be more consistent and more common capitalization
> than “Vcs-browser”.
done.
>
> I'd merge all 3 changelog entries into one, and remove of the stuff from
> it. There's no point mentioning that e.g. you added copyright file in an
> initial release. Of course you did. (But OTOH patches you added might be
> worth mentioning.)
done in part.
>
> Remove ${python:Breaks}, nothing generates this substitution variable
> anymore.
done.
>
> The package description is very bad. Please see Developer's Reference
> §6.2.3.
Changed, but I welcome further suggestions.
>
> The copyright file doesn't say where the upstream sources were obtained.
> This is serious violation of Policy §12.5.
Whole copyright file redone in dep5
>
> I don't understand your lintian override. Why you can't correct the
> spelling?
Changed the reasons to:
# Stanislas Marquis holds the copyright on the email
# containing the mispelling. Maintainer can not create
# derived work by editing the email
python-swisseph-docs binary: spelling-error-in-copyright indended intended
#mispelling occurs in upstream's license.
#Maintainer is not authorized to change license.
python-swisseph-docs binary: spelling-error-in-copyright GNU Public License
GNU General Public License
>
> You can remove “--buildsystem=python_distutils” from debian/rules; dh is
> able to detect the build system automatically.
done
>
> Please get rid of the “This file was automatically generated by stdeb”
> comment.
done
>
> Do not use patches to remove files. Such patches are huge and are very
> likely cause conflicts in the future. Just remove the files in
> debian/rules (but see below).
I don't delete them anymore; I just don't use them.
>
> The patches have “Forwarded: yes”, but were they actually forwarded? If
> yes, to who? They look Debian-specific to me.
replaced yes with the mail Message-Id: of the mail message sent to upstream
who has no bug tracker. message is informational, suggests upstream not do
anything.
>
> Assuming that you meant to use DEP-3 for your patch headers, and as far
> as I understand the specification, you need an empty line before the
> pseudo-header.
I believe I have fixed this.
>
> Please regenerate pydoc/* at build time.
done.
create new package:python-swisseph-docs for the results.
>
> The binary package name is wrong. It should be python-swisseph, as per
> Python Policy §2.2.
fixed.
>
> Upstream seems to support Python 3, too. Please consider building a
> separate python3-swisseph package.
done, but no way to test it.
>
> The is no source for PDFs in the doc/ directory. You have the following
> options:
> - Ask upstream to include the source in their tarballs.
> - Repackage their tarballs.
> If you choose the latter option, you could also get rid of unneeded
> files that delete-no-longer-need-swe-files patch currently removes.
Deleted it instead, creating a dsfg package. If anyone needs these files they
are in libswe-dev, a package, that does regenerate these files from source.
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message part.
Is there anyway to prettify long *-Depends: lines?
I have a really long Build-Depends: line. Multiple Build-Depends: lines is an error. '\' at end of physical lines to put logical lines on multiple physical lines does not work and is apparently not allowed. Most editors and display programs do not display long lines well in a fashion that is easy to read. Is there anyway to prettify these lines? Hard to read code can lead to bugs. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Is there anyway to prettify long *-Depends: lines?
On Saturday, May 12, 2012 11:00:04 PM Ben Finney wrote: > Paul Elliott writes: > > I have a really long Build-Depends: line. > > > > Multiple Build-Depends: lines is an error. > > I think you mean “multiple Build-Depends fields”. Yes, that's an error. > > But the field can span multiple lines by indenting the continuation lines: > > = > Build-Depends: > foo, > bar, > baz > = > > and it's all interpreted as a single field. > Thank You That worked. > See Debian policy §5.1, “Syntax of control files”. Yes but it is §7.1 that says the relationship files can be folded. I finally found it! -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
upstream upgrade capable of running in parallel with old version.
My upstream has released version 7. It is like gtk in that the new version and old version are capable of running on the same system. Names of executables have 7 appended to them instead of 6. What is the proper way of handling this? ITP a whole new package? Change the control file to allow it? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Non standard tar-ball.
I have a tarball for a gpled library that I was thinking of turning into a package for a shared library. The tarball is non-standard. Instead of one directory containing the name and version number, it just has a "src" and a "doc" directory in its root directory. Can such a tarball be used as a pristine source for a debian package? Where would the debian subdirectory be? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Non standard tar-ball.
On Thursday, March 24, 2011 03:49:38 am Paul Wise wrote: > dpkg-source doesn't care what is inside the upstream tarball, it will > always unpack to foo-1.2.3/ and the Debian tarball/diff will be > unpacked/applied so that foo-1.2.3/debian/ exists. I guess my question is how to create the source package in the first place, so that dpkg-source will have some thing to work with. I look at Debian New Maintainers' Guide Chapter 2 - First steps http://www.debian.org/doc/maint-guide/ch-first.en.html > Create a subdirectory under your home directory named debian or deb or > anything you find appropriate (e.g. just ~/gentoo would do fine in this > case). Place the downloaded archive in it, and extract it (with "tar xzf > gentoo-0.9.12.tar.gz"). This will create a "src" and "doc" directory in the same directory as the tarball, there will be no foo-1.2.3 sub directory for me to work with. So in what directory do I do the initial debianization? the dh_make? And how do I make sure that the "src" and "doc" directories are inside the directory in which I do the dh-make? It is very confusing! >Make sure there are no errors, even some > irrelevant ones, because there will most probably be problems unpacking on > other people's systems, whose unpacking tools may or may not ignore those > anomalies. On your console screen, you should see the following. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
upstream source contains .gif files
My upstream source contains .gif files that are not essential. If I delete these file and never use them, can I use this tarball as my pristine source, or must I resource? Thank You. P.S. there are a lot of complicated rules to create a package. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: upstream source contains .gif files
On Thursday, March 24, 2011 10:00:32 pm Paul Wise wrote: > On Fri, Mar 25, 2011 at 10:50 AM, Paul Elliott > > wrote: > > My upstream source contains .gif files that are not essential. If I > > delete these file and never use them, can I use this tarball as my > > pristine source, or must I resource? > > Unless they are non-free or you are already repacking the tarball, > don't bother removing them. If you are already repacking to remove > non-free stuff then I think it is acceptable to remove them and use > that as your tarball, check this section of the devref for > recommendations: > > http://www.debian.org/doc/developers-reference/best-pkging-practices.html#r > epackagedorigtargz > Never mind, I found out that patent expired Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
upstream source also includes a .pdf without source
I assume this is a problem for the debian distribution? I will try to get upstream to release the source. I know that fedora and perhaps opensuse can live with unsourced pdfs http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre- built_binaries_or_libraries > Content binaries (such as .pdf, .png, .ps files) are not required to be > rebuilt from the source code. http://en.opensuse.org/openSUSE:Packaging_guidelines#No_inclusion_of_pre- built_binaries_or_libraries (BTW, notice how these two guidelines documents appear to be copied from each other?) But I assume debian being more strict, would require that the source to pdfs be included? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Example library package?
Is there a recommended example library package for a simple library using auto*tools. It should do libfoo, libfoo-devel, and libfoo-doc. Also any tool or methodology to test if a soname is already in use or to reserve them? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: upstream source contains .gif files
On Friday, March 25, 2011 01:43:59 am Ben Finney wrote: > Paul Elliott writes: > > Never mind, I found out that patent expired > > I didn't think you were referring to the Unisys patent on GIF. Yes, that > patent has expired long ago (but GIF is still obsoleted by PNG, and I > usually encourage upstream to replace them). > > What I thought you were referring to was that the images were a binary > form and the “preferred form for making modifications” wasn't included, > hence making the source package non-free. Is that the case for this > package? It is just some logo that the upstream released. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What naming scheme should be used for the Swiss Ephemeris?
I am trying to package the Swiss Ephemeris in a way that will allow it to be included in all the various distros. Actually I hope to package all the free software astrology programs for the various distros. They all depend on the Swiss Ephemeris, so it must be first. It is unfortunate that the first package must be a library as I understand that libraries are the most difficult. The Swiss Ephemeris has been extensively used mostly in a WINDOWS environment and the upstream source is mostly concerned about that environment. Source tarballs are non-standard from a packaging standpoint. I plan to use the upstream's .h and .c files. I plan to replace the make system with autotools infrastructure and add packaging information for both debian and rpm based distros. I plan to get everything building on OBS, and then after some testing, get some people to help me get into the various distros. I do not want to modify the source, that is the .c and .h unless absolutely necessary to make things work. I am not an astrology programmer. Existing Linux programs, that link to the Swiss Ephemeris copy the source create a static library libswe.a and link to that. Existing source tarballs are named like this. swe_unix_src_1.67.00.tar.gz swe_unix_src_1.75.00.tar.gz swe_unix_src_1.76.00.tar.gz swe_unix_src_1.77.00.tar.gz The library has an entry point, swe_version that returns strings like this: 1.77.00 I have a note from the author saying > No API is changed, i.e. old applications work find against newer > libraries. I don't know if this has ever been tested in a Linux or UNIX environment as everyone has been linking staticly. I have read the section in Debian Library Packaging guide on package naming and what files go in what package. I have also read the GNU libtool manual on package versioning. But I am not sure I have understood it all. My questions are: 1) How should my source packages be named? Is swe_unix_src_1.77.00 OK? 2) How should by library package be named? I am sure it should start with libswe, but then I am not so sure. 3)How should my library -dev package be named? 4)what should my SONAME be? I am not sure how the versioning system used for packaging and libtools should interact with my upstream's versioning system which he has a lot invested in. 5)Should the library and its include files be in a subdirectory? I do not think people want include files from the Swiss Ephemeris in /usr/include Thank you for helping me. Many people currently spend a lot of money on proprietary astrology programs runing under proprietary OS. I feel that long term, free software astrology has great potential, because of its superior development model. sharing is better than hoarding. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What naming scheme should be used for the Swiss Ephemeris?
On Sunday, April 03, 2011 09:25:18 pm Paul Wise wrote: > On Mon, Apr 4, 2011 at 10:09 AM, Paul Elliott > > wrote: > > 1) How should my source packages be named? Is swe_unix_src_1.77.00 OK? > > The source package name should be swe and the version number 1.77.00. If I change the name how will people know the original name of the pristine tarball? Or be able to verify that it has not been changed? > > > 2) How should by library package be named? I am sure it should start with > > libswe, but then I am not so sure. > > Depends on the SONAME, see libpkg-guide for a regex that will give you > the package name for a specific SONAME. > > > 3)How should my library -dev package be named? > > libswe-dev unless the library has API versioning. > > > 4)what should my SONAME be? > > The same as upstream. If upstream doesn't build a shared library or > doesn't set the SONAME correctly then you should discuss that with > upstream and ask them to maintain the SONAME properly. If they don't > want to do that then use a Debian-specific SONAME. > > > I am not sure how the versioning system used for packaging and libtools > > should interact with my upstream's versioning system which he has a lot > > invested in. > > Best talk to upstream to clarify that. I am not sure the upstream knows that sonames exist or wants to know. If I am creating the libtools infrastructure, am I not responsible for this? I don't think anyone ever used libtools on this software before. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
data has a longer lifetime than libraries that read the data;What package should own the data directory?
I am working on packaging the Swiss Ephemeris. The Swiss Ephemeris uses a single directory to hold all its data. (Settable by the programmer, so a private directory can be used.) Call this directory the slush fund of data. I want to encourage different programs to share data in one big installed directory, so that different astrology programs do not all have their own private copies of this data. Which is the same. And a large user of space. The upstream has assured me that this data will always be downward compatable, so that if new data formats are ever introduced that old versions of the libraries can not read, new file names will be used for that data, so that old libraries will never try to open files that they can not understand. Any particular data file could be needed or not needed, installed or not installed depending on what is being done. Except for a few short files that should always be there, but they might need to be upgraded with new versions. My problem is: "What package should own the slush fund?" It should not be the library, because when the library upgrades most of the data does not become invalid. Would not want to delete and reinstall all the data at this point. Should not be the package for any particular file, because that package may not be needed hence not installed. Must I create one special essentially imortal package to own the "slush fund"? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
How are directories managed.
This may be a FAQ but I could not find the answer in the documentation: How are directories managed? When does a directory get deleted? What is the lifetime of a directory? Is a directory owned by a specific package? Which packages are alowed to deposit files in a specific directory? What exactly are the rules? If a package wants to put files in a directory, how does the package "know" that the directory will live longer than the file? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How are directories managed?
On Tuesday, April 12, 2011 07:12:15 am Niels Thykier wrote: > If we take the very simple case for a moment, then this is given that A > will exist as long as pkgA is installed. dpkg will not remove > directories as long as a file exists in it. > Extending it a bit, the file A can legally be renamed using > dpkg-divert. If another package uses dpkg-divert to move A, then said > package is expected to provide a replacement for A that keeps pkgA > functional. Otherwise, the diversion can be done by the system > administrator; in this case the sysadmin is expected to know what he/she > is doing. > > ~Niels So if a bunch of related packages all need to own files in the same directory, and if none of these packages has a long lifetime, there does not need to be a long lived package just to keep the directory in existance; the directory will go away when all the packages that use it are gone. Is that correct? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Package consisting of a single data file.
How does one package a single data file. Only other files are needed excepted required documentation files and license files. Nothing to be built. How would such a package be done? Are there any examples? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
data only package?
Can anyone name an example of a well packaged data only package, (no build needed), which is written in dh? I would like to look at an example. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
How to delete the .la file?
I gather that new libraries in the usual case are supposed to delete the la file. What is the standard way to accomplish this if the package is written in dh? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How to delete the .la file?
On Wednesday, May 11, 2011 12:28:57 pm Andreas Moog wrote:
> On 05/11/2011 06:30 PM, Patrick Matthäi wrote:
> > Am 11.05.2011 18:27, schrieb Paul Elliott:
> >> I gather that new libraries in the usual case are supposed to delete the
> >> la file. What is the standard way to accomplish this if the package is
> >> written in dh?
> >
> > I am just using the following snippet in my rules:
> > find debian/tmp/usr/lib -type f -name \*.la -exec sed
> > 's/^dependency_libs/#dependency_libs/g' -i {} \;
>
> That cleans out the dependency_libs entry in the la-file, which is the
> correct thing to do IF there is another package referencing that file.
> However, if that's not the case (like when packaging a new library), the
> la-file shouldn't be installed at all.
OK, how do I do that? Exactly what do I put in the rules file?
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message part.
Can quilt delete or rename a file?
Can Quilt delete or rename a file? My upstream supplies a GNU Makefile, but I am going to replace it with an auto* tools setup. The Makefile will be created by the ./configure step. Should I delete or rename the upstream's for clarity? How would I do this? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
How to adjust the source before a build?
I have an upstream source that was not really designed for Linux builds, (the author is primarily interested in Windblows, but he has GPLed the source), but can be made to work with some adjustments. (Like move or rename a bunch of files, or unpack some nested tarballs.) What is the standard build system hook to do this kind of stuff? At what point to I stop making adjustments and resource the source? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
different version numbers?
All the different versions numbers make my brain hurt! What is the relationship, if any, between the version number of the source pachage and the version number of a library, which has to do with SONAME. What do these have to do with PACKAGE_VERSION in autotools? My up stream, has version number associated with his source tarballs, that have nothing to do with debian or Linux, because he does not develop with Linux in mind. All though he does build a Linux static library. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Plan for managing the SWISS EPHEMERIS data, virtual packages.
Dear Debian Mentors, I am planing to package the SWISS EPHEMERIS library and its data. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635672 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636089 The SWISS EPHEMERIS data is 36 Meg in 54 files. The Swiss Ephemeris library can be used with out installed data if the user has a private copy of the data. I would like to encourage data sharing which is the reason for packaging the Swiss Ephemeris data. Any of the 54 data files could be needed or not needed depending on what the user is doing. For more info about the Swiss Ephemeris see: http://www.astro.com/swisseph/ http://www.astro.com/swisseph/swisseph.htm http://swissephauto.blackpatchpanel.com/ I believe that for desktop users the cost of managing this is less than the cost of installing all the data. It costs for people, either administrators or users to think about things and storage is getting cheap. However some day some one may want to put say, a astrology web server on a low memory device such as home router hardware. These people will want to control exactly what data they will install. I plan to create a package that will include all the data, but I want to provide for people to come a long later and take a more fine grained approach. I propose that each file have its own VIRTUAL PACKAGE. A package with a combination of files would provide and conflict with each virtual package for each file it includes. That way people could create a more fine grained approach to this problem with no risk of two packages providing the same file being installed as the same time. I would like to ask if this is an appropriate use of the virtual package concept? How should I choose the virtual package names? I understand there is a procedure involving Debian-devel consensus for using virtual packages. http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt However, there is an exception: > Packages MUST NOT use virtual package names (except privately, amongst > a cooperating group of packages) unless they have been agreed upon and > appear in this list. Since all packages using these virtual names would be astrology programs using the Swiss Ephemeris or the Swiss Ephemeris library, could this use be viewed as "privately, amongst a cooperating group of packages"? If so, I could skip the debian-devel consensus step. If I need to go the debian-devel I want to get the bugs out of my plan first. I thank everyone for their input and comments. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
how to write watch file for multi-tarball source package?
What is the correct way to handle the watch file in a multi-tarball source package? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201108041158.02750.pelli...@blackpatchpanel.com
Is registered Categories required for debian?
Are debian source packages required to follow http://standards.freedesktop.org/menu-spec/latest/apa.html A. Registered Categories, of freedesktop's Desktop Menu Specification? This document is only a draft, it is seriously messed up, and no one seems to be interested in fixing its flaws. Real bugs, have gone totally untouched for years. It is like no one is home. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: Digital signature
Re: Plan for managing the SWISS EPHEMERIS data, virtual packages.
On Friday, August 05, 2011 10:35:11 AM you wrote: > Hi Paul, > > What you want is not a virtual package but rather a meta-package. See > xserver-xorg for example (or texlive or libreoffice) which pull in > submodules from a central package that holds only central information or > even only puts the Depends (like the gnome and gnome-desktop-environment > package too). > > That way you can break apart sensible chunks into separate packages (up to > 54) and join them back with the central "give me everything" package > (which would be no. 55 at worst). > > I doubt however that it'll make sense to break apart more than ~10 packages > but I'll leave the decision up to you or someone more experienced with the > daily usage. A metapackage is basicly a package that does nothing but depends on other packages, so that installing a metapackage forces a combination of other packages to be installed. So if I created one package for every SE file, then I could define a metapackage SE-data-all that would depend on all of them. Some one else could define a packages that only depends on the modern data, SE-data-modern. The problem with this is that it requires me to package each file individually. I hoped to avoid doing this. If I define one virtual package for each file, I don't have to individually package each file. I can create one package that provides and conflicts with each individual virtual package=file and has a copy of all the data and call this SE-data-all. Someone else later could create a package that contained only the modern data, that would provide and conflict with each virtual package for which the coresponding file contained modern data and in would include only those files. They would call this SE-data-modern. Application programs could decide which virtual packages they wanted to depend on and recommend. Thus the maitreya astrology program could depend on the modern data and recommend all the other. At first my SE-data-all would be the only data package in existance, so maitreya would be forced to bring in all the data. But if someone later created SE-data-modern, the installer of maitreya could force only the modern data to be installed for a low diskspace application even though all the data would still be recommended. My original question is, is this a legitimate use of the virtual package concept? And does this exception apply > Packages MUST NOT use virtual package names (except privately, amongst > a cooperating group of packages) unless they have been agreed upon and > appear in this list. because programs that use the Swiss Ephemeris are a cooperating group of packages, so that I do not have to seek consensus on devian-devel? Thank You for considering this. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What is "privately, amongst a cooperating group of packages"?
What is the meaning of the phrase "privately, amongst a cooperating group of packages" in the document AUTHORITATIVE LIST OF VIRTUAL PACKAGE NAMES http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt I quote: > Packages MUST NOT use virtual package names (except privately, amongst > a cooperating group of packages) unless they have been agreed upon and > appear in this list. Could a group of packages using and providing various subsets of the Swiss Ephemeris data use virtual packages names to define what data they provide/require? Is this "privately, amongst a cooperating group of packages"? I guess all names would start swiss_ephemeris_data_ to prevent collisions. Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
In a single binary source package how does one fail to install some files?
When I was building a library and I wanted to not install the .la file that make install was creating, I could just leave it out of all of the package.install files and it would not be installed. In a single binary package how do I not install a file that make install creates? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: In a single binary source package how does one fail to install some files? It did not work
On Wednesday, August 17, 2011 04:46:30 AM Arno Töll wrote: > Hi, > > On 17.08.2011 05:52, Vincent Cheng wrote: > > override_dh_install: > > find . -name "*.la" -delete > > dh_install > > a single binary package most likely installs a single .la file only, so > a recursive search seems unneeded. That said a simple "rm > path/to/libfoo.la" will do it. > > By the way, dh_install also has a -X option ... > >-Xitem, --exclude=item >Exclude files that contain item anywhere in their filename > from being installed. It did not work! The following file failed to delete COPYING LICENSE.TXT > #!/usr/bin/make -f > # -*- makefile -*- > # Sample debian/rules that uses debhelper. > # This file was originally written by Joey Hess and Craig Small. > # As a special exception, when this file is copied by dh-make into a > # dh-make output file, you may use that output file without restriction. > # This special exception was added by Craig Small in version 0.37 of > dh-make. > > # Uncomment this to turn on verbose mode. > #export DH_VERBOSE=1 > > %: > dh $@ > > override_dh_install: > dh_install --exclude=COPYING --exclude=LICENSE.TXT But this one did delete the 2 files from the .deb file. What is wrong with -- exclude? > #!/usr/bin/make -f > # -*- makefile -*- > # Sample debian/rules that uses debhelper. > # This file was originally written by Joey Hess and Craig Small. > # As a special exception, when this file is copied by dh-make into a > # dh-make output file, you may use that output file without restriction. > # This special exception was added by Craig Small in version 0.37 of > dh-make. > > # Uncomment this to turn on verbose mode. > #export DH_VERBOSE=1 > > %: > dh $@ > > override_dh_install: > rm debian/swe-standard-data/usr/share/doc/swe-standard-data/COPYING \ > debian/swe-standard-data/usr/share/doc/swe-standard-data/LICENSE.TXT > dh_install Thank you. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Depends on -dev package
I quote from Debian Library Packaging guide > 2. -DEV package dependencies > > The -DEV package would usually declare Depends: relationship on all -DEV > packages for libraries that the library package directly depends upon, > with the specific SONAME version that the library package is linked > against. This includes libc-dev. [5] Does this mean that if my library has an include reference #include in one of its .c or .h files, then my -dev package must have a depends line like this in its debian/control file: Depends: OTHER-STUFF, libc6-dev If that is the case, how come the the debian/control file for libtar_1.2.11-6 does not list such a dependancy? it includes . I have been using it as a model, cause it has already gone thru the process. I am probably missing something. Thank you for clearing up my confusion. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Depends on -dev package
On Sunday, August 21, 2011 11:06:35 PM Fernando Lemos wrote: > Hi, > > On Mon, Aug 22, 2011 at 12:59 AM, Paul Elliott > > wrote: > > I quote from Debian Library Packaging guide > > > >> 2. -DEV package dependencies > >> > >> The -DEV package would usually declare Depends: relationship on all -DEV > >> packages for libraries that the library package directly depends upon, > >> with the specific SONAME version that the library package is linked > >> against. This includes libc-dev. [5] > > > > Does this mean that if my library has an include reference > > #include > > in one of its .c or .h files, then my -dev package must have a depends > > line like this in its debian/control file: > > Depends: OTHER-STUFF, libc6-dev > > > > If that is the case, how come the the debian/control file > > for libtar_1.2.11-6 does not list such a dependancy? > > it includes . > > You don't need to list explicity build-depend on anything already > provided by build-essential. According to the policy[1]: > > Build-dependencies on "build-essential" binary packages can be omitted. > > There's even a lintian check for that. It's probably a bad idea to > build depend on libc6-dev directly. > Why then would they explicitly mention that the policy includes libc-dev? > >> against. This includes libc-dev. [5] Surely they knew that libc-dev was in build-essential? I don't understand why they wrote what they did? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Depends on -dev package
A number of responses to my question seem to be confusing Debian Policy 4.2 which refers to "Build-depends:" that is packages necessary to build the package and the Debian Library Packaging guide section 6.2 which refers to the "Depends:" dependancies of the -dev packages that is the packages that the -dev package needs to work. A person installing a -dev package is not necessarily building packages and does not necessarily have build-essential installed. The text of 6.2 explicitly refers to libc-dev which everyone knows is in build essential. Please reconsider your answers in that light. Thank You. On Monday, August 22, 2011 04:54:20 AM Christoph Egger wrote: > Hi! > > Paul Elliott writes: > > I quote from Debian Library Packaging guide > > > >> 2. -DEV package dependencies > >> > >> The -DEV package would usually declare Depends: relationship on all -DEV > >> packages for libraries that the library package directly depends upon, > >> with the specific SONAME version that the library package is linked > >> against. This includes libc-dev. [5] > > > > Does this mean that if my library has an include reference > > #include > > in one of its .c or .h files, then my -dev package must have a depends > > line > > > like this in its debian/control file: > You need that for packages ∉ build-essential that any of your public > headers includes. No reason to do that for some .c files. I've basically > never ever seen a -dev package depending on libc-dev. > > Regards > > Christoph -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
How do I create a symbols file?
lintian -I says I should create a symbols file. But Debian Library Packaging guide nor Debian New Maintainers' Guide tells me exactly how to create such a file or how to name it. Neither does UsingSymbolsFiles http://wiki.debian.org/UsingSymbolsFiles it just says be carefull about it! I am packaging this library for the first time and I am probably the first to build it with libtool. So I probably don't have to worry about previous versions. But some day my work will be the previous version, so I want to do this correctly. The .c files proably have some global symbols that are not in the public interface. The inteface includes global varriables. (I did not write this program.) What should I do? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Please review my 2 packages for the Swiss Ephemeris.
Please review my 2 packages for the Swiss Ephemeris. The 1st is a library package and this is my first package so look for first time mistakes. I plan to eventually ask for a sponsor to get the Swiss Ephemeris into Debian. The Swiss Ephemeris is a blocking point for 4 or 5 other programs including one in KDE/playground. I have had to work around some problems with the upstream source that did not really work with the requirements of GNU/Linux in mind. The first is the Swiss Ephemeris library. Its source can be found here: ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/ #a directory not a repository ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001.orig.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001.orig-astrodienst.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001.orig-astrodocsrc.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001-1.debian.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001-1.dsc =source above=== ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe-dev_1.77.00.0001-1_i386.deb ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe0_1.77.00.0001-1_i386.deb ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/swe-basic-data_1.77.00.0001-1_all.deb ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001-1_i386.build ftp://ftp.berlios.de/pub/swissephauto/debian/libswe/libswe_1.77.00.0001-1_i386.changes This is an unusual 3 tarball source reason found in README.source. The second package is the Swiss Ephemeris standard data. It is bigger in size, but much more simple. I have had to source its tarball from data on astrodienst ftp site. It contains all the standard Swiss Ephemeris data. It can be found here: ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/#a directory not a repository ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1.orig.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1-1.debian.tar.gz ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1-1.dsc ==source above= ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1-1_all.deb ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1-1_i386.build ftp://ftp.berlios.de/pub/swissephauto/debian/swe-standard-data/swe-standard-data_1-1_i386.changes lintian -i -I does not show anything anymore. http://swissephauto.blackpatchpanel.com/ documents my way of building using autotools. This part is hosted at Berlios. https://developer.berlios.de/projects/swissephauto/ I have also had to resource some documentation source omitted by upstream. And I have had to source for the first time the Swiss Ephemeris data into a form that allows packaging , which is available from the upstream's (Astrodienst) web site. In the docs I refer in places to releases to parts at Berlios, these releases have not actually been made yet, because I may want to change those parts as a result of your criticism! Please ignore this. I will do the releases before applying for a sponsor. These packages also builds correctly under opensuse build service: https://build.opensuse.org/package/show?package=debian&project=home%3Apelliott11%3Aastrology%3Aswissephauto%3Alibswe https://build.opensuse.org/package/show?package=debian&project=home%3Apelliott11%3Aastrology%3Aswissephauto%3Aswe-standard-data Please inform me of any mistakes or flaws. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
I can not register.
I tried to register as described in: http://mentors.debian.net/intro-maintainers I filled out the form at: http://mentors.debian.net/register/register Then it sent me an email. but when I visited the page indicated by the email it said: Internal error 404 Help I need to register to send my package so people can find fault with it! -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Attempt to dput fails.
My attempt to send the package swe-standard-data to debian.mentors.net failed. It may be because this is a data package and therefore large. The file it apparently chokes on, swe-standard-data_1-1_all.deb, is 34M in size. I have included below the errors I encounter trying to dput it both with debian6 and with ubuntu. The ubuntu error messages is somewhat more informative. I would like to try method = ftp but that asks for a password and neither "" or anonymous works! Can someone help me? dput error using debian 6: == dput debexpo swe-standard-data_1-1_i386.changes Checking signature on .changes gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1_i386.changes. Checking signature on .dsc gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1.dsc. Uploading to debexpo (via http to mentors.debian.net): Uploading swe-standard-data_1-1.dsc: done. Uploading swe-standard-data_1.orig.tar.bz2: done. Uploading swe-standard-data_1-1.debian.tar.bz2: done. Uploading swe-standard-data_1-1_all.deb: Upload failed: 502 Bad Gateway = dput error using ubuntu dput -ol debexpo swe-standard-data_1-1_i386.changes D: Host debexpo found in config. Checking signature on .changes gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1_i386.changes. Checking signature on .dsc gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1.dsc. Package is now being checked with lintian. Package checked by dput. pelliott@hrnowl:/home/pelliott/develop/astrology/newlibswe/deb2/try$ dput debexpo swe-standard-data_1-1_i386.changes Checking signature on .changes gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1_i386.changes. Checking signature on .dsc gpg: Signature made Fri 23 Sep 2011 06:38:14 PM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2/try/swe- standard-data_1-1.dsc. Uploading to debexpo (via http to mentors.debian.net): Uploading swe-standard-data_1-1.dsc: done. Uploading swe-standard-data_1.orig.tar.bz2: done. Uploading swe-standard-data_1-1.debian.tar.bz2: done. Uploading swe-standard-data_1-1_all.deb: Traceback (most recent call last): File "/usr/bin/dput", line 944, in main() File "/usr/bin/dput", line 907, in main files_to_upload, debug, 0, progress=progress) File "/usr/share/dput/http.py", line 103, in upload conn.endheaders() File "/usr/lib/python2.7/httplib.py", line 951, in endheaders self._send_output(message_body) File "/usr/lib/python2.7/httplib.py", line 811, in _send_output self.send(msg) File "/usr/lib/python2.7/httplib.py", line 773, in send self.connect() File "/usr/lib/python2.7/httplib.py", line 754, in connect self.timeout, self.source_address) File "/usr/lib/python2.7/socket.py", line 553, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): socket.gaierror: [Errno -2] Name or service not known -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Attempt to dput fails.
On Sunday, September 25, 2011 03:41:39 AM Paul Wise wrote: > On Sun, Sep 25, 2011 at 3:58 PM, Paul Elliott wrote: > > Uploading swe-standard-data_1-1_all.deb: Upload failed: 502 Bad > > Gateway > > ... > > >for res in getaddrinfo(host, port, 0, SOCK_STREAM): > > socket.gaierror: [Errno -2] Name or service not known > > Looks like either a DNS issue or a proxy issue. I finally was able to upload this file using ftp. BTW, I was able to upload a more "normal" package before with http. In fact, I uploaded the normal package first. So I think it definately has something to do with size. I think the my account page should show how to setup .dput.cf for ftp as well. It took me a while to guess how this should look to make ftp work. Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
RFS: libswe
Dear mentors, I am looking for a sponsor for my package "libswe". * Package name: libswe Version : 1.77.00.0001-1 Upstream Authors: Dieter Koch ,Alois Treindl * URL : http://www.astro.com/swisseph/swephinfo_e.htm?lang=e * : http://swissephauto.blackpatchpanel.com/ * License : GPL2+ Section : libs It builds those binary packages: libswe-dev - C library for The Swiss Ephemeris libswe0- C library for the Swiss Ephemeris swe-basic-data - basic data files for the libswe package This is the Swiss Ephemeris Library. It works hand and glove with the package swe-standard-data which also needs a sponsor. Several Free Software programs depend on this library and can not be put into Debian without it. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libswe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libs/libswe/libswe_1.77.00.0001-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Paul Elliott -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
RFS: swe-standard-data
Dear mentors, I am looking for a sponsor for my package "swe-standard-data". * Package name: swe-standard-data Version: 1-1 Upstream Authors: Dieter Koch ,Alois Treindl * URL : http://www.astro.com/swisseph/swephinfo_e.htm?lang=e * : http://swissephauto.blackpatchpanel.com/ * License : GPL2+ Section: science It builds those binary packages: swe-standard-data - standard data for the Swiss Ephemeris It works hand and glove with libswe, (the Swiss Ephemeris Library), which also needs a sponsor. Several Free software programs use this data. Individual users of these programs would have to install this data in a private non-shared mode unless the data is installed by a site. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/swe-standard-data Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/swe-standard-data/swe-standard-data_1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Paul Elliott -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What version of debian to develop debian packages?
What version of debian must you have to develop debian packages? mentors.debian.net complains about my standards version: W: libswe source: out-of-date-standards-version 3.9.1 (current is 3.9.2) But if I set this version 3.9.2 on the control file Then lintian on my local debian 6.0 system says: W: libswe source: newer-standards-version 3.9.2 (current is 3.9.1) Must I have some special version of debian to develop, or is there some trick? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
At what point do I create a seperate -doc package for a library?
lintian -i -I is complaining about architecture-independent data: I: libswe-dev: arch-dep-package-has-big-usr-share 2121kB 78% N: N:The package has a significant amount of architecture-independent data N:(over 4MB, or over 2MB and more than 50% of the package) in /usr/share N:but is an architecture-dependent package. This is wasteful of mirror N:space and bandwidth since it means distributing multiple copies of this N:data, one for each architecture. N: N:If the data in /usr/share is not architecture-independent, this is a N:Policy violation that should be fixed by moving the data elsewhere N:(usually /usr/lib). N: N:Refer to Debian Developer's Reference section 6.7.5 N:(Architecture-independent data) for details. N: N:Severity: wishlist, Certainty: certain N: This is because the documentation in format .html and .pdf for this project is 2.2Meg does this mean I must split out a seperate -doc package? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
dput failure to mentors.debian.net
I tried emailing supp...@mentors.debian.net but the message was rejected by the recipient domain. Because of previous difficulty dput'ing swe-standard-data with http I decided to upload it with ftp. Here is the console output: As you can see in succeeds. == pelliott@hrnowl:/home/pelliott/develop/astrology/newlibswe/deb2sid/try$ dput mentors-ftp swe-standard-data_2-1_i386.changes Checking signature on .changes gpg: Signature made Sun 09 Oct 2011 02:59:05 AM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2sid/try/swe- standard-data_2-1_i386.changes. Checking signature on .dsc gpg: Signature made Sun 09 Oct 2011 02:58:40 AM CDT using DSA key ID 345CDD99 gpg: Good signature from "Paul Elliott " gpg: aka "Paul Elliott " Good signature on /home/pelliott/develop/astrology/newlibswe/deb2sid/try/swe- standard-data_2-1.dsc. Uploading to mentors-ftp (via ftp to mentors.debian.net): Uploading swe-standard-data_2-1.dsc: done. Uploading swe-standard-data_2.orig.tar.bz2: done. Uploading swe-standard-data_2-1.debian.tar.bz2: done. Uploading swe-standard-data_2-1_all.deb: done. Uploading swe-standard-data_2-1_i386.changes: done. Successfully uploaded packages. pelliott@hrnowl:/home/pelliott/develop/astrology/newlibswe/deb2sid/try$ == Here is my .dput.cf: = [mentors] fqdn = mentors.debian.net incoming = /upload/pelli...@blackpatchpanel.com/426f18257b8284f990ee9bdf6678d8a3 method = http allow_unsigned_uploads = 0 progress_indicator = 2 [mentors-ftp] fqdn = mentors.debian.net login = anonymous progress_indicator = 2 passive_ftp = 1 incoming = / method = ftp allow_unsigned_uploads = 0 == It has been several hours since I dput'ed. But the new swe-standard-data has not appeared. Please do not be confused by eariler version 1-1. I am refering to the version 2-1 I dputed today. The other package I dputed, libswe, appeared without incident but I used http for it. Any help would be appreciated. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
RFS: libswe
Dear mentors, I am looking for a sponsor for my package "libswe". * Package name: libswe Version : 1.77.00.0002-1 Upstream Authors: Dieter Koch , Alois Treindl * URL : http://www.astro.com/swisseph/swephinfo_e.htm?lang=e * : http://swissephauto.blackpatchpanel.com/ * License : GPL2+ Section: libs It builds those binary packages: libswe-dev - C library for The Swiss Ephemeris libswe-doc - documentation for the libswe package libswe0- C library for the Swiss Ephemeris swe-basic-data - basic data files for the libswe package This is the Swiss Ephemeris Library. It works hand and glove with the package swe-standard-data which also needs a sponsor. http://mentors.debian.net/package/swe-standard-data Several Free Software programs depend on this library and can not be put into Debian without it. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libswe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libs/libswe/libswe_1.77.00.0002-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Paul Elliott -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
RFS: swe-standard-data
Dear mentors, I am looking for a sponsor for my package "swe-standard-data". * Package name : swe-standard-data Version : 2-1 Upstream Authors : Dieter Koch ,Alois Treindl * URL: http://www.astro.com/swisseph/swephinfo_e.htm?lang=e *: http://swissephauto.blackpatchpanel.com/ * License : GPL2+ Section : science It builds those binary packages: swe-standard-data - standard data for the Swiss Ephemeris It works hand and glove with libswe, (the Swiss Ephemeris Library), which also needs a sponsor. http://mentors.debian.net/package/libswe Several Free software programs use this data. Individual users of these programs would have to install this data in a private non-shared mode unless the data is installed by a site. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/swe-standard-data Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/swe-standard-data/swe-standard-data_2-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Paul Elliott -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: Notes about mentors.debian.net
On Tuesday, October 11, 2011 10:32:41 AM Arno Töll wrote: > Hello Boris, > > On 10.10.2011 12:31, Boris Pek wrote: > > 1) Successfully uploaded packages are not deleted from mentors.debian.net > > as it was earlier. There is no even such option in account settings. So > > people should remove own packages manually. Not all need current > > functional for package reviewing... > > There is a setting. If you are logged in, you can remove a package by > clicking on the "Delete package" link. But how do I delete earlier versions without deleteing the most recent version? There is not a delete button for the individual versions. The package swe-standard-data is somewhat large, and I don't have a way of deleting the earlier versions w/o deleting everything. > [1] > http://anonscm.debian.org/gitweb/?p=debexpo/debexpo.git;a=blob;f=debexpo/cr > onjobs/removeolduploads.py;h=e710b2b05f31f3ba72bd3221d1be9ef4828bcb5b;hb=re > fs/heads/devel -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
berlios closing; where should my projects escape to?
Perhaps this is offtopic, but there are so many packagers here, perhaps I can find an answer. Berlios is closing, I have two small projects, GPLed, that use subversion and publish tarballs, where should I go? I looked at sourceforge, but they are always sending me adds. Too comercial for my taste. I signed up at savanah, but they have not even assigned my two create project requests even though their automated system says they should have been done 5 days ago. No one responds to me. I must move my projects before berlios closes. Any suggestions? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: berlios closing; where should my projects escape to?
On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote: > On 18 October 2011 06:02, Paul Elliott wrote: > > [...] > > > > Any suggestions? > > GitHub? I use them for my package repos, and I see that MythTV recently (in > the last few months) switched to them. Not sure about the "full" project > experience, I.e. mailing lists, website etc, but they do appear to have > these features, although I've not used it to that extent. > > Paul. I don't want to learn GIT right now. Is there someplace I could stay with svn? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
watch file when url is raw text not in a link.
Is it possible to write a watch file for a case when the url is raw text in the web page but not in a link, that is, no href? This web page contains the pointer to the file: http://www.openastro.org/?Download which is https://launchpad.net/~pellesimon/+archive/+files/openastro.org_1.1.25.orig.tar.gz but it is raw text in the web page, not in a link. How would one write a watch file for this? I want to pick up files of the form : openastro.org_(.*).orig.tar.gz -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
email rejected bugs.debian.org
I tried to correct a ITP by sending email to 646...@bugs.debian.org but the email was rejected. > Delivery to the following recipient failed permanently: > 646...@bugs.debian.org > > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the recipient > domain. We recommend contacting the other email provider for further > information about the cause of this error. The error that the other server > returned was: 550 550-Blacklisted URL in message. (blackpatchpanel.com) in > [black]. See 550 http://lookup.uribl.com. (state 18). This is a small family domain. I control it. It goes thru google email. only 2 accounts in domain. All the computers on it use linux. It is extremely unlikely any spam has ever been sent from this domain. Could someone white list this domain so that I can participate? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
my upstream's package contains a font.
Help, my upstream package contains a font. /usr/share/fonts/truetype/maitreya/MaitreyaSymbols6.ttf this font is highly specialized and unlikely to be used by any other package. lintian says I must split off a font package. > I: maitreya: font-in-non-font-package > usr/share/fonts/truetype/maitreya/MaitreyaSymbols6.ttf N: > N:This package contains a *.ttf, *.otf, or *.pfb file, file extensions > N:used by TrueType, OpenType, or Type 1 fonts, but the package does not > N:appear to be a dedicated font package. Dedicated font package names > N:should begin with ttf-, otf-, or t1-, depending on the types of fonts > N:included. (Type 1 fonts are also allowed in packages starting with > N:xfonts-.) If the font is already packaged, you should depend on that > N:package instead. Otherwise, normally the font should be packaged > N:separately, since fonts are usually useful outside of the package > that N:embeds them. > N: > N:Severity: wishlist, Certainty: possible > N: debian policy 11.8.5 seems to say the same thing. But I does not say anything about what the font package must be named. Where is that comming from? In any case, if I must split out a font package, how do I do it? Are there any examples out there? Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110270357.53660.pelli...@blackpatchpanel.com
setup packaging project on Alioth?
Could someone write a how to on how to setup a packaging project on Alioth? I would like to record the history of how I package some projects by putting my work in a repository. Maybe someday someone will choose to join in helping me with my projects. It would also help if it became neccessary to replace me, for someone else to take over. What is the standard way to record a packaging project on Alioth in a repository? Is this documented somewhere? I am look for some step by step document like the new maintainer's guide. I am working on a number of astrology programs that I hope to package into a form that can be added to Debian. I am tired of doing a cp -ax to provide myself a way to revert a possible mistake. I usually use svn. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
pre ITP maintainer wishes to remain anonymous
Before I filed an ITP the upstream was his own maintainer distributing outside of debian. His changelog uses his web page instead of his email address. Naturally, this results in lintian error maintainer-address-malformed. How do I keep the history without changing what the previous maintainer did? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: setup packaging project on Alioth?
On Saturday, October 29, 2011 03:29:56 AM Ben Finney wrote: > Paul Elliott writes: > > Could someone write a how to on how to setup a packaging project on > > Alioth? > > As I understand it, one criterion used by the Alioth admins when > deciding whether a project is accepted on Alioth is that it is already > being worked on by multiple people. > > I get the impression that's not the case for your projects, am I wrong? > That is correct right now. But in the future it might change. I read that you don't neccessarily have to have your own your own project: From: > If you maintain collaboratively only a single package, you probably don't > need a full Alioth project with mailing list and everything. You should > use one VCS (subversion repository, GIT repository, bzr repository, ...) > of the collab-maint project. Thanks to ACL, all Debian developers have > write access on those repositories. For SVN, commit notifications are > automatically sent to the Package Tracking System (you need to subscribe > in "advanced mode" on the web interface and to activate the "cvs" keyword, > check the PTS documentation). > > To integrate your package in the subversion repository, use svn-inject > (with option -o to avoid storing upstream sources) with the following URL: > svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/ It is also possible > to import all your previous changes from an existing repository into the > collab-maint repository, see Alioth/CollabMaintImport. If the package is > maintained by external contributors, it should be put in the ext-maint > directory instead of deb-maint (it can easily be moved later if needed). I am not sure I understand this especially the second paragraph. Is this an option? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: pre ITP maintainer wishes to remain anonymous
On Saturday, October 29, 2011 03:15:46 PM Russ Allbery wrote: > Paul Elliott writes: > > Before I filed an ITP the upstream was his own maintainer distributing > > outside of debian. His changelog uses his web page instead of his email > > address. > > > > Naturally, this results in lintian error maintainer-address-malformed. > > > > How do I keep the history without changing what the previous maintainer > > did? > > Lintian will ignore all changelog entries below the line: > > Old Changelog: > > with no leading whitespace in the changelog file. This is intended to > allow preservation of historic entries that are not formatted correctly > for the current standard. It did not work! I added "^Old Changelog:" (^ denotes beginning of line), and I still got maintainer-address-malformed comming from a location in the changelog file after the line begining with "Old Changelog:". Old Changelog: is documented in the section for syntax-error-in-debian-changelog perhaps it only works for syntax errors? Is this a bug or a feature? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
package errors requiring human judgment to detect?
Does anyone have a list of the most common errors that can not be caught by lintian because they require human judgment to detect? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
What is the proper way to rename scripts?
Because of Debian Policy Manual section 10.4 (Scripts) I must rename a script. What is the proper way to accomplish this when using dh 7? It seems to me to be a useless waste of time an energy. Somebody will have to maintain this change. Upstream is not going to rename it, they have real problems to deal with. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What is the proper way to rename scripts?
On Wednesday, November 02, 2011 05:50:29 AM Alexander Reichle-Schmehl wrote: > Hi! > > Am 02.11.2011 11:36, schrieb Paul Elliott: > > Because of Debian Policy Manual section 10.4 (Scripts) > > > > I must rename a script. > > > > What is the proper way to accomplish this when using dh 7? > > Use a dh_install_override to install normaly, and rename the file > afterwards. I have put in a patch to change all references to this script. This includes references in the build procedure. Therefore, the renaming must take place before any part of the build procedure runs. Just like it always had the new name. What is the canonical way to do this? Thank You. I can not change references outside the package, like references in web pages referring to the software, emails people have sent to each other telling them how to use it, and so-forth, therefore the change is sure to cause problems. But this is an objection that applies to many programs. People should really reconsider this policy. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What is the proper way to rename scripts?
On Wednesday, November 02, 2011 12:26:21 PM Siegfried-Angel Gevatter Pujals (RainCT) wrote: > 2011/11/2 Paul Elliott : > > I have put in a patch to change all references to this script. This > > includes references in the build procedure. Therefore, the renaming must > > take place before any part of the build procedure runs. Just like it > > always had the new name. What is the canonical way to do this? Thank > > You. > > Whenever I've encountered this situation I just change all references > after the build procedure, invoking "sed" from debian/rules (I find > this much cleaner than using patches, since it doesn't require any > changes if the files change, etc., you just have to be cautious that > the clean rule reverts the changes correctly). That will not work. The build procedure, (the part comming from upstream), has been changed to use the new name. I do not care to figure out which references to the script are in the build procedure and which need to exist at runtime. There may be some references to the script that are used by both. The rename really needs to happen before build or installation. Is there an dh override that is commonly used to hook in before the build procedure runs? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
documentation conflict --unified-reject-files
Quilt for Debian Maintainers http://pkg-perl.alioth.debian.org/howto/quilt.html says: > Attention: --unified-reject-files was removed in patch 2.6.1-1. Having this > option in ~/.quiltrc breaks quilt. but Debian New Maintainers' Guide 3.1. Setting up quilt http://www.debian.org/doc/manuals/maint-guide/modify.en.html#quiltrc recomends adding the line: >QUILT_PATCH_OPTS="--reject-format=unified" to ~/.quiltrc-dpkg Which is correct? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
