Re: "Team uploads"

[Matthew Johnson]

On Tue Apr 07 10:38, Charles Plessy wrote:
> so in the end, can we use the “ * QA upload.” special first line for
> non-uploader uploads without breaking the QA infrastructure?

That's wrong if the maintainer is not debian...@lists.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: UDD gatherer for DDTP translations (Was: Extended descriptions size)

[Andreas Tille]

On Sun, 5 Apr 2009, Martijn van Oosterhout wrote:


While I'm not against the idea of version numbers (though it would
have to be a list since a single translation may apply to dozens of
versions)


This might be discussed.


it's not that hard to identify the description you want.
What I often did was simply open up the description file to find the
description I wanted to test, cut and paste it into another console
running md5sum and that would be the md5 I needed to look for.


Well, I did not said that it is actually hard and in UDD you can get this
easily by

   SELECT md5(description || E'\n' || long_description || E'\n' ) AS md5
  FROM packages WHERE ...

but the actual method you are proposing might be not very reliable because
of the importance of spacings (like the exact newlines etc).  So comparing
version numbers is faster in any case and *easily* doable for humans -
even if you have the right md5 sum as you mentioned above - comparing it
is also harder than a short version string.  While the human readability
is not my main concern I care more for the feature to directly compare
Translations and Packages table with the available information rather
than taking the detour over MD5 sums.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:46 +0200, Christian Perrier wrote:
> Quoting Frans Pop (elen...@planet.nl):
> 
> > I'm not sure where the original mail comes from, but IMO this should be 
> 
> From lilo package BTS which I was tracking for l10n purposes. So I
> just happened to notice William's answer to a bug report and thought
> it would be good for this to be discussed in public.
> 
> Clearly, I didn't choose the right place to discuss and the topic has
> wider implications than just D-I, as the followups show. Good thing
> that you made the discussion wider.
> 
> > > Don't we have some install paths that still depend on LILO?
> > 
> > Yes: /boot on LVM is the main one.
> > 
> > > Anyway, even if we don't, I think we should track that lilo removal
> > > and coordinate with William, in order to stop providing
> > > lilo-installer.
> > >
> > > And, I think this should be mentioned as a release goal (dropping
> > > lilo). Either high priority if we have install paths depending on
> > > lilo, or normal priority otherwise.
> > 
> > D-I release goal or Debian release goal [1]?
> 
> Clearly Debian release "goal".
> 
> > IMO the latter could well be justified as there will also need to be some 
> > kind of upgrade strategy for existing users that does not make 
> > uncontrolled changes on their hard disk or loses them the ability to boot 
> > alternative OSes on dual (or multi) boot systems.
> 
> Which might be very tricky
> 
> But, as William mentioned in his original mail, upstream activity
> seems to be low so we need to figure out if we want to keep yet
> another unmaintained software in Debian. What later puzzled me if the
> mention in non collaboratve upstream *if we don't drop Debian
> patches*.
> 
> That's not exactly inactive upstream so it would be good to clarify
> the situation of lilo upstream.
> 

Lilo upstream is dead (no release in quite a while), but the lilo
maintainer has also been seen as saying in various mailing lists etc,
that since Debian patches lilo that he has no interest in helping to fix
problems in our version.

William


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Giacomo A. Catenazzi]

Gunnar Wolf wrote:

It does achieve not having bogus information on. If your system
crashed, some crappy daemons will refuse to start if
/var/run/crappyserver.pid exists, or will try to communicate with
their peers using /var/run/sloppydaemon.socket, possibly failing
cleanly, but possibly leading to head-scratching


In Debian policy:
: The init.d scripts must ensure that they will behave sensibly
: (i.e., returning success and not starting multiple copies of a
: service) if invoked with start when the service is already running,
: or with stop when it isn't, and that they don't kill
: unfortunately-named user processes.

this case is not cited in the examples, but I really think
that *behave sensibly* cover also thiscase , i.e. after a crash a
daemon should start, also if .pid exists.

ciao
cate


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

Re: lilo about to be dropped?

[Martin Wuertele]

* Frans Pop  [2009-04-07 02:54]:

> Martin Wuertele wrote:
> > Actually lilo is installed by lenny d-i if you use root-sw-raid with
> > LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo
> > should at least remain for sqeeze to ensure a proper upgrade path.
> 
> I'm afraid you're mistaken here. Lenny D-I should (and AFAIK does) default 
> to grub for that setup.
> 
> /boot on normal partition or RAID1 + / on whatever combination of RAID+LVM 
> is supported fine by grub. Unless there is some other factor that you've 
> not mentioned D-I does not fall back to lilo for that.

I wonder what it could be. I don't user XFS just plain ext3 and had to
manually install grub for 2 recent setups. One is an IBM X3560 with
harware-raid, /boot on one partitione, rest for lvm, the other is an
X3220 with /boot on md0 and lvm on md1. For both D-I installed lilo.

Yours
Martin


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

Re: "Team uploads"

[Russ Allbery]

Charles Plessy  writes:
> Le Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery a écrit :

>> There still should be some humans in Maintainer/Uploaders who are
>> taking primary responsibility for the package, but I think other team
>> members should be able to do QA-style fixes and transition uploads
>> without using NMU versioning or add themselves to Uploaders and hence
>> imply that they're taking ongoing responsibility for the package.

> so in the end, can we use the “ * QA upload.” special first line for
> non-uploader uploads without breaking the QA infrastructure?

No, that is reserved for orphaned packages and triggers other checks to
ensure the maintainer is set appropriately.

I think the conversation hasn't reached a conclusion yet about the right
way to do this, but I doubt it would be reusing the key phrase for
orphaned package uploads.

-- 
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: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Jan Lübbe]

On Mon, 2009-04-06 at 20:42 +0200, Michael Biebl wrote:
> Steve Langasek wrote:
> > I think he's referring to the fact that the FHS requires all files in
> > /var/run to be cleared on boot.  We have an init script
> > (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system
> > level, though, on behalf of all packages; the trouble is it's a lot less
> > efficient, overall, to have to repeatedly clean /var/run on boot than it is
> > to just write it to a tmpfs and let the contents be lost on reboot.
> 
> I think that is one of them main questions:
> 
> Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides
> directories) on boot in a single place (mountall-bootclean), or is it more
> efficient to use a tmpfs and let every package create it's run directory on 
> boot.
> It's probably hard to tell without proper benchmarking.

Another possibility would be to recreate the directories
in /var/{run,lock} on boot in a centeral initscript. Each package could
ship a directory as template somewhere else which would be copied on
boot (after cleaning or mounting a tmpfs) to /var/{run,lock}. Or shell
script snippets could be used instead.

This would at least avoid having an initscript for the sole purpose of
creating those directories.

Jan


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

Transition from libmysqlclient15 to libmysqlclient16

[Norbert Tretkowski]

Hi,

I plan to move MySQL 5.1 from experimental to unstable really soon now,
MySQL 5.0 will be dropped from Debian at the same time. This means 215
packages need to be rebuild.

There should be no changes necessary on these packages, a simple rebuild
should do it.

Norbert


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

Writing symbols files for C++ libraries.

[Daniel Kobras]

Hi!

I'm currently fighting with deb symbols files for a C++ library I'm
packaging, and I'd like to get some insight in how others are coping
with this task. In particular, I wonder how to get rid of symbols from
standard template instances that leak into the ABI, eg.

$ cat test.cpp 
#include 

std::string foome(const std::string& bar)
{
return "foo" + bar + "foo";
}

$ g++ -fPIC -c test.cpp
$ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E
'(FUNC|OBJECT)'
18: 23 FUNCWEAK   DEFAULT9 
_ZNSt11char_traitsIcE6lengthEPKc
22:    155 FUNCWEAK   DEFAULT   11 
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
30:    104 FUNCWEAK   DEFAULT   14 
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
33:    124 FUNCGLOBAL DEFAULT5 _Z5foomeRKSs

I can hide the operator+() and related instances from with a version
script, of course, but due to C++ name mangling they tend to be
arch-specific and thus hard to maintain. Does anyone know of a more
lightweight solution to limit visibility of template instances and
ensure a clean ABI for C++ libraries? What are the current best
practises when writing symbols files for C++ libraries, or is it simply
not recommended?

Regards,

Daniel.


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

Re: Writing symbols files for C++ libraries.

[Mike Hommey]

On Tue, Apr 07, 2009 at 01:22:51AM +0200, Daniel Kobras  
wrote:
> Hi!
> 
> I'm currently fighting with deb symbols files for a C++ library I'm
> packaging, and I'd like to get some insight in how others are coping
> with this task. In particular, I wonder how to get rid of symbols from
> standard template instances that leak into the ABI, eg.
> 
> $ cat test.cpp 
> #include 
> 
> std::string foome(const std::string& bar)
> {
>   return "foo" + bar + "foo";
> }
> 
> $ g++ -fPIC -c test.cpp
> $ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E
> '(FUNC|OBJECT)'
> 18: 23 FUNCWEAK   DEFAULT9 
> _ZNSt11char_traitsIcE6lengthEPKc
> 22:    155 FUNCWEAK   DEFAULT   11 
> _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
> 30:    104 FUNCWEAK   DEFAULT   14 
> _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
> 33:    124 FUNCGLOBAL DEFAULT5 _Z5foomeRKSs
> 
> I can hide the operator+() and related instances from with a version
> script, of course, but due to C++ name mangling they tend to be
> arch-specific and thus hard to maintain. Does anyone know of a more
> lightweight solution to limit visibility of template instances and
> ensure a clean ABI for C++ libraries? What are the current best
> practises when writing symbols files for C++ libraries, or is it simply
> not recommended?

