Re: dh_haskell in other directory
On Sun, 2005-07-10 at 15:19 -0300, Marco Tulio Gontijo e Silva wrote: > How can I set where dh_haskell (or any debhelper script, I gues) will be > executed? As you are running the script in ./ anywhere you could just use a shell statement like the following: (cd c2hs/; dh_haskell) It will chdir to the directory you specify, run the command and chdir back to the current working directory. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: ldconfig-symlink-missing-for-shlib error
On Thu, 2005-07-14 at 01:53 -0400, kamaraju kusumanchi wrote: > section 8.1 of debian-policy states that > [sic]The run-time library package should include the symbolic link that > |ldconfig| would create for the shared libraries. [sic] > > Does not this mean that ldconfig creates the symbolic link for the > shared libraries? In this case, correct me if I am wrong, ldconfig > should create libfortranposix.so.0 which should point to > libfortranposix.0.0.0 According to the policy you have to provide them by yourself in your run-time library package (e.g. libfortranposix0). Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: What should I call the source package?
On Thu, 2005-07-14 at 23:24 -0400, kamaraju kusumanchi wrote: > After compiling it, I will get two libraries (runtime and development > libraries). I named these packages as libfortranposix0, > libfortranposix0-dev according to their soname. It's libfortranposix0 for the runtime library and libfortranposix-dev for the development package. (If you read by chance debian-devel you should ignore the discussion about naming there for now.) > But I am not sure what the name of the source package should be? > Should it be fortranposix or libfortranposix or libfortranposix0? What's the name of the tarball provided by upstream? You should use that. Both fortranposix and libfortranposix is perfectly acceptable, depending on how the source is usually called. > Also can you please tell against which package name I should file the > ITP? ie against the name of the source or against the name of the binary > package? You should file it with the name of the source package. Not that it matters much, though. But filing it with the current SONAME would not make much sense. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: where to put object file
On Sun, 2005-07-24 at 22:25 +0100, Neil Williams wrote: > Don't forget that Debian is on so many different platforms, compiling the > main.o on one platform is simply not going to work on others. Oh well, did I misunderstand everything here? I thought main.o is an object file which goes indeed into the binary package, but is compiled separately for each architecture and it provides only a main function for standalone felix programs. John, couldn't you just use an ar archive? Otherwise I would say it should probably be installed in /usr/lib/felix and explicitly linked to the resulting binary anyhow? Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: [RFS] tdlinuxcounter
On Wed, 2005-08-03 at 12:59 +0200, Michelle Konzack wrote: > I have send an WNPP/ITP for "tdlinuxcounter" where I am the Upstream. > Because I am working since more then 6 years with Debian and like to > be DM in teh future, I have already packed it for Debian. You have neither provided us with the bug number nor with the description of your package. Please sum up the WNPP bug report and include the description you put into `debian/control'. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
On Aug 5, 2005, at 9:51 PM, Arnaud Vandyck wrote: I see there is a client and a server, do you package the client or the server or both? There is no sense in packaging the server currently, as normally users are not allowed to use the data sources. The data itself is free only for the users of TVBrowser. You have to agree to this on the first run. Did you tried to build/run it with free tools (kaffe, jamvm, sablevm, gcj/gij, jikes, etc...)? (it seems some javax.swing.text.html.* classes are missing in kaffe 1.1.5-x but I don't know if there've been implemented yet...) It didn't run with a free runtime when I tried it (the version from its homepage). Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
On Aug 6, 2005, at 6:09 PM, Bastian Venthur wrote: I wonder, because even if I've cleaned up the whole sources, there would still be the .orig.tar.gz where all this copyrighted stuff is in. You just encountered the case where you need to repackage the source code, with the non-free parts removed from the .orig.tar.gz. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
On Fri, 2005-08-12 at 10:55 +0200, Andreas Fester wrote: > configure *is* the platform independant configure script, > so why ever should I need to create it on my specific platform? Perhaps because somebody found out that the Autotools are buggy in the time frame between configure was built and when the package is built. This frame could actually get quite big. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#672290: RFS: uhub/0.4.0-1 (updated) -- High performance Advanced Direct Connect p2p hub
On Thu, Jun 07, 2012 at 10:58:57PM +0300, Boris Pek wrote: > This version of package should fix FTBFS on s390 and s390x. Which is now > important as I see in debian-devel-announce mailing list [2]. Sorry, but no: 117 files changed, 7945 insertions(+), 1683 deletions(-) I'm ok with sponsoring targetted fixes, but not new upstream versions. Please ask on mentors or your former sponsor. (This looks like drive-by sponsoring which makes me sad.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: RFS: hercules (Non-maintainer upload)
On Tue, Mar 29, 2011 at 11:10:46AM +0800, liang wrote: > I am looking for a sponsor for the version 3.07-2.1 of > my package "hercules". > > It builds these binary packages: > hercules - System/370, ESA/390 and z/Architecture Emulator > > The upload would fix these bugs: 585508, 615729 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/h/hercules > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/h/hercules/hercules_3.07-2.1.dsc > > This is a Non-maintainer upload, before change it myself, > I've tried to contact to contact with Peter De Schrijver, > but failed. So I just make a little change and ask someone > to sponsor it. > > I would be glad if someone uploaded this package for me. Will do. Thanks Philipp kern signature.asc Description: Digital signature
Re: RFS: coldfire: packages URL
On 30.06.2005, at 21:32, Claudio Matsuoka wrote: Changed to 3.6.2.1, which I assume it's the latest policy manual version. I noticed that rpncalc uses Standards-Version: 3.6.6. Is that correct? Lastest is "3.6.2". You do not need to list the minor patch level .1 which is for cosmetic fixes only. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: coldfire: packages URL
On 01.07.2005, at 15:42, Justin Pryzby wrote: Anyone know of a good pseudopackage on which to clone this bug to prevent acceptance of any package with such a standards-version? Is ftp an appropriate place? You could file a wishlist bug on ``ftp.debian.org'' but I doubt that it would get implemented soon. But I doubt that this is a good idea as QA should happen by the DD packaging it before he uploads the package. The first packages uploaded with a new standards-version would be rejected by the archive maintenance scripts if the latter are not updated in time when a new Debian policy hits the archives. And you could not count on a timely update of the standards-version on the FTP infrastructure. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uploading packages built on an amd64 box inside ia32 chroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.07.2005, at 19:56, Geert Stappers wrote: If you have a non ia32 system, then show that and be proud of it. Well at least it should not be possible to upload amd64 binary packages to the main Debian incoming as the port is unknown to katie. But this leads me to another question: Are source-only uploads possible, so that all buildds pick it up? Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 iEYEARECAAYFAkLNinkACgkQ7Ro5M7LPzdhvdACcDmPVXcKQ3HRUw4z7TbwWIwKH jNwAn1Gatfg9a1o+On1crhr8ji8reUSf =ySik -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uploading packages built on an amd64 box inside ia32 chroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.07.2005, at 22:08, Justin Pryzby wrote: I was also wondering, can't you just use a .d.o machine to compile the package, uploading also to some other .d.o machine (incoming, or ftp-master, or whatever it might be). You could not compile most of the packages on the d.o machines with normal user privileges because the dependencies are often missing. Please tell me so if there are now working pbuilder environments on them. ;) Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 iEYEARECAAYFAkLNnWcACgkQ7Ro5M7LPzdhopQCeOc3mEAdgljRw29ExKss0SWkW E74AoIN836cGlFnES1aRgh04PdE2qAWQ =qXKf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: separate binary and sources
On 08.07.2005, at 04:40, John Skaller wrote: (b) apt tools can't build from source Is there a tool which does that? Hm. ``apt-build'' should be able to do it, if it works... I personally had some problems with it. It fetches the source from the normal apt repositories and builds them locally. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tintin++ -- classic text-based MUD client
On 10 Feb 2005, at 16:59, Chris Sacca wrote: I wish to adopt tintin++. I filed a ITA on it (#222109) last week with a complete, lintian / linda clean package of the new upstream (closes bugs #280604 and #170252). I contacted the old maintainer about my wish to adopt the package and asked if he was willing to sponsor me, but he has not responded. I took care of it and intent to sponsor Chris Sacca on tintin++. Regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: nxtvepg
On 11 Feb 2005, at 21:33, Martin Theiss wrote: I am also looking for a Debian Developer near Stuttgart/Germany to have my gpg key signed and complete the first step in the new maintainer process. Look at http://nm.debian.org/gpg_offer.php#de for a Debian developer near you. Regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: Closing bugs
On 27 Feb 2005, at 09:39, Bartosz Fenski aka fEnIo wrote: Also you *have to* tell it to your sponsor. Just tell him to use `dpkg-buildpackage -rfakeroot -v1.2.3-4` or something like that. Please read `man dpkg-buildpackage`. I think it's ``dpkg-buildpackage -rfakeroot -sa -v1.2.3-0''. This would tell the build system to include the source archive in the upload (``-sa'') and to include all changelog items since and include all changelog items strictly later than version 1.2.3-0 (``-v1.2.3-0'', so it would copy those from 1.2.3-1 to 1.2.3-4 into the changes files, together with the ``Closes:'' header. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: Peercast
On 27 Feb 2005, at 17:06, Romain Beauxis wrote: I've tried my best to make it the more clean as possible. Please remove the ``when to start peercast?'' question from the Debconf part of your package. Stuff like this should be your decision, not the one of the user. If both icecast and peercast cannot be started at the same time, please add a ``Conflicts'' for icecast. Second point... Please wrap the changelog after 80 chars. It looks ugly in a normal terminal. And why is "+radiopi" mentioned in the version of the package? Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: Peercast
On 27 Feb 2005, at 19:27, Romain Beauxis wrote: Yes that is the main problem, because it may depends on the end user configuration. Will the Conflicts for icecast prevent from installing both of them? I hope so. And why is "+radiopi" mentioned in the version of the package? Because I made two changes from the source. Do I have to make a new version? Or else? Just include the changes directly in the diff or use ``dpatch'' for a better patch management. But I encourage you to submit those patches upstream if it makes sense. If they are Debian-specific, you should keep them in the Debian-diff anyway. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: kdiff3 - compares and merges 2 or 3 files or directories
On 6 Mar 2005, at 21:19, martin f krafft wrote: ... and thus cannot be used without 150 Mb of additional software I would never need otherwise, right? It is already in Debian. It's about a new revision. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: setserial -- Controls configuration of serial ports (2nd try)
On 11 Mar 2005, at 08:29, Jan Zizka wrote: BTW at least when I have re-duploaded those corrections to mentors.debian.net the package was updated just fine even thow the revision didn't change. I would actually expect what you have described but seems that it's not like that. Mentors uses the simple dinstall method but the Debian archive has a full-fledged dak running. So you would not be able to change something in a revision already uploaded to the official archives. Regards, Philipp Kern PGP.sig Description: This is a digitally signed message part
Re: RFS: mpich2 - An implementation of the MPI2 message-passing interface
Hi Zach, On 19 Mar 2005, at 17:08, Zach Lowry wrote: I'm a long time Debian-user, and this is the first time I'm looking to become more actively involved in Debian development. I have been creating a package for MPICH2 for the past 3 revisions, but I have just now uploaded the package to debian-mentors. There are a couple lf lintian warnings but nothing critical. The packages are available at http://mentors.debian.net or at http://torvalds.cs.mtsu.edu/~zach/debian/1.0.1. A more thorough description of the software follows: I noticed a little typo in README.Debian (``shoudl'' instead of should) and you might want to remove debian/conffiles.ex as it is an example file. debian/copyright: ``It was downloaded from ANL MPICH2 CVS'': Could you please provide the URL to some source code anyway? debian/control: libstdc++5 and libstdc++5-3.3-dev are both build-essential and so is libgcc1, so you don't have to list those in the build dependencies. debian/rules: You should delete all commented dh_* lines. Use them or lose them. dh_installinit --name=mpd: Could this clash with [1]? This package is distributed under the following license: http://www-unix.mcs.anl.gov/mpi/mpich2/license.htm Looks reasonable to me. Kind regards, Philipp Kern Debian Developer [1] http://packages.debian.org/unstable/sound/mpd PGP.sig Description: This is a digitally signed message part
Re: RFS: mpich2 - An implementation of the MPI2 message-passing interface
On 19 Mar 2005, at 18:21, Zach Lowry wrote: | dh_installinit --name=mpd: Could this clash with [1]? Yes it will. Also, the executables clash. Should I make a conflicts entry for this package? I think the better way might be changing the name of your executable and mentioning this fact in README.Debian. Some other mentor could also give his comment on this. By the way you should also check if your package builds in a pbuilder chroot environment. However, due to the fact that you listed that many build dependencies I doubt that it will fail. Regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: main, contrib, non-free
On 5 Apr 2005, at 12:27, Benjamin Cutler wrote: If your .changes file does not say contrib or non-free, then it will not end up there once it hits the official archives. How could I achieve this if I package something for contrib/non-free? Regards, Philipp Kern PGP.sig Description: This is a digitally signed message part
Re: [off topic comment] Re: RFC: cycle (calendar program for women, written in python)
On 5 Apr 2005, at 10:15, Alexandre wrote: On Tue, Apr 05, 2005 at 10:07:15AM +0200, Miriam Ruiz wrote: calculate the days until menstruation, the days of "safe" sex, the fertile period, and the days to I seriously question the use of such tools as contraceptive method, but this is quite off topic here, and I'd suggest including a big flashing warning somewhere in the documentation. And secondly it would not help against AIDS. EOT or follow-up to poster, Philipp Kern PGP.sig Description: This is a digitally signed message part
Re: Create user during installation
On 5 Apr 2005, at 23:06, martin f krafft wrote: Urks, reminds me of those horrible reference counting approaches in popular programming languages. Brittle brittle brittle. Perhaps the user accounts should just go ``out of scope''? ;) Regards, Philipp Kern PGP.sig Description: This is a digitally signed message part
Re: Need sponsored upload
On 7 Apr 2005, at 00:00, Volker Janzen wrote: I hope I fixed all the item in the list, but I'd need someone who controls this and then do a sponsored upload for me. Please provide us with the URL to your prepared package. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: Revision control systems and Debian packages
On 13 Apr 2005, at 13:20, Christoph Berg wrote: Re: Jamie Jones in <[EMAIL PROTECTED]> Can anybody suggest some good revision control systems for maintaining Debian packages. I'm about to outgrow using RCS on the debian directory and wanted to get an idea of what other maintainers are using for their packages. svn-buildpackage. I am still waiting for darcs-buildpackage. ;) Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: NMU for chkrootkit
On 17 Apr 2005, at 18:40, Romain Beauxis wrote: I found out that there had been an new upstream release for chkrootkit, and I intented to package it. chkrootkit is not orphaned, however the maintainer[1] seems missing in action again. Did you already try to contact him by mail about your efforts? At least I doubt that you would find some sponsor who helps you to just take it over instead of following the procedures. Kind regards, Philipp Kern Debian Developer [1] [EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part
Re: Shared library concern
On 17 Apr 2005, at 20:24, François-Denis Gonthier wrote: The soname doesn't seem to be the problem in that case: E: codeblocks: sharedobject-in-library-directory-not-actually-a-shlib usr/lib/libcodeblocks.so.1.0-beta6 ``1.0-beta6'' is not a SONAME. Please read the Debian Library Packaging Guide. Regards, Philipp Kern
Re: RFS: sitecopy
On 23 Apr 2005, at 05:45, Reed Snellenberger wrote: Files are available at: http://home.houston.rr.com/snellenberger/debian/sitecopy/ Do you know why there is an outdated debian/ subdirectory in the upstream tarball? And if the current version of sitecopy does not work with the old xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the versioned one. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Re: RFS: sitecopy
On 23 Apr 2005, at 16:32, Reed Snellenberger wrote: 2) leave the existing Conflicts: in place as-is, because it suggested an actual conflict with the earlier version of xsitecopy. My question was more like this: Is the current xsitecopy in Debian incompatible with the new one? If so please conflict, if not you did the right thing. I was just wondering about it. 3) as an interim step, possibly ask ftp-masters to remove the existing (semi-broken) xsitecopy-0.11.4-6 package (still undecided about that) I don't know really what our archive maintenance ladies do if they lose a binary package from a source package. Perhaps someone else could comment on this. Comments on this strategy would be appreciated ;-) Looks ok to me. Kind regards, Philipp Kern PGP.sig Description: This is a digitally signed message part
Library package naming
-BEGIN PGP SIGNED MESSAGE- (BHash: SHA1 (B (BDear mentors, (B (BI got into trouble with library package naming. I package something (Bcalled net6 which passes -release 1 and -version-info 0:0:0 to (Blibtool. The library version number is 1.0, and the library on disk (Bis called libnet6-1.so.0.0.0 (according to the former parameters). (BHow should the Debian binary package be called? (B (BWhen I read the Debian Library Packagaing Guide I get the impression (Bthat libnet6-1-0 would be correct, but some in #debian-devel said (Bthat the library is improperly named. Upstream's intention for $B!H(B- (Brelease 1$B!I(B was that major versions are binary incompatible anyway and (Bso one could reset the SONAME to 0:0:0. If this versioning should be (Bchanged upstream please tell me so, and please with a clue for me (Bwhat's wrong with it. Otherwise please give me a package name with (Bwhich the package could be added to Debian. (B (BKind regards, (BPhilipp Kern (BDebian Developer (B-BEGIN PGP SIGNATURE- (BVersion: GnuPG v1.4.1 (Darwin) (B (BiEYEARECAAYFAkJ8WTEACgkQ7Ro5M7LPzdjCuACg1q+C0c1tPmiIZ4ZIsLAjKdYc (BfVUAoJHM4Fv+umJwtYoQrjsKz4u45IzY (B=n1ve (B-END PGP SIGNATURE-
Re: RFS: erlang & erlang-base
On 07.05.2005, at 19:03, François-Denis Gonthier wrote: After I said there was no O or RFA, some people on #debian-mentors recommended that I put up an ITA to claim the package. I really don't know if it was the Right Thing to do in retrospect but nor the Debian NM and Reference guide had nothing to say about that. Those were officially orphaned, just not yet filed in the BTS, so I think it was ok to file an ITA. Kind regards, Philipp Kern Debian Developer
Re: Package name
On 20.05.2005, at 08:31, Shachar Shemesh wrote: The package itself had two major life cycles. As such, the source library is called "argtable2". As far as so version goes, it has version 4. Obviously, I will need to ad a "lib" at the beginning. At the moment, I have this: source package: argtable2 shared object: libargtable2-4 devel: libargtable2-4-dev (Donated by Steve Langasek) $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]] *SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' For the devel package I would take the binary package name without the SONAME like libargtable2-dev. I'm having doubts about all choices, however: Should the source be named "argtable"? It seems that upstream is not particularly interested in maintaining the "1" series around, but one never knows. They are clearly and utterly incompatible, however, and there is some slim chance that someone will want to package "libargtable1". How is the tarball named? argtable-2.x oder argtable2-1.x? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volk wird nur zum zahlen gebraucht!
On 20.05.2005, at 10:35, Netty Tielemans wrote: no email s.v.p. There is currently a flood of right-wing German SPAM. This results out of Windows boxes infected with Sober. It harvests random email addresses and uses them for outgoing emails. I advise to just kill those messages containing one or two URLs at the beginning and looking German. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
On 22.05.2005, at 19:15, Shachar Shemesh wrote: I'm sorry, but that is totally wrong. Are you claiming that rsyncrypto is illegal, because it is GPL and links with OpenSSL (which is BSD)? And if you claim this ridiculous claim, who is the offended party? Who has the power to sue me for GPL violation? I'm the sole copyright holder. There are linking exceptions issued by the copyright holders especially for programs linked against OpenSSL. Otherwise GNUTLS has to be used. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ajgui - official gui for p2p-client applejuice
On 24.05.2005, at 13:46, Krall, Torsten wrote: Is nobody interested in helping me ? What is the reason ? Why is there no WNPP bug filed for it? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gephex package
On 28.05.2005, at 13:39, Martin Bayer wrote: I'm searching for an interested sponsor of the upcoming stable release. A sponsor of the upcoming stable release? Anyway, if you mean that you want it in Sarge... Then it is too late. We're only some days apart from the release. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation fails with "unofficial" tesksel .deb file
On 29.05.2005, at 17:37, nidr wrote: Validating tasksel... Debootstrap Error Couldn't download tasksel. Well, you haven't changed the Packages file on your installation medium, with which debootstrap verifies the integrity of the packages it installs (it checks for possible data corruption). I do not have any media at hand, but look for it (it is usually gzipped) and change the md5sum for tasksel to the value you compute with md5sum for the deb. Hope that helps, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation fails with "unofficial" tesksel .deb file
On 29.05.2005, at 19:53, nidr wrote: I actually found the Packages.gz in several places. In my dists/ folder i got five folders which contains the folders contrib and main. Inside all those folder I find Packages and Packages.gz files. But I do not know which of them to edit. There is such a huge amount of them. Try "zgrep 'Package: tasksel' Package.gz" on those in a "main" subdirectory. I don't know what kind of distribution directory you have got within your image. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Sponsor needed for dav text editor (Closes bug #161106)
On 04.06.2005, at 05:39, astronut wrote: Package: dav Architecture: any Description: A minimalist ncurses-based text editor DAV (DAV is not VI) is a free (as in freedom) GNU/Linux console- based text editor. It is licensed under the GPL and is still in development. Could you please list some unique features of this editor? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13.06.2005, at 22:36, martin f krafft wrote: A package that installs /usr/lib/libspf-1.0.so.0.0.0 should be names libspf-1.0-0 from all I can tell. The policy does not dictate how the -dev (and -doc) package should be named. I would prefer not to call it libspf-dev but rather encode the version. If you see the -release bit as the API version you should name your dev package libspf-1.0-dev. That was at least what I was advised to do when I had the same problem some weeks ago. Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 iEYEARECAAYFAkKt9DAACgkQ7Ro5M7LPzdj8KwCgnrObwP4dRHwtjri5RGuyqaOh mAEAn2C05nGr9/zzFsnUK+UUTTJEJ2Qq =6M2e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
On 14.06.2005, at 14:47, martin f krafft wrote: Do you have a pointer to the discussion? Just looking it up in the old thread "Library package naming" I saw that you told me not to use -release at all when packaging a shared library. But yes, the naming of the dev package is not explicitly mentioned. But well, other packages should build-depend on the API and depend on the ABI. The API is specified by the -release flag and the ABI by the SONAME. So it is IMO sane to name it libpkg-1.0-dev, so if there is a new 2.0 API which breaks much of the backwards- compatibility older software could still be built when a new package is uploaded for libpkg-2.0-dev. Just my few cents, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
On 15.06.2005, at 01:51, Junichi Uekawa wrote: The library package guide should tell you to use If it doesn't, that's an error in the guide; but I would also first check the SONAME of the library. Exactly, but I do not recall that it mentions the name of the corresponding dev package, but I did not look it up again. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
On 15.06.2005, at 21:28, Roger Leigh wrote: Major gripe: you build-confict and build-depend upon autoconf and automake. There should not be *any* need to run these and build time. If you do alter Makefile.ams or configure.ac, run the autotools on your system, and have the changes included in the .diff.gz, which makes the build deterministic on all systems, and makes the build much more simple and reliable. What makes a dependency on a more or less specified version of the Autotools turning the whole build into something non-deterministic? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#1088275: RFS: s390-tools/2.35.0-1.1 [NMU] -- Set of fundamental utilities for Linux on S/390
Hi, On 2024-11-27 15:25, Phil Wyett wrote: [...] * For an NMU, version should be 2.35.0-0.1 * 'debian/copyright' needs conversion to DEP-5 format. For an NMU especially - but also in general - I don't think conversion to DEP-5 format is required. I'd go and address at the very least the Lintian warnings on https://mentors.debian.net/package/s390-tools/ (which include the NMU versioning bit). I could figure out if mentors lets me fetch a debdiff against the archive and I don't have my usual tools available right now - so I can't do a more proper check. My question - without further context because of lack of time - would be if the new version was tested. One other interesting test case is building an installer[1] with the new udeb in installer/build/localudebs and actually trying to test an install. Kind regards Philipp Kern
