Re: What is the best place for package meta-data ?

[Andreas Tille]

On Wed, Aug 05, 2009 at 07:47:25PM +0900, Charles Plessy wrote:
> 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???

Well, I think my mail [1] was a bit missinterpreted.  *Currently* all gatherers
to feed information into UDD are using a retrieving model.  But PET has a
need to use a pushing model and now we might have another case where pushing
information makes much more sense than the currently implemented gatherers.
I did not intended to copy the PET solution (even if it is somehow similar
to what we might need) but I rather wanted to mention that chances are good
that a pushing modell might be implemented as well if the nature of the data
and their use suggests this.  There are no decisions made yet but at least it
was discussed in the PET Bof[2] at DebConf (but I don't think there were
recordings available).

Kind regards

 Andreas.

[1] http://lists.debian.org/debian-med/2009/08/msg9.html
[2] https://penta.debconf.org/dc9_schedule/events/515.en.html

-- 
http://fam-tille.de
Klarmachen zum Ändern!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Is Christian Meder MIA?

[Walter Franzini]

Christian Meder  writes:

[...]

> 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.

I've just uploaded the package for 4.24.2 on 
http://aegis.stepbuild.org/debian/aegis 
it now build and *test* under (a properly configured) pbuilder!

Can we manage to setup the collective maintanership stuff as you
proposed some time ago?

ciao :-)
-- 
Walter Franzini
http://aegis.stepbuild.org/


pgp9Qzw13k4i8.pgp
Description: PGP signature

Bug#540155: ITP: pdfmod -- simple tool for modifying PDF documents

[Chow Loong Jin]

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 


* Package name: pdfmod
  Version : 0.4
  Upstream Author : Gabriel Burt 
* URL : http://live.gnome.org/pdfmod
* License : GPL-2+
  Programming Lang: C#
  Description : simple tool for modifying PDF documents

 PDF Mod is a simple tool for modifying PDF documents. It can rotate, extract,
 remove and reoder pages via drag and drop. Multiple documents may be combined
 via drag and drop. You may also edit the title, subject, author and keywords of
 a PDF document using PDF Mod.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

piuparts-MBF: not using invoke-rc.d

[Holger Levsen]

Hi,

as announced at DebConf9 I'll now (slowly) start threads about different bug 
categories detected by piuparts, with the aim to agree on mass filing bugs 
with the correct severity.

Having a piuparts clean archive is again a release goal for squeeze, currently 
http://piuparts.debian.org/squeeze/ shows 16198 successfully tested packages, 
391 failures and 7800 packages cannot be tested for various reasons: depends 
which failed the piuparts tests, circular depends so piuparts cannot 
determine whether the depends have been tested successfully and a bug in 
piuparts master, preventing some packages to be tested, which could.

For today I picked a simple category: packages which have processes running 
inside the chroot at the end of the piuparts run. This is probably due to 
directly calling /etc/rc.d/ scripts in packages maintainer scripts, which is 
a violation of policy 9.3.3.2 and must be replaced by using invoke-rc.d - see 
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3. This is 
mandatory since policy version 3.7.0.

http://piuparts.debian.org/squeeze/processes_running_error.html and 
http://piuparts.debian.org/squeeze/processes_running_error.html lists those 
packages. 

Only three packages have been detected which are affected, so I filed bugs 
with severity serious right away, as IMO this is a pretty clear case of 
violating a mandatory policy requierement, where the violation seriously 
disrupts user expectations. Also, filing three bugs is not exactly mass bug 
filing :-)

Other bug categories detected by piuparts will IMO be more worth 
discussing ;-)


regards,
Holger

P.S.: I've bcc:ed this mail to -qa@ and -release@ and do _not_ plan to 
continue to do this in the future, unless people ask me to.


signature.asc
Description: This is a digitally signed message part.

Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

[Gustavo Noronha Silva]

On Sat, 2009-08-01 at 16:12 +, Debian Bug Tracking System wrote:
> > if you have to disable ipv6 to make "the internet connection fast", the 
> > setup 
> > at your provider is broken - Debian comes with working out of the box 
> > support 
> > for ipv6, if you need to disable it to make the network work for you, there 
> > is something wrong on the network.

While I agree in general, it is still a PITA that Debian fails miserably
in these cases. It does cause a bad impression. I keep having problems
with misbehaving ipv6 myself, and it seems unlikely that stuff will just
start supporting ipv6 correctly in the near future.

While at debconf I was debugging why epiphany-webkit (libsoup, really)
was failing to get to Rhonda's blog, and it seems like DNS was resolving
the name to the ipv6 address as well as the ipv4. It seems like firefox
handles this by falling back, but soup doesn't.

Can we do better?

See you,

-- 
Gustavo Noronha Silva 
Debian




-- 
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]

Le Wed, Aug 05, 2009 at 03:22:12PM +0200, Cyril Brulebois a écrit :
> 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?

Le Wed, Aug 05, 2009 at 03:22:14PM +0200, Giacomo A. Catenazzi a écrit :
>
> 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.

Le Wed, Aug 05, 2009 at 06:56:05PM +0200, Tollef Fog Heen a écrit :
> 
> They're easier to review (because you have a bit of context) and to
> adapt to sources where they don't apply 100%.

Le Wed, Aug 05, 2009 at 11:23:11PM +1000, Ben Finney a écrit :
> 
> 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.


So to summarise, you are suggesting me to write upstream that:

 1) We want to review their patches,
 2) We can not do this with context diffs,
 3) We do want to actively reject non-unified diffs despite our tools work well 
with them,
 4) The reason why they should adopt a new diff format is because it is new.

May I have some evidence that somebody really wants to review their patch? As I
explained already, it is not a random patch grabbed from their BTS, it is their
standard way to publish official corrections that change a few lines in an
archive of 20 Mo. I do not think there is more reason to review this patch than
any other change that they make when they release a new version.

