Re: The future of the boot system in Debian

[Mike Hommey]

On Sun, Sep 27, 2009 at 03:35:41PM +1000, Russell Coker wrote:
> > IME, simple initrds that don't really impact on your hability to boot
> > are fine (and great to load firmware, CPU microcode and kernel modules),
> > but anything else (like root on lvm or on non-auto-started md arrays)
> > will cause trouble sooner or later.
> 
> Root on LVM is good for backups and gives the potential for changing the size 
> of root with little inconvenience.

It also allows to move the root fs to another disk, on a live system.

Mike


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

Re: The future of the boot system in Debian

[Russell Coker]

On Sun, 27 Sep 2009, Henrique de Moraes Holschuh  wrote:
> For which I am very grateful.  The backlash against über-fragile and
> over-complex boot environments has already started, and you could see it
> really well in LKML (refer for the tmpdevfs threads, for example).
> RedHat's initrd has often been refered to with strong words there, I
> don't think we should commit to *requiring* something like that.

That's interesting.

I think that the initrd should do NOTHING other than make it possible to mount 
root.

> Also, RedHat could care less for the smaller boxes, they don't optimize
> for anything that doesn't have hardware RAID.  That's fine for RHEL user
> demographics, but we're not like that, our user demographic is not like
> that, and our values are not in perfect sync with theirs.  What's good
> for RedHat is not necessarily good for Debian.

I think that you are exaggerating slightly.  RHEL and Fedora work quite nicely 
on systems with software RAID.  Admittedly they don't work as well as Debian 
which allows you to do unusual but convenient things such as installing to a 
degraded RAID-1.

> IME, simple initrds that don't really impact on your hability to boot
> are fine (and great to load firmware, CPU microcode and kernel modules),
> but anything else (like root on lvm or on non-auto-started md arrays)
> will cause trouble sooner or later.

Root on LVM is good for backups and gives the potential for changing the size 
of root with little inconvenience.  Given that 10G is large for a root 
filesystem (I don't think that I run a machine with more than 8G for root) 
and the smallest newly manufactured hard drive seems to be something in 
excess of 300G (with 2T being common) it seems that there is no real benefit 
in changing the size of root (just make it reasonably large for all 
machines - we have space to burn).

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Bug#548643: ITP: libparams-coerce-perl -- Perl module to permit parameter coercion for classes

[Jonathan Yu]

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

* Package name: libparams-coerce-perl
  Version : 0.14
  Upstream Author : Adam Kennedy 
* URL : http://search.cpan.org/dist/Params-Coerce/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to permit parameter coercion for classes

 Params::Coerce attempts to encourage flexibility in the ways that your class
 accepts parameters by making it easier to take different types of parameters,
 while adding negligible additional complexity to your code.



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

Re: DEB_MAINTAINER_MODE: is it popular and should we document it?

[Felipe Sateler]

Philipp Kern wrote:

> On 2009-09-27, Charles Plessy  wrote:
>> in a discussion on how to force network-dependant regression tests (that
>> must be disabled in our build network, but whose result I want to see
>> before uploading), I was suggested by Jonas Smedegaard, who got this idea
>> from Romain Beauxis, to use a DEB_MAINTAINER_MODE environment variable
>> that is detected in debian/rules.
>>
>> I was just wondering if other people were using something similar and if
>> there would be ground for standardisation.s
> 
> Although the goal to enable more tests is laudable the approach of
> modifying a maintainer build that is later uploaded to the archive from a
> buildd build
> doesn't sound right.  Maybe the build could then fail in the end through
> dpkg-buildpackage so that the result cannot be uploaded?

But then you cannot automatically check if maintainer mode did it's thing 
correctly.

-- 
Felipe Sateler


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

zendframework package with or without bin package

[Frank Habermann]

Hi folks,

i have created the package zendframework and zendframework-bin. The package 
zendframework contains the php libraries. The bin package contains two 
scripts with that you can create a mvc environment with the zendframework. 
This is only important for developers.

So my question is, if i should also add the binary files to the zendframework 
package or if i should leave them separate?

I also want to rename the package to libphp-zendframework.

regards,
Frank


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

Re: Transitional (dummy) packages considered silly

[Stefano Zacchiroli]

On Sun, Sep 27, 2009 at 06:11:13PM +0200, Andreas Metzler wrote:
> I always thought dummy transitional packages were supposed to be in
> section oldlibs anyway.

According to the archive section description, that section is just for
transition *libraries* (as the name hints).

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


signature.asc
Description: Digital signature

Re: Transitional (dummy) packages considered silly

[Stefano Zacchiroli]

On Sun, Sep 27, 2009 at 07:22:27PM +0200, Vincent Danjean wrote:
> Recognizing transitional packages is only a small part of the problem.

Agreed. As discussed in my post, that's the part of the problem which I
was trying to address.

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


signature.asc
Description: Digital signature

Re: Transitional (dummy) packages considered silly

[Francesco P. Lovergine]

On Sun, Sep 27, 2009 at 04:30:50PM +0200, Stefano Zacchiroli wrote:
> 
> - Status quo: grepping for "transitional package" in package
>   descriptions
> 

Transitional packages are often not defined as such in description.
Too unsafe rely on keyword such as transitional, dummy, what else.
This is sub-optimal IMHO.

> - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed)
>   be willing to pursue that road?
> 
> - Debtags. Apparently there's already a tag "role::dummy" whose
>   semantics seems to match "transitional package" (hence the name should
>   probably be better?).
> 