Unfortunately, gcc upstream consider this as a feature, and not a bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022

I found nothing better than using a version script. I'm lucky that the
library in question (WebKit) only really exports C symbols, and C++ is only
internal details, so I'm filtering everything that starts with _Z, now.

Mike


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

Bug#522914: ITP: agda -- a dependently typed functional programming language and proof assistant

[Iain Lane]

Package: wnpp
Severity: wishlist
Owner: Iain Lane 

* Package name: agda
  Version : 2.2.0
  Upstream Author : Ulf Norell 
* URL : http://wiki.portal.chalmers.se/agda/
* License : MIT/X11
  Programming Lang: Haskell
  Description : a dependently typed functional programming language and 
proof assistant

Agda is a dependently typed functional programming language: It has
inductive families, which are like Haskell's GADTs, but they can be
indexed by values and not just types. It also has parameterised
modules, mixfix operators, Unicode characters, and an interactive
Emacs interface (the type checker can assist in the development of
your code).
..
Agda is a proof assistant: It is an interactive system for writing
and checking proofs. Agda is based on intuitionistic type theory, a
foundational system for constructive mathematics developed by the
Swedish logician Per Martin-Lf. It has many similarities with other
proof assistants based on dependent types, such as Coq, Epigram and
NuPRL.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: i386 (i686)

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.




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

depending on obsolete packages

[jidanni]

One finds packages depending on obsolete packages, e.g.,
# aptitude -F %p search ?obsolete | xargs -n 1 echo aptitude why|sh -x
+ aptitude why libicu38
i   gimpDepends libwebkit-1.0-1 (>= 1.0.1)
i A libwebkit-1.0-1 Depends libicu38 (>= 3.8-5)
+ aptitude why libltdl3
i   php5-mcrypt Depends libltdl3 (>= 1.5.2-2)
+ aptitude why libvolume-id0
i   hal Depends libvolume-id0 (>= 0.113-1~)
+ aptitude why linux-image-2.6.26-1-686
i   linux-image-686 Depends linux-image-2.6.26-1-686
Bugs have been filed for all of them, but can't there be an automatic
check added to the system to stop or warn somebody?


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

Bug#522924: ITP: agda-stdlib -- standard library for Agda - a dependently typed functional programming language and proof assistant

[Iain Lane]

Package: wnpp
Severity: wishlist
Owner: Iain Lane 

* Package name: agda-stdlib
  Version : unreleased
  Upstream Author : Nils Anders Danielsson 
* URL : 
http://wiki.portal.chalmers.se/agda/agda.php?n=Libraries.StandardLibrary
* License : MIT/X
  Programming Lang: Agda
  Description : standard library for Agda - a dependently typed functional 
programming language and proof assistant

Agda is a dependently typed functional programming language: It has
inductive families, which are like Haskell's GADTs, but they can be
indexed by values and not just types. It also has parameterised
modules, mixfix operators, Unicode characters, and an interactive
Emacs interface (the type checker can assist in the development of
your code).
..
Agda is a proof assistant: It is an interactive system for writing
and checking proofs. Agda is based on intuitionistic type theory, a
foundational system for constructive mathematics developed by the
Swedish logician Per Martin-Lf. It has many similarities with other
proof assistants based on dependent types, such as Coq, Epigram and
NuPRL.
..
This package contains the standard library for Agda, which provides
some modules for common programming- and proof-structuring idioms.
Modules are included for algebra, category theory, coinduction, data
types, the foreign function interface, induction, IO, relations,
and sized types.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: i386 (i686)

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.




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

Bug#522921: ITP: haskell-ifelse -- Anaphoric and miscellaneous useful control-flow

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 


* Package name: haskell-ifelse
  Version : 0.85
  Upstream Author : Jeff R. Heard and Wren Thornton
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/IfElse
* License : BSD
  Programming Lang: Haskell
  Description : anaphoric and miscellaneous useful control-flow

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 This package provides control-flow functions to use with Monads.

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



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

Re: lilo about to be dropped?

[Giacomo A. Catenazzi]

Stephen Gran wrote:

This one time, at band camp, William Pitcock said:

The only way it is feasible to do so is to drop all of the Debian
patches. Without this, upstream is not cooperative with us.


Why is this?


I think because of William Pitcock with:
- his very strong words,
- his attitude: perfect or nothing (in design, in management, ...),
- his lack to listen upstreams and their needs: needs of other
  distributions, old compatibility needs, or simply time
  constrain and limited interest of upstream.

ciao nenolod ;-)

ciao
cate


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

Re: Writing symbols files for C++ libraries.

[Josselin Mouette]

Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit :
> I found nothing better than using a version script. I'm lucky that the
> library in question (WebKit) only really exports C symbols, and C++ is only
> internal details, so I'm filtering everything that starts with _Z, now.

BTW, for such simple things, you can let libtool create the version
script for you, using -export-symbols-regex.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: lilo about to be dropped?

[Mike Hommey]

On Mon, Apr 06, 2009 at 11:10:25PM +0200, Iustin Pop wrote:
> On Mon, Apr 06, 2009 at 11:42:42AM -0500, William Pitcock wrote:
> > On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote:
> > > On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:
> > > 
> > > ||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
> > >  wrote:
> > > 
> > > ||  > I use lilo, I like lilo.
> > > ||  > I don't like grub because it has unlogically config, unlogically
> > > ||  > behavior, strange reconfig-system. I don't like the programs with
> > > ||  > perverse intellect. Grub is not unixway.
> > > ||
> > > ||  Which is more perverse to read a kernel?
> > > ||  - reading actual files from actual filesystems
> > > ||  - reading hardcoded blocks on the device
> > > 
> > > I think this question should be:
> > > 
> > > Which is more perverse to read without a kernel?
> > > 
> > > The answer could still fall either way.
> > 
> > No, the answer is always the second one.
> 
> Err, why? I've seen grub failing more often, and heard way more report
> of this, than of lilo. Please explain why you say so.
> 
> The grub installer also used to read the blockdevice while the
> filesystem was mounted, which is never the right answer. It has always
> seemed hackish to me, duplicating fs functionality (and not always
> correctly, e.g. related to journal replaying on ext3/xfs).
> 
> A simple block list is just that.

Run update-initramfs -u without running lilo. Oh, you boot on the old
initramfs. Now remove the old initramfs and put some other files in
/boot. Then you're likely to not be able to boot at all. That sure is
better.

Mike


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

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 22:20 +0100, Stephen Gran wrote:
> This one time, at band camp, William Pitcock said:
> > The only way it is feasible to do so is to drop all of the Debian
> > patches. Without this, upstream is not cooperative with us.
> 
> Why is this?

See my other mail, basically, lilo upstream view is that our patches
"broke" it and that we have to fix it ourselves. I've seen him on
various threads saying basically that over the years.

But regardless, a lilo release has not been made in some time.

William


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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Petter Reinholdtsen]

[Michael Biebl]
> As (co-)maintainer of pm-utils and hal, I'd prefer if we could work
> towards standardizing on one power management stack in Debian (and
> not install 3 by default [1]), i.e. I'd support in phasing out
> acpi-support and would gladly accept patches for hal and pm-utils
> which add (if there are) any missing bits from acpi-support.

Perhaps hotkey-setup should be made obsolete too?  Is it still work
keeping?  http://packages.qa.debian.org/h/hotkey-setup.html >.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Mon, 06 Apr 2009 01:13:19 -0400
Filipus Klutiero  wrote:

> > > > > That would be a nice improvement, but let me suggest another 
> > > > > implementation. To avoid introducing a second diff, why not updating 
> > > > > the 
> > > > > regular diff (in the case of non-native packages) but indicating that 
> > > > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > > > simpler.

That also involves separate handling for native vs non-native packages.
The DEP does not require that - the +t1.diff.gz is used for native and
non-native. Any changes to the .diff.gz (or .tar.gz for native
packages) uploaded by the maintainer would require a source rebuild in
order to maintain the integrity of the archive - that is precisely what
the DEP is trying to avoid. You can't have a source package in a state
that says "this isn't the source we actually used to build the binary".
The source to build the .deb needs to be unchanged. The changes made to
generate the .tdeb need to sit alongside the existing source package
and have absolutely no effect on anything related to the binary
packages or the source package uploaded by the maintainer.

> > > > That breaks the existing source package in Debian - the .dsc referring
> > > > to that .diff.gz has been signed by the maintainer and any changes will
> > > > break that signature.
> >
> > > Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> > > I don't see why .dsc-s wouldn't include the tdiff's digest.
> >
> > There will be a complementary dsc using the +t1 version suffix.

> That can work, though I don't see what you were trying to say.

