Re: packages up for adoption

[Anibal Avelar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Serafeim.

>>
>> > archivemail
>
> Anibal, funny as it may sound, would you mind letting archivemail to me? You
> can still have the rest :) (or else just ignore this email)

Ok, go ahead.

archivemail is written on Python.  I'm expert on C/C++.

I will take the rest.

>> > splitvt   - I use it.
>> > unclutter   - I use it.
>> > xaoom ? I think would be xzoom?


Regards,


- --
Anibal Avelar (FixXxeR) http://fixxxer.cc
GPG: 83B64656 - C143 4AD8 B017 53FA B742 D6AA CEEA F9F3 83B6 4656

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFIOZpszur584O2RlYRAgfkAJ9OHm0zS5Qe+mdM5nxmUYJRwol88gCaApfK
vvsMOz1KQCabNjS+bgy8Owk=
=CcyR
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Alexander E. Patrakov]

Joerg Jaspert wrote:


That already has a problem: How to define "large"? One way, which we
chose for now, is simply "everything > 50MB".


Random thought: some architecture-dependent -dbg packages are also > 50 MB in 
size. Shouldn't they get some special treatment, too?


--
Alexander E. Patrakov


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#482913: ITP: daptup -- see changes in new & upgradeable lists after aptitude update

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/08 15:54, Eugene V. Lyubimkin wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Eugene V. Lyubimkin" <[EMAIL PROTECTED]>
> 
> 
> * Package name: daptup
>   Version : 0.2
>   Upstream Author : Eugene V. Lyubimkin <[EMAIL PROTECTED]>
> * URL : http://sf.net/projects/daptup
> * License : GPLv3
>   Programming Lang: Bash
>   Description : see changes in new & upgradeable lists after aptitude 
> update
> 
>  Daptup runs "aptitude update" inside and then outputs two lists:
>  - packages came to archive with this update;
>  - new upgradeable packages.

How is this different from apt-show-versions?

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOgfbS9HxQb37XmcRAr9qAJ4l4yKkZlTFiEHnPSAav+tHcgOizQCdGVqf
AtWDEBmUT1sn3VcEpPcqeIQ=
=07ow
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Charles Plessy]

Le Mon, May 26, 2008 at 02:02:52AM +0200, Joerg Jaspert a écrit :
> On 11397 March 1977, Charles Plessy wrote:
> 
> > I have a question about the sources: for big datasets, would it be
> > acceptable that the source package does not contain the data itself but
> > only a script to download it? Since the source packages are not to be
> > autobuilt and the binary packages only available through download,
> > depending on Internet at build time seem to me to be acceptable. (The
> > goal is of course to save space and upload time).
> 
> No, we have to distribute the source. DFSG#2, many licenses require it.
> Relying on some external system to keep the source for us is also a
> no-go.

OK, then I suppose that data for which we do not have the permission to
modify will not be accepted in this repository. Would you consider
adding a non-free section? For scientific data it would be very useful,
because often people do not think of it as a computer program when they
define its redistribution rights, which sometimes lead to non-compliance
to DFSG.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Joerg Jaspert]

On 11397 March 1977, Charles Plessy wrote:

> I have a question about the sources: for big datasets, would it be
> acceptable that the source package does not contain the data itself but
> only a script to download it? Since the source packages are not to be
> autobuilt and the binary packages only available through download,
> depending on Internet at build time seem to me to be acceptable. (The
> goal is of course to save space and upload time).

No, we have to distribute the source. DFSG#2, many licenses require it.
Relying on some external system to keep the source for us is also a
no-go.

-- 
bye, Joerg
 schneidet nie chilis und wascht euch dann _nicht_ die hände und reibt 
euch dann an der nase.
 uargs, wie das brennt
 hammer. das ist ja schlimmer als die dinger zu essen...


pgpa9h8kheaD0.pgp
Description: PGP signature

Re: Large data packages in the archive

[Joerg Jaspert]

On 11396 March 1977, Raphael Geissert wrote:

> What about going the 'b.)' way but define it as a RG (or even RC) with some
> other changes to policy (like requiring big data package's source packages
> to be arch-indep and not build anything else but the data packages). 

No, as already written in my mail.

-- 
bye, Joerg
> What would you do if your package contains an Emacs major mode?
Orphan it.
>  If you don't use/know Emacs then this: What would you do if your
>  package contains a perl module?
Submit it to this year's obfuscated coding contest.


pgpJsrFuYRI2q.pgp
Description: PGP signature

Re: Large data packages in the archive

[Charles Plessy]

Le Sun, May 25, 2008 at 08:18:01PM +0200, Joerg Jaspert a écrit :
> Basic Problem: "What to do with large data packages?"
> 
> That already has a problem: How to define "large"? One way, which we
> chose for now, is simply "everything > 50MB".

(...)

>  - It is an own archive, so it needs full source uploads to work,
>every data package you create will be a full source package and you
>have to split the source between this archive and the rest that goes
>into the normal Debian one.

Hi Joerg, thanks for getting things moving.

I have a question about the sources: for big datasets, would it be
acceptable that the source package does not contain the data itself but
only a script to download it? Since the source packages are not to be
autobuilt and the binary packages only available through download,
depending on Internet at build time seem to me to be acceptable. (The
goal is of course to save space and upload time).

(By the way, there is a short summary of last year's discussions on the
wiki: http://wiki.debian.org/DataPackages)

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Goswin von Brederlow]

Luk Claes <[EMAIL PROTECTED]> writes:

> Raphael Geissert wrote:
>> Hi all,
>> 
>> What about going the 'b.)' way but define it as a RG (or even RC) with some
>> other changes to policy (like requiring big data package's source packages
>> to be arch-indep and not build anything else but the data packages). 
>> 
>> That way the transition could be done gradually for lenny+1 so there's no
>> bloating.
>> 
>> And, mirror admins could then have plenty of time to decide whether to
>> mirror the data packages or not.
>
> Are you sure that the current sync scripts make that possible and won't
> sync everything unless explicitely stated differently and will keep
> working without intervention for the time being? Because otherwise it's
> like Joerg said not an option IMHO.

It is quite simple to ignore a suite in the official mirror scripts
and they will just sync everything without intervention.

I also think that any space pressed mirror admin has no problems
adding an exclude.


What I think could be problematic is that mirrors are chained. If any
mirror in the middle of the chain excludes the data suite then all
mirrors downstream will do so too. I'm not sure how long the chains
are but there could be surprising effects.

Excluding the data suite could only be allowed if all downstream
mirrors agree they don't want that or get changed to a different
source.


Overall it is nothing unsurmountable but it would certainly cause some
disruptions. Hopefully this showed you some of the risk of option b.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated files and patch systems

[Goswin von Brederlow]

Neil Williams <[EMAIL PROTECTED]> writes:

> I'm getting into a crazy situation with this lintian warning:
>
> patch-system-but-direct-changes-in-diff
>
> I've removed one diversion from libgpewidget but I still need to use one
> and this requires a patch to configure.ac using dpatch. This then
> regenerates configure and aclocal.m4.
>
> I think patch-system-but-direct-changes-in-diff is just too buggy to be
> deployed - that isn't the fault of lintian, I think the "problem" cannot
> be detected/determined in a sane manner. Maybe a downgrade to info?

If you regenerate those files then remove them in clean. If lintian
still complains then that is imho a bug.

If you can't work without those files then the only way out is to save
them and restore them in clean.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482921: Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

[Andreas Barth]

severity 482921 important
thanks

Hi,

* Matthias Klose ([EMAIL PROTECTED]) [080526 00:06]:
> Aurelien Jarno writes:
> > Matthias Klose a écrit :
> > > Package: glibc
> > > Version: 2.7-11
> > > Severity: important
> > > 
> > > Please build libc6-hppa64 and libc6-hppa64-dev packages; there is no
> > > package build-depending on libc6-hppa64-dev, but we need these
> > > packages to run the testsuites for binutils and gcc-4.X. Currently
> > > these packages are completely untested, although used to build the
> > > 64bit flavour of the kernel on hppa.

> > There is no upstream support for 64-bit glibc on hppa, so this bug is
> > currently a wontfix. Please provide us a patch.

> that's fine. in this case we should drop support for hppa for lenny.

I fail to see currently why no support for 64-bit glibc (while we have a
32 bit port) is a reason to drop the port.

Hppa-porters, do you have any opinion on that?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 482921 important
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Severity set to `important' from `serious'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> clone 482902 -1
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
Bug 482902 cloned as bug 482921.

> reassign -1 general
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Bug reassigned from package `glibc' to `general'.

> severity -1 serious
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Severity set to `serious' from `wishlist'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Luk Claes]

Raphael Geissert wrote:
> Luk Claes wrote:
>> Are you sure that the current sync scripts make that possible and won't
>> sync everything unless explicitely stated differently and will keep
>> working without intervention for the time being? Because otherwise it's
>> like Joerg said not an option IMHO.
> 
> I can't tell for sure, but I don't even think that's relevant.
> Because let's say source package foo is already in the archive and builds
> foo and foo-data, the former being an arch-dependent package and the latter
> independent. If the 'data' component is added, next upload of foo should
> build foo-data placing it under 'data', causing no more traffic than the
> one caused by a new upload of foo without the data component.

I don't think existing packages would be the main part as they usually
are 'small'...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luk Claes wrote:
> 
> Are you sure that the current sync scripts make that possible and won't
> sync everything unless explicitely stated differently and will keep
> working without intervention for the time being? Because otherwise it's
> like Joerg said not an option IMHO.

I can't tell for sure, but I don't even think that's relevant.
Because let's say source package foo is already in the archive and builds
foo and foo-data, the former being an arch-dependent package and the latter
independent. If the 'data' component is added, next upload of foo should
build foo-data placing it under 'data', causing no more traffic than the
one caused by a new upload of foo without the data component.

Then, if the addition of the new component is scheduled just after lenny is
released (just an example), it would give some time to mirror admins to
take a decision, and even more time before lenny+1 is released to stop
mirroring the data component (considering it is automagically mirrored).

My POV is that way 'b' causes less pain and less work than option 'c' and
achieves the same goal without having to setup another repository which
would also require more integration work in the current tools (package.d.o,
PTS, DDPO, DEHS, ).

And if that change is defined as a lenny+1 RC goal, it would ensure that all
data packages are in the data component for lenny+1 (which I don't think
are too many).

Please correct me if my assumption is wrong.

> 
> Cheers
> 
> Luk

Cheers,
Raphael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOdiVYy49rUbZzloRApp9AJ9QK9igtCxUXIjl3o3YDKw9wtLhvwCeJyna
QuJfLQ7G1BvQKdNBbyXVJCI=
=/zsL
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482913: ITP: daptup -- see changes in new & upgradeable lists after aptitude update

[Eugene V. Lyubimkin]

Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin" <[EMAIL PROTECTED]>


* Package name: daptup
  Version : 0.2
  Upstream Author : Eugene V. Lyubimkin <[EMAIL PROTECTED]>
* URL : http://sf.net/projects/daptup
* License : GPLv3
  Programming Lang: Bash
  Description : see changes in new & upgradeable lists after aptitude update

 Daptup runs "aptitude update" inside and then outputs two lists:
 - packages came to archive with this update;
 - new upgradeable packages.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Luk Claes]