That could be an alternative, but I would prefer a solution under
full maintainer's control. Debtags currently is not AFAIK. And this
is probably the reason of the mismatches below.

>   However, if I check on my laptop I've about 20 transitional packages
>   installed (detected using "status quo" above) and some empiric tests
>   show that quite a lot of them do not have the "role::dummy" tag. This
>   means that, at least currently, the debtags way is not really enough
>   (or better: it looks to be sound, but not complete). I wonder why? Is
>   it just missing tags or is there some more serious infrastructure
>   problem? E.g.: is there a tag flow problem which "erases" tags from
>   transitional package of past versions when the package got removed
>   from the archive (but not necessarily from user machines?). Cc-ing
>   debtags-devel for advices.
> 
> - A new debian/control field, e.g. "Transitional: yes"
>

This is equivalent to the archive solution, but it increases fields
pollution. I have not a strong opinion about what's better.

> 
> I see no clear winner among the above choices. The proposed solution of
> using archive sections, for instance, has the drawback that you renounce
> to the "original" section and hence you will partly defeat user actions,
> e.g., removing all installed packages belonging to a given section.
> 

I see no uses for such a selective removing. But that could be a pro
for the control field.

> Debtags is clearly meant to solve this problem, but for transitional
> packages I'd like to have a solution which is both sound and
> complete. Only with such properties I'd be confident of integrating a
> clean up actions which we can recommend doing, e.g., in release notes.
> 
> Thoughts?
> 



-- 
Francesco P. Lovergine


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

Bug#548618: ITP: libdeclare-constraints-simple-perl -- Perl module to validate data structures

[Jonathan Yu]

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

* Package name: libdeclare-constraints-simple-perl
  Version : 0.03
  Upstream Author : Robert Sedlacek 
* URL : http://search.cpan.org/dist/Declare-Constraints-Simple/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to validate data structures

 Declare::Constraints::Simple is a Perl module that provides an easy way to
 construct a profile that can be used to validate a data structure. The module
 accomplishes this by providing a basic set of declarative keywords that can
 be combined to validate constraints from the basic to complex.



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

Re: Transitional (dummy) packages considered silly

[Vincent Danjean]

Stefano Zacchiroli wrote:
> I see various ways of enabling such recognition:

Recognizing transitional packages is only a small part of the problem.
You also need to 'move' the 'non-automatic' flags to another package
if needed. And I'm not sure there is currently enough information in
(transitional or not) packages to do this automatically.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Re: safe value for HOME

[Tollef Fog Heen]

]] Atsuhito Kohda 

| I'm a maintainer of mathematica-fonts which downloads fonts
| with wget and I got the following bug report.
| What is a safe value for HOME in this case?

Make a temporary directory and point $HOME there.

-- 
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: /var/www is depracated, which directory to use?

[Tollef Fog Heen]

]] Holger Levsen 

| The way I read 
| 
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM 
 
| /srv/munin would be the proper location for our purpose, but I know that some 
| people disagree, claiming that /srv is only to be used by the local admins.
| 
| As I read it, no package should remove files there, but placing files there 
| should be fine. What's more important, I don't see which location is better 
| suited.

I realise you've had good an constructive responses for webapps, so
commenting on /srv in particular:

As I read it, putting stuff there is absolutely not fine.  It's even
more off-limits than /usr/local (where you can create directories, but
not remove them).

-- 
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: Transitional (dummy) packages considered silly

[Andreas Metzler]

In gmane.linux.debian.devel.general Stefano Zacchiroli  wrote:
[...]
> - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed)
>  be willing to pursue that road?
[...]

I always thought dummy transitional packages were supposed to be in
section oldlibs anyway.

cu andreas


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

Re: DEB_MAINTAINER_MODE: is it popular and should we document it?

[Raphael Geissert]

Charles Plessy wrote:

> Dear all,
> 
> in a discussion on how to force network-dependant regression tests (that
> must be disabled in our build network, but whose result I want to see
> before uploading), I was suggested by Jonas Smedegaard, who got this idea
> from Romain Beauxis, to use a DEB_MAINTAINER_MODE environment variable
> that is detected in debian/rules.
> 
> I was just wondering if other people were using something similar and if
> there would be ground for standardisation.
> 

Why not reuse the current env var used for that kind of things?
DEBIAN_BUILD_OPT. 'netavail' or something like that could be used to tell
the rules file that it is ok to try to do anything that requires an
interface.

Just an idea regarding the name, not that I'm advocating it (I don't
maintain any package that would benefit from it).

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Re: DEB_MAINTAINER_MODE: is it popular and should we document it?

[Philipp Kern]

On 2009-09-27, Charles Plessy  wrote:
> in a discussion on how to force network-dependant regression tests (that must
> be disabled in our build network, but whose result I want to see before
> uploading), I was suggested by Jonas Smedegaard, who got this idea from Romain
> Beauxis, to use a DEB_MAINTAINER_MODE environment variable that is detected in
> debian/rules.
>
> I was just wondering if other people were using something similar and if there
> would be ground for standardisation.s

Although the goal to enable more tests is laudable the approach of modifying
a maintainer build that is later uploaded to the archive from a buildd build
doesn't sound right.  Maybe the build could then fail in the end through
dpkg-buildpackage so that the result cannot be uploaded?

Kind regards,
Philipp Kern


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

Re: Transitional (dummy) packages considered silly

[Stefano Zacchiroli]

On Thu, Sep 24, 2009 at 05:37:03PM +0200, Francesco P. Lovergine wrote:
> What about moving those packages under a transitional Section in the
> archive?  That would allow users to easily detect and remove them
> after dist-upgrades for instance, and it would also allow maintainers
> to mark proper transitional/dummy packages.

I was thinking along the same lines (which is a line of thought
orthogonal to an implementation of a Supersedes field: we can have
both).

So, let's focus on the user problem: how can we empower users to
recognize, with some certainty transactional packages to remove. Once we
have that, we can add a specific package manager command (a-la apt-get's
"autoremove" that in one step removes them).

I see various ways of enabling such recognition:

- Status quo: grepping for "transitional package" in package
  descriptions

- Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed)
  be willing to pursue that road?