That there should be no update to the .dsc because the existing source
package must not be altered, therefore the second .dsc with the +t1
version suffix. In the case of a TDeb update during a release
freeze, the .dsc signed by the maintainer is already part of testing so
the TDeb upload to unstable must not change that .dsc. (Whether the
+t1.dsc is retained is a different issue - I suspect that we only
actually need to retain the +t1.diff.gz but as any .dsc is tiny, it
isn't a big issue either way.)

Note that many packages containing translatable content won't need a
+t1.diff.gz at all, if the current version in testing was made after
making a call for translations and waiting to receive updates before
the upload (subject to RC bug fixes requiring a change during the
freeze). The +t1.diff.gz is a way to introduce new translations and
translation updates for packages that could not be translated prior to
the maintainer upload of the original '+t0' TDeb which itself is
described in the source package uploaded by the maintainer.

Outside a release freeze, it will be up to debian-i18n to coordinate
TDeb uploads for each source package amongst the translation teams and
possibly with the maintainer to make arrangements such that translation
updates can be uploaded in a collective manner (typically using a
deadline of some sort) or as part of the next maintainer upload. Whilst
the DEP supports +t[0-9], it is envisaged that the need for +t2 and +t3
etc. should be rare.

> > Package management tools need a way to tell a .deb from a .tdeb - the
> > two need to be handled differently by tools like dak, britney, apt,
> > dpkg, reprepro, deb-gview and others.

> Do you mean that package management tools need a way to tell a 
> traditional/current .deb from a package containing what the DEP proposes 
> to put in a .tdeb? 

In a similar way to udebs. The .tdeb needs to be handled differently by
package management tools (things like reprepro and dak) so that uploads
of TDebs can be made by translation teams, so that the existing source
package is not affected, so that TDeb uploads can more easily be made
during a release freeze without causing problems for archive management
software and without needing the tools to look inside the TDeb or rely
solely on a version suffix. 

udebs have different requirements for migration into testing (specific
unblocks required with d-i approval), different locations under
pool/main/ and different handling by archive software compared to
standard .debs. TDebs have different requirements for migration into
testing (TDebs migrate even if the package itself is frozen, as long as
the version in testing matches that in unstable or the TDeb upload goes
via testing-proposed-updates etc.), different handling by archive tools
to retain the .diff.gz and the +t1.diff.gz and different upload
restrictions.

> If you're only talking about the tdeb format per se, 
> I don't understand your reasoning.

Other tools may need to support the locale roots in the .tdeb - these
changes will be easier if the tool can rely on these only existing in
a .tdeb instead of occurring in random .debs but not in others.

-- 


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



pgp3AHIXo2PQI.pgp
Description: PGP signature

Re: Writing symbols files for C++ libraries.

[Mike Hommey]

On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette  
wrote:
> Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit :
> > I found nothing better than using a version script. I'm lucky that the
> > library in question (WebKit) only really exports C symbols, and C++ is only
> > internal details, so I'm filtering everything that starts with _Z, now.
> 
> BTW, for such simple things, you can let libtool create the version
> script for you, using -export-symbols-regex.

The problem with libtool's option is that it is inclusive, i.e. what
you give it will be exported, not hidden, which is sometimes much easier
to handle.

Mike


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

D-I not using grub (was: lilo about to be dropped?)

[Frans Pop]

Let's move this subthread back to d-boot. Reply-to set.
Please let us know if you'd like to be CCed.

Martin Wuertele wrote:
> * Frans Pop  [2009-04-07 02:54]:
> 
>> Martin Wuertele wrote:
>> > Actually lilo is installed by lenny d-i if you use root-sw-raid with
>> > LVM, even if your /boot is an differen partition/sw-raid. Therefore
>> > lilo should at least remain for sqeeze to ensure a proper upgrade
>> > path. 
>> 
>> I'm afraid you're mistaken here. Lenny D-I should (and AFAIK does)
>> default to grub for that setup.
>> 
>> /boot on normal partition or RAID1 + / on whatever combination of
>> RAID+LVM is supported fine by grub. Unless there is some other factor
>> that you've not mentioned D-I does not fall back to lilo for that.
> 
> I wonder what it could be. I don't user XFS just plain ext3 and had to
> manually install grub for 2 recent setups. One is an IBM X3560 with
> harware-raid, /boot on one partitione, rest for lvm, the other is an
> X3220 with /boot on md0 and lvm on md1. For both D-I installed lilo.

Next time you get in that situation, please add a 'set -x' in
   /var/lib/dpkg/info/grub-installer.isinstallable
and then run it from one of the debug shells.

That should tell you why D-I skips grub and falls back to lilo.

Cheers,
FJP


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

Re: lilo about to be dropped?

[Felipe Sateler]

Harald Braumann wrote:

> * configuration of grub2 is really a PITA
> 
> You can't specify boot options per entry (there's only a global option
> in /etc/default grub, that applies to all entries).

You may want to check bug 470398. The patch is probably outdated by now, though.
Requiring bug/patch submitters to suscribe to a relatively active list is
definitely the wrong thing to do, which is why the patch didn't make it
upstream (and the maintainer, who is active upstream too, doesn't seem to care
to do it himself).

-- 

  Felipe Sateler


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

Re: lilo about to be dropped?

[Tollef Fog Heen]

]] William Pitcock 

| Have you looked into ext2linux? It is intended to supercede lilo. I
| think your usage requirements will be satisfied by it.

It does not appear to exist in Debian?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Russ Allbery wrote:
> Charles Plessy  writes:
> > so in the end, can we use the “ * QA upload.” special first line for
> > non-uploader uploads without breaking the QA infrastructure?
> 
> No, that is reserved for orphaned packages and triggers other checks to
> ensure the maintainer is set appropriately.
> 
> I think the conversation hasn't reached a conclusion yet about the right
> way to do this, but I doubt it would be reusing the key phrase for
> orphaned package uploads.

The simplest solution would be to use " * Team upload" as a new key
phrase to mark such packages.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#522934: ITP: python-whoosh -- pure-Python full text indexing, search, and spell checking library

[Daniel Watkins]

Package: wnpp
Severity: wishlist
Owner: Daniel Watkins 

* Package name: python-whoosh
  Version : 0.1.13
  Upstream Author : Matt Chaput 
* URL : http://whoosh.ca
* License : Apache
  Programming Lang: Python
  Description : pure-Python full-text indexing, search, and spell checking 
library

Whoosh is a fast, pure-Python indexing and search library. Programmers
can use it to easily add search functionality to their applications and
websites. As Whoosh is pure Python, you don't have to compile or
install a binary support library and/or make Python work with a JVM, yet
indexing and searching is still very fast. Whoosh is designed to be
modular, so every part can be extended or replaced to meet your needs
exactly.



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

tdiff (DEP-4: The TDeb specification.)

[Filipus Klutiero]

Neil Williams wrote:

On Mon, 06 Apr 2009 01:13:19 -0400
Filipus Klutiero  wrote:

> > > > > That would be a nice improvement, but let me suggest another 
> > > > > implementation. To avoid introducing a second diff, why not updating the 
> > > > > regular diff (in the case of non-native packages) but indicating that 
> > > > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > > > simpler.


That also involves separate handling for native vs non-native packages.
The DEP does not require that - the +t1.diff.gz is used for native and
non-native. Any changes to the .diff.gz (or .tar.gz for native
packages) uploaded by the maintainer would require a source rebuild in
order to maintain the integrity of the archive - that is precisely what
the DEP is trying to avoid. You can't have a source package in a state
that says "this isn't the source we actually used to build the binary".
The source to build the .deb needs to be unchanged.
Yes, but the source package contains more than the source used to build 
the "traditional" binary packages. It also contains (potentially) source 
for translation debs. As long as the only source changed is the source 
for the translation debs, the "traditional" binary packages don't need 
to be rebuilt.

The changes made to
generate the .tdeb need to sit alongside the existing source package
and have absolutely no effect on anything related to the binary
packages or the source package uploaded by the maintainer.
  
Per what I wrote above, I don't see anything preventing the source 
changes for translation debs to be integrated in the traditional diff 
(again, in the case of non-native packages).

> > > > That breaks the existing source package in Debian - the .dsc referring
> > > > to that .diff.gz has been signed by the maintainer and any changes will
> > > > break that signature.
> >
> > > Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> > > I don't see why .dsc-s wouldn't include the tdiff's digest.

> >
> > There will be a complementary dsc using the +t1 version suffix.

> That can work, though I don't see what you were trying to say.

That there should be no update to the .dsc because the existing source
package must not be altered, therefore the second .dsc with the +t1
version suffix. In the case of a TDeb update during a release
freeze, the .dsc signed by the maintainer is already part of testing so
the TDeb upload to unstable must not change that .dsc.
I don't see a problem preventing the traditional .dsc to be changed. 
Changing the .dsc does not imply that the existing source package must 
be altered. The .dsc could be updated in testing.