Raphael Geissert wrote:
> Hi all,
> 
> What about going the 'b.)' way but define it as a RG (or even RC) with some
> other changes to policy (like requiring big data package's source packages
> to be arch-indep and not build anything else but the data packages). 
> 
> That way the transition could be done gradually for lenny+1 so there's no
> bloating.
> 
> And, mirror admins could then have plenty of time to decide whether to
> mirror the data packages or not.

Are you sure that the current sync scripts make that possible and won't
sync everything unless explicitely stated differently and will keep
working without intervention for the time being? Because otherwise it's
like Joerg said not an option IMHO.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

What about going the 'b.)' way but define it as a RG (or even RC) with some
other changes to policy (like requiring big data package's source packages
to be arch-indep and not build anything else but the data packages). 

That way the transition could be done gradually for lenny+1 so there's no
bloating.

And, mirror admins could then have plenty of time to decide whether to
mirror the data packages or not.

I believe the key point here is doing it gradually.

What do people think?

Cheers,
Raphael.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOcVeYy49rUbZzloRAjJlAJ9uFLKRdhPn0FH//nxaGx5MGg0NYACeIb6t
M14wTyfCSWKv60Dkk9z4IXo=
=bsfM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Ove Kaaven]

Joerg Jaspert skrev:

 - Packages in main need to be installable and not cause their (indirect)
   reverse build-depends to FTBFS in the absence of data.debian.org.
   If the data is necessary for the package to work and there is a small
   dataset (like 5 to 10 MB) that can be reasonably substituted for the
   complete data package, the smaller dataset should be included in
   main and the package then may depend on "foo-data | foo-data-small".


Hmm. Would anything happen to the current fgfs-base package (200 MB 
compressed)? This *is* intended to be the minimum data necessary to 
start FlightGear. The "full" data set, for comparison, supposedly fits 
on 3 DVDs. (Obviously, so far I have not felt the urge to package that, 
the users can get that themselves if they want it...)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated files and patch systems

[Raphael Hertzog]

On Sun, 25 May 2008, Mark Brown wrote:
> On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:
> 
> > So I am running the relevant autotools at build time but I still get the
> > warning.
> 
> If you run autotools at build time you should also ensure that the
> changes which autotools makes are reverted in the clean target.  This
> means that your diff doesn't get cluttered with automatically generated
> things and ensures that repeated builds of the package produce the same
> diff.gz.

Exactly, it's the reason why I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482716 in the first
place.

Removing the files which are regenerated in the configure stage is a
simple way to make sure that that you don't end up with such clutter.

Several of the packages which contain such useless changes in the diff
end up causing problems once you try to convert them to source format 3.0
(quilt) because the changes can't be applied/unapplied at any point of
time if the files are regenerated by some intermediate step.

Some examples:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482749
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482733

So I'm in favor of keeping this lintian warning because if the maintainer
makes the effort to keep clean patches, it should also make the effort to
make sure that the package cleans up nicely and doesn't clutter the
.diff.gz.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Michael Hanke]

Hi,

On Sun, May 25, 2008 at 08:18:01PM +0200, Joerg Jaspert wrote:

> So assume we go for solution c. (which is what happens unless someone
> has a *very* strong reason not to, which I currently can't imagine) we
> will setup a seperate archive for this. This will work the same way as
> our main archive does, with a few notable points:
> 
>  - It will be solely arch:all, not splitted per architecture. Or, if
>someone presents *good* reasons why a data archive needs to be
>architecture-aware, we will also offer this, but *NO* autobuilder
>support will be provided.
>This is meant as a place for large datasets, and those should be
>arch independent. And would kill many autobuilders (think of binary
>packages having 500, 800 or more megabytes!)
> 
>  - It is an own archive, so it needs full source uploads to work,
>every data package you create will be a full source package and you
>have to split the source between this archive and the rest that goes
>into the normal Debian one.

> 
> Any comments?
First, thanks a lot for taking care of this issue.

As you mentioned there had been several discussions about this before.
I'd be curious what you think about a scenario for data source packages
that has been outlined by Anthony Towns before:

http://lists.debian.org/debian-devel/2007/06/msg00298.html

Basically it is a virtually empty source package that build-depends on
the binary package that it builds. I made a draft of such a source
package that I use to build a 1GB data package that I host myself
(currently). It is initially built by forcing dpkg-buildpackage to ignore
the build-dep. When the necessary data is not detected during build-time
a small script downloads it from upstream and puts it in the build-tree. This
scenario has the advantage that it prevents doubling the size of the archive
when the data in source and binary packages is identical.

An example package is here (source is just a few kB, but binary is
approx. 1GB)

http://apsy.gse.uni-magdeburg.de/debian/pool/non-free/f/fsldata/fsldata_4.0.4-1.dsc

Would you support/accept such a package?
What about licenses? Is data.debian.org just for stuff that could go in
main or also non-free stuff (above has a non-commerical license)?


> Timeframe for this? I expect it to be ready within 2 weeks.
Great!

BTW, what would be the new maximum size of a package for data.debian.org
-- 10 GB? ;-)


Thanks,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/08 13:03, Chris Bannister wrote:
> On Sun, May 25, 2008 at 08:29:56AM -0500, Ron Johnson wrote:
>> What's an extra few MB plus parsing overhead when "everyone" has
>> 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?
>>
> 
> Huh?. Why commit "good" machines to the landfill?

Because... Newer Is Better, Older is Eviler.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOa8gS9HxQb37XmcRAnDUAJ43RuH5zivlYjGBjoHC8VrjMkAScgCeLadw
gNbGuQM5Xsz3851GfxaSVaU=
=pKYz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Large data packages in the archive