- Debtags. Apparently there's already a tag "role::dummy" whose
  semantics seems to match "transitional package" (hence the name should
  probably be better?).

  However, if I check on my laptop I've about 20 transitional packages
  installed (detected using "status quo" above) and some empiric tests
  show that quite a lot of them do not have the "role::dummy" tag. This
  means that, at least currently, the debtags way is not really enough
  (or better: it looks to be sound, but not complete). I wonder why? Is
  it just missing tags or is there some more serious infrastructure
  problem? E.g.: is there a tag flow problem which "erases" tags from
  transitional package of past versions when the package got removed
  from the archive (but not necessarily from user machines?). Cc-ing
  debtags-devel for advices.

- A new debian/control field, e.g. "Transitional: yes"


I see no clear winner among the above choices. The proposed solution of
using archive sections, for instance, has the drawback that you renounce
to the "original" section and hence you will partly defeat user actions,
e.g., removing all installed packages belonging to a given section.

Debtags is clearly meant to solve this problem, but for transitional
packages I'd like to have a solution which is both sound and
complete. Only with such properties I'd be confident of integrating a
clean up actions which we can recommend doing, e.g., in release notes.

Thoughts?

Cheers.

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


signature.asc
Description: Digital signature

DEB_MAINTAINER_MODE: is it popular and should we document it?

[Charles Plessy]

Dear all,

in a discussion on how to force network-dependant regression tests (that must
be disabled in our build network, but whose result I want to see before
uploading), I was suggested by Jonas Smedegaard, who got this idea from Romain
Beauxis, to use a DEB_MAINTAINER_MODE environment variable that is detected in
debian/rules.

I was just wondering if other people were using something similar and if there
would be ground for standardisation.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: Fields used in packages

[Charles Plessy]

Le Sun, Sep 27, 2009 at 10:46:04AM +0200, Raphael Hertzog a écrit :
> - have dak check those fields (would avoid packages built on ubuntu being
>   uploaded in debian)

Hi Raphaël,

That part may not be necessary since it was announced that all packages
distributed by Debian will be autobuilt:

  Debian GNU/Linux 6.0 "Squeeze" release goals:
  
  The Debian Release Team - in cooperation with the Debian Infrastructure
  Team - plans to include the following goals in the upcoming release:
  
   * Discard and rebuild of binary packages uploaded by maintainers, 
 leaving only packages build in a controlled environment 

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

Have a nice day

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: GObject introspection mini-policy, take 2

[Hendrik Sattler]

Am Sonntag 27 September 2009 04:59:38 schrieb Paul Wise:
> 2009/9/26 Josselin Mouette :
> > 1. Directory layout
> >
> > GObject-introspection data is generally provided in two formats:
> >  * XML format in /usr/share/gir-1.0/Foo-X.Y.gir
> >  * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
> 
> ...
> 
> > 6. Example
> >
> > Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
> > source generates the following files, put in the following packages:
> >libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
> >libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
> >libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
> >gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib
> 
> Would this proposal need to be adjusted for multiarch support?
> 
> If so, perhaps just insert an arch triple?
> 
>  /usr/lib//girepository-1.0/Foo-2.0.typelib

Isn't the lib directory for each arch already different?

I just question the need for a seperate package for _one_ typelib file.

HS


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

Re: Auto Backporting (Was: Backports of scientific packages)

[Michael Banck]

On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
> > 
> > Yes. I like the idea but we simply can't rebuild everything from the
> > task pages of these blends since there are also tools from KDE or GNOME
> > which would mean to backport quite a lot of unrelated stuff. Also,
> > packages with code in interpreted language can almost always be used
> > directly from testing. But I think auto-building could work for a
> > well-defined subset of packages.
> 
> IMHO this problem is not really Debian Science or Blends related and the
> idea to handle backports analog to non-free autobuilds sounds quite
> reasonable - but in this case we *really* make it analog tp non-free which
> works with a debian/control field
> 
> XS-Autobuild: yes
> 
> So why not using a similar field
> 
> XS-Autobackport: yes
> 
> ?  Well, it's definitely not that easy but I see a quite large set of
> packages (specifically in the Debian Science field) which perfectly
> compiles against Build-Depends of stable.  If we could handle this set
> automatically for a first shot and think later about those packages
> which need Build-Depends which are not available in stable this would
> be an interesting thing.
> 
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way. 