(Whether the
+t1.dsc is retained is a different issue - I suspect that we only
actually need to retain the +t1.diff.gz but as any .dsc is tiny, it
isn't a big issue either way.)

I think it should be retained; small issue, indeed.


To sum up, I still don't see anything that imposes introducing a tdiff, 
even to avoid rebuilding the traditional binary packages. But, I'm 
starting to see tdiff is probably a good idea anyway for security reasons.



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

.tdeb format (DEP-4: The TDeb specification.)

[Filipus Klutiero]

> > Package management tools need a way to tell a .deb from a .tdeb - the
> > two need to be handled differently by tools like dak, britney, apt,
> > dpkg, reprepro, deb-gview and others.

> Do you mean that package management tools need a way to tell a 
> traditional/current .deb from a package containing what the DEP proposes 
> to put in a .tdeb? 


In a similar way to udebs. The .tdeb needs to be handled differently by
package management tools (things like reprepro and dak) so that uploads
of TDebs can be made by translation teams, so that the existing source
package is not affected, so that TDeb uploads can more easily be made
during a release freeze without causing problems for archive management
software and without needing the tools to look inside the TDeb or rely
solely on a version suffix.
  
Yes. I think a translation package could simply be identified by a 
control field.

Say
Translates: foo
or, if Translates would only list the source package,
Translation: Yes
> If you're only talking about the tdeb format per se, 
> I don't understand your reasoning.


Other tools may need to support the locale roots in the .tdeb - these
changes will be easier if the tool can rely on these only existing in
a .tdeb instead of occurring in random .debs but not in others.
  
But these locale roots would only exist in .tdeb-s. In .deb-s, there 
wouldn't be such locale roots. If we're wondering whether we should 
introduce a .tdeb format, we shouldn't reason that that there will be a 
need for .tdeb if .tdeb is introduced.



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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Manoj Srivastava]

On Sat, Apr 04 2009, Noah Slater wrote:

> On Sat, Apr 04, 2009 at 01:35:17PM -0600, Raphael Geissert wrote:
>> opts=handler=svn http://domain.tld/svn/foo/...>
>> would do the right thing.
>
> What about uscan being able to use custom make targets in debian/rules?
>
> There could be a way to tell uscan to use the following:
>
>   debian/rules get-orig-source
>
>   debian/rules check-version
>
> This allows developers the flexibility to handle any situation, and
> doesn't bloat uscan by having to add all kinds of fancy handlers for
> different version control systems.
>
> As a concrete benefit, my nightly cron to check uscan for all my
> packages will be able to alert me about the ones pulled from
> repository revisions, all I would need to do is add a new
> "check-version" target.

Why bloat debian/rules? ALl this can be done using the current
 mechanism of just adding a script into the watchfile, and does not tie
 down uscan to the debian checked out source.

manoj
-- 
Each person has the right to take the subway.
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

Re: Forthcoming changes in kernel-package

[Manoj Srivastava]

On Thu, Feb 26 2009, Theodore Tso wrote:

> On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote:
>> > BTW, I have a set of patches you might want to consider.  I'll file
>> > them in BTS if you're currently making make-kpkg.
>> 
>> Please. I have been thinking about the request you made for
>>  debugging symbols being packaged, and now I do have some time to play
>>  with building kernels again, I would like to see that in Squeeze.
>
> Sorry for the delay; I've sent you the private patches I've been using
> for make-kpkg.  Some of them are quite hackish, and some of they you
> may have fixed in other ways, so I won't feel bad at all if you need
> to significantly rework them before you can merge them into your
> master sources.

Most of these bugs had been fixed, and all but one have been
 fixed by last night's upload into experimental. The only one remaining
 is the one about creating a new debuginfo package; I am torn between
 letting the debuginfo remain with the image package, but move the debug
 infromation from /lib/modules into /usr/ or /var; and to creating a
 whole new package just for the debugging information.

manoj
-- 
The Gordian Maxim: If a string has one end, it has another.
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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Manoj Srivastava]

On Thu, Apr 02 2009, Noah Slater wrote:

> On Fri, Apr 03, 2009 at 10:50:11AM +1100, Ben Finney wrote:
>> That's the trouble though. AIUI, different VCSen have different ways
>> of identifying a specific state of the working tree; we have not only
>> revisions, but also tags, branches, threads, heads, and probably
>> others I've forgotten. Should all of those be allowed? Is that too
>> complex an interface?
>>
>> As for “latest”: is there an unambiguous “latest” for every
>> repository? What does this mean with repositories that have
>> simultaneous lines of history within the same location?
>
> Okay, but for the purposes of this file we only need two actions, right? Is 
> the
> current version the latest one we're interested in, and how can we fetch the
> upstream source for the current version. If we let these two actions be 
> scripted
> through a standard interface, it should work with any repository.


If the current version is what we are interested, why not get it
 from the canonical site, the Debian archive?

I am not seeing the sue case for not getting the sources
 distributed by Debian from Debian. People who do not trust the Debian
 archive, ought not to trust the Debian script, and go get the upstream
 using a trusted download agent on their own; so security is not the use
 case.

By far the most common use case I can see is to get the latest
 upstream, and do whatver munging needs to be done to make it acceptable
 for Debian as a source archive.

What am I missing?

manoj
-- 
Moore's Constant: Everybody sets out to do something, and everybody does
something, but no one does what he sets out to do.
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

Re: Improvements to ‘debian/watch’for fetching f rom VCS

[Paul Wise]

On Tue, Apr 7, 2009 at 11:06 PM, Manoj Srivastava wrote:

>        What am I missing?

One case I can think of; it is (possibly) common for sponsors to check
that the result from get-orig-source matches the contents of the
tarball uploaded to mentors by the sponsee.

-- 
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: Forthcoming changes in kernel-package

[Manoj Srivastava]

Hi,

A few hours ago, a new version of kernel-package was uploaded to
 Experimental.  This is a major change, the new kernel-package is far
 more nimble, more flexible, and supports people who make a minor change
 to a kernel, or who update the kernel sources (via git or otherwise),
 and want a minimal, simple, recompile. 

 79 files changed, 1776 insertions(+), 3706 deletions(-)

The full NEWS.Debian file is appended below, but I'll highlight
 the major differences: This version does not support the official
 images (which is OK, since the kernel  team thinks kernel-package is
 broken anyway, and have been deprecating it for a few years now), it
 does not run a bootloader, or manage symlinks, or create an init ram fs
 for you -- since the policies governing these actions were becoming too
 rigid, and had to cater to the lowest common denominator.