[Joerg Jaspert]

Hi,

one important question lately has been "What should we do with large
packages containing data", like game data, huge icon/wallpaper sets,
some science data sets, etc. Naturally, this is a decision ftpmaster has
to take, so here are our thoughts on it to facilitate discussion and see
if we missed important points but we keep the right to have the last
word how it gets done. :)


Basic Problem: "What to do with large data packages?"

That already has a problem: How to define "large"? One way, which we
chose for now, is simply "everything > 50MB".


While the archive software is written in Python, this problem sounds
like a Perl one as "There is more than one way to do (solve) it":

a.) We can simply say that we don't want this in Debian and people
should use external hosting for such packages. After all they are
for a very small minority usually.

b.) We can just add another component "data" besides
main/contrib/non-free.

c.) We can host an own archive for it under control of ftpmaster.


The first two seem to have grave problems:

a.) Is basically no (good) option. It is our job to maintain the
archive, and if there is enough demand we should make it possible to
also host things like these data packages. Additionally it has the
problem that it would require a move of everything that needs those
data packages into contrib, as there wouldn't be a good base for a
Policy exception.

b.) While that would be the most simple solution it has other problems,
large enough that we decided against it. The biggest one being that
of the principle of least surprise for our mirrors. We are talking
about this to not bloat the main archive too much. If we just add
another component stuff will end up mirrored a lot. Even if we send
an announcement weeks before. Requiring every mirror admin to take a
decision if they want to mirror or exclude it, then adjust their
scripts, is a simple no-go for us.

So the way to go for us seems to be c.), hosting the archive ourself
(somewhere below data.debian.org probably).


For all the rest of the mail I talk about solution c., unless otherwise
stated.


So assume we go for solution c. (which is what happens unless someone
has a *very* strong reason not to, which I currently can't imagine) we
will setup a seperate archive for this. This will work the same way as
our main archive does, with a few notable points:

 - It will be solely arch:all, not splitted per architecture. Or, if
   someone presents *good* reasons why a data archive needs to be
   architecture-aware, we will also offer this, but *NO* autobuilder
   support will be provided.
   This is meant as a place for large datasets, and those should be
   arch independent. And would kill many autobuilders (think of binary
   packages having 500, 800 or more megabytes!)

 - It is an own archive, so it needs full source uploads to work,
   every data package you create will be a full source package and you
   have to split the source between this archive and the rest that goes
   into the normal Debian one.

 - We need to change policy. It currently forbids packages in main to
   Depend/Recommend something outside of it (which is good). As that
   would make the data archive less useful, I propose to change this to
   something including the meaning of "Packages in main are allowed to
   recommend packages in the data archive".
   Dependencies should *not* be allowed, but read the next point.

 - Packages in main need to be installable and not cause their (indirect)
   reverse build-depends to FTBFS in the absence of data.debian.org.
   If the data is necessary for the package to work and there is a small
   dataset (like 5 to 10 MB) that can be reasonably substituted for the
   complete data package, the smaller dataset should be included in
   main and the package then may depend on "foo-data | foo-data-small".


Any comments?

Timeframe for this? I expect it to be ready within 2 weeks.

-- 
bye, Joerg
Some AM after a mistake:
Sigh.  One shouldn't AM in the early AM, as it were.  


pgp5XPRRvM9lK.pgp
Description: PGP signature

Re: packages up for adoption

[Joey Hess]

David Watson wrote:
> I'll take rss2email if no one else wants to.

Ok, you have it. Good luck!

-- 
see shy jo


signature.asc
Description: Digital signature

Re: What about use xml for descriptions of packages?

[Chris Bannister]

On Sun, May 25, 2008 at 08:29:56AM -0500, Ron Johnson wrote:
> What's an extra few MB plus parsing overhead when "everyone" has
> 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?
> 

Huh?. Why commit "good" machines to the landfill?

-- 
Chris.
==
"One, with God, is always a majority, but many a martyr has been burned
   at the stake while the votes were being counted."  -- Thomas B. Reed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Manuel Prinz]

First of all, I did not get it in my first reply that you spoke from a
translaters point of view. I just have a very limited view on
translation work, so my arguments may not be correct.

Am Sonntag, den 25.05.2008, 16:05 +0200 schrieb Fernando Cerezal:
> How can a program know if
> 
>  * A description sentence with
> two lines
> 
> and
> 
>  * A description sentence with
> two lines
> 
> are the same?

As always: by definition. If you define that indentation matters, first
one would be treated as two lines and the second as one. If you define
that indentation does not matter and bullet points have to be seperated
by an empty line (I think POD does something like this), then the first
entry is one line. So the problem is a missing definition of how the
formating should be treated by a parser, not a new document format.

> Or other similar problem: The url of project web page changes, like this:
> 
> Upstream URL: http://www.example.com
> Upstream URL: http://www.example.com/project
> 
> This is handled like a modification of the translation, and a
> translator for every language needs to review that, and «translate»
> it.

For this case, the Homepage field exists. By using that, the Description
does not need to be touched in any way.

> The problem is that the number of descriptions translated grows lower
> than the number of packages, and besides this, the translators have to
> review older descriptions that have not new information, but change of
> format, change of URLs and so on.

I see the burdon that it brings to translators but I do not understand
how XML may resolve those. URL should IMHO not be in the description as
they are subject to change and a better alternative exists. If the
format changes, the problem is to detect whether it is a "real" change.
Checking for changes in whitespace are equally easy to detect in the old
and an XML-based format. If new points are added to list or a point is
split into two, you can not automatically detect and correct those in
either format.

> I think using XML, or HTML, and embed a tiny web browser into
> synaptic, we can resolve part of the problem for translations and use
> the benefits of HTML, like including images, real links for web pages,
> links between packages that can be "easyly" handled.

I'm still not convinced that these features have a benefit.

> I write XML because is something I know. I mean markup tags.

This is valid but I think there are better markup languages for that
purpose that do not effect the readability of the document. Also, a lot
of parsers for these language exists and they are easily transformable
into other formats, such as (X)HTML.

> The descriptions have a lot of lists, execute strings, urls, and so on.
> If an item of a lists changes, we have to review all the list, find
> the change, do it in the translations and send it to revision process.

How does XML prevent a review here?

> There is no convention with this [Homepage field]. Or if there is, it is not 
> used.

There is. If it's not used, you can file wishlist bugs.

> > I still do not see why the current scheme is limited. Can you give
> > examples where special markup or links in the texts may be useful?
> 
> lists, links, non-translatable strings (URLs, numbers of version),
> changes in tabulation...

All such things are covered by more readable markup languages, too. I
agree that lists are a problem with the current format.

> Perhaps my question is bad presented and it introduces noise to the
> list. I'm sorry so.

I do not think so. As said, at least I did not see that you spoke from a
translator's point of view at first.

Best regards
Manuel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated files and patch systems

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> writes:
> On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:

>> If you run autotools at build time you should also ensure that the
>> changes which autotools makes are reverted in the clean target.  This
>> means that your diff doesn't get cluttered with automatically generated
>> things and ensures that repeated builds of the package produce the same
>> diff.gz.

> I haven't seen any other packages doing that - is there an example
> involving aclocal.m4 somewhere?

Lots of other packages do this -- one of mine off the top of my head is
xml-security-c.

> I really don't want to do all that for the tmpl/* files as well - I
> don't see the need, copying dozens of files into foo.safe or
> foo.upstream and then moving them back?

Just delete them then.

The point is to not put mechanically generated changes in the diff, since
it makes it much harder to review what the maintainer has actually done.
I think most people take the approach of just deleting such files in the
clean target, which will exclude their changes from the diff.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/08 08:34, David Paleino wrote:
> On Sun, 25 May 2008 08:29:56 -0500, Ron Johnson wrote:
> 
>> What's an extra few MB plus parsing overhead when "everyone" has
>> 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?
> 
> Well, and what about !i386, !amd64 and !powerpc ? ;)