One problem is that unlike non-free autobuilds, auto-backports should
happen once the package enters testing, not unstable.  Otherwise, users
tracking this auto-backports repository will basically track unstable
for the applications they use and will get burnt by zero-day
grey-paper-bag uploads or otherwise unstable software.

As such, a facility more like the binNMU triggers for the release-team/
buildd-maintainers might be better; i.e. wait till a package hits
testing, then evaluate its impact and trigger an auto-backport via
wanna-build something else.  Of course, at that point, doing a manual
backports.org upload is not too far off, effort-wise.


Michael


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

Re: different .diff.gz for different platforms (armel) prohibiting upload

[Steffen Moeller]

Hi Raphael,

Raphael Hertzog wrote:
> On Sun, 27 Sep 2009, Steffen Moeller wrote:
>> I tried to help it out with my OpenMoko running Debian, and while it builds, 
>> I
>> cannot upload since the .diff.gz generated by dpkg-buildpackage -sd is not
>> bit-identical to the .diff.gz that is in the archive. The unpacked diff.gz
>> however _is_ identical. You then the the .dsc and the .changes to disagree 
>> with
>> the various checksums.
> 
> That's why you don't rebuild the source package and use dpkg-buildpackage -B
> like the buildds in those situations.

have many many thanks, I as not aware of -B being different from -sd for an
all-arch-dependent package. I know now.

[ Uploading job mgltools-molkit_1.5.4.cvs.20090603-1_armel
 mgltools-molkit_1.5.4.cvs.20090603-1_armel.deb 2879.3 kB, ok (26 s, 110.74 
kB/s)
 mgltools-molkit_1.5.4.cvs.20090603-1_armel.changes 1.1 kB, ok (1 s, 1.10 kB/s) 
]

The .diff.gz is indeed no longer an issue, as it seems.

Happy now!

Steffen


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

Re: different .diff.gz for different platforms (armel) prohibiting upload

[Steffen Moeller]

Russ Allbery wrote:
> Raphael Hertzog  writes:
> 
>> That said uploading missing binaries yourself is not the rigt way forward,
>> official build daemons must be able to build it and you should work with
>> buildd maintainers and porters to get your package built (and building).
> 
> I thought that statement didn't apply to non-free packages?

This is also my understanding, Raphael has probably missed the indication of
the package being in non-free.

As a sidenote, and to promote the summary on http://wiki.debian.org/buildd a
bit, there is a non-free buildd network. This has taken perfect care of my
non-free packages so far, but it seems defunct for mips and armel these days.

Cheers,

Steffen


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

safe value for HOME

[Atsuhito Kohda]

Hi all,

I'm a maintainer of mathematica-fonts which downloads fonts
with wget and I got the following bug report.
What is a safe value for HOME in this case?

> this packages calls wget without first setting HOME to a safe value. This
> means that when I do:
> 
> sudo apt-get install mathematica-fonts
> 
> I get the warning:
> wget: Cannot read /home/glisse/.netrc (Permission denied).
> 
> (my HOME is on NFS)

Thanks in advance.

Regards,2009-9-27(Sun)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

Re: Fields used in packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
> I wonder what's up with all the Gstreamer and Npp fields.

Those are used to find the needed package for autocodec installation when you
try to reproduce a package with a missing decoder/encoder/whatever (package
gnome-codec-install).

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: DEP-3 update: Patch Tagging Guidelines

[Paul Wise]

On Sun, Sep 27, 2009 at 4:51 PM, Raphael Hertzog  wrote:

> Did you read the changes about the structure ?

I did not.

> It explains that we can have two sets of fields. The intended scenario for
> this change is precisely to respond to this use-case of having a second set
> of fields after some description.

Hmm, OK. I'm confused about why such a thing would be needed, but anyway.

-- 
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: different .diff.gz for different platforms (armel) prohibiting upload

[Russ Allbery]

Raphael Hertzog  writes:

> That said uploading missing binaries yourself is not the rigt way forward,
> official build daemons must be able to build it and you should work with
> buildd maintainers and porters to get your package built (and building).

I thought that statement didn't apply to non-free packages?

-- 
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: different .diff.gz for different platforms (armel) prohibiting upload

[Julien Cristau]

On Sun, Sep 27, 2009 at 10:53:01 +0200, Steffen Moeller wrote:

> Hello,
> 
> my non-free package mgltools-molkit built nicely everywhere, but the armel
> could yet not be uploaded - blocking the autodocktools to arrive in testing.
> 
> I tried to help it out with my OpenMoko running Debian, and while it builds, I
> cannot upload since the .diff.gz generated by dpkg-buildpackage -sd is not
> bit-identical to the .diff.gz that is in the archive. The unpacked diff.gz
> however _is_ identical. You then the the .dsc and the .changes to disagree 
> with
> the various checksums.
> 
You're not supposed to upload the source twice.  You upload the source
once, and other architectures do binary-only uploads.

Cheers,
Julien


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

Re: different .diff.gz for different platforms (armel) prohibiting upload

[Raphael Hertzog]

Hi,

On Sun, 27 Sep 2009, Steffen Moeller wrote:
> I tried to help it out with my OpenMoko running Debian, and while it builds, I
> cannot upload since the .diff.gz generated by dpkg-buildpackage -sd is not
> bit-identical to the .diff.gz that is in the archive. The unpacked diff.gz
> however _is_ identical. You then the the .dsc and the .changes to disagree 
> with
> the various checksums.

That's why you don't rebuild the source package and use dpkg-buildpackage -B
like the buildds in those situations.

That said uploading missing binaries yourself is not the rigt way forward,
official build daemons must be able to build it and you should work with
buildd maintainers and porters to get your package built (and building).

Cheers,
-- 
Raphaël Hertzog


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

different .diff.gz for different platforms (armel) prohibiting upload

[Steffen Moeller]

Hello,

my non-free package mgltools-molkit built nicely everywhere, but the armel
could yet not be uploaded - blocking the autodocktools to arrive in testing.

I tried to help it out with my OpenMoko running Debian, and while it builds, I
cannot upload since the .diff.gz generated by dpkg-buildpackage -sd is not
bit-identical to the .diff.gz that is in the archive. The unpacked diff.gz
however _is_ identical. You then the the .dsc and the .changes to disagree with
the various checksums.

I have performed the armel-builds and uploads for a series of other mgltools-*
packages, hence while the error may be on my side, I would be somewhat 
surprised.

Is there a standard procedure to follow? Shall I somehow (how?) invoke
dpkg-genchanges manually with the .diff.gz being exchanged with the original
again? Is there some other trick of the trade?

And: if my error report is correct, is the logic possibly flawed to reject the
upload even though the contents of the .diff.gz are identical?

$ LANG=C diff mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz
../mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz && echo identical ||echo differ
Binary files mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz and
../mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz differ
differ

now with zdiff:

$ LANG=C zdiff mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz
../mgltools-molkit_1.5.4.cvs.20090603-1.diff.gz && echo identical ||echo 
different
identical


Many thanks

Steffen



signature.asc
Description: OpenPGP digital signature

Re: DEP-3 update: Patch Tagging Guidelines

[Raphael Hertzog]

On Sun, 27 Sep 2009, Paul Wise wrote:
> Hmm, in the examples, I would expect that the Origin/Bug/Bug-Debian
> fields would be before the Subject field. If they aren't then I would
> have thought they were part of the long description.