What is next? Will the Project decide a standard whitespace policy and nitpick
every upstream project that does not respect it?

The only patch review system I know in Debian works well with context diffs
(http://patch-tracking.debian.net/package/emboss/6.1.0-2). Quilt, patch, 
diffstat,
all work well with context diff. dpkg-dev itself works well with context diffs.
The only reason it fails is that there is a political decision to reject
non-unified diffs.

I have moved the patches from debian/patches to debian/patch, which circumvents
the problem, since there is no will to compromise on either side.

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

Re: piuparts-MBF: not using invoke-rc.d

[Cyril Brulebois]

Hi Holger.

Holger Levsen  (06/08/2009):
> http://piuparts.debian.org/squeeze/processes_running_error.html and 
> http://piuparts.debian.org/squeeze/processes_running_error.html lists
> those packages. 

Identical URLs? And for the sake of archiving for one, and for the sake
of people not always online, could you please attach a package list /
dd-list next time?

Thanks for considering.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Cyril Brulebois]

Charles Plessy  (06/08/2009):
> So to summarise, you are suggesting me to write upstream that:
> 
>  1) We want to review their patches,
>  2) We can not do this with context diffs,
>  3) We do want to actively reject non-unified diffs despite our tools work 
> well with them,

Sure.

>  4) The reason why they should adopt a new diff format is because it is new.

It *was*. 20 years ago.

> May I have some evidence that somebody really wants to review their
> patch?

Any NMUer, any QA folks, any security-team guy, etc. Guess what? A
package can have a lot of eyes going over it, that don't belong to the
Maintainer/Uploaders.

> As I explained already, it is not a random patch grabbed from their
> BTS, it is their standard way to publish official corrections that
> change a few lines in an archive of 20 Mo.

AHAHAH. Want to talk about amule again? If that was still needed, that's
a *very* good reason to check what upstream does, especially when it
comes to security. And having *context* when it comes to a *20MB* (you
used the French unit, FWIW, just to clarify to other readers) *might* be
a very good idea.

> What is next? Will the Project decide a standard whitespace policy and
> nitpick every upstream project that does not respect it?

Delirium Tremens? Unified diffs are not about whitespace-only changes,
as you were already explained.

> The only patch review system I know in Debian works well with context
> diffs (http://patch-tracking.debian.net/package/emboss/6.1.0-2).
> Quilt, patch, diffstat, all work well with context diff. dpkg-dev
> itself works well with context diffs.

You probably don't want to list each and every stuff for which we keep
some sort of backward-compatibility. Or you should probably get started.

> The only reason it fails is that there is a political decision to
> reject non-unified diffs.

Sure.

Oh, if you really need an example, what about the following? We tend to
fix GCC issues. We tweak headers. Some might get added, some might be
removed. We have such a patch. A CVE arrives. A context diff gets
published. It gets applies on the top of the other patches. Say it's
something like:
| > BUGON(my_pointer_shall_not_be_null);

But, since we tweak the headers, the check can get added before the
first dereferencement. Of course, there are the fuzzy stuff with patch,
but sounds less likely to happen.

Of course, that's only about politics and victimization.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: piuparts-MBF: not using invoke-rc.d

[Holger Levsen]

Hi KiBi,

On Donnerstag, 6. August 2009, Cyril Brulebois wrote:
> Holger Levsen  (06/08/2009):
> > http://piuparts.debian.org/squeeze/processes_running_error.html and
> > http://piuparts.debian.org/squeeze/processes_running_error.html lists
> > those packages.
> Identical URLs?

Gah. Forgot to s/squeeze/sid/ in one of them

> And for the sake of archiving for one, and for the sake 
> of people not always online, could you please attach a package list /
> dd-list next time?

Will try to remember... 

The three packages of this are zope2.10-sandbox, zope2.10-sandbox and 
plone3-site.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Cyril Brulebois]

Cyril Brulebois  (06/08/2009):
> But, since we tweak the headers, the check can get added before the
> first dereferencement. Of course, there are the fuzzy stuff with patch,
> but sounds less likely to happen.

Heh, might have left that to the attentive reader, but let's fix the
typo: s/before/after/. :)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Cyril Brulebois]

Cyril Brulebois  (06/08/2009):
> Heh, might have left that to the attentive reader, but let's fix the
> typo: s/before/after/. :)

And given I wasn't even using the right option, I'm going to hide for a
while, lalala. (Thanks pusling.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Non-unified patches and dpkg source format ‘3. 0 (quilt)’.

[Paul Wise]

On Thu, Aug 6, 2009 at 1:41 PM, Cyril Brulebois wrote:
> Charles Plessy  (06/08/2009):
>>  4) The reason why they should adopt a new diff format is because it is new.
>
> It *was*. 20 years ago.

Perhaps it is about time it was made the default :)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: not using invoke-rc.d

[Roland Mas]

Holger Levsen, 2009-08-06 11:27:34 +0200 :

> Hi,
>
> as announced at DebConf9 I'll now (slowly) start threads about
> different bug categories detected by piuparts, with the aim to agree
> on mass filing bugs with the correct severity.

Thank you for this effort.  I must admit piuparts has been too
frightening for me to try, so far.  So, in order to comfort me in my
laziness, would you consider doing continuous (or regular) runs of
piuparts on the whole archive, and sending the results to the PTS
(probably with a new keyword)?

Roland.
-- 
Roland Mas

Just a little bit of you every day will surely keep the doctors away.
  -- Just a little bit of you (The Jackson Five)


-- 
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)???.

[Michael Banck]

On Thu, Aug 06, 2009 at 07:52:08PM +0900, Charles Plessy wrote:
> So to summarise, you are suggesting me to write upstream that:

Why do you need to write anything to upstream?  If they still insist on
context diffs (or whatever that is called), I guess there is not much we
can do.  Debian insists (for good reasons) on unified diffs.  You can of
course ask them to reconsider again, but (as pointed out numerous times)
there is no reason to bring up anything like "the dpkg maintainer
oppresses you", it's a simle fact that unified diffs are the de-facto
standard in the FLOSS world.

The sensible way is to work around upstream by transforming their diffs
into unified diffs and storing the original diff in the source package
as well for reference.  Another option would be to make up a new orig
tarball (a bit more hassle, but certainly feasable).

The other alternative is to just make up your own source package patch
system and use 3.0-native as Goswin suggested (though I have no clue how
that works).


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: not using invoke-rc.d

[Holger Levsen]

Hi Roland,

On Donnerstag, 6. August 2009, Roland Mas wrote:
> Thank you for this effort.  I must admit piuparts has been too
> frightening for me to try, so far.  So, in order to comfort me in my
> laziness, would you consider doing continuous (or regular) runs of
> piuparts on the whole archive, and sending the results to the PTS

Uhm, there was this mail to d-d-a which I planned to send, but haven't, 
yet ;-)

Go to http://piuparts.debian.org where you can find the results for piuparts 
runs on the whole archive for sid and squeeze (for those packages which have 
been tested, which are those which depends have been successfully tested by 
piuparts).

These results are already integrated in the PTS, see for example 
http://packages.qa.debian.org/l/lpr.html - piuparts links are only shown in 
the PTS if there are problems.

Then there are maintainer/uploader specific packages, ie 
http://piuparts.debian.org/sid/maintainer/l/lolando%40debian.org.html

I guess looking at that maintainer page will result in more questions, I hope 
those are answered on http://wiki.debian.org/piuparts/FAQ - if not, or if you 
have further questions, please add them there, I'm subscribed to that page 
and would like to collect questions and answers there, instead of repeating 
myself endlessly ;-)


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: piuparts-MBF: not using invoke-rc.d

[Holger Levsen]

Hi,

On Donnerstag, 6. August 2009, Holger Levsen wrote:
> http://wiki.debian.org/piuparts/FAQ 
> I'm subscribed to 
> that page and would like to collect questions and answers there, instead of
> repeating myself endlessly ;-)

That might leave a wrong impression, so let me add: Thanks for asking here and 
your interest in piuparts / a clean archive! :-) I'm glad there is interest 
in this!


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: piuparts-MBF: not using invoke-rc.d

[Roland Mas]

Holger Levsen, 2009-08-06 14:44:53 +0200 :

> Hi Roland,
>
> On Donnerstag, 6. August 2009, Roland Mas wrote:
>> Thank you for this effort.  I must admit piuparts has been too
>> frightening for me to try, so far.  So, in order to comfort me in my
>> laziness, would you consider doing continuous (or regular) runs of
>> piuparts on the whole archive, and sending the results to the PTS
>
> Uhm, there was this mail to d-d-a which I planned to send, but haven't, 
> yet ;-)
>
> Go to http://piuparts.debian.org where you can find the results for
> piuparts runs on the whole archive for sid and squeeze (for those
> packages which have been tested, which are those which depends have
> been successfully tested by piuparts).

Excellent.

> These results are already integrated in the PTS, see for example
> http://packages.qa.debian.org/l/lpr.html - piuparts links are only
> shown in the PTS if there are problems.

  Ah-ha, that's what confused me.  I only looked at the page for one of
my packages, and it didn't display anything.  My fault for being lazy.

  Thanks again,

Roland.
-- 
Roland Mas

Such compressed poems / With seventeen syllables / Can't have much meaning...
  -- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540182: ITP: libgctp -- General Cartographic Transformation Package Library

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: libgctp
  Version : 1.0
  Upstream Author : Abe_Taaheri abe_taah...@raytheon.com 
* URL :  http://gcmd.nasa.gov/records/USGS-GCTP.html
* License : Mixed public-domain and BSD
  Programming Lang: C
  Description : General Cartographic Transformation Package Library

 The General Cartographic Transformation Package (GCTP) is a system of
 software routines designed to permit the transformation of coordinate
 pairs from one map projection to another. The GCTP is the standard
 computer software used by the National Mapping Division for map
 projection computations.

This library is used by hdf-eos4 and hdf-eos5, which have ITP's assigned,
as well as libproj internally. 

The upstream author claified the license situation:

The GCTP was originally developed by USGS. For EOS (funded by NASA) we 
took it and added a few more projections to be used by HDF-EOS. Any one 
can use it or modify it (both commercial and non-comercial) as long as 
it is acknowledged. If you want to use it please use the latest versions ( see 
download 
at   http://newsroom.gsfc.nasa.gov/sdptoolkit/toolkit.html ). The 
source code is packaged with hdfeos and hdfeos5.


-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
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)’.

[Ben Pfaff]

Cyril Brulebois  writes:

> Oh, if you really need an example, what about the following? We tend to
> fix GCC issues. We tweak headers. Some might get added, some might be
> removed. We have such a patch. A CVE arrives. A context diff gets
> published. It gets applies on the top of the other patches. Say it's
> something like:
> | > BUGON(my_pointer_shall_not_be_null);
>
> But, since we tweak the headers, the check can get added before the
> first dereferencement. Of course, there are the fuzzy stuff with patch,
> but sounds less likely to happen.

If you are going to argue against diffs that do not have any
context, please say so.  Do not confuse the issue by instead
arguing against "context diffs", because context diffs and
unified diffs have exactly the same properties, just different
formatting.

Here is the diff manual's introduction to showing context:

Usually, when you are looking at the differences between files, you will
also want to see the parts of the files near the lines that differ, to
help you understand exactly what has changed.  These nearby parts of the
files are called the "context".

   GNU `diff' provides two output formats that show context around the
differing lines: "context format" and "unified format".  It can
optionally show in which function or section of the file the differing
lines are found.

Here is the example of a context diff from the "diff" manual:

 *** laoSat Jan 26 23:30:39 1991
 --- tzuSat Jan 26 23:30:50 1991
 ***
 *** 1,7 
 - The Way that can be told of is not the eternal Way;
 - The name that can be named is not the eternal name.
   The Nameless is the origin of Heaven and Earth;
 ! The Named is the mother of all things.
   Therefore let there always be non-being,
 so we may see their subtlety,
   And let there always be being,
 --- 1,6 
   The Nameless is the origin of Heaven and Earth;
 ! The named is the mother of all things.
 !
   Therefore let there always be non-being,
 so we may see their subtlety,
   And let there always be being,
 ***
 *** 9,11 
 --- 8,13 
   The two are the same,
   But after they are produced,
 they have different names.
 + They both may be called deep and profound.
 + Deeper and more profound,
 + The door of all subtleties!

Here is the diff manual's comparison between context diffs and
unified diffs:

The unified output format is a variation on the context format that is
more compact because it omits redundant context lines.  To select this
output format, use the `-U LINES', `--unified[=LINES]', or `-u' option.
The argument LINES is the number of lines of context to show.  When it
is not given, it defaults to three.

   At present, only GNU `diff' can produce this format and only GNU
`patch' can automatically apply diffs in this format.  For proper
operation, `patch' typically needs at least two lines of context.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: not using invoke-rc.d

[Stefano Zacchiroli]

On Thu, Aug 06, 2009 at 02:44:53PM +0200, Holger Levsen wrote:
> > Thank you for this effort.  I must admit piuparts has been too
> > frightening for me to try, so far.  So, in order to comfort me in my
> > laziness, would you consider doing continuous (or regular) runs of
> > piuparts on the whole archive, and sending the results to the PTS
> These results are already integrated in the PTS, see for example 
> http://packages.qa.debian.org/l/lpr.html - piuparts links are only shown in 
> the PTS if there are problems.

To be clear: the results are already integrated with the PTS in the
sense that a "problem" would be reported for non-piuparts-clean
packages (and a corresponding link on the right would be added in case
of piuparts issues).  A pending news item targeted at d-d-a about that
is currently waiting in Misc Developer News [1].

However, the mail notification of piuparts error is _not_ integrated
with the PTS. To that end I would prefer not having a new keyword, the
default one seems reasonable to me, as it is opt-in anyhow and the
frequency is (I guess) rather low.

Cheers.

[1] http://wiki.debian.org/DeveloperNews

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: piuparts-MBF: not using invoke-rc.d

[Jonas Meurer]

On 06/08/2009 Holger Levsen wrote:
> > And for the sake of archiving for one, and for the sake 
> > of people not always online, could you please attach a package list /
> > dd-list next time?
> 
> Will try to remember... 
> 
> The three packages of this are zope2.10-sandbox, zope2.10-sandbox and 
> plone3-site.

at least for zope2.1[01]-sandbox, i don't know how to fix that issue.
invoking the initscript at postinst/prerm of the -sandbox packages will
cause _all_ zope instances on the system to be restarted, and that isn't
an option at all.

thus the postinst/prerm scripts of -sandbox packages invoke the zopectl
script at /var/lib/zope2.1[01]/instance/sandbox/bin/zopectl directly in
order to only start/stop the sandbox instance that is being installed or
removed.

so any ideas what to do about this?

greetings,
 joans


signature.asc
Description: Digital signature

backward/forward binary compatibility checker

[Andrey Ponomarenko]

Colleagues, I'm software engineer from Institute for System
Programing of Russian Academy of Sciences and we are developing a free
lightweight tool for checking backward/forward binary compatibility of
shared C/C++ libraries in OS Linux. It checks interface signatures and
data type definitions in two library versions (headers and shared
objects) and searches ABI changes that may lead to incompatibility.
We have released 1.1 version of this tool and we'd like you to consider
its usefulness for your project.
The wiki-page with the latest release of binary compatibility checker is
http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

Andrey Ponomarenko


-- 
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)’.

[Russ Allbery]

So... you all realize, right, that old-style context diffs and unified
diffs can be trivially converted into each other?  They have the same
amount of information.

filterdiff --format=unified < context.diff
filterdiff --format=context < unified.diff

(filterdiff comes with patchutils.)  Given that, this seems like a tempest
in a teapot to me.  Just convert the diff into whatever format the tool
that you're using expects or the reviewer wants to read.

diff -c diffs are somewhat easier to read in some specific circumstances,
usually involving significant code rewrites, than diff -u diffs.

-- 
Russ Allbery (r...@debian.org)   


-- 
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)’.

[Pierre Habouzit]

On Wed, Aug 05, 2009 at 10:07:02PM +0900, Charles Plessy wrote:
> 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?

FWIW I've read this sub-thread with some kind of consternation,
especially seeing how wrong some arguments are.

First of all, non-unified diffs are called "context diffs", and can have
...  wait for it ... context. Those are actually valid ed scripts IIRC.
The reason why unified diffs are prefered is because those are usually
way more readable.

For example, vim upstream is using non unified diffs with context as a
way to release its incremental versions, still nowadays.

That said, yes, using non-unified diff is as laughable as using RCS or
SCCS nowadays. Though I consider it a bug if dpkg refuses to apply a
patch that patch(1) (that it uses in the end) would apply fine. I shall
say that I absolutely don't get why there even is an "analyze()" routine
in Patch.pm, if you want that, let patch(1) do it using its --dry-run
mode.  It'll report failed hunk and bad syntax the same way.

I concur with Charles that it's a dpkg-dev bug, I don't think his patch
is valid though. I'm unsure if it needed all that trolling, and that a
minor bug on dpkg-dev asking for non-unified diffs support is in order.