Suffer like the 3rd-class citizens they are!

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOXbNS9HxQb37XmcRAs/3AKC7SGpRrXUE+QM06pN4bmf1nJlOvACg4kMs
MrqrfpsAFSLEW8oqNl9hL9g=
=/nRd
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482846: ITP: arora -- simple cross platform web browser.

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: arora
  Version : 0.2~git-of-the-day
  Upstream Author : Benjamin Meyer
* URL : http://code.google.com/p/arora
* License : GPL
  Programming Lang: C++ / Qt
  Description : simple cross platform web browser.

simple webkit based webbrowser using Qt toolkit. Originally based
on the Qt demo browser to show the possibilities of Qt Webkit.
Arora is a very basic browser that supports history and bookmarks.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (200, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20-1-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Fernando Cerezal]

2008/5/25 Manuel Prinz <[EMAIL PROTECTED]>:
> Am Sonntag, den 25.05.2008, 14:40 +0200 schrieb Fernando Cerezal:
>> I'm thinking about advantages and disadvantages of write the
>> description of the packages using XML.
>
> I like XML but it's a huge pain to write by hand. The current format is
> easy to read, easy to write and easy to parse. This is important and
> definitely not the case if it is XML.

How can a program know if

 * A description sentence with
two lines

and

 * A description sentence with
two lines

are the same?

Or other similar problem: The url of project web page changes, like this:

Upstream URL: http://www.example.com
Upstream URL: http://www.example.com/project

This is handled like a modification of the translation, and a
translator for every language needs to review that, and «translate»
it.

Sorry, perhaps XML is not the solution, but I prefer present a problem
with a possible solution than simplely the problem.
The problem is that the number of descriptions translated grows lower
than the number of packages, and besides this, the translators have to
review older descriptions that have not new information, but change of
format, change of URLs and so on.

I think using XML, or HTML, and embed a tiny web browser into
synaptic, we can resolve part of the problem for translations and use
the benefits of HTML, like including images, real links for web pages,
links between packages that can be "easyly" handled.

>
>> I think using XML the descriptions can be rendered in different form
>> for text and graphical tools.
>
> If this something that is really needed, one could think about more sane
> such as allowing Markdown[1] for Description field.

I write XML because is something I know. I mean markup tags.

>  I thought about that
> for a while now but never really saw the need to have formatted text or
> code examples in a package description.

The descriptions have a lot of lists, execute strings, urls, and so on.
If an item of a lists changes, we have to review all the list, find
the change, do it in the translations and send it to revision process.

>  IMHO those just do not belong
> there. And for cases where links are needed, special fields as the
> Homepage field exists which are properly shown in most tools.

There is no convention with this. Or if there is, it is not used.

>
>> As disadvantage, we will need to develop a robot that do format for
>> the current descriptions and translations and we will have to review
>> all of them. Ciertainly, this will be an huge job.
>
> I'd rather convince people to adpot a new format, not to decide for them
> whether they want it or not. Change by evolution, not revolution.

I agree, I write to the list asking if there were any previous discussion.

>
>> However, I think the current scheme of descriptions is very limitied
>> and is better to do it earlier than translate more descriptions and
>> then move all to a new format in the future.
>
> I still do not see why the current scheme is limited. Can you give
> examples where special markup or links in the texts may be useful?

