Re: How do you delete a sbuild an sbuild chroot and start over?
OK this time I deleted the recommended files as before, but I noted there were no other chroots in use. So I purged both sbuild and schroot with apt-get and reinstalled. I then recreated th chroot using steps 1-6 of "Create the chroot" from the wiki page. I get the same error! Setup apt archive - Merged Build-Depends: build-essential, fakeroot Filtered Build-Depends: build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-core-dummy' in '/<>/resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'. dpkg-deb: error: failed to make temporary file (control member): No such file or directory Dummy package creation failed E: Setting up apt archive failed +--+ | Cleanup Some how some bad data is being stored in some unknown place. Is there any way to figure out what directory does not exist? (control member) Thank You On Fri, Aug 5, 2016 at 2:42 AM, Paul Elliott <pelli...@blackpatchpanel.com> wrote: > Ok, I deleted my old sbuild chroot for debian testing. > > I then created two sbuild chroot according to the wiki instructions. > > For testing, and for unstable. > > I have then tried to build 2 different packages, on the different chroots. > > > I always get the following error: > Setup apt archive > - > > Merged Build-Depends: build-essential, fakeroot > Filtered Build-Depends: build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-core-dummy' in > '/<>/resolver-mAdLP4/apt_archive/sbuild- > build-depends-core-dummy.deb'. > dpkg-deb: error: failed to make temporary file (control member): No such > file or directory > Dummy package creation failed > E: Setting up apt archive failed > +--- > ---+ > | Cleanup > > I am not sure if this error is because of the way I deleted the old > chroot. Before I was getting a different error complaining > that debfoster does not exist under "testing". BTW why does debfoster fail > to exist under testing? > > Any ideas what the problem is with the above error? As far as I can figure > out sbuild-build-depends-core-dummy does not even exist. > > > Thank You > -- > Paul Elliott 1(512)837-1096 > pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 > http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 > > > On Tue, Aug 2, 2016 at 11:06 PM, Paul Elliott < > pelli...@blackpatchpanel.com> wrote: > >> >> >> Sometimes a user gets a sbuild chroot so screwed up that it does not >> work anymore, and the user has no idea how to fix it, because he does not >> know what he did wrong. >> >> He wants to start over from scratch. >> >> The problem is, it is not documented the correct way to delete >> the chroot and tar ball. The users want to put sbuild back to >> the way it was just after sbuild was installed. >> >> >> What is the proper way to do that? >> >> Thank You for your answers. >> >> >> -- >> Paul Elliott 1(512)837-1096 >> pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 >> http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 >> > >
Re: How do you delete a sbuild an sbuild chroot and start over?
Ok, I deleted my old sbuild chroot for debian testing. I then created two sbuild chroot according to the wiki instructions. For testing, and for unstable. I have then tried to build 2 different packages, on the different chroots. I always get the following error: Setup apt archive - Merged Build-Depends: build-essential, fakeroot Filtered Build-Depends: build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-core-dummy' in '/<>/resolver-mAdLP4/apt_archive/sbuild-build-depends-core-dummy.deb'. dpkg-deb: error: failed to make temporary file (control member): No such file or directory Dummy package creation failed E: Setting up apt archive failed +--+ | Cleanup I am not sure if this error is because of the way I deleted the old chroot. Before I was getting a different error complaining that debfoster does not exist under "testing". BTW why does debfoster fail to exist under testing? Any ideas what the problem is with the above error? As far as I can figure out sbuild-build-depends-core-dummy does not even exist. Thank You -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 On Tue, Aug 2, 2016 at 11:06 PM, Paul Elliott <pelli...@blackpatchpanel.com> wrote: > > > Sometimes a user gets a sbuild chroot so screwed up that it does not > work anymore, and the user has no idea how to fix it, because he does not > know what he did wrong. > > He wants to start over from scratch. > > The problem is, it is not documented the correct way to delete > the chroot and tar ball. The users want to put sbuild back to > the way it was just after sbuild was installed. > > > What is the proper way to do that? > > Thank You for your answers. > > > -- > Paul Elliott 1(512)837-1096 > pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 > http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 >
How do you delete a sbuild an sbuild chroot and start over?
Sometimes a user gets a sbuild chroot so screwed up that it does not work anymore, and the user has no idea how to fix it, because he does not know what he did wrong. He wants to start over from scratch. The problem is, it is not documented the correct way to delete the chroot and tar ball. The users want to put sbuild back to the way it was just after sbuild was installed. What is the proper way to do that? Thank You for your answers. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 signature.asc Description: PGP signature
How to upgrade my gpg key to debian standards?
I am looking at upgrading my gpg key. What parameters should I use? Is there a standard way to get all the people that signed the old key to sign the new key? Thank You. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com 3300 Plaza Drive, apt 1 http://www.free.blackpatchpanel.com/pme/ New Albany, IN 47150 signature.asc Description: Digital signature
Re: Please criticize the package I have been working on, https://github.com/pelliott80/simplescreenrecorder-dpm.git
On Sat, Mar 14, 2015 at 07:15:17AM +1100, Riley Baird wrote: On Fri, 13 Mar 2015 08:27:23 -0500 d/changelog: +You should only list versions of the package that will actually be in Debian, so get rid of the vivid entry. +The changes you make before the initial release generally aren't important enough to go in the changelog. +Generally, new packages should have priority low. *Close the ITP bug. Yes, but remember I don't own this bug, I want to show these change to upstream and the bug owner. Perhaps they will clone, or pull these changes. If I get it working, let them have the fun of closing the bug. d/control: *Where is simplescreenrecorder-lib? This is a very important point. Usually, libs are more difficult... But often initial version is not bad. it is a good idea to insure easy update. d/copyright: *DEP-5 convention is to use GPL-3+ instead of GPL-3.0+ *Remove the and signs from the Source: field. *Include the licensing information for the build files like aclocal.m4, configure, m4/* and build-aux/* *There are some files in glinject/ that are MIT licensed. OK -- 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: Should VCS fields refer to the packaging source or upstream source?
On Fri, Mar 13, 2015 at 02:39:21PM +1100, Riley Baird wrote: your other points appear to be correct, I will work on it. On Thu, 12 Mar 2015 16:42:36 -0500 Paul Elliott pelli...@blackpatchpanel.com wrote: Please criticize the package I have been working on https://github.com/pelliott80/simplescreenrecorder-dpm.git in a git repo in dpm format. -Vcs-Git and Vcs-Browser refer to the VCS of the Debian packaging, not of upstream development Debian Policy Manual Chapter 5 - Control files and their fields 5.6.26 Version Control System (VCS) fields https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields clearly states: Debian source packages are increasingly developed using VCSs. The purpose of the following fields is to indicate a publicly accessible repository where the Debian source package is developed. I interpreted repository where the Debian source package is developed to mean that the VCS fields should point to the packaging source, not the upstream source. Experenced package maintainers please comment. Am I wrong? -Is there any reason that you are limited to i386 and amd64? The upstream did that, perhaps he had a good reason I will check. Riley Baird -- 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
Please criticize the package I have been working on, https://github.com/pelliott80/simplescreenrecorder-dpm.git
Please criticize the package I have been working on https://github.com/pelliott80/simplescreenrecorder-dpm.git in a git repo in dpm format. I am not the owner of the ITP bug, but the owner knows I am working on it. I plan to submit this work to the ITP bug owner. I want to get it in perfect shape for debian. Package now has no lintian errors, except for lack of PGP signatures, and that is an upstream problem. Best wishes to all, and 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
Re: best way to fork data only package on Alioth?
On Tue, Jan 13, 2015 at 01:22:46PM +0800, Paul Wise wrote: On Tue, Jan 13, 2015 at 1:17 PM, Paul Elliott wrote: The two sets of data are disjoint. Your initial mail made it sound like two packages have data in common. Since they actually have no data in common, I'm not sure why forking is needed. If you are wondering about forking the debian/ dir, just copy it to a new git empty repository, delete and recreate debian/changelog, done. Because much of the packaging files are the same or similar. The copyright is almost the same, the watch file is almost the same. The control file is almost the same. the rules file is the same. I did not want to reinvent these wheels. I wanted to be able to track the history of everything. I was originally asking because of the clone --local I was not actually using additional space on the server for the large data files because of links and software smoke and mirrors? -- 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: best way to fork data only package on Alioth?
On Mon, Jan 12, 2015 at 08:25:41AM +0800, Paul Wise wrote: On Sun, Jan 11, 2015 at 11:32 AM, Paul Elliott wrote: ... Your mail doesn't include which package/data you are talking. It is very hard to give you correct advice when we aren't being given the necessary information about the situation we are responding to. I want to create a new package that is identical to the old one except that 1) the name of the package is changed. 2) the data files and their names are changed. What is the reason for wanting the new package? It sounds unnecessary. Would it be a reasonable way to proceed to fork the old package? Create a meta-package depending on the old package and containing symlinks to the old data files. The new package contains data most people won't want. It is big. 69M But those who need this data, need it. By creating a different package, I give the majority the default of opting out, while giving the few the chance to get the data they need. The new package contains ephermis extrapolated data for far past, and far future dates. Researchers can use this data for astronomical historic research like determining the date of the Mahabarata war. I had already decided on the new package. I was asking about the best way to technical way to execute the fork. The Old package is swe-standard-data, new will be swe-extrapolated-data. (Now in progress). -- 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: best way to fork data only package on Alioth?
On Tue, Jan 13, 2015 at 12:55:29PM +0800, Paul Wise wrote: On Mon, Jan 12, 2015 at 6:28 PM, Paul Elliott wrote: The new package contains data most people won't want. It is big. 69M But those who need this data, need it. By creating a different package, I give the majority the default of opting out, while giving the few the chance to get the data they need. The new package contains ephermis extrapolated data for far past, and far future dates. Researchers can use this data for astronomical historic research like determining the date of the Mahabarata war. I had already decided on the new package. I was asking about the best way to technical way to execute the fork. The Old package is swe-standard-data, new will be swe-extrapolated-data. (Now in progress). Could you explain how these two data sets relate to each other? Is swe-standard-data a strict subset of swe-extrapolated-data? If so I would say make swe-extrapolated-data depend on swe-standard-data. Or are the two packages have some data in common and some unique data in each of them? If so I would split the data up into three sets, swe-core-data/swe-standard-data/swe-extrapolated-data. The data is in the same format and used by libraries linked to libswe0. The two sets of data are disjoint. The data one would want depends on the time one is studying. A researcher reasoning about the putitive 5561BC date of the Mahabarata war might want only swe-extrapolated-data. An astrologer doing horiscopes for modern clients would want only swe-standard-data. From the README file: The swe-extrapolated-data package contains only data files for the periods: 11 Aug 13000 BC to 5402 BC and 5400 AD to 7 Jan 16800 AD such data is not usually needed by people not doing extraordinary research. In terms of git repositories, I would only put the debian/ dirs in git. -- bye, pabs https://wiki.debian.org/PaulWise -- 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
best way to fork data only package on Alioth?
I have a data only package on Alioth. make is essentially a nop because the package is all data. I want to create a new package that is identical to the old one except that 1) the name of the package is changed. 2) the data files and their names are changed. The data files are fairly large and unnecessary copies should be avoided if possible. If I were to log on to alioth and do git clone --local --bare old new Would it be a reasonable way to proceed to fork the old package? Am I correct that because of the --local switch the large data files would not actually be copied? Because of hard links and other software smoke and mirrors? What are the pitfalls? 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
How to do a test sbuild with additional package, not in the repositories?
I must prepare a new version of my package because of a transition. however they are holding one package that my package depends on, out of unstable because that would start the transition. The package is libwxsqlite3-3.0-dev I want to be one jump ahead of them when they do do the transition. I have grabed the source from experimental built it under unstable, and used it to test build my package with debuild. However I want to test build my package with sbuild. Sometimes debuild succeeds when it should not, because my test system has some unlisted dependancy. How do I get the one package that is not in unstable (libwxsqlite3-3.0-dev) into sbuild's list of packages for a test build? Thank you for considering this question. It is only 2 packages. How about this for an idea? Use /etc/schroot/sbuild/copyfiles to copy the .dep files into the sbuild chroot then use --pre-build-commands dpkg -i my.dep on the command line to install the additional packages. Do you think it would work? What would go wrong? What should I lookout for? Thank You for your 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: Digital signature
How to do a test sbuild with additional package, not in the repositories?
I must prepare a new version of my package because of a transition. however they are holding one package that my package depends on, out of unstable because that would start the transition. The package is libwxsqlite3-3.0-dev I want to be one jump ahead of them when they do do the transition. I have grabed the source from experimental built it under unstable, and used it to test build my package with debuild. However I want to test build my package with sbuild. Sometimes debuild succeeds when it should not, because my test system has some unlisted dependancy. How do I get the one package that is not in unstable (libwxsqlite3-3.0-dev) into sbuild's list of packages for a test build? Thank you for considering this question. -- 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
I would like to renew my request to delay the removal of maitreya from testing.
On Sat, May 31, 2014 at 12:04:28PM +0100, Olly Betts wrote: On Sat, May 31, 2014 at 12:45:19AM -0500, Paul Elliott wrote: Is there any way the removal of maitreya from testing can be delayed until after the new version of sqlite3 becomes available in unstable? That shouldn't be a concern - the autorm is 4 weeks off, and there are only 3 dependent packages in the wxsqlite3 transition. And looking at the buildd status for wxsqlite3 for experimental, I see the updated package has built everywhere but sparc, and sparc is not currently taken into account for testing migration, so it looks ready to me. Laszlo: Are you ready for an upload to unstable when we get a go from the release team? If so, we should file a transition bug (I'm happy to file it on your behalf if that gets things moving along more efficiently). Paul: I've now filed the wxwidgets3.0 transition bug for maitreya which I promised you in a previous mail in this thread. It looks like there are a few changes needed for wxwidgets3.0 support (I included a partial patch). The package upstream has just finished updating the package and I am now working to use that new upstream release which has been modified to use wxwidgets3.0. It should not take long if I do not run into problems. BUT! I have just checked packages.debian.org and I find that libwxsqlite3-3.0-dev which the new version of maitreya will depend on is still in experimental! Even if it were released to unstable immeadiately, it would take at least 10 days, by my understanding, for it to reach testing, and then 10 days for maitreya to follow. Therefore, I would like to request additional delay to sometime after libwxsqlite3-3.0-dev reaches testing. As matters now stand there is no way I can reach the deadline of -- maitreya 7.0.5-1 is marked for autoremoval from testing on 2014-06-28 -- due to factors outside of my control! I plan to grab the source for libwxsqlite3-3.0-dev from testing and see if I can get it to build under unstable. I then should be able to test my new version of maitreya, but even if all this works, I still will have to wait till it actually reaches unstable before I can ask Jaldhar H. Vyas to upload. Thank You for considering my request. Cheers, Olly -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
I inform a developer about some of the problems with packaging.
it is intended to divert amateurs into the GPL so that libswe will never have a propiatary competitor (it is dual licnesed.) That is OK. I believe in the GPL and would not have it any other way. I created a fork that fixed these problems without changing the astrology. Your bug is not an astrology bug. If your problem were an astrolgy bug I would report it to the real upstream and wait. By real I mean the upstrem's upstream. In this case. Some forks consider themselves to be indpendant projects. Swiss Ephemeris AutoTools does not consider itself that way. It is a matter of interpretation. So I will take your report and create a new tarball for Swiss Ephemeris AutoTools. This I will do wearing my developer hat. Then I will put on my packager hat and take that tarball and import into libswe.git using git-dpm import-new-upstream. In the general case there could be conflicts with previous patches that I would have to resolve at this point. In this case, that will not happen. I will update the changelog and the version number with dch -i and import that into git. Then I will check that I have not broken anything, and that maitreya still builds and works. I will then notify my DD about the new package release and the need for an upload. I have slowly learned this process over many months. I am still learning. 2014-01-21 22:23 GMT+01:00 Paul Elliott pelli...@blackpatchpanel.com: I failed to get into debian. I could not get a sponsor. on Fri, 16 Aug 2013 18:58:54 +0200 the package request was converted from ITP to RFP intent to package to request to package. It is impossible to know exactly why the package failed to get a sponsor. Things to Do to get package into debian IMPORTANT Remove unsourced swisseph documentation from the tar ball. This doc is already available in debian in the package libswe-doc where it is rebuilt from source. Unsourced binaries always force a package to become a .dsfg package. Heavly document everything. Get a packager with experience packaging DEBIAN python and political pull with those known to sponsor python programs. Current packaging source is Vcs-Git: git://git.debian.org/git/collab-maint/pyswisseph.git Vcs-Browser: http://git.debian.org/?p=collab-maint/pyswisseph.git I would be happy to colaborate with experinced python debian packager. sincere best wishes. 2012/4/16 Paul Elliott pelli...@blackpatchpanel.com: Dear Colleague; I don't think this effort will be hampered by any anti-astrology prejudice; I have already gotten maitreya into debian unstable. I am having to work with debian technicalities that apply to all debian programs. Everything built must be rebuilt from source by the build procedure. You must have a license for every file documented. No convenience copies of code. Many other small picky details. The system was designed by Virgos. :-) -- 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
video card for packager who must sometimes run unstable?
This may be the wrong list, but I am not sure what the right list is. When I package, I like to run unstable to see if the packages work. This is becomming difficult because my video interface built into the mother board, is becomming poorly supported, although it used to work well in debian 6. I have nvidia c61 GeForce 6150SE nforce 430. It is very difficult to use. Old windows do not get erased properly. I filed a bug, but I am tired of waiting. It is unusable under debian 7, and unstable has the bug with not erasing windows. I noticed I have an unused PCI Express 16 slot. I thought I could get an inexpensive video card for that slot to work around the problem. I don't need fancy game graphics and I do not want an unfree driver. But what card to get? The usual Linux compatiblity lists do not say how well a card works under unstable. But many of the people on this list, probably also have to use unstable. So I ask what is a inexpensive video card for a PCI express 16 slot, that works well under unstable with free drivers? 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
wxsqlite3 is replaced? how do I find the new functionality?
I have just been notified that my project is being removed from debian testing because of the resolution of bug 741730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741730 Apparently wxsqlite3 is being replaced by functionality in wxwidgets3.0. The problem is I can not find the new functionality! my project includes the file: #include wx/wxsqlite3.h and links to -lwxsqlite3-2.8 -lsqlite3 But debian package search can not find a file named wxsqlite3.h anywhere in unstable except for libwxsqlite3-2.8-dev which is what they are trying to get rid of. How do I find the new functionality, how do I find its include files and how do I link to it? In my opinion they should not be removing old functionality without saying exactly where the new functionality is in the same message! -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
Re: wxsqlite3 is replaced? how do I find the new functionality?
Is there any way the removal of maitreya from testing can be delayed until after the new version of sqlite3 becomes available in unstable? On Sat, May 31, 2014 at 02:06:51AM +0100, Olly Betts wrote: On Fri, May 30, 2014 at 07:13:40PM -0400, Jaldhar H. Vyas wrote: On Fri, 30 May 2014, Paul Elliott wrote: I have just been notified that my project is being removed from debian testing because of the resolution of bug 741730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741730 Apparently wxsqlite3 is being replaced by functionality in wxwidgets3.0. No, the wxsqlite3 package is being updated to be built for wxwidgets3.0 instead of wxwidgets2.8. my project includes the file: #include wx/wxsqlite3.h and links to -lwxsqlite3-2.8 -lsqlite3 Once the new version of wxsqlite3 which uses wxwidgets3.0 is uploaded to unstable (it's currently in experimental), you'll need to change this to instead be: -lwxsqlite3-3.0 -lsqlite3 But debian package search can not find a file named wxsqlite3.h anywhere in unstable except for libwxsqlite3-2.8-dev which is what they are trying to get rid of. That'll be replaced by libwxsqlite3-3.0-dev. You'll also need to update the build dependencies for wxwidgets2.8 to wxwidgets3.0. Instead of: libwxbase2.8-dev, libwxgtk2.8-dev, wx2.8-headers, wx2.8-i18n You should just use: libwxgtk3.0-dev, wx3.0-i18n (Assuming you actually need the i18n files at *build* time - if not, the wx*-i18n). You may need to patch your upstream code to work with wx3.0. I've not yet got to maitreya in my bug filing for the wx3.0 transition, but I'll file a bug shortly with more info. You're right. I'm cc'ing Olly and Lazlo and hopefully they can help you. The bug report that the new version should be backwards compatible but if this is not the case we need to make sure the old package doesn't get removed. (Or that Maitreya can be updated.) The autorm from testing may sound a bit scary, but it's really just a way to make transitions less painful. If a package does get removed by this, once a fixed upload is made to unstable, it'll migrate back to testing in the usual way. But it's 4 weeks off, so we should be able to get things fixed by then anyway. Cheers, Olly -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
how to convert a .doc file in the context of a package build?
The upstream for my package has created excellent documentation for the package, in the form, Goddess help him, of a .doc file! Well, at least it is GPLed. I have had more trouble, converting this documentation, in the context of a build, to a civilized form, than I ever had building the program. I would like to comment on some of the methods I have used and solicit comments from others that must have had the same problem. All of the methods, that I have been able to use, are based on libreoffice. This is a difficulty, because libreoffice seems always to change. Also the parts that need to be installed for the conversion to work, seems to vary and be undocumented. unoconv works but it must be carefully used. It tends to leave unkilled sub-processes around that must be carefully killed or sbuild will hang indefinitely. libreoffice convert (loconvert) from the open suse world can be copied over. It is gpled. But it is written in python2 and the dependencies are also not clear. libreoffice --convert-to works, but the command to be used is baroque and undocumented and the build-depends dependencies are undocumented and unclear. We need a clear method for converting these files, which does to leave unclear subprocess, which is well documented and whose build-depends dependencies are clear and documented. What are others experience? -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
Re: What do you do when your sid development system stops working?
On Mon, May 12, 2014 at 08:45:36AM +0200, Greg Horn wrote: Hi Paul, It might be helpful if you mention how far you can get. For instance, are you stuck in X11 with no screen, or do you know how to log into your system through the linux console by pressing ctrl-alt-F3 (or F4, F5...)? Did you try a previous kernel from the grub boot menu? I logged in using ctrl-alt-f1. Tried restarting gdm3, then stopping gdm3, using kdm instead. Did not work. Stopping the dm, and login as user, and startx did not work. The previous kernel did not help. Best, Greg -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
Re: What do you do when your sid development system stops working?
On Mon, May 12, 2014 at 11:56:49AM +0200, Jérémy Lal wrote: Le dimanche 11 mai 2014 à 21:33 -0500, Paul Elliott a écrit : It happened to me this sunday (got caught by the llvm-3.4 upgrade). I carefully downgrade each package recently updated, as logged in /var/log/apt/history.log. If i cannot find the old version of a package, i use lynx to download directly the deb file out of snapshot.debian.org. It usually restores the system in a working state. Also, etckeeper might help if you're often fiddling with /etc. Jérémy. Below is the long list of debs that were installed. do any strike people as suspicious? i.e. the one to check first? Thank You. Start-Date: 2014-05-11 20:35:27 Commandline: apt-get dist-upgrade Install: libmwaw-0.2-2:i386 (0.2.0-2, automatic), librygel-server-2.2-2:i386 (0.22.1-1, automatic), libfreehand-0.0-0:i386 (0.0.0-3, automatic), libeot0:i386 (0.01-2, automatic), librygel-renderer-2.2-2:i386 (0.22.1-1, automatic), libavdevice54:i386 (10.1-1, automatic), libiptcdata0:i386 (1.0.4-3, automatic), libfbclient2:i386 (2.5.2.26540.ds4-10, automatic), libetonyek-0.0-0:i386 (0.0.4-2, automatic), libindi-plugins:i386 (0.9.8.1-2, automatic), firebird2.5-common-doc:i386 (2.5.2.26540.ds4-10, automatic), rename:i386 (0.20-3, automatic), libavfilter4:i386 (10.1-1, automatic), libreoffice-base-drivers:i386 (4.2.4-1, automatic), libreoffice-sdbc-firebird:i386 (4.2.4-1, automatic), xserver-xorg-video-modesetting:i386 (0.8.1-2, automatic), libavutil53:i386 (10.1-1, automatic), firebird2.5-common:i386 (2.5.2.26540.ds4-10, automatic), firebird2.5-server-common:i386 (2.5.2.26540.ds4-10, automatic), librygel-core-2.2-2:i386 (0.22.1-1, automatic), ruby2.1:i386 (2.1.2-1, automatic), libruby2.1:i386 (2.1.2-1, automatic), libcmis-0.4-4:i386 (0.4.1-6, automatic), libabw-0.0-0:i386 (0.0.2-3, automatic), libreoffice-avmedia-backend-gstreamer:i386 (4.2.4-1, automatic), libtracker-sparql-1.0-0:i386 (1.0.1-2, automatic), xulrunner-29:i386 (29.0.1-1, automatic), libe-book-0.0-0:i386 (0.0.3-2, automatic), libindidriver0c:i386 (0.9.8.1-2, automatic), libavformat55:i386 (10.1-1, automatic), libavcodec55:i386 (10.1-1, automatic), libreoffice-sdbc-hsqldb:i386 (4.2.4-1, automatic), libfbembed2.5:i386 (2.5.2.26540.ds4-10, automatic) Upgrade: libreoffice-common:i386 (4.1.6~rc2-1, 4.2.4-1), ant:i386 (1.9.3-2, 1.9.4-1), nautilus-data:i386 (3.8.2-2, 3.8.2-3), console-setup:i386 (1.107, 1.108), libx11-xcb1:i386 (1.6.2-1, 1.6.2-2), git-doc:i386 (2.0.0~rc0-2, 2.0.0~rc2-1), libreoffice-evolution:i386 (4.1.6~rc2-1+b1, 4.2.4-1), perl-modules:i386 (5.18.2-2, 5.18.2-3), java-common:i386 (0.51, 0.52), apt:i386 (1.0.2, 1.0.3), kde-l10n-it:i386 (4.11.5-1, 4.12.4-1), dnsmasq-base:i386 (2.70-1, 2.70-2), libindi-data:i386 (0.9.7-1, 0.9.8.1-2), libharfbuzz0b:i386 (0.9.27-1, 0.9.28-1), libgweather-3-6:i386 (3.12.0-1, 3.12.1-1), perl:i386 (5.18.2-2+b1, 5.18.2-3), make:i386 (4.0-4, 4.0-5), libdevhelp-3-2:i386 (3.12.0-2, 3.12.1-1), libopenvg1-mesa:i386 (10.1.1-1, 10.1.2-1), libreoffice-impress:i386 (4.1.6~rc2-1+b1, 4.2.4-1), libva-x11-1:i386 (1.3.0-2, 1.3.1-1), kde-l10n-lv:i386 (4.11.5-1, 4.12.4-1), ure:i386 (4.1.6~rc2-1+b1, 4.2.4-1), libindi0b:i386 (0.9.7-1, 0.9.8.1-2), libreoffice-help-en-us:i386 (4.1.6~rc2-1, 4.2.4-1), libvte-2.90-common:i386 (0.36.0-2, 0.36.1-1), python-simplejson:i386 (3.3.3-1, 3.4.1-1), brasero:i386 (3.8.0-2+b1, 3.10.0-1), kde-l10n-nl:i386 (4.11.5-1, 4.12.4-1), libx11-data:i386 (1.6.2-1, 1.6.2-2), libreoffice-style-tango:i386 (4.1.6~rc2-1, 4.2.4-1), libglapi-mesa:i386 (10.1.1-1, 10.1.2-1), libbrasero-media3-1:i386 (3.8.0-2+b1, 3.10.0-1), git-svn:i386 (2.0.0~rc0-2, 2.0.0~rc2-1), libibverbs-dev:i386 (1.1.7-1, 1.1.8-1), keyboard-configuration:i386 (1.107, 1.108), libva1:i386 (1.3.0-2, 1.3.1-1), libibverbs1:i386 (1.1.7-1, 1.1.8-1), gdm3:i386 (3.8.4-7, 3.8.4-8.1), lm-sensors:i386 (3.3.5-1, 3.3.5-2), geoip-database:i386 (20140409-1, 20140509-1), libdrm-intel1:i386 (2.4.53-1, 2.4.54-1), ps2eps:i386 (1.68-1, 1.68+binaryfree-1), kde-l10n-sv:i386 (4.11.5-1, 4.12.4-1), default-jre:i386 (1.7-51, 1.7-52), libvte-2.90-9:i386 (0.36.0-2, 0.36.1-1), ttf-liberation:i386 (1.07.3-3, 1.07.4-1), default-jre-headless:i386 (1.7-51, 1.7-52), xserver-xorg-video-mga:i386 (1.6.3-1+b1, 1.6.3-2), libegl1-mesa:i386 (10.1.1-1, 10.1.2-1), libdevel-stacktrace-perl:i386 (1.3100-1, 1.3200-1), libexception-class-perl:i386 (1.37-1, 1.38-1), libreoffice-math:i386 (4.1.6~rc2-1+b1, 4.2.4-1), libxmu6:i386 (1.1.1-1, 1.1.2-1), espeak:i386 (1.47.11-1, 1.48.04-1), grub-common:i386 (2.02~beta2-9, 2.02~beta2-10), libreoffice-calc:i386 (4.1.6~rc2-1+b1, 4.2.4-1), libraptor2-0:i386 (2.0.13-1, 2.0.14-1), libgbm1:i386 (10.1.1-1, 10.1.2-1), libxmuu1:i386 (1.1.1-1, 1.1.2-1), python-qt4-dbus:i386 (4.10.3+dfsg1-1+b1, 4.10.4+dfsg-2), bogofilter-common:i386 (1.2.4+dfsg1-2, 1.2.4+dfsg1-3), libdrm-radeon1:i386 (2.4.53-1, 2.4.54-1), libespeak1:i386 (1.47.11-1, 1.48.04-1), fonts-opensymbol:i386 (102.3+LibO4.1.6~rc2
What do you do when your sid development system stops working?
I like to do my packaging under sid, because that is where the packages will first have to run, so I can test them there. But what do you do when your sid system stop work after doing an apt-get dist-upgrade? X11 stopped working no screens found. Of course I filed a bug. But is there some kind of work around that will let you keep working somehow? -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
how to allocate a TCP port?
I am currently working on a way that computers with hardware random numbers generators can share random numbers with computers that do not have hardware random number generators. It looks like everything can be done with simple scripts so that no new low level source code needs to be written. All that seems to be needed is a xinet.d entry on the source, and a /etc/init.d/ entry and a bash script on the reciever. When I get it done and tested, I plan to submit it to the rng-tools people. Perhaps they will put it in contrib. Or perhaps I will make my own project. In any case, the sender and reciever need to share a privledged port. What is the official way of getting one of these allocated in /etc/services? 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
Re: how to allocate a TCP port?
On Sun, Oct 20, 2013 at 04:39:09PM -0700, Russ Allbery wrote: https://www.iana.org/form/ports-services However, if by privileged port you mean a port number lower than 1024, note: User port numbers range between 1024 and 49151. If you wish to register a system port — those numbered 1023 or less — it must be done through the standardisation process of the IETF. In other words, you will need to write an RFC for your protocol and have it approved by the normal IETF process. (I think this is quite reasonable given how scarce such ports are.) The reason to make it privileged would be to prevent spoofing by non-privileged users. perhaps one of the crpto based authentication strategies, (ssh, ssl) would be better for the general case. But these are expensive of cpu cycles. -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
Should .pc filenames depend on the version number?
This may be an upstream type question, but because I do the *autotools type stuff for libswe, (even though I I don't touch the actual source,) I thought I would ask this question. should the .pc file name depend on the version number of the library? That is for version 1.80.00.x of libswe should the version number be in the name for the .pc file? Someone has suggested that if the version number was not in the name of the .pc file, people linking to the library would not have to change their link code. In my case the version number was originally put in by anjuta. Are their any counter arguments against removing the version number from the .pc filename? Thank you for considering this question. -- 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
add additional -D from the debian/rules file?
What is the official way to add additional -D definitions to the gcc command line from the debian/rules file? Is it DEB_CFLAGS_MAINT_APPEND ? 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
proper value for --version-info
The first version of libswe in debian was 1.77.00. so the value of --version-info was 0:0:0 libswe_la_LDFLAGS =3D \ -version-info 0:0:0 \ -lm \ -export-symbols-regex ^swe_ Note only symbols beginning swe_ are exposed. version 1.78.00 which was never released, added a new symbol beginning swe_ but it did not change the meaning of any of the old ones so the --version-info for that version should be 1:0:1 I built and checked that version privately, so I consider it a virtual release. Version 1.79.00 does not add any new swe_ symbols at all over 1.78. But new #define preprocessor constansts are added, and the old functions produce new results for these constants. In addition some of the 1.78.00 behavior was a bug. It produced the wrong answer. This has been fixed so that the 1.79.00 gives the correct documented answer. Under these conditions what is the proper value for 1.79.00 --version-info? The reason for my confusion is this section of Libtool: 7.3 Updating library version information https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info It says: The following explanation may help to understand the above rules a bit better: consider that there are three possible kinds of reactions from users of your library to changes in a shared library: 1. Programs using the previous version may use the new version as drop-in replacement, and programs using the new version can also work with the previous one. In other words, no recompiling nor relinking is needed. In this case, bump revision only, don't touch current nor age. 2. Programs using the previous version may use the new version as drop-in replacement, but programs using the new version may use APIs not present in the previous one. In other words, a program linking against the new version may fail with unresolved symbols if linking against the old version at runtime: set revision to 0, bump current and age. 3. Programs may need to be changed, recompiled, relinked in order to use the new version. Bump current, set revision and age to 0. In the above description, programs using the library in question may also be replaced by other libraries using it. I believe that 1) is not true. Because and programs using the new version can also work with the previous one is not true. They will try to use the new #define in the .h files and they will not work. The first part of 2) is true: Programs using the previous version may use the new version as drop-in replacement, but programs using the new version may use APIs not present in the previous one. but the second part of 2) is not true: In other words, a program linking against the new version may fail with unresolved symbols if linking against the old version at runtime This is not true because the linker never sees the new interface. It is hidden by new behavior on calls with new #define in constants. 3) is not true. So the answer depends on weather I should count 2) as true! What do the Debian experts think? I always update the debian/libsweX.symbols file for a new release. In this case it shows no new symbols. 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
multi arch shared libarary with non multi arch -dev package?
Is it OK to have a shared library multi arch with the corresponding -dev package not multi arch? The the -dev package contains some utilitiy arch dep executables and thus can not be made multi arch? 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 --- Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Edward Snowden signature.asc Description: Digital signature
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.
Re: Is there anyway to prettify long *-Depends: lines?
On Saturday, May 12, 2012 11:00:04 PM Ben Finney wrote: Paul Elliott pelli...@blackpatchpanel.com 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.
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.
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 pelli...@blackpatchpanel.com, 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.
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#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 stn...@gmail.com
* 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 pellesi...@gmail.com * 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
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 pmla...@suse.cz : Mirko Nasato mi...@artofsolving.com * URL : https://build.opensuse.org/package/show?project=3DLibreOffice:Unstablepackage=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
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.
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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 module 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.
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 pmla...@suse.cz : Mirko Nasato mi...@artofsolving.com * URL : https://build.opensuse.org/package/show?project=LibreOffice:Unstablepackage=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
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-converterproject=LibreOffice:Unstable For strings that look like: a href=https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice- converter-3.3.tar.bz2?rev=2dffadb97b188c6bc4c0037f1d4c446damp; 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-converterproject=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-converterproject=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: a href=https://api.opensuse.org:443/public/source/LibreOffice:Unstable/libreoffice-converter/libreoffice- converter-3.3.tar.bz2?rev=2dffadb97b188c6bc4c0037f1d4c446damp; 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-converterproject=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-converterproject=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.
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 pmla...@suse.cz Jan Holesovsky ke...@suse.cz * URL : https://build.opensuse.org/package/show?project=LibreOffice:Unstablepackage=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:Unstablepackage=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
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.
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.
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 pelli...@blackpatchpanel.com, 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 pelli...@blackpatchpanel.com, 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.
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]
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 stn...@gmail.com * 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 pellesi...@gmail.com * 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
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.
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.
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
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 pluginhttp://www.microsoft.com/download/en/details.aspx?id=7(and file save as.. or export?) or a programhttp://www.softpedia.com/get/Office-tools/PDF/Simpo-PDF-Creator-Lit e.shtml(and go fileprint) 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.
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.
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.
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.
Re: RFS for libswe
On Wednesday, November 30, 2011 12:18:24 AM Jaldhar H. Vyas wrote: Paul Elliott pelliott at blackpatchpanel.com writes: Thank You for looking at it. Sorry, only got a chance to look at over the weekend. Both packages are looking good but I do have some questions. Why is the data in /usr/share/libswe/users/ephe and not directly in /usr/share/libswe? Does the library require it somehow? If not (and I doubt if it does) it should be changed for aesthetic reasons IMO. Also is there anyway you can avoid the dependency on libreoffice for converting the .doc files? If these issues cannot be resolved it isn't a huge deal. The package is otherwise ready to go. The answer to your question is partly historical, partly reasons. I first worked with libswe, which means I was working with the source file from astrodienst swe_unix_src_1.77.00.tar.gz. One alternative I considered was to make this my pristine source and to make all my changes in the form of patches. But this file has a number of problems. 1) It has pre-built binaries that have to be thrown away. 2) It has some documentation with out the source of that documentation that is the pdf and html files. I had to get the source for the documentation from astrodienst's ftp site, together with a note from the author that the additional files are also under the license. I first worked on getting libswe working. swe_unix_src_1.77.00.tar.gz has a number of small data files that the end user would probably need, and because they were included in swe_unix_src_1.77.00.tar.gz they might be changed with the next release. So I decided to put these in the package swe-basic-data, associated with the same source package. That way if those files changed with the next release from astrodienst, I could change these at the same time. The files in swe-standard-data all come from astrodienst's ftp site. As far as I know astrodienst never put them in a tar ball. I made my own tarball for these files consisting of files from astrodienst ftp site+ license from astrodienst ftp site + autotools make files from me that could be used for packaging. This was done after the package libswe. The libswe package can be used without installed data if the end user provides his own data and points an environment variable at it. This is why libswe0 only recommends swe-basic-data, and swe-standard-data, but does not require it. Because the stuff in libswe is associated with an astrodienst tarball, it probably has a different life-cycle than the data in swe-standard-data. Anything in swe_unix_src_1.77.00.tar.gz could change in the next release from astrodienst. The people at astrodienst have said that the .se1 files will never become unusable. If there is ever a new file format, they will give it a new file name, so that old programs will continue to work. So the stuff in swe- standard-data will probably never have to change because of changes at astrodienst, but the stuff in the libswe packages might change with the next release. So I think it might be a good idea to keep this into separate packages. I thought for a long time about how to organize the .se1 type data into packages. Not every person absolutely needs all this data. Some one could argue it should be broken up into sub packages. I finally thought that disk space is becoming so cheap that the cost of installing it all is probably less than the cost of requiring people to think about and communicate about what data they wanted to install. Some times the end user and the administrator are not the same person. It would be one more opportunity for miscommunication. On the other hand, probably no one would want to install all of the innumerable asteroid files. So I left those out, except for those in the se1 files and one sample. If someone was putting an astrology web page server on a low memory device like a router, they might want to only install part of the data in swe- standard-data. The original libswe from astrodienst assumed all the data would be at: .:/users/ephe2/:/users/ephe/ I knew this would be wrong for debian because most debian systems don't have a /users main directory. So I had to put in a patch to change this location to one that could be owned by the packages. But I wanted to keep the layout of the data parallel to the way it is laid out on the astrodienst ftp site. That way if someone grabs more data from astrodienst's ftp site to put it somewhere on a local site, they would have a natural place to put it. So my place was: .:/usr/share/libswe/users/ephe2/:/usr/share/libswe/users/ephe/ I am not absolutely sure that all these decisions are perfect. I can change them if needed. Please tell me what you think. Thank You for helping me get the package into shape. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX
Re: RFS for libswe
On Monday, November 14, 2011 11:41:40 PM Jaldhar H. Vyas wrote: Paul Elliott pelliott at blackpatchpanel.com writes: I am looking for a sponsor for my package libswe. I'll do it. There has been a longstanding request for the Swiss Ephemeris from users. I even made a package at one point but didn't pursue it as it wasn't completely Open Source at the time. I'll review your work in a day or two. How is the review of libswe doing? I was just wondering. Thank You for looking at 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.
Re: reentrantcy?
On Sunday, November 20, 2011 03:01:57 AM Peter Samuelson wrote: [Paul Elliott] B If all linkings are shared, it is my understanding that the global state of the multiple-linked library would be shared by all references. Statement A and B above seem to contradict each other. If global state means global variables, my experiments show that B is not true but A is true. No, what he meant is: if you link to libraries 'foo' and 'bar', and library 'foo' also happens to use 'bar', then at runtime there will be only one copy of 'bar' in your process address space. If library 'bar' is not reentrant and has shared state, this shared state will affect functionality used by both your base program and library 'foo'. This is all within a single process. Multiple processes don't affect each other unless, as others have noted, you explicitly set up shared memory and the like. Ok I understand what you meant now. I take it I am correct that non-reentrant libraries are allowed, and that non- reentrantcy is no reason to link staticly? Thank You for your answers. -- 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.
reentrantcy?
Is there any requirement that a shared library be reentrant, if the upstream wrote it that way? Am I correct in my assumption, that although non-reentrancy presents a problem for multi threaded programs, it is not a problem for multi-programming, that is two programs using the same shared library at the same time, because the linker will assure that the separate programs will have separate copies of any writable global or static data? I believe that it is better to write reentrant code and such code should be written when starting from scratch. But there is no reason not to use already existing non-reentrant code in non multi threaded applications. Am I correct? Also, I believe that non-reentrantcy, is not reason for static linking. The linker is capable of creating separate copies of writable global or static data, when programs are linked to a shared library. Am I correct? I ask these questions, because I have encountered someone who believes differently. -- 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: reentrantcy?
On Saturday, November 19, 2011 07:27:14 PM you wrote: On Sat, Nov 19, 2011 at 07:03:19PM -0600, Paul Elliott wrote: Is there any requirement that a shared library be reentrant, if the upstream wrote it that way? Am I correct in my assumption, that although non-reentrancy presents a problem for multi threaded programs, it is not a problem for multi-programming, that is two programs using the same shared library at the same time, because the linker will assure that the separate programs will have separate copies of any writable global or static data? A It's not the linker that does it, it's the kernel. Separate programs have separate address space and can not influence each other over memory unless they make the effort of setting up shared memory. I believe that it is better to write reentrant code and such code should be written when starting from scratch. But there is no reason not to use already existing non-reentrant code in non multi threaded applications. Am I correct? There is also the case that a library can be used more than once without threads, for example when you use the library in your program and another library you link in also links to that library. B If all linkings are shared, it is my understanding that the global state of the multiple-linked library would be shared by all references. Statement A and B above seem to contradict each other. If global state means global variables, my experiments show that B is not true but A is true. The state of a global variable in one program does not effect the state of the same global variable in another program that links the same shared library. Both programs have seperate copies of static or global writable varriables of the shared library. Unless the programmer takes special action to force only one copy. Best Wishes. -- 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.
packages on debian mentors.net
When I successfully upload a package debian.mentors software has no problem with, I get a success email. However, if there is something wrong with the package, (that can be detected by the auto software), so that the package is not added to the list, I get no email message. Also, on the Details about package page there is a delete option, but no way to delete earlier versions of the package, (which may be obsolete), without deleting the whole thing! -- 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/20141252.12180.pelli...@blackpatchpanel.com
RFS for libswe
Dear mentors, I am looking for a sponsor for my package libswe. * Package name: libswe Version : 1.77.00.0003-1 Upstream Author (code): Dieter Koch die...@astro.ch, Alois Treindl al...@astro.ch Upstream Author (autotools package): Paul Elliott pelli...@blackpatchpanel.com * URL : http://swissephauto.blackpatchpanel.com/ * URL : http://www.astro.com/swisseph/swephinfo_e.htm?lang=e * 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 I have three Free Software programs packaged and ready for upload that depend on this library and its sister package, but can not be put into RFSed without them. I am working on others. I have simplified this package from its first version. It now has a watch file that actually works. No longer uses multiple tarballs. This will be the 3rd RFS for this package, last RFS was over a month ago. If you can not sponsor this package, please review 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.0003-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 for swe-standard-data
Dear mentors, I am looking for a sponsor for my package swe-standard-data. * Package name: swe-standard-data Version : 3-1 Upstream Author (data): Dieter Koch die...@astro.ch,Alois Treindl al...@astro.ch Upstream Author (tarball): Paul Elliott pelli...@blackpatchpanel.com * URL : http://swissephauto.blackpatchpanel.com/ * URL : http://www.astro.com/swisseph/swephinfo_e.htm?lang=e * 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 I have three Free Software programs packaged and ready for upload that depend on this library and its sister package, but can not be put into RFSed without them. I am working on others. This will be the 3rd RFS for this package, last RFS was over a month ago. Although this package is large because of the data, it is conceptually simple. The data is moved to its location, nothing has to be built. If you can not sponsor this package, please review it. 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_3-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.
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.
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 pelli...@blackpatchpanel.com: 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.
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.
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 pelli...@blackpatchpanel.com 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 pelli...@blackpatchpanel.com 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.
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.
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
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.
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.
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 pelli...@blackpatchpanel.com 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.
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: 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.
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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 die...@astro.ch, Alois Treindl al...@astro.ch * 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 die...@astro.ch,Alois Treindl al...@astro.ch * 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.
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.
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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 pelli...@blackpatchpanel.com gpg: aka Paul Elliott pelli...@io.com 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 module 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 die...@astro.ch,Alois Treindl al...@astro.ch * 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 die...@astro.ch,Alois Treindl al...@astro.ch * 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.
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.
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=debianproject=home%3Apelliott11%3Aastrology%3Aswissephauto%3Alibswe https://build.opensuse.org/package/show?package=debianproject=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.
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.
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 pelli...@blackpatchpanel.com 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 stdio.h 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.
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 stdio.h 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 stdio.h. 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 pelli...@blackpatchpanel.com 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 stdio.h 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 stdio.h. 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.