Instead, the package comes with example scripts that can be
 dropped into /etc/kernel/*.d directories to do all that, and more (you
 can change the number of symlinks you keep,  for example). Now you can
 add actions to {pre,post}{inst,rm} stages of the package installation or
 removal, independently, for image, header, source, and doc packages.

More importantly, the initramfs scripts provided work with the
 make-kpkg images as well as the official images, and are thus better
 than the script shipped with initramfs-tools themselves, as they offer
 a super set of functionality.

This version of kernel-package also demonstrates how the
 postsinst script communicates with the initramfs scripts so that no
 initramfs is generated in case you do not want it (I personally compile
 all modules in my non-laptop kernel, and thus do not need an
 initramfs).

I have not yet seeded the  env with the maintainer script
 parameter arguments, but I'll put in what Frans suggested unless there
 are objections.

Please take this for a spin. Kick the tires. I need helpe from
 people who run Xen machines, since  I do not use Xen, and would like to
 make the Xen images work better.

manoj

kernel-package (12.001) experimental; urgency=low

  * This is a major change in functionality; do not upgrade unless you are
prepared for the changes required on target machines.
  * make-kpkg removes and re-creates ./debian on every invocation

This does make the kernel-package far more nimble; we now offer less
surprise to users who did not expect stampts that the kernel-packagge
used to not do duplicate work. Now, if you edit a couple of files in
the kernel source, and run make-kpkg, the kernel will build as
expected. There are no more "version mismatch" errors, and the kernel
version can be modified using localconfig as one desires. With this,
kernel-package can rountinely be used to build kernels out of the git
tree.

The con is that we no longer cater to official kernels, or to anyone who
expected content in ./debian to persist. At some point, there are plans
to implement an overlay directory that will shadow
/usr/share/kernel-package/ruleset, but that is not yet implemented.
  * Get rid of the facility to patch kernel sources

The patch the kernel facility was adding complexity, and failing to
provide the flexibility required for a generic patching facility. It used
to be useful at one point, but in the modern parlance, witht he
widespread use of distribute version control systems, and various
facilities to manage source and patch them, the built in version was
clunky.  This means the --added-patches option of make-kpkg is gone,
the work-around is to prepare the kernel sources _before_ calling
make-kpkg. 
  * Remove special case code for official kernels

For the longest tine (well, ever since Herbert Xu too over building
kernel images from me), kernel-package has carried specal case code
for official images. This has caused some problems, recently, since
the need to preserve ./debian has caused no end of problems when the
version changed out from under ./debian, or when people wanted to edit
a file and expected kernel-package to do a minimal recompile.

However, sometime in the Etch release cycle, the kernel team
deprecated kernel-package as the means of building official kernels,
and therefore, a full release cycle later, we can get rid of the
special case rules used for official packages. Also, this allows us to
drop ./debian at teh drop of a hart, and recreate it with an version
that reflects the current state of the kernel sources.
  * No longer ship header debs that create symbolic links in /usr/src,
instead, ship an example shell script that replicated the old
behaviour. This script can then be deployed on the target machines,
and could be a part of a locally created kernel configuration package,
if one needs to deploy the same behavior across a cluster of
machines. 
  * 

Re: Improvements to ‘debian /watch’ for fetching from VCS

[Noah Slater]

On Tue, Apr 07, 2009 at 10:00:05AM -0500, Manoj Srivastava wrote:
> On Sat, Apr 04 2009, Noah Slater wrote:
> > As a concrete benefit, my nightly cron to check uscan for all my
> > packages will be able to alert me about the ones pulled from
> > repository revisions, all I would need to do is add a new
> > "check-version" target.
>
> Why bloat debian/rules? ALl this can be done using the current
>  mechanism of just adding a script into the watchfile, and does not tie
>  down uscan to the debian checked out source.

Because this bloats the uscan implementation.

GNU Make already lets us add these rules, and the only real difference,
presuming that the rules would be of the same length no matter where you put
them, is the file they are located in.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: lilo about to be dropped?

[Otavio Salvador]

On Mon, Apr 6, 2009 at 9:21 PM, William Pitcock
 wrote:
> Lilo upstream is dead (no release in quite a while), but the lilo
> maintainer has also been seen as saying in various mailing lists etc,
> that since Debian patches lilo that he has no interest in helping to fix
> problems in our version.

Ok but you could try to push those patches upstream. This is how
grub has been improved and also parted. This works most of time.

This way we "reduce" the amount of patches we keep in Debian
and also you could try to get in touch with other distros to share
the load and avoid reworking at same things.

-- 
Otavio Salvador  O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br


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

Re: Improvements to ‘debian /watch’ for fetching from VCS

[Noah Slater]

On Tue, Apr 07, 2009 at 10:06:18AM -0500, Manoj Srivastava wrote:
> If the current version is what we are interested, why not get it
>  from the canonical site, the Debian archive?

I am a new maintainer, and I have sponsors for various packages.

People can check out the source code, and run:

  debian/rules get-orig-source

This works for all my packages, and is very handy for other people.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: .tdeb format (DEP-4: The TDeb specification.)

[Neil Williams]

On Tue, 07 Apr 2009 10:23:37 -0400
Filipus Klutiero  wrote:

> > In a similar way to udebs. The .tdeb needs to be handled differently by
> > package management tools (things like reprepro and dak) so that uploads
> > of TDebs can be made by translation teams, so that the existing source
> > package is not affected, so that TDeb uploads can more easily be made
> > during a release freeze without causing problems for archive management
> > software and without needing the tools to look inside the TDeb or rely
> > solely on a version suffix.
> >   
> Yes. I think a translation package could simply be identified by a 
> control field.

Then every file-based operation has to query the contents of the file
to know how to handle it. TDebs are sufficiently different internally
that other tools can handle them more easily if the filename is clearly
indicative.

This is more important where there are lots of TDebs, so that is how
.tdeb came into the Specification. In Emdebian, a package can have
dozens of .tdeb files, obscuring the .deb files in a simple directory
listing. With the modifications for Debian TDebs after DebConf and the
resulting single TDeb per source package, this is not a problem for
archive listings but it could still be a problem for other tools.

> Say
> Translates: foo
> or, if Translates would only list the source package,
> Translation: Yes

I'm working on the patches for dpkg at the moment, I'm extending
Thomas' code to support 'dpkg -c' etc. and it is looking like a field
in DEBIAN/control will be necessary. I'm looking at putting a Languages:
field inside DEBIAN/control that lists the locale roots supported by
that TDeb. (The name of the field isn't material, Locale-roots: is more
accurate than Languages: but not as suitable IMHO.) This field will
be generated by dpkg-deb --tdeb -b so that it is always up to date.
However, if I find a better way of obtaining the data that can be
gleaned from using: `ar -t` with relevant parsing, then there will be no
need for the field, at least on the part of dpkg.

There is also a Package-Type: tdeb field which is used by
dpkg-genchanges in the same way as Package-Type: udeb is done currently.

I don't see that either of those predicate against a .tdeb extension
when .udeb exists for the same reasons.

> > > If you're only talking about the tdeb format per se, 
> > > I don't understand your reasoning.
> >
> > Other tools may need to support the locale roots in the .tdeb - these
> > changes will be easier if the tool can rely on these only existing in
> > a .tdeb instead of occurring in random .debs but not in others.
> >   
> But these locale roots would only exist in .tdeb-s. In .deb-s, there 
> wouldn't be such locale roots. If we're wondering whether we should 
> introduce a .tdeb format, we shouldn't reason that that there will be a 
> need for .tdeb if .tdeb is introduced.

Having .tdeb makes it simpler to handle TDebs on a variety of fronts
but I really don't think that a control field is comparable in terms of
functionality.

We have .udeb, .tdeb is sufficiently clear and aids the handling
of .tdeb by other packages - why restrict every operation to having to
inspect the DEBIAN/control file every time? `dpkg -f $file Languages`
is going to get tiresome every time, not to mention slow. (Package-Type
is just a different string for the same thing, except that will require
additional parsing for tdeb vs udeb.)

-- 


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



pgpyIJpOI03ny.pgp
Description: PGP signature

Re: "Team uploads"

[Russ Allbery]

Raphael Hertzog  writes:
> On Mon, 06 Apr 2009, Russ Allbery wrote:
>> Charles Plessy  writes:

>>> so in the end, can we use the “ * QA upload.” special first line for
>>> non-uploader uploads without breaking the QA infrastructure?

>> No, that is reserved for orphaned packages and triggers other checks to
>> ensure the maintainer is set appropriately.

>> I think the conversation hasn't reached a conclusion yet about the
>> right way to do this, but I doubt it would be reusing the key phrase
>> for orphaned package uploads.

> The simplest solution would be to use " * Team upload" as a new key
> phrase to mark such packages.

Can anyone think of any drawbacks to that?  (We really need a document
somewhere listing all these key phrases -- I wonder if that would be
appropriate for Policy given how much software now cares.)

-- 
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: tdiff (DEP-4: The TDeb specification.)

[Neil Williams]

On Tue, 07 Apr 2009 09:57:30 -0400
Filipus Klutiero  wrote:

(Could you add a blank line between the quoted reply and your content?
It makes the content easier for me to read. Thanks.)

> Neil Williams wrote:
> > On Mon, 06 Apr 2009 01:13:19 -0400
> > Filipus Klutiero  wrote:
> >
> > > > > > > That would be a nice improvement, but let me suggest another 
> > > > > > > implementation. To avoid introducing a second diff, why not 
> > > > > > > updating the 
> > > > > > > regular diff (in the case of non-native packages) but indicating 
> > > > > > > that 
> > > > > > > the package shouldn't be entirely rebuilt when uploading? This 
> > > > > > > seems 
> > > > > > > simpler.
> >
> > That also involves separate handling for native vs non-native packages.
> > The DEP does not require that - the +t1.diff.gz is used for native and
> > non-native. Any changes to the .diff.gz (or .tar.gz for native
> > packages) uploaded by the maintainer would require a source rebuild in
> > order to maintain the integrity of the archive - that is precisely what
> > the DEP is trying to avoid. You can't have a source package in a state
> > that says "this isn't the source we actually used to build the binary".
> > The source to build the .deb needs to be unchanged.
>
> Yes, but the source package contains more than the source used to build 
> the "traditional" binary packages. It also contains (potentially) source 
> for translation debs. As long as the only source changed is the source 
> for the translation debs, the "traditional" binary packages don't need 
> to be rebuilt.

But the source package would still be the wrong source for the binaries
that exist. The archive needs to contain the unique source package for
the binaries that exist, modifying the source without modifying the
binaries is not an option for legal reasons, as I understand it.

> > The changes made to
> > generate the .tdeb need to sit alongside the existing source package
> > and have absolutely no effect on anything related to the binary
> > packages or the source package uploaded by the maintainer.
>
> Per what I wrote above, I don't see anything preventing the source 
> changes for translation debs to be integrated in the traditional diff 
> (again, in the case of non-native packages).

Why treat the two differently? Whether the package is native or
non-native makes no difference to how the TDeb is generated or handled.
It has a bearing on which packages will be handled at which stage of
the transition to TDebs but nothing beyond that.

> > > > > > That breaks the existing source package in Debian - the .dsc 
> > > > > > referring
> > > > > > to that .diff.gz has been signed by the maintainer and any changes 
> > > > > > will
> > > > > > break that signature.
> > > >
> > > > > Right - unless the .dsc is also updated. And if there is to be a 
> > > > > tdiff, 
> > > > > I don't see why .dsc-s wouldn't include the tdiff's digest.
> > > >
> > > > There will be a complementary dsc using the +t1 version suffix.
> >
> > > That can work, though I don't see what you were trying to say.
> >
> > That there should be no update to the .dsc because the existing source
> > package must not be altered, therefore the second .dsc with the +t1
> > version suffix. In the case of a TDeb update during a release
> > freeze, the .dsc signed by the maintainer is already part of testing so
> > the TDeb upload to unstable must not change that .dsc.
>
> I don't see a problem preventing the traditional .dsc to be changed. 
> Changing the .dsc does not imply that the existing source package must 
> be altered. The .dsc could be updated in testing.

If the .dsc is modified, the source package no longer matches the
binaries that are in the archive that were built from the old .dsc.

Just who/what is supposed to modify the existing .dsc anyway? The
archive software? TDebs are not necessarily built from an unpacked
source directory, they can be built by tools working just from the POT
file and PO contributions.

Yes, the +t0 TDeb, the one created by the maintainer, will have the
normal source and the normal tools, there is nothing to say that +t1
would have the unpacked source available necessarily. Translators will
often have the source in order to test the translation but the final
+t1 TDeb will collate the contributions of several translators and
several translation teams, via several sources. The +t1.dsc is likely
to need to be signed but merging that with the existing .dsc could give
the utterly misleading impression that the nominated l10n person doing
the upload is somehow responsible for the binary packages that have
not been touched but are affected by the change to the .dsc.

This is another area where TDebs are quite different to normal .deb -
there is nothing to say that dpkg-buildpackage has to be involved, none
of the standard Debian build tools need exist other than dpkg itself
(not even dpkg-dev, although that would be unusual).

> > (Whether the
> > +t1.dsc is retained 

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Steve Langasek]

On Tue, Apr 07, 2009 at 01:26:18PM +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work
> > towards standardizing on one power management stack in Debian (and
> > not install 3 by default [1]), i.e. I'd support in phasing out
> > acpi-support and would gladly accept patches for hal and pm-utils
> > which add (if there are) any missing bits from acpi-support.

> Perhaps hotkey-setup should be made obsolete too?  Is it still work
> keeping?  http://packages.qa.debian.org/h/hotkey-setup.html >.

That is also being phased out in Ubuntu.  The only remaining functionality
in that package for jaunty is setting /proc/acpi/video/*/DOS; we need to
either confirm that this is handled somewhere else or determine an
appropriate package to set this by default before dropping hotkey-setup.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: lilo about to be dropped?