lists, links, non-translatable strings (URLs, numbers of version),
changes in tabulation...
And all other semantic issues and where form and content are mixed.

I don't know how is the backend of dpkg, but I know how is the
translator work and I think this thing could do the process more
efficiente.
Perhaps my question is bad presented and it introduces noise to the
list. I'm sorry so.

>
> Best regards

Regards.

> Manuel
>
> [1] http://en.wikipedia.org/wiki/Markdown
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>

Re: What about use xml for descriptions of packages?

[Noah Slater]

On Sun, May 25, 2008 at 08:46:22AM -0400, Roberto C. Sánchez wrote:
> On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote:
> > I'm thinking about advantages and disadvantages of write the
> > description of the packages using XML.
>
> Personally, I would hate this.  I've written too many ant build.xml
> scripts to think that writing XML by hand is even a remotely sane thing
> to do.

Same here.

  A lot of people when faced with a problem think "I know, I'll use XML!"

  Now they have two problems.

Seriously though, XML is often used for no apparent reason other than it being
"trendy" or "cool" or whatnot. I think this is one of those times.

Some initial problems I can think of:

  * You can't "just" use XML, you have to use a dialect. Dialects require
schemas and schemas are Hard.

  * XML is hard to edit and prone to errors when done by hand.

  * XML would be very hard to format by hand when embedded within RFC 2822, the
format of the debian/control file.

  * XML is great for complex content that requires many degrees of freedom and
processing possibilities, non of which really apply to package descriptions.

  * XML even when used is usually better when derived from some other format,
such as a light text based markup language. Think AsciiDoc, Markdown or 
REsT.

Some initial questions I can think of:

  * What would XML buy us that plain text doesn't?

  * Do those benefits outweigh all the negative issues.

  * Could something more light weight be chosen instead?

Best,

-- 
Noah Slater - Bytesexual 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Neil Williams]

On Sun, 2008-05-25 at 08:29 -0500, Ron Johnson wrote:
> > 13 x 10 x 20,000 = bloat.
> 
> It would probably be more like one paragraph per .

Still far too much.

> > Now that really is out of the question - please remember that the
> > packages descriptions go into the dpkg database which is already too
> > big.
> 
> What's an extra few MB plus parsing overhead when "everyone" has
> 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?

I am going to assume you are not being serious.

Try 64Mb Flash, ARM5 CPU and 64Mb RAM.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: What about use xml for descriptions of packages?

[David Paleino]

On Sun, 25 May 2008 08:29:56 -0500, Ron Johnson wrote:

> What's an extra few MB plus parsing overhead when "everyone" has
> 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?

Well, and what about !i386, !amd64 and !powerpc ? ;)

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: What about use xml for descriptions of packages?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/08 08:17, Neil Williams wrote:
> On Sun, 2008-05-25 at 15:07 +0200, Fernando Cerezal wrote:
[snip]
> 
>> A description with lines
> 
> Is an extra 13 characters per line, per description, per package.
> 
> 13 x 10 x 20,000 = bloat.

It would probably be more like one paragraph per .

>> The program foo is used for help you in your task > src="http://logo_of_foo.jpg";>
> 
> Now that really is out of the question - please remember that the
> packages descriptions go into the dpkg database which is already too
> big.

What's an extra few MB plus parsing overhead when "everyone" has
250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM?

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOWnUS9HxQb37XmcRAssUAJ4w+nYc+jGxTSGID8Y5LldxRfaMUQCdFva0
CVCmI+LtEmE0YjvljXmy/CY=
=+o0E
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Manuel Prinz]

Am Sonntag, den 25.05.2008, 14:40 +0200 schrieb Fernando Cerezal:
> I'm thinking about advantages and disadvantages of write the
> description of the packages using XML.

I like XML but it's a huge pain to write by hand. The current format is
easy to read, easy to write and easy to parse. This is important and
definitely not the case if it is XML.

> I think using XML the descriptions can be rendered in different form
> for text and graphical tools. 

If this something that is really needed, one could think about more sane
such as allowing Markdown[1] for Description field. I thought about that
for a while now but never really saw the need to have formatted text or
code examples in a package description. IMHO those just do not belong
there. And for cases where links are needed, special fields as the
Homepage field exists which are properly shown in most tools.

> As disadvantage, we will need to develop a robot that do format for
> the current descriptions and translations and we will have to review
> all of them. Ciertainly, this will be an huge job.

I'd rather convince people to adpot a new format, not to decide for them
whether they want it or not. Change by evolution, not revolution.

> However, I think the current scheme of descriptions is very limitied
> and is better to do it earlier than translate more descriptions and
> then move all to a new format in the future.

I still do not see why the current scheme is limited. Can you give
examples where special markup or links in the texts may be useful?

Best regards
Manuel

[1] http://en.wikipedia.org/wiki/Markdown



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Neil Williams]

On Sun, 2008-05-25 at 15:07 +0200, Fernando Cerezal wrote:
> 2008/5/25 Roberto C. Sánchez <[EMAIL PROTECTED]>:
> > On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote:
> Yes, you are right. However, currently the translations of the Debian
> website are being done by hand, so there is the same problem and it
> works enough fine. 

What are we talking about here, www.debian.org or apt-cache show?

These are two very different issues.

> Are interpreted as two difference descriptions. 

They would be in gettext - unless marked up in such a way as to not
include the extra spaces.

> A description with lines

Is an extra 13 characters per line, per description, per package.

13 x 10 x 20,000 = bloat.

> The program foo is used for help you in your task  src="http://logo_of_foo.jpg";>

Now that really is out of the question - please remember that the
packages descriptions go into the dpkg database which is already too
big.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Generated files and patch systems

[Neil Williams]

