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 ca
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
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/
* Licens
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 Roma
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
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 Zacchirol
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 @ U
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 s
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
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
(transitiona
]] 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 it
]] 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
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 UNS
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_MA
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_MA
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
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
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:
D
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-
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 me
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 archi
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
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-f
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
Descripti
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 d
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-
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 wh
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_
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-buildpac
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 tha
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 O
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 t
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.
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
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
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#SRVDATAFORSERVI
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 b
37 matches
Mail list logo