Did you read the changes about the structure ?

It explains that we can have two sets of fields. The intended scenario for
this change is precisely to respond to this use-case of having a second set
of fields after some description.

Cheers,
-- 
Raphaël Hertzog


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

Re: Fields used in packages

[Raphael Hertzog]

On Sat, 26 Sep 2009, Russ Allbery wrote:
> Paul Wise  writes:
> > http://lintian.debian.org/tags/redundant-origin-field.html
> 
> When I asked the dpkg developers about that, I think the answer was that
> dpkg's use was intended as an example of correct use.

Yes, but we also plan to auto-add the Origin and Bugs field to all .deb
based on the information in /etc/dpkg/origins/default. Though it would
require some other changes:
- have those fields dropped from Packages files (to avoid an unnecessary
  size increase in official Packages files)
- have dak check those fields (would avoid packages built on ubuntu being
  uploaded in debian)

Cheers,
-- 
Raphaël Hertzog


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

Re: /var/www is depracated, which directory to use?

[Russ Allbery]

Holger Levsen  writes:

>> i would recommend similar, but with the modification that you use a
>> dedicated subdirectory (i.e. /usr/share/munin/site), so that you still
>> have /usr/share/munin for other uses as well.

> Thats for read-only data only.

Right, you take the static data shipped with the package and put it there,
and you put the dynamically generated data in /var/lib/munin, following
the FHS.

You don't need to put all the web files in the same place.  There's no
correlation between where files are located on disk and what URLs they're
exposed as.

> I think having munin working out-of-the-box is a very neat feature.

I think we need better support in the Apache package for adding particular
aliases and similar URL configuration into the default site, so that those
who want to do things like this can add the necessary URL mappings to the
default site and those of us who are doing anything more complex and who
are therefore disabling the default site anyway don't have random packages
suddenly taking over portions of our URL space.

-- 
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: /var/www is depracated, which directory to use?

[Holger Levsen]

Hi Sean,

On Sonntag, 27. September 2009, sean finney wrote:
> > > currently munin ships some file(s) in /var/www/munin/ and also puts its
> > > generated graphs there. This location has been depracted and we, the
> > > munin maintainers, would like to come up with a new location for
> > > squeeze.
> take a look at http://webapps-common.alioth.debian.org/draft/html/ , which
> covers most of the stuff you're asking about.

I've skimmed it and neither 3.1 nor 5.1.1 covers what I'm interested at. Where 
to put static files is easy... but not my main question :)

> i would recommend similar, but with the modification that you use a
> dedicated subdirectory (i.e. /usr/share/munin/site), so that you still
> have /usr/share/munin for other uses as well.

Thats for read-only data only.

> > I personally do not believe that serving anything from a package via the
> > web by default is a good goal.  Certainly for my systems, any system
> > that's running a web server has a virtual host configuration and anything
> > that packages try to do to control what my web server serves out is
> > broken and undesireable.
> i'd have to disagree there.  i think anything that might serve up content
> while unconfigured is a horrible idea 

I think having munin working out-of-the-box is a very neat feature.

> (one more reason to avoid /var/www 
> and /usr/lib/cgi-bin), but if someone installs an application that can
> behave sanely out of the box, i don't see why one shouldn't go out of
> their way to do so.

munin can. I just dont know where to go ;-)


regards,
Holger


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

Re: /var/www is depracated, which directory to use?

[sean finney]

hi holger, russ,

On Sun, Sep 27, 2009 at 12:36:43AM -0700, Russ Allbery wrote:
> Holger Levsen  writes:
> 
> > currently munin ships some file(s) in /var/www/munin/ and also puts its
> > generated graphs there. This location has been depracted and we, the
> > munin maintainers, would like to come up with a new location for
> > squeeze.

take a look at http://webapps-common.alioth.debian.org/draft/html/ , which
covers most of the stuff you're asking about.