On Sun, 2008-05-25 at 14:01 +0100, Neil Williams wrote:
> On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
> > On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:
> > 
> > > So I am running the relevant autotools at build time but I still get the
> > > warning.
> > 
> > If you run autotools at build time you should also ensure that the
> > changes which autotools makes are reverted in the clean target.  This
> > means that your diff doesn't get cluttered with automatically generated
> > things and ensures that repeated builds of the package produce the same
> > diff.gz.
> 
> I haven't seen any other packages doing that - is there an example
> involving aclocal.m4 somewhere?

Actually, I just converted the package to CDBS and it did
TheRightThing(tm) so I'll either stick with that or convert what cdbs
does into the existing package.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: What about use xml for descriptions of packages?

[Neil Williams]

On Sun, 2008-05-25 at 08:46 -0400, Roberto C. Sánchez wrote:
> On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote:
> > Hello,
> > I'm thinking about advantages and disadvantages of write the
> > description of the packages using XML.
> 
> Personally, I would hate this.  I've written too many ant build.xml
> scripts to think that writing XML by hand is even a remotely sane thing
> to do.

I agree - I write a lot of XML and XSL and write various XML backends
for various upstream projects. It sounds like a very bad idea to me,
especially considering the extra workload required to parse the dpkg
data on low resource installations.

The extra bloat of the XML tags alone is sufficient reason not to do
this, IMHO.

I like XML but it isn't the right choice for package descriptions IMHO.
Better to work with a simpler format but one that can still be parsed by
gettext so that TDebs can read the translation strings from binary .mo
files.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: What about use xml for descriptions of packages?

[Fernando Cerezal]

2008/5/25 Roberto C. Sánchez <[EMAIL PROTECTED]>:
> On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote:
>> Hello,
>> I'm thinking about advantages and disadvantages of write the
>> description of the packages using XML.
>
> Personally, I would hate this.  I've written too many ant build.xml
> scripts to think that writing XML by hand is even a remotely sane thing
> to do.

Yes, you are right. However, currently the translations of the Debian
website are being done by hand, so there is the same problem and it
works enough fine. Besides, the descriptions are formated using
spaces, so

 * A description sentence with
two lines

and

 * A description sentence with
   two lines

Are interpreted as two difference descriptions. And a change such as
this do that, at least, 28 (the number of languages Debian is being
translated) translators have to review the translations.

However, something like

A description with lines

will not have that problems and will reduce the number of translations
to be reviwed without real modifications. I think this method will
help to reuse strings and reduce the number of strings to translate.

And using this, we could do things like:

The program foo is used for help you in your task http://logo_of_foo.jpg";>

So, apt can ignore img tags, but programs such synaptic can offer a
very much graphic experience.

I think the current method for descriptions is very limitied.

>
> Regards,
>
> -Roberto
>
> --
> Roberto C. Sánchez
> http://people.connexer.com/~roberto
> http://www.connexer.com
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIOV+e5SXWIKfIlGQRAh10AKCYpH+ESHW8H7RD4J0dYdabMgHZdgCfZNAL
> 0ItGduqjWil437/bvIqK0aI=
> =F6l8
> -END PGP SIGNATURE-
>
>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What about use xml for descriptions of packages?

[Mikhail Gusarov]

Twas brillig at 14:40:07 25.05.2008 UTC+02 when Fernando Cerezal did gyre and 
gimble:

 FC> I think using XML the descriptions can be rendered in different
 FC> form for text and graphical tools.

Same for current format. Just use perl/python/whatever instead of XSLT.

 FC> The URL of the descriptions can be real links and, even and the
 FC> project thinks it is appropiate, links to the logos, and perhaps
 FC> sponsors, of the project when description is showed in graphical
 FC> mode.

Same for current format.

 FC> Besides, I think will be more easy to develop a tool that manage
 FC> XML for manage descriptions and their translations than plain text
 FC> with its special details.

IMHO quite opposite.

 FC> And, of course, we will not format the descriptions using spaces.

While formatting is consistent, it may be converted to anything you
want.

-- 


pgpnVMlU0evrM.pgp
Description: PGP signature

Re: Generated files and patch systems

[Neil Williams]

On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
> On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:
> 
> > So I am running the relevant autotools at build time but I still get the
> > warning.
> 
> If you run autotools at build time you should also ensure that the
> changes which autotools makes are reverted in the clean target.  This
> means that your diff doesn't get cluttered with automatically generated
> things and ensures that repeated builds of the package produce the same
> diff.gz.

I haven't seen any other packages doing that - is there an example
involving aclocal.m4 somewhere?

I really don't want to do all that for the tmpl/* files as well - I
don't see the need, copying dozens of files into foo.safe or
foo.upstream and then moving them back?

> This is the same idea as patch systems reverting the changes they make
> in the clean target.

Unfortunately, I can't get it to work either.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: What about use xml for descriptions of packages?

[Roberto C . Sánchez]

On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote:
> Hello,
> I'm thinking about advantages and disadvantages of write the
> description of the packages using XML.

Personally, I would hate this.  I've written too many ant build.xml
scripts to think that writing XML by hand is even a remotely sane thing
to do.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

What about use xml for descriptions of packages?

[Fernando Cerezal]

Hello,
I'm thinking about advantages and disadvantages of write the
description of the packages using XML.
I think using XML the descriptions can be rendered in different form
for text and graphical tools. The URL of the descriptions can be real
links and, even and the project thinks it is appropiate, links to the
logos, and perhaps sponsors, of the project when description is showed
in graphical mode.
Besides, I think will be more easy to develop a tool that manage XML
for manage descriptions and their translations than plain text with
its special details. And, of course, we will not format the
descriptions using spaces.