In between there are as many already said many workarounds, the easier
one being to regenerate the diff, which you can easily do using
combinediff (I've not checked if there is anything more
straightforward):

$ cat aa
toto
tuti
titi

$ cat ab
toto
tutu
titi

$ diff -C2 aa ab | tee aa-to-ab.diff
*** aa  2009-08-06 18:25:44.875327948 +0200
--- ab  2009-08-06 18:25:50.107327652 +0200
***
*** 1,3 
  toto
! tuti
  titi
--- 1,3 
  toto
! tutu
  titi

$ combinediff aa-to-ab.diff /dev/null
unchanged:
--- aa  2009-08-06 18:25:44.875327948 +0200
+++ ab  2009-08-06 18:25:50.107327652 +0200
@@ -1,3 +1,3 @@
 toto
-tuti
+tutu
 titi

Cheers,
-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


-- 
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)’.

[Pierre Habouzit]

On Thu, Aug 06, 2009 at 06:33:28PM +0200, Pierre Habouzit wrote:

> Those are actually valid ed scripts IIRC.

Okay, sorry, I meant to remove that sentence that is actually wrong...
sorry 'bout that.

-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


-- 
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)’.

[Russ Allbery]

Pierre Habouzit  writes:

> FWIW I've read this sub-thread with some kind of consternation,
> especially seeing how wrong some arguments are.
>
> First of all, non-unified diffs are called "context diffs", and can have
> ...  wait for it ... context. Those are actually valid ed scripts IIRC.
> The reason why unified diffs are prefered is because those are usually
> way more readable.

I think you're confusing the many different non-unified diff formats.
There are at least four.

1. Classic diff format (the default)

3c3
< baz
---
> bar

2. ed script format (diff -e)

3c
bar
.

3. RCS diff format (diff -n)

d3 1
a3 1
bar

4. Classic context diff format (diff -c)

*** foo.1   2009-08-06 09:38:26.0 -0700
--- foo.2   2009-08-06 09:38:35.0 -0700
***
*** 1,6 
  foo
  bar
! baz
  foo
  bar
  baz
--- 1,6 
  foo
  bar
! bar
  foo
  bar
  baz

The fourth format is entirely equivalent, in informational content, to a
unified diff, just formatted differently.  That form and unified diff form
are mutually convertible.

Unified diff is generally considered to be easier to read for most use
cases, but can be nigh-incomprehensible when there are lots of changes in
the same area of the code since it tries a bit too hard to find
similarities and tends to think that some blank line or brace in the
middle of a changed block is the same line between the two versions.  In
those cases, classic context diff is easier to read.

The first three formats have no context, are extremely fragile if anything
changes about the file to which one is applying the diff (*particularly*
two and three), and should basically never be used for anything any more.
The fourth style above is exactly equivalent to a unified diff in terms of
information content and is really just a matter of taste.

> I concur with Charles that it's a dpkg-dev bug,

Likewise.

> I don't think his patch is valid though. I'm unsure if it needed all
> that trolling, and that a minor bug on dpkg-dev asking for non-unified
> diffs support is in order.

I think dpkg should accept old-format context diffs but reject all diffs
without context (including unified diffs without context).  Diffs without
context are dangerous.  They may apply in places where they're not
supposed to and make changes that are entirely unexpected.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

[Stephen Gran]

This one time, at band camp, Gustavo Noronha Silva said:
> While at debconf I was debugging why epiphany-webkit (libsoup, really)
> was failing to get to Rhonda's blog, and it seems like DNS was resolving
> the name to the ipv6 address as well as the ipv4. It seems like firefox
> handles this by falling back, but soup doesn't.

Debconf had fully working ipv6.  I do wish you could have reported
problems with it at the time so we could have looked at it.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: backward/forward binary compatibility checker

[Paul Wise]

[CCing you since I presume you are not subscribed to debian-devel]
[CCing the Debian release team since they may be interested]

On Thu, Aug 6, 2009 at 4:38 PM, Andrey Ponomarenko wrote:

>    Colleagues, I'm software engineer from Institute for System
> Programing of Russian Academy of Sciences and we are developing a free
> lightweight tool for checking backward/forward binary compatibility of
> shared C/C++ libraries in OS Linux. It checks interface signatures and
> data type definitions in two library versions (headers and shared
> objects) and searches ABI changes that may lead to incompatibility.
> We have released 1.1 version of this tool and we'd like you to consider
> its usefulness for your project.
>    The wiki-page with the latest release of binary compatibility checker is
> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