> My recommendation would be for it to install its static files in
> /usr/share/munin, put its generated graphs in /var/lib/munin, and provide
> example configuration for common web servers such as Apache that explain
> how to serve out the appropriate files.

i would recommend similar, but with the modification that you use a
dedicated subdirectory (i.e. /usr/share/munin/site), so that you still
have /usr/share/munin for other uses as well.

> I personally do not believe that serving anything from a package via the
> web by default is a good goal.  Certainly for my systems, any system
> that's running a web server has a virtual host configuration and anything
> that packages try to do to control what my web server serves out is broken
> and undesireable.

i'd have to disagree there.  i think anything that might serve up content
while unconfigured is a horrible idea (one more reason to avoid /var/www
and /usr/lib/cgi-bin), but if someone installs an application that can
behave sanely out of the box, i don't see why one shouldn't go out of
their way to do so.


sean
-- 


signature.asc
Description: Digital signature

Re: /var/www is depracated, which directory to use?

[Russ Allbery]

Holger Levsen  writes:

> currently munin ships some file(s) in /var/www/munin/ and also puts its
> generated graphs there. This location has been depracted and we, the
> munin maintainers, would like to come up with a new location for
> squeeze.

> The way I read 
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>   
> /srv/munin would be the proper location for our purpose, but I know that some 
> people disagree, claiming that /srv is only to be used by the local admins.

> As I read it, no package should remove files there, but placing files there 
> should be fine. What's more important, I don't see which location is better 
> suited.

My recommendation would be for it to install its static files in
/usr/share/munin, put its generated graphs in /var/lib/munin, and provide
example configuration for common web servers such as Apache that explain
how to serve out the appropriate files.

I personally do not believe that serving anything from a package via the
web by default is a good goal.  Certainly for my systems, any system
that's running a web server has a virtual host configuration and anything
that packages try to do to control what my web server serves out is broken
and undesireable.

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

/var/www is depracated, which directory to use?

[Holger Levsen]

Hi,

currently munin ships some file(s) in /var/www/munin/ and also puts its 
generated graphs there. This location has been depracted and we, the munin 
maintainers, would like to come up with a new location for squeeze.

The way I read 
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM 
 
/srv/munin would be the proper location for our purpose, but I know that some 
people disagree, claiming that /srv is only to be used by the local admins.

As I read it, no package should remove files there, but placing files there 
should be fine. What's more important, I don't see which location is better 
suited.

http://lintian.debian.org/tags/dir-or-file-in-var-www.html nor debian-policy 
is helpful to resolve this issue - so I would like to discuss this here and 
come up with a good solution.

Suggestions?


regards,
Holger


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

Re: Auto Backporting (Was: Backports of scientific packages)

[Mike Hommey]

On Sat, Sep 26, 2009 at 05:40:58PM +1000, Russell Coker wrote:
> On Sat, 26 Sep 2009, Rene Engelhard  wrote:
> > > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > > And if it doesn't build that way, I'd say there's a bug in the package
> > > anyways, because it should bump some build dependencies.
> >
> > build-deps are not necessarily runtime deps. Especially if
> > stuff changed in the fs or for policy reasons and that is not reflected in
> > the build-deps because the change is not in the build-deps.
> 
> The runtime dependencies should either be based on the versions of the 
> packages that were compiled against (in which case they should be correct 
> automaticall) or they will be based on some specific features (EG a new 
> version of a package containing /bin/foo adds a new command-line option 
> to /bin/foo) in which case an explicit versioned dependency should be 
> sufficient (failure to do so would be a bug in any case).  It should not be 
> THAT difficult to make a back-port build daemon refrain from building 
> packages if the runtime dependencies can never be satisfied.

But runtime dependencies can be the result of shlibs bumps, where the
runtime dependency will be different depending on the build-dep version
used at build time. So the selection should be done *after* having tried
at least once to build a package that has all its build-deps
satisfiable.

Mike


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