[William Pitcock]

On Tue, 2009-04-07 at 10:52 +0200, Giacomo A. Catenazzi wrote:
> Stephen Gran wrote:
> > This one time, at band camp, William Pitcock said:
> >> The only way it is feasible to do so is to drop all of the Debian
> >> patches. Without this, upstream is not cooperative with us.
> > 
> > Why is this?
>
> I think because of William Pitcock with:
> - his very strong words,
> - his attitude: perfect or nothing (in design, in management, ...),
> - his lack to listen upstreams and their needs: needs of other
>distributions, old compatibility needs, or simply time
>constrain and limited interest of upstream.
> 
> ciao nenolod ;-)

Actually, the damage was done years ago, long before I ever maintained
lilo. But thanks for the flame.

William


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

Re: lilo about to be dropped?

[William Pitcock]

On Tue, 2009-04-07 at 13:06 -0300, Otavio Salvador wrote:
> On Mon, Apr 6, 2009 at 9:21 PM, William Pitcock
>  wrote:
> > Lilo upstream is dead (no release in quite a while), but the lilo
> > maintainer has also been seen as saying in various mailing lists etc,
> > that since Debian patches lilo that he has no interest in helping to fix
> > problems in our version.
> 
> Ok but you could try to push those patches upstream. This is how
> grub has been improved and also parted. This works most of time.
> 
> This way we "reduce" the amount of patches we keep in Debian
> and also you could try to get in touch with other distros to share
> the load and avoid reworking at same things.

lilo is officially unmaintained now. The canonical website of lilo now
points to a 404 error page, see http://lilo.go.dyndns.org/ .

So at this point, our only option seems to be taking over upstream lilo
maintainance ourselves (which could be a good thing in some ways, I am
not denying that), or find a way to transition these use-cases to
grub/grub2/extlinux.

However, if we are to maintain lilo ourselves, then we need to flesh out
exactly what usecases we're going to be using it for. 

I recommend if we go that route that we come up with a list of
improvements that we want to see and get to hacking. If some of the
people who like lilo a lot got around to helping with a fork, we could
create a much less buggy bootloader than the current lilo.

Alternatively, we can just leave it and let it become another XMMS. I
don't like this solution very much.

William


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

Re: lilo about to be dropped?

[Cyril Brulebois]

William Pitcock  (07/04/2009):
> Alternatively, we can just leave it and let it become another XMMS. I
> don't like this solution very much.

Beware, gtk3 is coming, so you'd better update lilo to no longer depend
on gtk2!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 



* Package name: jruby1.2
  Version : 1.2.0
  Upstream Author : The JRuby Team
* URL : http://jruby.codehaus.org/
* License : tri-license CPL/GPL/LGPL
  Programming Lang: Java
  Description : 100% pure-Java implementation of Ruby

JRuby is tightly integrated with Java to allow the embedding of the
interpreter into any Java application with full two-way access between
the Java and the Ruby code.

-- System Information:
Debian Release: 5.0
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable'), (500, 'stable'), 
(1, 'unstable')
Architecture: i386 (i686)



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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Mike Hommey]

On Tue, Apr 07, 2009 at 12:09:56PM -0700, Sebastien Delafond wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sebastien Delafond 
> 
> 
> 
> * Package name: jruby1.2
>   Version : 1.2.0
>   Upstream Author : The JRuby Team
> * URL : http://jruby.codehaus.org/
> * License : tri-license CPL/GPL/LGPL
>   Programming Lang: Java
>   Description : 100% pure-Java implementation of Ruby
> 
> JRuby is tightly integrated with Java to allow the embedding of the
> interpreter into any Java application with full two-way access between
> the Java and the Ruby code.

Why do we need jruby1.0, jruby1.1 and now jruby1.2 ?

Mike


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Gunnar Wolf]

Giacomo A. Catenazzi dijo [Tue, Apr 07, 2009 at 11:05:35AM +0200]:
> In Debian policy:
> : The init.d scripts must ensure that they will behave sensibly
> : (i.e., returning success and not starting multiple copies of a
> : service) if invoked with start when the service is already running,
> : or with stop when it isn't, and that they don't kill
> : unfortunately-named user processes.
> 
> this case is not cited in the examples, but I really think
> that *behave sensibly* cover also thiscase , i.e. after a crash a
> daemon should start, also if .pid exists.

Strong +1. This is, however, unrelated to whatever happened at boot -
If the daemon crashed during regular system usage and it is started
again, it should start regardless if there are any pidfiles lying around.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Bug#522984: ITP: magics++ -- Meteorological plotting software

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: magics++
  Version : 2.6.4
  Upstream Author : ECMWF 
* URL : http://www.ecmwf.int/products/data/software/magics++.html
* License : Apache license, version 2.
  Programming Lang: C, Fortran
  Description : Meteorological plotting software
 Magics++ is the latest generation of the ECMWF's Meteorological plotting
 software MAGICS. Although completely redesigned in C++, it is intended to be
 as backwards-compatible as possible with the Fortran interface.
 Besides its programming interfaces (Fortran and C), Magics++ offers MagML,
 a plot description language based on XML aimed at automatic web production.
 .
 The library supports the plotting of contours, wind fields, observations,
 satellite images, symbols, text, axis and graphs (including boxplots).
 .
 Data fields to be plotted may be presented in various formats,
 for instance GRIB 1 and 2 code data, Gaussian grid, regularly spaced grid
 and fitted data. Input data can also be in BUFR and NetCDF format
 or retrieved from an ODB database.
 .
 The produced meteorological plots can be saved in various formats,
 such as PostScript, EPS, PDF, GIF, PNG, SVG and KML.



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

Re: lilo about to be dropped?

[Iustin Pop]

On Tue, Apr 07, 2009 at 07:36:40AM +0200, Mike Hommey wrote:
> On Mon, Apr 06, 2009 at 11:10:25PM +0200, Iustin Pop wrote:
> > On Mon, Apr 06, 2009 at 11:42:42AM -0500, William Pitcock wrote:
> > > On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote:
> > > > On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:
> > > > 
> > > > ||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
> > > >  wrote:
> > > > 
> > > > ||  > I use lilo, I like lilo.
> > > > ||  > I don't like grub because it has unlogically config, unlogically
> > > > ||  > behavior, strange reconfig-system. I don't like the programs with
> > > > ||  > perverse intellect. Grub is not unixway.
> > > > ||
> > > > ||  Which is more perverse to read a kernel?
> > > > ||  - reading actual files from actual filesystems
> > > > ||  - reading hardcoded blocks on the device
> > > > 
> > > > I think this question should be:
> > > > 
> > > > Which is more perverse to read without a kernel?
> > > > 
> > > > The answer could still fall either way.
> > > 
> > > No, the answer is always the second one.
> > 
> > Err, why? I've seen grub failing more often, and heard way more report
> > of this, than of lilo. Please explain why you say so.
> > 
> > The grub installer also used to read the blockdevice while the
> > filesystem was mounted, which is never the right answer. It has always
> > seemed hackish to me, duplicating fs functionality (and not always
> > correctly, e.g. related to journal replaying on ext3/xfs).
> > 
> > A simple block list is just that.
> 
> Run update-initramfs -u without running lilo. Oh, you boot on the old
> initramfs. Now remove the old initramfs and put some other files in
> /boot. Then you're likely to not be able to boot at all. That sure is
> better.

Are you complaining that lilo allows one to shot oneself in the foot?
Because that how it looks like.