That sounds extremely useful for Debian and other free software
distributions. Please notify at least Fedora, I suggest writing an
article about it for LWN (http://lwn.net) though. Have you considered
packaging it for Debian so that library maintainers can use it to
check their packages or the release managers could use it to block
libraries with broken ABIs (for example)?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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 ?

[Paul Wise]

On Wed, Aug 5, 2009 at 12:47 PM, Charles Plessy wrote:

> 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,…

I'd put the package description in a "user" category or just its own category.

>  - Informations for the online user. For instance the homepage and VCS URLs.

I'd put the homepage in a "user" category and the VCS URLs in a
"developer" category.

> 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…

It seems to me that all this metadata we have about packages, the
canonical location for it is dak's database on ftp-master, the
Packages/Sources files are generated from there.

The data in that database is gathered from .changes files and binary
and source packages uploaded to ftp-master, except for debtags and
translated descriptions (IIRC, not sure how those get in). Re-using
that workflow for meta-data updates, say, by uploading metadata
updates in .changes files instead of full packages could be useful.

How to split up the Packages/Sources files into more granular pieces
would be nice, but which fields should go into which sets needs
defining, and which set of sets should be the default. For
compatability, it could continue to generate Packages/Sources as they
are and add Packages-Homepage, Packages-dpkg, Packages-user etc files
for updated apt/dpkg to use, allowing us to avoid waiting a whole
release cycle to use this stuff.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540247: ITP: abi-compliance-checker -- tool for checking binary compatibility of shared libraries (was: Re: backward/forward binary compatibility checker)

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: abi-compliance-checker
  Version : 1.1
  Upstream Author : Andrey Ponomarenko
* URL : 
http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
* License : GPL-3+
  Programming Lang: Perl
  Description : tool for checking binary compatibility of shared libraries
 ABI-compliance-checker is a lightweight tool for checking backward
 binary compatibility of shared C/C++ libraries in OS Linux. It checks
 interface signatures and data type definitions in two library
 versions (headers and shared objects) and searches ABI changes that
 may lead to incompatibility. Breakage of the compatibility may result
 in crashing or incorrect behavior of applications built with an old
 version of a library when it is running with a new
 one. ABI-compliance-checker was intended for library developers that
 are interested in ensuring backward binary compatibility. Also
 ABI-compliance-checker may be used for checking forward binary
 compatibility and compliance checking of the same library versions on
 different Linux distributions.

Hi Andrey,

On Thu, Aug 06, 2009 at 06:38:41PM +0400, Andrey Ponomarenko wrote:
> Colleagues, I'm software engineer from Institute for System
> Programing of Russian Academy of Sciences and we are developing a free
> lightweight tool for checking backward/forward binary compatibility of
> shared C/C++ libraries in OS Linux. It checks interface signatures and
> data type definitions in two library versions (headers and shared
> objects) and searches ABI changes that may lead to incompatibility.
> We have released 1.1 version of this tool and we'd like you to consider
> its usefulness for your project.
> The wiki-page with the latest release of binary compatibility checker is
> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
> 

This looks like an extremely useful piece of software (in the past
I've thought "I wish there were a tool to do this" :)). I'll package
it for Debian.

Cheers,
Ryan

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Bug#540286: ITP: libcatalyst-model-adaptor-perl -- Perl module to use a plain class as a Catalyst model

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libcatalyst-model-adaptor-perl
  Version : 0.04
  Upstream Author : Jonathan Rockway 
* URL : http://search.cpan.org/dist/Catalyst-Model-Adaptor/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to use a plain class as a Catalyst model
 Catalyst::Model::Adaptor provides a simple way to write a class normally, and
 apply a bit of glue code to make it work nicely with Catalyst as a model. By
 using this module, your Model classes can be kept separate from the rest of
 your application, therefore making it easy to ensure they are well-abstracted,
 reusable and easy to test.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540295: ITP: libfile-queue-perl -- Perl module providing a FIFO queue

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libfile-queue-perl
  Version : 1.01
  Upstream Author : Jason Lavold 
* URL : http://search.cpan.org/dist/File-Queue/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module providing a FIFO queue
 File::Queue allows for the creation of persistent First In, First Out (FIFO)
 queue objects, saving data in a file. Queue elements can only be scalars; if
 you want to work with references or other complex data structures, you have
 to serialize them first. While this module was written with speed in mind,
 and is indeed very fast, one should take care to understand its limitations.



-- 
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 ?

[Paul Wise]

On Thu, Aug 6, 2009 at 9:17 PM, Paul Wise  wrote:

> How to split up the Packages/Sources files into more granular pieces
> would be nice, but which fields should go into which sets needs
> defining, and which set of sets should be the default. For
> compatability, it could continue to generate Packages/Sources as they
> are and add Packages-Homepage, Packages-dpkg, Packages-user etc files
> for updated apt/dpkg to use, allowing us to avoid waiting a whole
> release cycle to use this stuff.

Looks like this bit is already being worked on:

http://lists.debian.org/debian-announce/2009/msg00010.html

> * Move of packages' long descriptions into a separate "translated
>   package list", which will facilitate their translation and also
>   provide a smaller footprint for embedded systems thanks to smaller
>   Packages files.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[no subject]

[tired]

Hey Hun I just setup my webcam check it out! Check my cam Dear debiandevel! Get 
Yourself a cool, short @in.com Email ID now!

Bug#540298: ITP: lua-iconv -- iconv bindings for the Lua programming language

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: lua-iconv
  Version : 6
  Upstream Author : Alexandre Erwin Ittner 
* URL : http://luaforge.net/projects/lua-iconv/
* License : MIT/X
  Programming Lang: C
  Description : iconv bindings for the Lua programming language

lua-iconv provides POSIX 'iconv' bindings for the Lua programming
language.  It converts a sequence of characters from one codeset into a
sequence of corresponding characters in another codeset.



-- 
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)’.

[Manoj Srivastava]

On Thu, Aug 06 2009, Russ Allbery wrote:

> So... you all realize, right, that old-style context diffs and unified
> diffs can be trivially converted into each other?  They have the same
> amount of information.
>
> filterdiff --format=unified < context.diff
> filterdiff --format=context < unified.diff
>
> (filterdiff comes with patchutils.)  Given that, this seems like a tempest
> in a teapot to me.  Just convert the diff into whatever format the tool
> that you're using expects or the reviewer wants to read.
>
> diff -c diffs are somewhat easier to read in some specific circumstances,
> usually involving significant code rewrites, than diff -u diffs.

Also, emacs diff-mode does this in the buffer for you, so you
 don't need to even have filterdiff installed, assuming you worship at
 the altar of the one true editor.

manoj
-- 
Oh what a tangled web we weave, when first we practice to
deceive. Shakespeare
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Work-needing packages report for Aug 7, 2009

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 367 (new: 5)
Total number of packages offered up for adoption: 124 (new: 2)
Total number of packages requested help for: 53 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   kbiff (#540212), orphaned today
 Description: KDE mail notification utility
 Installations reported by Popcon: 275

   komba2 (#540211), orphaned today
 Description: KDE Samba browser
 Installations reported by Popcon: 486

   lkl (#540213), orphaned today
 Description: userspace keylogger for x86 architecture
 Installations reported by Popcon: 87

   wflogs (#540214), orphaned today
 Description: The modular firewall log analyzer of the WallFire
   project
 Installations reported by Popcon: 30

   wfnetobjs (#540210), orphaned today
 Description: The WallFire modular firewalling application library -
   development files
 Reverse Depends: libwfnetobjs0-dev wflogs
 Installations reported by Popcon: 39

362 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   file-rc (#539609), offered 4 days ago
 Description: Alternative boot mechanism using a single configuration
   file
 Reverse Depends: festival sysvinit
 Installations reported by Popcon: 138

   kpowersave (#53), offered yesterday
 Installations reported by Popcon: 6934

122 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] phpwiki (#540061), requested yesterday
 Description: informal collaborative website manager
 Installations reported by Popcon: 69

   ara (#450876), requested 634 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 111

   asymptote (#517342), requested 160 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 618

   athcool (#278442), requested 1745 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 177

   boinc (#511243), requested 210 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1614

   cvs (#354176), requested 1260 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10
   more omitted)
 Installations reported by Popcon: 20652

   dctrl-tools (#448284), requested 649 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage libsbuild-perl mlmmj simple-cdd
 Installations reported by Popcon: 12207

   dpkg (#282283), requested 1719 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alqalam alsa-source apt-build apt-cross
   apt-src asymptote asymptote-doc autoconf-doc avrdude-doc (258 more
   omitted)
 Installations reported by Popcon: 84265

   elvis (#432298), requested 759 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 355

   fglrx-driver (#454993), requested 607 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-kernel-src
 Installations reported by Popcon: 1847

   flightgear (#487388), requested 411 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 657

   gentoo (#422498), requested 823 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 246

   gnat-4.4 (#539562), requested 483 days ago
 Description: help needed to execute test cases
 Reverse Depends: gnat-4.4 libgnat-4.4 libgnat-4.4-dbg libgnatprj4.4
   libgnatprj4.4-dbg libgnatprj4.4-dev libgnatvsn4.4 libgnatvsn4.4-dbg
   libgnatvsn4.4-dev

   gnat-gps (#496905), requested 343 days ago
 Description: co-maintainer needed
 I

Bug#540300: ITP: libsub-current-perl -- Perl module to determine the executing subroutine

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libsub-current-perl
  Version : 0.02
  Upstream Author : Rafael Garcia-Suarez 
* URL : http://search.cpan.org/dist/Sub-Current/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to determine the executing subroutine
 Sub::Current provides a fairly magical function called ROUTINE() which returns
 a code reference pointing at the currently executing subroutine. It does not
 make sense to use this inside a special block (such as BEGIN, END, UNITCHECK,
 CHECK or INIT) or at the top level of a program, so ROUTINE will return undef.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: backward/forward binary compatibility checker

[Guillem Jover]

Hi!

On Thu, 2009-08-06 at 18:38:41 +0400, Andrey Ponomarenko wrote:
> Colleagues, I'm software engineer from Institute for System
> Programing of Russian Academy of Sciences and we are developing a free
> lightweight tool for checking backward/forward binary compatibility of
> shared C/C++ libraries in OS Linux. It checks interface signatures and
> data type definitions in two library versions (headers and shared
> objects) and searches ABI changes that may lead to incompatibility.
> We have released 1.1 version of this tool and we'd like you to consider
> its usefulness for your project.
> The wiki-page with the latest release of binary compatibility checker is
> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

How does this compare with projects like icheck or abicheck?

regards,
guillem


-- 
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]

Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit :
> 
> (filterdiff comes with patchutils.)  Given that, this seems like a tempest
> in a teapot to me.  Just convert the diff into whatever format the tool
> that you're using expects or the reviewer wants to read.

Hi Russ and everybody,

I already explained that I prefered that the patch stays in the original format
so that it is easy for everybody (co-maintainers, reviewers, users) to verify
that it was not altered.

Giving a standard interface to reviewers is a laudable goal, but I do not see
reviewers except in elaborate scenarios about security. Therefore I will not
trade a real benefit for a hypothetical one, even if both are neglectible.
Also, I think that it is very important in a project of 1,000 persons to stick
to facts, and avoid building illusions together. So as long as there is no
reviewing process nor package reviews, there is no need to adapt to imaginary
reviewers.

This said, if there were a project-wide momentum for standardising on one patch
format, I would not oppose. This would probably be a release goal, a
preparation for a Policy change, or a demand from the security team to the
package manintainers. Something with a motivation, a plan, some facts and some
volunteers to get things done.

I have reassigned the bug of my package to dpkg-dev. It is holiday season, so
let's wait for a while and see the answer of the dpkg developers. 

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#540302: ITP: itaka -- Itaka is a on-demand screen capture server

[Marc E.]

Package: wnpp
Severity: wishlist
Owner: "Marc E." 

* Package name: itaka
  Version : 0.2.2
  Upstream Author : Marc E. 
* URL : http://itaka.jardinpresente.com.ar
* License : (GPL, CC-BY-SA-2.5)
  Programming Lang: (Python)
  Description : On-demand screen capture server
  
  Itaka is a on-demand screen capture server based on the HTTP protocol. It 
integrates a specifically coded server to take screenshots when your machine is 
queried through a remote browser.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540304: ITP: libtext-reflow-perl -- Perl module for reflowing files using Knuth's algorithm

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libtext-reflow-perl
  Version : 1.09
  Upstream Author : Martin Ward 
* URL : http://search.cpan.org/dist/Text-Reflow/
* License : GPL-2+
  Programming Lang: Perl
  Description : Perl module for reflowing files using Knuth's algorithm

 Text::Reflow provides a series of utilities that reflow paragraphs in a given
 file, filehandle, string or array using Knuth's paragraphing algorithm (as
 used in TeX) to pick the optimal places to break lines. The reflow algorithm
 tries to keep lines the same length but also tries to break at punctuation,
 and to avoid breaking within a proper name or after certain connectives. The
 result is more readable since fewer phrases are broken across line breaks.



-- 
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)’.

[Ben Finney]

Pierre Habouzit  writes:

> First of all, non-unified diffs are called "context diffs"

Not necessarily. I've been using the term to reply to *any* diff output
format that isn't unified-diff format. From my perspective, there is the
de facto standard of unified-diff format, used by the vast majority for
patch data interchange; and there is the vanishing minority of any other
patch format, which should be deprecated.

> I concur with Charles that it's a dpkg-dev bug, I don't think his
> patch is valid though. I'm unsure if it needed all that trolling, and
> that a minor bug on dpkg-dev asking for non-unified diffs support is
> in order.

Rather, for specifically “context diff” format. +1 to that suggestion;
I'm fine with tools accepting it, but it should be strongly deprecated
(by social, not technical, means).

-- 
 \“The industrial system is profoundly dependent on commercial |
  `\   television and could not exist in its present form without it.” |
_o__)—John Kenneth Galbraith, _The New Industrial State_, 1967 |
Ben Finney


-- 
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)’.

[Ben Finney]

Ben Finney  writes:

> Pierre Habouzit  writes:
> 
> > First of all, non-unified diffs are called "context diffs"
> 
> Not necessarily. I've been using the term to reply to *any* diff output
> format that isn't unified-diff format.

s/reply to/refer to/

-- 
 \   “One seldom discovers a true believer that is worth knowing.” |
  `\ —Henry L. Mencken |
_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: Bug#540247: ITP: abi-compliance-checker -- tool for checking binary compatibility of shared libraries (was: Re: backward/forward binary compatibility checker)

[George Danchev]

--cut--
> > The wiki-page with the latest release of binary compatibility checker
> > is http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
>
> This looks like an extremely useful piece of software (in the past
> I've thought "I wish there were a tool to do this" :)). I'll package
> it for Debian.

Hi,
There is also icheck package available in Debian for some years, but it 
targets mainly C. Perhaps you can use it as a comparison tool when testing 
this one.

-- 
pub 4096R/0E4BD0AB 2003-03-18 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540311: show something to ponder while filesystem checking

[jidanni]

Package: initscripts
Version: 2.87dsf-2
Severity: wishlist
File: /etc/init.d/checkfs.sh
X-debbugs-Cc: debian-devel@lists.debian.org

I have an idea. Every few days when booting we encounter a file system
check, which takes several minutes. We sit there, helpless,
unable to issue any command. All we can do is watch the progress marker.

Now being high powered Computer Pros (not me though), we ought to have
something smart put there on the screen for us to ponder as the check
proceeds. (No ads or fortune messages though please.)

Then it dawned on me, we sit there wondering "it says it is checking
/dev/hda6. What disk of mine is that that is taking so long? /home?
/usr?" OK, then tell us.

Sure, we can see on the screen that
it is /dev/hda6 etc. But our hands are tied, we cannot do
$ grep /dev/hda6 /etc/fstab
or any other command at this point, and even if we could,
/etc/fstab might have it listed as /dev/disk/by-id/... etc. and not
/dev/hda6. Therefore I'm proposing that just like you say
"Checking root file system", before checking it, you also say what the
other file systems you are checking refer to.

Here is the log of what we see.

# cat /var/log/boot
Fri Aug  7 12:53:17 2009: Checking root file system...fsck from util-linux-ng 
2.16
Fri Aug  7 12:53:17 2009: /dev/hda1: clean, 16109/81280 files, 239546/325048 
blocks
Fri Aug  7 12:53:17 2009: done.
Fri Aug  7 12:53:17 2009: Cleaning up ifupdown
Fri Aug  7 12:53:17 2009: Loading kernel modules...done.
Fri Aug  7 12:53:17 2009: Checking file systems...fsck from util-linux-ng 2.16
Fri Aug  7 12:53:17 2009: /dev/hda6 has been mounted 35 times without being 
checked, check forced.
Fri Aug  7 12:53:17 2009: \002/dev/hda6: 44085/542720 files (14.7% 
non-contiguous), 3993396/4339408 blocks
Fri Aug  7 12:53:17 2009: /dev/hda7: clean, 12120/678912 files, 3955626/5428048 
blocks (check in 5 mounts)
Fri Aug  7 12:53:17 2009: /dev/hda8: clean, 114339/814400 files, 587051/1627282 
blocks (check in 3 mounts)
Fri Aug  7 12:53:17 2009: /dev/hda9: clean, 218558/950272 files, 
1103243/1899442 blocks
Fri Aug  7 12:53:17 2009: /dev/hda10: clean, 1839/490560 files, 1298458/1959922 
blocks

I notice a problem with these logs too, one needs to look at the kernel
times to realize that I stood there helplessly wondering 192-11=181
seconds. Hey, that's three whole minutes of Ph. D. time (not me
though)... let's be sure they are pondering something better than 'which
filesystem is /dev/hda6?'. And Ph. D.s don't keep hardcopy of previous
mount(8) output.

# cat /var/log/kern.log
Aug  7 12:53:21 jidanni2 kernel: [   12.450865] EXT3 FS on hda1, internal 
journal
Aug  7 12:53:21 jidanni2 kernel: [  192.161015] kjournald starting.  Commit 
interval 333 seconds
Aug  7 12:53:21 jidanni2 kernel: [  192.161323] EXT3 FS on hda6, internal 
journal

OK, now I can find the answer to the mystery:
# mount|grep /dev/hda6
/dev/hda6 on /home type ext3 (rw,commit=333)

Perhaps also mention some df(1) stats for us to think about while we are
sitting there. OK, I mean fdisk stats as it is not mounted yet.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org