As disadvantage, we will need to develop a robot that do format for
the current descriptions and translations and we will have to review
all of them. Ciertainly, this will be an huge job. However, I think
the current scheme of descriptions is very limitied and is better to
do it earlier than translate more descriptions and then move all to a
new format in the future.

Is there any earlier discussion about this?

I sent this to i18n, but I had not reponse.

Regrets.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated files and patch systems

[Mark Brown]

On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:

> So I am running the relevant autotools at build time but I still get the
> warning.

If you run autotools at build time you should also ensure that the
changes which autotools makes are reverted in the clean target.  This
means that your diff doesn't get cluttered with automatically generated
things and ensures that repeated builds of the package produce the same
diff.gz.

This is the same idea as patch systems reverting the changes they make
in the clean target.

> Do I have to move aclocal.m4 aside in debian/rules and move it back? How
> does that help? - it'll still be in the .diff.gz under a different
> filename. That doesn't help the build-twice release goal issue. Yes, the
> package meets the letter of the release goal by building twice in a row
> but not without either spurious lintian overrides or spurious lintian
> warnings.

If you actually move it back in the clean target (rather than just
copying it back) then it won't appear in the diff.gz.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Generated files and patch systems

[Neil Williams]

I'm getting into a crazy situation with this lintian warning:

patch-system-but-direct-changes-in-diff

I've removed one diversion from libgpewidget but I still need to use one
and this requires a patch to configure.ac using dpatch. This then
regenerates configure and aclocal.m4.

I think patch-system-but-direct-changes-in-diff is just too buggy to be
deployed - that isn't the fault of lintian, I think the "problem" cannot
be detected/determined in a sane manner. Maybe a downgrade to info?

From #471263
> I personally think such changes should be made by running the relevant
> Autotools at build time, but I realize this is an ongoing debate and
> that's far from the consensus at the moment.  I think we're still trying
> to feel out what Lintian's role should be here.  I'd welcome any feedback
> from other people reading the mailing list.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED])
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471263#10

So I am running the relevant autotools at build time but I still get the
warning.

Then a more bizarre problem arrives - the first build I get:
Now running lintian...
W: libgpewidget source: patch-system-but-direct-changes-in-diff aclocal.m4
Finished running lintian.

Any subsequent build produces:
Now running lintian...
W: libgpewidget source: patch-system-but-direct-changes-in-diff aclocal.m4
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/color-slider.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/colordialog.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/colorrenderer.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/gpeclockface.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/gpedialog.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/gpehelp.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/gtkdatecombo.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/gtksimplemenu.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/libgpewidget-unused.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/link-warning.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/pixmaps.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/smallbox.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff 
doc/tmpl/spacing.sgml
Finished running lintian.

I don't see why I should "patch" aclocal.m4 and I consider it a harmful
thing to do seeing as every update of autotools will likely cause the
other changes in aclocal.m4 and the patch will to fail to apply causing
a FTBFS - a much more serious issue.

Having aclocal.m4 in the .diff.gz causes problems with uscan; uupdate
because it does fail to apply from one upstream release to the next but
that is only a problem for me and I can live with it.

What is the solution here?

Do the other dpkg source formats have a solution for generated files?

(PLEASE don't spout on and on about git. I don't use git, I have no
intention of using git - I do not particularly want to use any RCS with
this particular package although I might consider SVN seeing as
svn-buildpackage at least has sane MergeWithUpstream support. The more
noise the git-fanclub make, the less I listen so don't expect a reply
from me if you want to talk about git.)

Do I have to move aclocal.m4 aside in debian/rules and move it back? How
does that help? - it'll still be in the .diff.gz under a different
filename. That doesn't help the build-twice release goal issue. Yes, the
package meets the letter of the release goal by building twice in a row
but not without either spurious lintian overrides or spurious lintian
warnings.

What is the problem that this lintian check is trying to solve, why does
it apply to generated files and is there a sane way to tell the
difference (especially when a "generated file" can still mean a file
present in the upstream source and modified in the .diff.gz because
modifications result from the actions of a third-party build-tool)?

I'm not sure why gtk-doc-tools is making these changes - this is a new
upstream release (although there appear to be differences in the
autotools environment between myself and upstream, hence the aclocal.m4
diff) and the tmp/ files have been updated upstream. Quite why I get no
error with the first build but errors with all subsequent builds I have
no idea. I can reproduce the "silent" build by simply copying the
tmp/*.sgml files back into place from the .orig.tar.gz so those could be
"moved aside" as well but it seems a lot of work if the lintian warning
itself is dubious or cannot be applied in a sane manner. I don't see
that creating patches for these tmpl/ files is correct either - a change
in gtk-doc-tools could easily break many such patches and I do not
consider it "my fault" 

Re: what about an special QA package priority?

[Stefano Zacchiroli]

On Fri, May 23, 2008 at 06:44:39PM +0200, Steinar H. Gunderson wrote:
> On Fri, May 23, 2008 at 06:03:51PM +0200, Stefano Zacchiroli wrote:
> > So, basically, I welcome your proposal, but IMO its simplest and most
> > effective implementation would be: ``packages scoring high in popcon
> > have to be maintained by teams using some Vcs-*''.
> 
> Why do you want to force the use of a VCS onto a team?

Uh? I'm probably not getting your question, but I do not want to force
the use of a _specific_ VCS, if that is what you meant. Assuming that
the proposal rationale was to give more visibility to what is going on
to a given package, since it is an "important" one, using _whatever_ VCS
sounds like a requirement to me.

Of course you need also to specify that it should be public, better if
it has a web interface to monitor changes and yada yada ...

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Crown Victoria 5,555

[Ford]

Edge 7,777

[Ford]