My point is that in controlled environments, lilo looks to be more
stable. Not for desktop usage, not for update-iniramfs usage without
knowing what needs to be done.

Again, my point is (like the grand-grand-parent), that the answer
differs by application. grubs is not always better.

regards,
iustin


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Sebastien Delafond]

On Apr/07, Mike Hommey wrote:
> Why do we need jruby1.0, jruby1.1 and now jruby1.2 ?

so multiple versions of jruby can be simultaneously installed on a
system, like with python2.x, ruby1.x, etc ?

Cheers,

--Seb


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Adeodato Simó]

+ Sebastien Delafond (Tue, 07 Apr 2009 13:08:17 -0700):

> On Apr/07, Mike Hommey wrote:
> > Why do we need jruby1.0, jruby1.1 and now jruby1.2 ?

> so multiple versions of jruby can be simultaneously installed on a
> system, like with python2.x, ruby1.x, etc ?

The question was, rather: why would a user want to install jruby1.0 or
jruby1.1 instead of jruby1.2? What purpose does it serve having three
different versions in the archive instead of one, or two at most?

Thanks,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Mike Hommey]

On Tue, Apr 07, 2009 at 01:08:17PM -0700, Sebastien Delafond wrote:
> On Apr/07, Mike Hommey wrote:
> > Why do we need jruby1.0, jruby1.1 and now jruby1.2 ?
> 
> so multiple versions of jruby can be simultaneously installed on a
> system, like with python2.x, ruby1.x, etc ?

While I see why it can be needed for python, I fail to see how it is
important for jruby...

Mike


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Sebastien Delafond]

On Apr/07, Adeodato Simó wrote:
> The question was, rather: why would a user want to install jruby1.0 or
> jruby1.1 instead of jruby1.2? What purpose does it serve having three
> different versions in the archive instead of one, or two at most?

jruby1.0 will indeed be removed shortly from the archive, so we can move
forward without accumulating too many versions of jruby.

Cheers,

--Seb


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Mike Hommey]

On Tue, Apr 07, 2009 at 01:40:54PM -0700, Sebastien Delafond wrote:
> On Apr/07, Adeodato Simó wrote:
> > The question was, rather: why would a user want to install jruby1.0 or
> > jruby1.1 instead of jruby1.2? What purpose does it serve having three
> > different versions in the archive instead of one, or two at most?
> 
> jruby1.0 will indeed be removed shortly from the archive, so we can move
> forward without accumulating too many versions of jruby.

But why a need for two versions at a time ? AFAICS, jruby 1.2 supports
both ruby 1.8 *and* 1.9, as jruby 1.1 does, so why would jruby 1.1 still
be needed ?

Mike


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Sebastien Delafond]

On Apr/07, Mike Hommey wrote:
> While I see why it can be needed for python, I fail to see how it is
> important for jruby...

to have 2 versions of jruby available ? I guess so you can at least, for
instance, try the new one on your existing jruby code without removing
the old one, for instance ?

Are you advocating for only one instance of jruby at all times in the
archive ? If so, why ?

Cheers,

--Seb


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

Re: lilo about to be dropped?

[Harald Braumann]

On Mon, 06 Apr 2009 10:24:54 -0500
William Pitcock  wrote:

> On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
> > Yes, I do and it works without problems. There are some
> > inconveniences, though, with grub2, which might make some stick
> > with LILO:
> 
> The LVM support in LILO is hideously broken, so these arguments do not
> really matter. 
Works for me.

> It only works in certain conditions and is known to
> break horribly if you have say, a kernel spanning multiple PVs.
> 
> Only a true idiot boots off an LVM volume anyway, 
You're too nice. Anyway, boot is the least important partition. Any
live CD or USB installation will do to recover.

> since there is risk of metadata corruption, etc. 
What metadata are you talking about, and what's it got to do with the
boot partition?

> > The is no simple configuration file that one could edit. You have to
> > write scripts to add entries.
> 
> /boot/grub/{menu.lst,grub.conf} is hard to edit...?
No, but since grub2 doesn't use those, your statement is moot. So are
the following.

> > You can't specify the default entry (only the number of the entry,
> > which changes if a new kernel is installed) and there is no
> > vmlinuz/vmlinuz.old (unless you add a script that adds these
> > entries)
> 
> "default X" in the config file, and "setdefault", works for me.
> 
> > 
> > You can't specify boot options per entry (there's only a global
> > option in /etc/default grub, that applies to all entries).
> 
> Sure you can, just don't use update-grub(1) and update it yourself
> instead. Same as lilo, really.
> 
> William

harry


signature.asc
Description: PGP signature

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Sebastien Delafond]

On Apr/07, Mike Hommey wrote:
> But why a need for two versions at a time ? AFAICS, jruby 1.2 supports
> both ruby 1.8 *and* 1.9, as jruby 1.1 does, so why would jruby 1.1
> still be needed ?

As I said in my other mail, for transition reasons;
backward-compatibility is something many people like to *try* before
actually taking the leap.

Cheers,

--Seb


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Mike Hommey]

On Tue, Apr 07, 2009 at 02:17:09PM -0700, Sebastien Delafond wrote:
> On Apr/07, Mike Hommey wrote:
> > But why a need for two versions at a time ? AFAICS, jruby 1.2 supports
> > both ruby 1.8 *and* 1.9, as jruby 1.1 does, so why would jruby 1.1
> > still be needed ?
> 
> As I said in my other mail, for transition reasons;
> backward-compatibility is something many people like to *try* before
> actually taking the leap.

Backward compatibility apply for ruby 1.8 vs ruby 1.9. I don't see it
applying between jruby 1.1 and jruby 1.2, except for bugs.

Mike


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

Re: lilo about to be dropped?

[Darren Salt]

I demand that William Pitcock may or may not have written...

[snip]
> So at this point, our only option seems to be taking over upstream lilo
> maintainance ourselves (which could be a good thing in some ways, I am
> not denying that),

I say go for it...

> or find a way to transition these use-cases to grub/grub2/extlinux.

Assuming, for the moment, that extlinux is equivalent to syslinux at least as
far as configuration goes, then I see that some lilo configuration options
which I use or have had use for appear to be missing:

addappend
optional
password
restricted

[snip]
> I recommend if we go that route that we come up with a list of improvements
> that we want to see and get to hacking. If some of the people who like lilo
> a lot got around to helping with a fork, we could create a much less buggy
> bootloader than the current lilo.

For me, lilo works fine as it is. If I see something which affects me, I'll
at least have a look at it; no guarantees, though, since there's a lot of
stuff here with which I'm not familiar.

> Alternatively, we can just leave it and let it become another XMMS. I
> don't like this solution very much.

.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Let's keep the pound sterling

Beauty seldom recommends one to another.


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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Ben Finney]

(Why was Manoj's message also sent individually to me?)

On 07-Apr-2009, Manoj Srivastava wrote:
> If the current version is what we are interested, why not
> get it from the canonical site, the Debian archive?

The Debian archive is *not* the canonical location for the upstream's
original source. The upstream's repository (whether VCS or static
files or whatever they make available) is the canonical location.
Debian's archive might be more consistent and convenient, but it's an
intermediary source for most packages, *not* canonical.

> I am not seeing the sue case for not getting the sources
> distributed by Debian from Debian. People who do not trust
> the Debian archive, ought not to trust the Debian script,
> and go get the upstream using a trusted download agent on
> their own; so security is not the use case.

Trust isn't binary. One use case is to confirm what re-packing of an
original source archive has been done. Another is to verify whether
perhaps *upstream* has fiddled with the original source archive since
Debian packaged it. Yet another is to get an original source archive
that hasn't yet made it into Debian's archive.

> By far the most common use case I can see is to get the
> latest upstream, and do whatver munging needs to be done to
> make it acceptable for Debian as a source archive.
>
> What am I missing?

It's not at all unusual for me to *not* want to get the latest version
precisely because I'm not ready to package that version, or because it
is worse (FSVO worse) than the version specified in
‘debian/changelog’.

