Re: Is Christian Meder MIA?
Am Mittwoch, den 08.07.2009, 18:40 +0200 schrieb Walter Franzini: > Hi, > > in the past months I've tryied without success to contact Christian > Meder (ch...@absolutegiganten.org), the maintainer of the aegis package, > offering my help. > > As a Debian and Aegis user I'm a bit worried of state of the aegis > package. > > He uploaded 4.24-1 (2008-04-20) and next packaging updates until 4.24-5 > (2008-12-05) in the meantime the upstream team has done one stable > updates (4.24.1 released 2008-09-24). Later (2009-06-29) the upstream > team has released another stable release (4.24.2). > > thanks Hi Walter, sorry for being unresponsive. I had a pretty intense 2009 at work and was mostly ignoring non-urgent private emails. Sorry again. Now life has slowed down a bit and I intend to return to my aegis duties. Thank you for preparing the updated Debian package I'll check it and upload it afterwards. Greetings, Christian -- Christian Meder, email: ch...@absolutegiganten.org The Way-Seeking Mind of a tenzo is actualized by rolling up your sleeves. (Eihei Dogen Zenji) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: > And for the format of the patch, I do not know what to tell them apart that > unified diff is the preferred format of some Debian developers, It's the preferred format for 99% of all Free Software work/projects AFAICT. > and that we like that others use the formats that we prefer. I think > that is a too weak argument, so unless there is a real flaw in the > format used upstream, I will not bother them for a change. This > formats works with quilt, so I do not understand why it would be > difficult to get it work with the format ???3.0 (quilt)??? of dpkg. > According to the current discussion, the problem is more political > than technical. If all fails, you can still drop the upstream patches in debian/upstream-patches/ or so for your own purposes. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is the best place for package meta-data ?
Le Sun, Aug 02, 2009 at 01:37:29PM +0200, Paul Wise a écrit : > I think tying such information to a source or binary package is a bad > idea since it changes independently of the package. I have similar > issues with the Homepage field and to a lesser extent, watch files. > > Do you think that apt needs to have access to this information? Hi Paul, I think that you asked the key question, and that the answer will help us to sort out the metadata contents in Debian packages. Currently, debian/control contains: - Informations for the package manager (dpkg). For instance, the package name, the build dependancies, the binary dependancies, the Essential field,… - Informations for the archive manager (apt). For instance, the section and the priority, the package description,… - Informations for the online user. For instance the homepage and VCS URLs. Typically, informations for the archive manager that are provided by a package repository can differ from the contents of the source package. Descriptions can be translated, section can be overriden (the Section: field in the source package is not authoritative), Debtags can be added, … Informations for the online user could follow the same logic: a copy could be included in the source packages, for the benefit of providing it in a central place and to give an easy interface to the package maintainers, but the one that the users get on-line could be refreshed independantly of package uploads. I was thinking to propose to have a supplementary file in the debian directory following the ‘Name: contents’ convention of Debian control files (same as YAML if we do not do wrapping), that maintainers could update in the source package’s VCS (or at worse on their local hard drive) and use to push the meta-data in a central database between two uploads if need is. However, I realised that the Ultimate Debian Database, which I thought would be a nice place to host the data, works on a retreiving model rather than a pushing model. Before elaborating a complex workaround involving an intermediate place where maintainers could push their meta-data, does anybody think about an alternative? Andreas Tille suggested me the Package Entropy Tracker, but it would limit the system to packages hosted in a Subversion repository. This said, since many of the packages that caused us dig that question (software for which we would like to provide registration and bibliographic information) are mostly stored in a Svn, that may not be a blocker for making a poof of principle… Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
CDBS + python + control with 2 .deb
Hi, I have a package named python-sqlkit with python package sqlkit. I'm using cdbs with a simple rule and the packge is ok: #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk DEB_PYTHON_SYSTEM = pysupport DEB_COMPRESS_EXCLUDE := .py .sqlite include /usr/share/cdbs/1/class/python-distutils.mk binary-install/python-sqlkit:: make DESTDIR=$(CURDIR)/debian/python-sqlkit install Where the last line refers to:: mkdir -p $(DESTDIR)/usr/share/doc/python-sqlkit cp -a demo $(DESTDIR)/usr/share/doc/python-sqlkit cp -a bin/sqledit $(DESTDIR)/usr/bin In control file I added the definition for a second .deb, holding the documentation (+ a sqlkit-doc.docs conf file):: Package: sqlkit-doc Architecture: all Depends: Description: Documentation for sqlkit Pdf and html docs for sqlkit package Now this package is ok but the former does not have the python package any more!... What should I do to have 2 packages defined in control, one a python package and one a documentation package and use cdbs? Thanks in advance sandro *:-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: CDBS + python + control with 2 .deb
sandro (05/08/2009): > What should I do to have 2 packages defined in control, one a python > package and one a documentation package and use cdbs? Try -ment...@. Mraw, KiBi. signature.asc Description: Digital signature
Re: Status of new source formats project
Michael Banck (05/08/2009): > On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: > > And for the format of the patch, I do not know what to tell them > > apart that unified diff is the preferred format of some Debian > > developers, > > It's the preferred format for 99% of all Free Software work/projects > AFAICT. I was wondering who could be in the last 1%. At least OpenSceneGraph people[1] prefer being sent the whole files. :) 1. http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol Mraw, KiBi. signature.asc Description: Digital signature
Bug#540061: RFH: phpwiki -- informal collaborative website manager
Package: wnpp Severity: normal I request assistance with maintaining the phpwiki package. In particular, I need assistance dealing with a number of bugs related to code from other packages that is embedded within the PHPwiki codebase. There is also at least one further instance of this reported by lintian which is not yet in the BTS. PHPwiki wasn't really designed to have these dependencies fulfilled outside of the PHPwiki source and the upstream has not made a release for quite some time (although there are sporadic commits to the upstream svn repository). Some of the code included in PHPwiki is older than the currently packaged versions and a quick diff shows large changes between the packaged versions and PHPwiki's embedded copy. Anyone interested in working on this will likely need to be willing to modify PHPwiki to support loading the dependencies from outside of the PHPwiki source tree, fix any breakage/changes required by the newer versions and then submit the patches upstream. I don't have the time to undertake this kind of work at the moment. Let me know if you are interested. Cheers -- Matt Brown ma...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Non-unified patches and dpkg sou rce format ‘3.0 (quilt)’.
Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit :
>
> The point, rather, seems to be that unified-diff format is the de facto
> standard format for exchanging patch information.
Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit :
>
> It's the preferred format for 99% of all Free Software work/projects
> AFAICT.
In my workplace's cafeteria, 99 % of the people eat curry rice with a spoon,
and 1 % with chopsticks. But this is causing no trouble, and never the spoon
users ask the chopsticks users to change their instrument (and I can tell you
that I do not leave a single grain of rice when I eat my curry rice with
chopsticks).
I am all for campaigning for the unified diff format if there are arguments on
which I can base a discussion with Upstream, but a mere cultural preference,
be it the one of a very large majority, is a too weak argument.
The only practical argument currently is the regression between the dpkg format
1 to 3.0 (quilt), where non-unified patches in debian/patches cause the source
package to be not buildable, only because the Dpkg maintainers decided to
reject non-unified patches despite they can be applied by the patch command
they use in Dpkg::Source::Patch.pm. How is that relevant for Upstream ?
After deleting the following check, my source package builds fine.
--- a/scripts/Dpkg/Source/Patch.pm
+++ b/scripts/Dpkg/Source/Patch.pm
@@ -325,9 +325,6 @@ sub analyze {
unless (defined($_ = getline($diff_handle))) {
error(_g("diff `%s' finishes in middle of ---/+++ (line %d)"),
$diff, $.);
}
- unless (s/^\+\+\+ //) {
- error(_g("line after --- isn't as expected in diff `%s' (line
%d)"), $diff, $.);
- }
$_ = strip_ts($_);
if ($_ eq '/dev/null' or s{^(\./)?[^/]+/}{$destdir/}) {
$fn2 = $_;
Why not just applying the patches and catch errors if there are, instead of
writing a new patch parser from scratch just to check that it looks like being
in the unified format?
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540065: ITP: libsynthesis -- library for SyncML-DS (SyncML Data Sync) clients
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: libsynthesis Version : 3.0.28+git1+cc01b66 Upstream Author : * URL : http://www.synthesis.ch/indefero/index.php/p/libsynthesis/ * License : LGPL2.1 or LGPL3 (with some BSD) . Unless noted otherwise, all files are dual-licensed (LICENSE.LGPL-2.1) and 3.0 (LICENSE.LGPL-3). . Files in the following directories are under a different license: src/expat : public domain (src/expat/copying.txt) doc, src/sysync_SDK : BSD (LICENSE.BSD) src/syncml_tk : BSD-like license (src/syncml_tk/opensource_license.txt) src/zlib: BSD-like (src/zlib/README) Programming Lang: C++, C Description : library for SyncML-DS (SyncML Data Sync) clients The Synthesis SyncML engine supports SyncML versions 1.0, 1.1 and 1.2 including complex features like data filtering, suspend & resume, vCard/vCalendar format conversion in a way completely transparent to the user of the library. This package is a build-dependency for syncevolution (ITP#404942). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
Charles Plessy (05/08/2009): > In my workplace's cafeteria, 99 % of the people eat curry rice with a > spoon, and 1 % with chopsticks. But this is causing no trouble, and > never the spoon users ask the chopsticks users to change their > instrument (and I can tell you that I do not leave a single grain of > rice when I eat my curry rice with chopsticks). Should we care? > I am all for campaigning for the unified diff format if there are > arguments on which I can base a discussion with Upstream, but a mere > cultural preference, be it the one of a very large majority, is a too > weak argument. According to a quick look at the diff wikipedia page[1], unified diffs appeared in GNU diff 1.15, released in January 1991. 1. http://en.wikipedia.org/wiki/Diff Time to move on? Anyway: Heard about the thing called “context”? Mraw, KiBi. signature.asc Description: Digital signature
Re: Non-unified patches and dpkg so urce format ‘3.0 (quilt)’.
Charles Plessy wrote: Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit : The point, rather, seems to be that unified-diff format is the de facto standard format for exchanging patch information. Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit : It's the preferred format for 99% of all Free Software work/projects AFAICT. In my workplace's cafeteria, 99 % of the people eat curry rice with a spoon, and 1 % with chopsticks. But this is causing no trouble, and never the spoon users ask the chopsticks users to change their instrument (and I can tell you that I do not leave a single grain of rice when I eat my curry rice with chopsticks). I am all for campaigning for the unified diff format if there are arguments on which I can base a discussion with Upstream, but a mere cultural preference, be it the one of a very large majority, is a too weak argument. I think there is few advantages on non-unified diff: I don't think many upstreams will take advantage of it, and I think few upstream will take patched from our source package. IMHO the right way to sent patched upstream is send comments and patches, in they preferred form (format of patch, format of comment, target (like mailing list) and last upstream version). Note also: rediff works only on unified patches. The disadvantages: we need to build a lot of tools to test quality of our packages. I think handling different diff format will decrement the quality of such tests. I really think that in our future we will have a lot of automatic testing tools to detect problem before they happens. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Charles Plessy writes: > Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit : > > > > The point, rather, seems to be that unified-diff format is the de > > facto standard format for exchanging patch information. > > Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit : > > > > It's the preferred format for 99% of all Free Software work/projects > > AFAICT. > > In my workplace's cafeteria, 99 % of the people eat curry rice with a > spoon, and 1 % with chopsticks. But this is causing no trouble Right, because an individual's use of spoon or chopsticks to eat their own meal isn't about interaction *between* people; it's a private choice that affects only that individual. The analogy doesn't hold for this discussion, since this is about data interchange formats, which affects *all* parties in the transaction. See how far you'd get with expecting accommodation of 1% of people using a different form of currency to pay for their curry rice. > I am all for campaigning for the unified diff format if there are > arguments on which I can base a discussion with Upstream, but a mere > cultural preference, be it the one of a very large majority, is a too > weak argument. Standard data interchange formats is such an argument: one which you even quoted me as putting forth. The de facto standard data format for interchange of patch data is unified-diff format. -- \ “Well, my brother says Hello. So, hooray for speech therapy.” | `\ —Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is the best place for package meta-data ?
Charles Plessy writes: > Le Sun, Aug 02, 2009 at 01:37:29PM +0200, Paul Wise a écrit : >> I think tying such information to a source or binary package is a bad >> idea since it changes independently of the package. I have similar >> issues with the Homepage field and to a lesser extent, watch files. >> >> Do you think that apt needs to have access to this information? > > Hi Paul, > > I think that you asked the key question, and that the answer will help us to > sort out the metadata contents in Debian packages. > > Currently, debian/control contains: > > - Informations for the package manager (dpkg). For instance, the package > name, >the build dependancies, the binary dependancies, the Essential field,⦠> > - Informations for the archive manager (apt). For instance, the section and >the priority, the package description,⦠> > - Informations for the online user. For instance the homepage and VCS URLs. - Information for the BTS (maintainer) - Information for DAK (maintainer, uploader, DM-Allowed) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can you (re)confirm that packages re-uploaded to NEW are processed according to the date of their first upload?
> The web summary of the queue contents lists the packages by upload date, but I > remember reading from you in a previous discussion that the queue is processed > according to the date of the first upload. Unfortunately, I lost the > reference… > Can you confirm, or can somebody point me at the correct message in our lists > archive, so that I can document it on the wiki page? The queue is not strictly date sorted, but yes, a later upload does not move your package back in the queue. -- bye, Joerg if klecker.d.o died, I swear to god, I'm going to migrate to gentoo. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
]] Charles Plessy | I am all for campaigning for the unified diff format if there are | arguments on which I can base a discussion with Upstream, but a mere | cultural preference, be it the one of a very large majority, is a too | weak argument. They're easier to review (because you have a bit of context) and to adapt to sources where they don't apply 100%. I would start by asking upstream first and see if they reject the request, or ask «why?» before pushing for changes in Debian tools. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2
Bastian Blank writes: > What happens if someone install libc-bin without a new libc6 then? At present, I would expect that to run into file conflicts with libc6. In the future, yes, that could be a problem without appropriate Breaks: or Conflicts: declarations. :-/ One possible workaround could be to follow gtk+-2.0's lead: keep the actual binaries in the lib package, but place them under /usr/lib and have the bin package just ship symlinks to them. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Spam on the lists [Was: Re: Account Upgrade (Unex)]
Christian Perrier schrieb am Tuesday, den 04. August 2009: Hi, > > > look it up yourself: > > > http://lists.debian.org/archive-spam-removals/review/stats.html (my > > > user is morph...). So, are you going to help us kill spam (reporting > > > it) or no time for this? > > > > So you're Debian's Mr. Antispam, my humble apologies. > > > .../... > > What's interesting to add is that I've heard at Debconf that the > identified (and removed) spam is now used to feed out CRM114 on > lists.d.o (or will be, I'm not sure). So, the more spam filtering is > done...the better our spam filters might become. It will be in the future. I'm currently evaluating CRM114 together with amavisd-new on a private setup. Next step will be updating my lists.d.o amavis packages and after that we will run crm114 with a low scoring. If everything works well a few weeks later crm114 should replace the old bayes. Alex - listmaster -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes
On Wed, Aug 5, 2009 at 23:49, Joerg Jaspert wrote: > The format for such bug reports against the ftp.debian.org > pseudopackage: > > Subject: override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority > > Include the justification for the change in the body of the bug please. > > (I hope reportbug will understand this soon, similar to it knowing about > removal bugs). Ask us to support it :) Please file a bug report against reportbug with the rational (ah, patches are welcome), so we won't forget. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