--
 \   “Science shows that belief in God is not only obsolete. It is |
  `\also incoherent.” —Victor J. Stenger, 2001 |
_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: Improvements to ‘debian /watch’ for fetching from VCS

[Noah Slater]

On Wed, Apr 08, 2009 at 09:04:21AM +1000, Ben Finney wrote:
> (Why was Manoj's message also sent individually to me?)
>
> On 07-Apr-2009, Manoj Srivastava wrote:
> > If the current version is what we are interested, why not
> > get it from the canonical site, the Debian archive?
>
> The Debian archive is *not* the canonical location for the upstream's
> original source. The upstream's repository (whether VCS or static
> files or whatever they make available) is the canonical location.
> Debian's archive might be more consistent and convenient, but it's an
> intermediary source for most packages, *not* canonical.

Debian's archive might contain DFSG modified orig tarballs anyway, right?

> It's not at all unusual for me to *not* want to get the latest version
> precisely because I'm not ready to package that version, or because it
> is worse (FSVO worse) than the version specified in
> ‘debian/changelog’.

Yes, I more often find myself wanting to just get the current tarball.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Writing symbols files for C++ libraries.

[Daniel Kobras]

On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette wrote:
> Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit :
> > I found nothing better than using a version script. I'm lucky that the
> > library in question (WebKit) only really exports C symbols, and C++ is only
> > internal details, so I'm filtering everything that starts with _Z, now.
> 
> BTW, for such simple things, you can let libtool create the version
> script for you, using -export-symbols-regex.

Have you used this option successfully with a C++ library? In this case,
libtool creates input for the linker option "-retain-symbols-file"
rather than a version script like it does with C libs. In my tests,
"-retain-symbols-file" only affected static symbols, but didn't touch
the list of dynamic symbols. Which is quite pointless for my use case.
Is this a known bug/misfeature or might I by doing something wrong here?

Regards,

Daniel.


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

Re: Writing symbols files for C++ libraries.

[Michael Biebl]

Daniel Kobras schrieb:
> On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette wrote:
>> Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit :
>>> I found nothing better than using a version script. I'm lucky that the
>>> library in question (WebKit) only really exports C symbols, and C++ is only
>>> internal details, so I'm filtering everything that starts with _Z, now.
>> BTW, for such simple things, you can let libtool create the version
>> script for you, using -export-symbols-regex.
> 
> Have you used this option successfully with a C++ library? In this case,
> libtool creates input for the linker option "-retain-symbols-file"
> rather than a version script like it does with C libs. In my tests,
> "-retain-symbols-file" only affected static symbols, but didn't touch
> the list of dynamic symbols. Which is quite pointless for my use case.
> Is this a known bug/misfeature or might I by doing something wrong here?

libtool's -export-symbols(-regex) only works with C libraries afaik.

For C++ libs the only way I know of is to use GCC's visibility support [1].

Cheers,
Michael

[1] http://gcc.gnu.org/wiki/Visibility
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: autoconf method in ifupdown

[Guillem Jover]

Hi!

On Sun, 2009-03-29 at 18:00:14 +0100, Thomas Preud'homme wrote:
> I was looking a method to just have ipv6 with autoconf network and
> found this patch
> http://mlblog.osdir.com/linux.debian.devel.ipv6/2005-05/msg00012.shtml

This link didn't seem to work, got this instead:

  

> Does anybody know the answer of upstream dev to this patch proposition ?

Checking the ifupdown bug reports, it does not seem this ever got
submitted. It might make sense to file one with the patch.

regards,
guillem


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

Re: RFC: Better formatting for long descriptions

[Guillem Jover]

Hi!

On Mon, 2009-03-23 at 16:23:12 -0700, Daniel Burrows wrote:
>   I don't have the energy to push this any more, but I should probably
> at least refer to my previous attempt to standardize bulleted lists:
> 
> http://lists.debian.org/debian-devel/2005/12/msg00531.html
> 
>   You might find it useful, or not.  At least it more or less documents
> current practice in aptitude (I think there have been some tweaks since
> then; if anyone cares I could go research what they are and dig them up).

There's been a wiki page trying to track this, including packages
which formatting was proving problematic:

  

regards,
guillem


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

Re: "Team uploads"

[Gunnar Wolf]

Matthew Johnson dijo [Mon, Apr 06, 2009 at 08:24:44AM +0100]:
> > It is a useful concept, but I would like to consider them as "special
> > case NMUs" rather than "special case MUs".
> 
> Quite apart from the issue of deciding whether or not something is 'team
> maintained' in all cases, if you are a member of the team and you are
> making uploads to the package, then you should just add yourself to
> uploaders, surely...?
> 
> That said, the option so far which is least bad is "Team Upload" in the
> same way as "QA Upload", i.e. no NMU version number, no  NMU procedures,
> no delay, etc, just something to ack the mismatch of changed-by and
> uploaders/maintainer.

In the pkg-perl group, at least, it is not at all uncommon that a team
member (usually not a DD) works on a package and tags it as ready for
upload. And then a DD just comes along, checks it, builds and uploads
- without having worked with it. It is not precisely a sponsored
upload, but a team activity for both. So, yes, we have usually worked
aroud it by adding both the people who did the work and the DD to
Uploaders: 

Still, even if the package is group-maintained, it is good to be able
to note who is most familiar or has worked most with the package -
And the current scheme does not properly represent it (save for
parsing debian/changelog)

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Gunnar Wolf]

Sebastien Delafond dijo [Tue, Apr 07, 2009 at 01:59:00PM -0700]:
> On Apr/07, Mike Hommey wrote:
> > While I see why it can be needed for python, I fail to see how it is
> > important for jruby...
> 
> to have 2 versions of jruby available ? I guess so you can at least, for
> instance, try the new one on your existing jruby code without removing
> the old one, for instance ?
> 
> Are you advocating for only one instance of jruby at all times in the
> archive ? If so, why ?

Do the Jruby versions somehow map to the Ruby versions? If I'm not
mistaken, Jruby (and IronRuby) versions aimed at compatibility with
specific Ruby language releases - and the only Ruby language
specification is the main implementation itself.

So, does JRuby 1.2 provide a bigger/different API than 1.0? Which one
is closer to the main implementation 1.8? 1.9? 

Now, if JRuby 1.2 (say) implements 1.9 and JRuby 1.0 implements 1.8,
possibly the (so far main) implementation should be renamed to only
provide libruby1.8, so that also JRuby can satisfy it?

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby

[Gunnar Wolf]

Sebastien Delafond dijo [Tue, Apr 07, 2009 at 02:17:09PM -0700]:
> On Apr/07, Mike Hommey wrote:
> > But why a need for two versions at a time ? AFAICS, jruby 1.2 supports
> > both ruby 1.8 *and* 1.9, as jruby 1.1 does, so why would jruby 1.1
> > still be needed ?
> 
> As I said in my other mail, for transition reasons;
> backward-compatibility is something many people like to *try* before
> actually taking the leap.

Umh... For our users (yes, those following stable releases), do you
want to provide an not-exactly-bleeding-edge-but-stable and one
quite-old versions? Why? What's the gain?

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Manoj Srivastava]

On Tue, Apr 07 2009, Ben Finney wrote:

> (Why was Manoj's message also sent individually to me?)
>
> On 07-Apr-2009, Manoj Srivastava wrote:
>> If the current version is what we are interested, why not
>> get it from the canonical site, the Debian archive?
>
> The Debian archive is *not* the canonical location for the upstream's
> original source. The upstream's repository (whether VCS or static
> files or whatever they make available) is the canonical location.
> Debian's archive might be more consistent and convenient, but it's an
> intermediary source for most packages, *not* canonical.

As far as Debian is concerned, it is: this is the orig.tar.gz
 that the diff.gz needs to be applied to in order to get the
 Debian package in the archive.

Whatever is upstream may or may not produce the package we have
 (it could have been corrupted, updated, or whatever). 

>
>> I am not seeing the sue case for not getting the sources
>> distributed by Debian from Debian. People who do not trust
>> the Debian archive, ought not to trust the Debian script,
>> and go get the upstream using a trusted download agent on
>> their own; so security is not the use case.
>
> Trust isn't binary. One use case is to confirm what re-packing of an
> original source archive has been done. Another is to verify whether
> perhaps *upstream* has fiddled with the original source archive since
> Debian packaged it. Yet another is to get an original source archive
> that hasn't yet made it into Debian's archive.

Most of htese checks, while laudable, ought not to bload either
 uscan, or debian/rules, since these are far off topic, in my opinion. 


>> By far the most common use case I can see is to get the
>> latest upstream, and do whatver munging needs to be done to
>> make it acceptable for Debian as a source archive.
>>
>> What am I missing?
>
> It's not at all unusual for me to *not* want to get the latest version
> precisely because I'm not ready to package that version, or because it
> is worse (FSVO worse) than the version specified in
> ‘debian/changelog’.

I think that is usually an uncommon  case. And we ought to be
 coding to the common case, while not making the uncommon cases impossible.

manoj
-- 
Ours is a world of nuclear giants and ethical infants. General Omar
N. Bradley
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

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

On Wed, 8 Apr 2009, Guillem Jover wrote:


There's been a wiki page trying to track this, including packages
which formatting was proving problematic:

 


Great.  The most important information from this page for myself is that
there are actually other tools (not the one I intended to write for
Blends) which actually would profit from a more standardized formating
of descriptions.  IMHO this rectifies filing bug reports against packages
that try to implement a list but fail to use the form:

  has_list |= ( line =~ /^\s+-/ )# a line starts with "  -"
  has_list |= ( line =~ /^\s+\+/ )   #"  +"
  has_list |= ( line =~ /^\s+\*/ )   #"  *"
  has_list |= ( line =~ /^\s+o\s+/ ) #"  o "

BTW, why are you checking for \s after the itemizing symbol only after
'o'?  IMHO it should always follow each itemizing symbol.  I also see
no good chances to detect multi level lists and thus I would like to
come back to more strict rules regarding the itemizing symbol and the
spacing.  In contrast to the comment in the end the check also allows

"  -"

and I would rather like to force

   /^  - /  or  /^  + /

(yes, not checking for any space but really the character ' ' = blank).
IMHO this would increase the reliability of detecting a list and if there
are tools like aptitude who are actually making use of it it should be
worth the effort.

For the sake of interest: What programming language is the script above?

Kind regards

   Andreas.

--
http://fam-tille.de


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