On Sun, 26 Jan 2025, Niko Tyni wrote:
On Sun, Jan 26, 2025 at 12:39:52AM +0500, Andrey Rakhmatullin wrote:
On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:
I know this is experimental and so breakage is expected but it seems to
have been like this for a while now so I'm reporting i
On Sun, Jan 26, 2025 at 12:39:52AM +0500, Andrey Rakhmatullin wrote:
> On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:
> > I know this is experimental and so breakage is expected but it seems to
> > have been like this for a while now so I'm reporting it here in case
> > it's been miss
On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:
> I know this is experimental and so breakage is expected but it seems to
> have been like this for a while now so I'm reporting it here in case
> it's been missed.
You may be confused, as perl 5.40.1-1 was only uploaded to experimental
On Tue, Mar 05, 2024 at 11:55:28PM +0100, John Paul Adrian Glaubitz wrote:
> > Thanks! You saved me a lot of headaches!
FWIW to do a bootstrap build of perl I had to:
- disable libdb and libgdbm build-deps
- disable build-time tests, which would pick up old ndbm module from
on-disk and break
Hi Roderich,
On Wed, 2024-03-06 at 19:20 +0100, Roderich Schupp wrote:
> Hi,
>
> > Parser.c: loadable library and perl binaries are mismatched (got first
> > handshake key 0xb600080, needed 0xb700080)
> >
>
>
> The upper 16 bits in these keys (i.e. 0xb60 vs 0xb70) is
> sizeof(PerlInterpreter
On Tue, 05 Mar 2024 23:55:28 +0100, John Paul Adrian Glaubitz wrote:
> Also, I noticed that libxs-parse-keyword-perl build-depends on
> libextutils-cbuilder-perl
> which is apparently obsolete and also still depends on the old Perl API [1]
> which makes
> me wonder how libxs-parse-keyword-perl w
Hi,
On Tue, 2024-03-05 at 23:10 +0100, John Paul Adrian Glaubitz wrote:
> >
> > oks like it's built with dpkg-dev_1.22.4 but the time64 build flags are
> > only activated with 1.22.5.
>
> Ah, that would explain it, thank you so much!
>
> > I think there was talk about making them the default in
(Oops, forgot the Cc you asked for. So resending. Apologies for the
duplicate on the list.)
On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote:
> I am getting strange Perl error after rebuilding Perl for the time64_t
> transition on powerpc:
>
> loadable library and perl
On Wed, 2024-03-06 at 00:08 +0200, Niko Tyni wrote:
> (Oops, forgot the Cc you asked for. So resending. Apologies for the
> duplicate on the list.)
No worries.
> On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote:
>
> > I am getting strange Perl error after rebuilding Per
On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote:
> I am getting strange Perl error after rebuilding Perl for the time64_t
> transition on powerpc:
>
> loadable library and perl binaries are mismatched (got first handshake key
> 0xb600080, needed 0xb700080)
>
> See:
On Sat, Jun 05, 2021 at 10:03:55AM +0200, Marc Haber wrote:
> On Fri, 4 Jun 2021 21:54:16 +0200, RhineDevil
> wrote:
> >I've looked up /usr/share/debootstrap/functions and I've seen some perl code
> >What does this code do exactly and why wasn't it translated to shell?
> Writing it in shell would
On Fri, 4 Jun 2021 21:54:16 +0200, RhineDevil
wrote:
>I've looked up /usr/share/debootstrap/functions and I've seen some perl code
>Can I know why perl is a requirement if pkgdetails.c is not found?
>What does this code do exactly and why wasn't it translated to shell?
As far as I remember, the p
On Fri, Dec 07, 2018 at 04:34:48PM +0100, Cyrille Bollu wrote:
> The URL https://release.debian.org/transitions/html/perl5.28.html is 404
Indeed. The correct one seems to be
https://release.debian.org/transitions/html/perl.html
The havoc part of the transition is long over though, so no big ma
On 12/7/18 4:34 PM, Cyrille Bollu wrote:
> The URL https://release.debian.org/transitions/html/perl5.28.html is
> 404 :-(
>
With Perl 5.28 in testing, the transition is over.
Cheers,
Julien
The URL https://release.debian.org/transitions/html/perl5.28.html is 404
:-(
BR,
Cyrille
Le mer. 31 oct. 2018 à 23:14, Niko Tyni a écrit :
> I have uploaded Perl 5.28 to Debian unstable, starting a 500+ package
> transition. Wide uninstallability is to be expected in sid for the next
> few da
On Fri, Nov 18, 2011 at 20:52:48 +0100, gregor herrmann wrote:
> > * genders (#646286): patch ready, maybe NMU?
>
> Uploaded in the meantime.
>
Uploaded, but still broken.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
On Fri, 18 Nov 2011 18:25:16 +0100, Luk Claes wrote:
> The following packages block the perl transition and will become testing
> removal candidates soon unless the bugs get fixed:
> * libdbd-interbase-perl (#648857)
Just asked for removal from the archive.
> * prima (#628500)
Already NMUd, s
On Fri, Nov 18, 2011 at 10:55 PM, Luk Claes wrote:
> The following packages block the perl transition and will become testing
> removal candidates soon unless the bugs get fixed:
> ...
> * nginx (#649061)
> ...
This doesn't look like Perl issue, but I'm uploading new version that
should fix build
On 11/18/2011 09:25 AM, Luk Claes wrote:
> Hi
>
> The following packages block the perl transition and will become testing
> removal candidates soon unless the bugs get fixed:
>
> ...
>
> * genders (#646286): patch ready, maybe NMU?
Working on an upload of genders now. Sorry, for some reason I
On Tue, Nov 15, 2011 at 11:30:38PM +, Dominic Hargreaves wrote:
> On Sun, Nov 13, 2011 at 01:59:19PM +, Dominic Hargreaves wrote:
> > As per #637809, I plan to upload perl 5.14 to unstable soon (maybe today,
> > depending on how some last bits of testing go). Like last time, this
> > will m
On 03/05/2011 12:02, Neil Williams wrote:
>
> With such a large number of packages involved and the transition page
> being constructed from multiple dependency levels, is there a way of
> linking the transitions data from DDPO or having some other output
> which is organised on a per-developer /
On Tue, 3 May 2011 10:21:09 +0100
Dominic Hargreaves wrote:
> Hi all,
>
> On Sunday, in collaboration with the release team, I uploaded
> perl 5.12-6 to unstable. This necessarily causes around 400 packages
> to be uninstallable with the new perl. The release team will be
> scheduling binNMUs in
On Sun, May 09, 2010 at 11:37:24PM +0300, Niko Tyni wrote:
> Testing 5.12.0 with and without use64bitint on x86 shows an approximately
> 10% increase with scalars and arrays:
>
> perl -e '${"v$i"} = $i while ($i++ < $ARGV[0]); system("ps -o rss $$")'
> 100
> perl -e '$a[$i++] = $i while ($
On Sun, May 09, 2010 at 11:37:24PM +0300, Niko Tyni wrote:
> I'm partial to enabling use64bitint on all architectures, if only for the
> sake of uniformity already mentioned in the uselongdouble discussion: bugs
> that only happen on the "smaller" architectures because of differences
> like this a
On Mon, May 10, 2010 at 11:50:23AM +0200, Martin Becker wrote:
> I'd argue against a default setting where floating point numbers
> are less precise than integers.
I believe this has always been the case on our 64-bit architectures
(ia64, alpha, amd64.)
On current sid / amd64 (perl 5.10.1-12):
On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > The benefits are obviously improved numeric range and precision. The
> > downside is presumably increased memory usage. I have no measurement
> > data on this; suggestions on suitable tests would be welcome.
>
>
On Sun, May 09, 2010 at 12:25:43PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > Given that we've already run into a dozen or so incompatibilities
> > with just the CPAN modules, -Duselongdouble seems to be a pretty
> > rare thing to do. I'm inclined to revert this setting.
>
> That is, 64 bi
On Sun, May 09, 2010 at 12:17:56PM +0200, Florian Weimer wrote:
> So it boils down to malloc granularity (I don't think Perl's allocator
> is used on Debian). For that, I wrote this little test program:
While we do use the system malloc(), I think Perl allocates bigger chunks
at a time and thus
* Niko Tyni:
> I wasn't initially going for long doubles, but several upstream
> developers recommended that they be enabled together.
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00773.html
This shows that long doubles are not backwards-compatible. 8-) The
root cause
* Stefan Fritsch:
> I may be a bit late to this discussion, but aren't 64bit ints (and
> especially pack/unpack "Q") very useful for 64bit file pointers and
> such? IMHO, this means that they would also be very useful on
> "smaller" architectures like arm.
Yes, they are, and that's where I hav
On Wednesday 05 May 2010, Brendan O'Dea wrote:
> > It would be possible to choose these settings separately for each
> > architecture. Should I exclude the 'smaller' architectures
> > (armel, mips*?)
>
> You could ask debian-...@lists.debian.org and the other ports
> lists, but it seems reasonable
On Sat, May 08, 2010 at 03:44:03PM +, Philipp Kern wrote:
> On 2010-05-08, Frans Pop wrote:
> > archkernel userland
> > -- --
> > alpha 32 32
>
> Isn't alpha the first 64bit of all?
>
> > mips/mipsel 3
On Saturday 08 May 2010, Julien Cristau wrote:
> alpha is all 64.
Shows that alpha is the arch I'm least familiar with...
> and sparc kernel is 64.
This I should have gotten right :-(
Thanks.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
On 2010-05-08, Frans Pop wrote:
> arch kernel userland
> ----
> alpha 32 32
Isn't alpha the first 64bit of all?
> mips/mipsel 32 32
I think that's 32/64, 32; at least for mipsel.
> sparc 32
On Sat, May 8, 2010 at 17:15:50 +0200, Frans Pop wrote:
> Niko Tyni wrote:
> > Can anybody list our "pure" 32-bit architectures off-hand
> > or suggest a simple test?
>
> AFAIK for Squeeze the arches are as follows, but please anybody correct me
> where incorrect.
>
> arch kernel
Niko Tyni wrote:
> Can anybody list our "pure" 32-bit architectures off-hand
> or suggest a simple test?
AFAIK for Squeeze the arches are as follows, but please anybody correct me
where incorrect.
archkernel userland
-- --
i3863
On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote:
> * Niko Tyni:
>
> > The benefits are obviously improved numeric range and precision. The
> > downside is presumably increased memory usage. I have no measurement
> > data on this; suggestions on suitable tests would be welcome.
>
>
On 4 May 2010 22:54, Niko Tyni wrote:
> unlike earlier versions, perl 5.12.0-1 in experimental is configured with
> the "use64bitint" and "uselongdouble" options on all architectures. I'm
> looking for input on whether this is the right choice for sid.
Sounds like a good idea to me. I had intend
* Niko Tyni:
> The benefits are obviously improved numeric range and precision. The
> downside is presumably increased memory usage. I have no measurement
> data on this; suggestions on suitable tests would be welcome.
I have run into several incompatibilities between i386 and amd64 due
to differ
On Fri, Jan 01, 2010 at 03:18:17PM +0100, Magnus Holmgren wrote:
> Would a new package relationship, say "Post-Depends", be helpful?
No. Too many of our maintainers can't even follow the semantics of the
relationship fields we /already/ have...
--
Steve Langasek Give me a lev
On fredagen den 23 oktober 2009, Don Armstrong wrote:
> Currently there is a proposal[0] to combine perl-modules and perl into
> a single package. perl-modules currently contains architecture
> independent bits, and perl contains architecture dependent bits.
>
> FWICT, the primary argument[1] to d
On Sun, Oct 25, 2009 at 05:52:46PM -0700, Don Armstrong wrote:
> On Sun, 25 Oct 2009, Peter Samuelson wrote:
> > [Don Armstrong]
> > > I actually suggested that perl-modules recommend perl, but that was
> > > rejected for the reason that perl-modules doesn't do anything useful
> > > without perl.
>
On Sun, 25 Oct 2009, Peter Samuelson wrote:
> [Don Armstrong]
> > I actually suggested that perl-modules recommend perl, but that was
> > rejected for the reason that perl-modules doesn't do anything useful
> > without perl.
>
> You sure?
I'm sure that it was the reason given, but I didn't have
[Don Armstrong]
> I actually suggested that perl-modules recommend perl, but that was
> rejected for the reason that perl-modules doesn't do anything useful
> without perl.
You sure? That surprises me - I would have thought a lot of the
modules in perl-modules only needed perl-base.
--
Peter Sa
James Vega wrote:
>> However, I agree that in almost all cases (including this case) it
>> seems silly for any other package to depend on B or for users to
>> install B directly. I actually suggested that perl-modules recommend
>> perl, but that was rejected for the reason that perl-modules doesn't
James Vega wrote:
[...]
> I don't see how perl-modules is that much different than the various
> arch-independent data packages which provide little to no functionality
> on their own but are required by another arch-dependent package. Many
> of those either Recommend the relevant package or decl
On Fri, Oct 23, 2009 at 03:22:34PM -0700, Don Armstrong wrote:
> On Sat, 24 Oct 2009, Josselin Mouette wrote:
> > Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit :
> > > 3: Specifically, where Package A Depends on (B=1), and Package B
> > > Depends on A; A and B are from the same
On Sat, 24 Oct 2009, Josselin Mouette wrote:
> Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit :
> > 3: Specifically, where Package A Depends on (B=1), and Package B
> > Depends on A; A and B are from the same source, B is architecture
> > independent, and does not require configu
Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit :
> Because this is a common situtation, where there is architecture
> independent data (of varying sizes) which is interdependent on
> architecture specific code of a particular version, reflexive
> dependencies are necessary.[2]
>
Hi,
On Thu, 2008-08-21 at 00:52:44 +0300, Niko Tyni wrote:
> The only perl scripts provided by Essential packages are
>
> /usr/bin/scriptreplay
This one comes from bsdutils, and it's fairly short (around 30 lines
with comments).
> /usr/bin/chkdupexe
And this one is a bit longer, but still shor
On Thu, Jul 03, 2008 at 08:11:05PM +0100, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#489132: lenny release notes, upgrade dpkg
> first"):
> > To work-around a problem that can happen in the perl 5.10 upgrade (see
> > #479711), the perl scripts contained in dpkg (update-alternatives,
> > dpk
On Thu, Jul 03, 2008 at 10:17:47PM +0200, Raphael Hertzog wrote:
> On Thu, 03 Jul 2008, Ian Jackson wrote:
> > * This problem is clearly release critical. I don't think documenting
> > a release critical bug of this severity in the release notes is
> > acceptable. Furthermore, the proposed w
On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> This is why I suggested to integrate liblocale-gettext-perl in perl-base
> itself. This would be the simplest/nicest solution IMO. It would always be
> synchronized with the current perl.
>
> See http://bugs.debian.org/cgi
On Thu, 03 Jul 2008, Ian Jackson wrote:
> Here is a summary of the problem:
FWIW, the summary is right according to my understanding.
> * This problem is clearly release critical. I don't think documenting
> a release critical bug of this severity in the release notes is
> acceptable. Furth
On Thu, 03 Jul 2008, Ian Jackson wrote:
> * Suppressing lazy symbol resolution may work in this case, but it
> is not correct.
Lazy symbol resolution should be supressed while in eval regardless of
the method which we use to resolve this problem. Non-recoverable
failures from code in eval should
On Thu, 08 May 2008, Niko Tyni wrote:
> > It's the scripts that are doing the eval that must set the environment
> > variable, isn't it? Or do you see a way to force this from the module
> > side?
>
> It's precisely those modules that are doing the eval in the
> Locale::gettext case, and the examp
On Thu, May 08, 2008 at 09:41:35AM +0200, Raphael Hertzog wrote:
> On Wed, 07 May 2008, Niko Tyni wrote:
> > The only room for improvement that I can see here is to always set
> > PERL_DL_NONLAZY=1 when executing an eval statement. This sounds a bit
> > intrusive, but arguably anybody using an eval
On Wed, 07 May 2008, Niko Tyni wrote:
> The only room for improvement that I can see here is to always set
> PERL_DL_NONLAZY=1 when executing an eval statement. This sounds a bit
> intrusive, but arguably anybody using an eval wants to catch any
> exceptions immediately.
>
> I'll bring this up on
(switched a separate cloned bug, #479711. I think we can leave
debian-devel at this point, interested people can subscribe to the bug.)
On Wed, May 07, 2008 at 09:27:28AM +0200, Raphael Hertzog wrote:
> We already had this issue with the perl 5.6 -> 5.8 move, see
> http://bugs.debian.org/cgi-bin
On Saturday 04 June 2005 19.20, Joshua Jackson wrote:
> Where could I find out about projects that still need developers. I could
> code in perl and java. Please tell me where I can read the resources
> regarding to the available projects in debian.
Java: A group of people tries very hard to get
Joshua Jackson:
>
> Where could I find out about projects that still need developers. I could
> code in perl and java. Please tell me where I can read the resources
> regarding to the available projects in debian.
Aside from Debian, you could browse the Sourceforge.net project list
sorted by progr
On Sat, 4 Jun 2005, Joshua Jackson wrote:
Where could I find out about projects that still need developers. I could
code in perl and java. Please tell me where I can read the resources
regarding to the available projects in debian.
Please take a look at http://webmin.alioth.debian.org/ partic
Re: Carlo U. Segre in <[EMAIL PROTECTED]>
> I noticed that a number of perl packages and perl-tk in particular have
> been orphaned but they do not appear on the "wnpp" list.
>
> Is this beacause they have not been orphaned by the Maintainer himself?
Looking at http://bugs.debian.org/cgi-bin/pkg
On Wed, Nov 19, 2003 at 05:42:29PM +, Colin Watson wrote:
> [...]
> - Fix msqid_ds on MIPS. Dpatch from Guido Guenther, patch by
> Thiemo Seufer (Closes: #215273, #200215, #217593).
> [...]
...additionally the current 2.4.22 mips kernel packages have the
necessary fixes. The mips
On Wed, Nov 19, 2003 at 06:03:39PM +0100, Karsten Merker wrote:
> On Wed, Nov 19, 2003 at 02:58:16PM +, Colin Watson wrote:
> > On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote:
> > > i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
> > >
> > > why it is in this
On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote:
> i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
>
> why it is in this state? it blocks the build of a lot of software.
I'm told that getting it past the test suite requires a newer kernel,
which our mips buildds d
Domenico Andreoli, 2003-11-19 11:30:17 +0100 :
> i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
>
> why it is in this state? it blocks the build of a lot of software.
I'm currently building it by hand.
Roland.
--
Roland Mas
Qu'est-ce qui est petit, jaune et vachement dangereux
Michel Loos <[EMAIL PROTECTED]> writes:
> Em Qui, 2003-03-27 às 19:38, David N. Welton escreveu:
> > [ Please CC me in replies ]
> > Hi, I have emailed the guy who submitted this bug, with no answer.
> > Any Perl people want to have a look at it and see if the problem
> > behavior is still there?
On Thu, Aug 29, 2002 at 10:28:43AM +0100, Colin Watson wrote:
> On Thu, Aug 29, 2002 at 10:34:04AM +0200, Marcelo E. Magallon wrote:
r > >> Brian May <[EMAIL PROTECTED]> writes:
> > > I don't have an unstable system handy...
> > >
> > > So can anybody tell if if perl 5.8 has Unix::Syslog?
> >
On Thu, Aug 29, 2002 at 12:00:41PM +0200, Marcelo E. Magallon wrote:
> Looking at the dependency line, yes, that seems to be the case. My
> guess is the reporter performed a dist-upgrade and that removed the
> libunix-syslog-perl package.
Something like that.. My mail was bouncing for about 8
On Thu, Aug 29, 2002 at 12:23:06PM +0200, Marek Habersack wrote:
> On Thu, Aug 29, 2002 at 11:16:53AM +0100, Colin Watson scribbled:
> > $ dlocate bytes.pm
> > perl-modules: /usr/share/perl/5.8.0/bytes.pm
> > $ dpkg -l perl-modules | grep ^ii
> > ii perl-modules 5.8.0-8Core Perl
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> >> Brian May <[EMAIL PROTECTED]> writes:
>
> > I don't have an unstable system handy...
> >
> > So can anybody tell if if perl 5.8 has Unix::Syslog?
> >
> > Do I need to add an extra depends or something to amavis?
>
> Uhm...
>
> http
On Thu, Aug 29, 2002 at 11:16:53AM +0100, Colin Watson scribbled:
> On Thu, Aug 29, 2002 at 12:10:41PM +0200, Marek Habersack wrote:
> > perl-base contains Data/Dumper.pm, that in turn wants to use bytes.pm
> > which used to be in perl-modules for perl 5.6 - it doesn't exists in
> > perl-modules
On Thu, Aug 29, 2002 at 12:10:41PM +0200, Marek Habersack wrote:
> perl-base contains Data/Dumper.pm, that in turn wants to use bytes.pm
> which used to be in perl-modules for perl 5.6 - it doesn't exists in
> perl-modules for 5.8.
$ dlocate bytes.pm
perl-modules: /usr/share/perl/5.8.0/bytes
On Thu, Aug 29, 2002 at 07:51:20PM +1000, Brian May wrote:
> > Unix::Syslog wasn't part of the perl package even for 5.6.1. Looks
> > like libunix-syslog-perl need to be recompiled for 5.8.
>
> I take it that my package is OK then because it depends on
> libunix-syslog-perl?
Looking at
On Thu, Aug 29, 2002 at 10:34:04AM +0200, Marcelo E. Magallon wrote:
> Uhm...
>
> http://makeashorterlink.com/?N240364A1
>
> Unix::Syslog wasn't part of the perl package even for 5.6.1. Looks
> like libunix-syslog-perl need to be recompiled for 5.8.
I take it that my package is OK then beca
On Thu, Aug 29, 2002 at 10:34:04AM +0200, Marcelo E. Magallon wrote:
> >> Brian May <[EMAIL PROTECTED]> writes:
> > I don't have an unstable system handy...
> >
> > So can anybody tell if if perl 5.8 has Unix::Syslog?
> >
> > Do I need to add an extra depends or something to amavis?
>
> Uh
>> Brian May <[EMAIL PROTECTED]> writes:
> I don't have an unstable system handy...
>
> So can anybody tell if if perl 5.8 has Unix::Syslog?
>
> Do I need to add an extra depends or something to amavis?
Uhm...
http://makeashorterlink.com/?N240364A1
Unix::Syslog wasn't part of the perl
I don't have an unstable system handy...
So can anybody tell if if perl 5.8 has Unix::Syslog?
Do I need to add an extra depends or something to amavis?
--
Brian May <[EMAIL PROTECTED]>
--- Begin Message ---
| CCed to Mark, the author.
Thanks Brian.
| > I discovered the hard way that perl 5.8 br
>>"Brendan" == Brendan O'Dea <[EMAIL PROTECTED]> writes:
Brendan> Note that in addition, since perl 5.8.0 includes some
Brendan> modules which were previously stand-alone, any package
Brendan> declaring a versioned[0] dependency on:
Brendan> libcgi-perl,
Brendan> needs to either have
On Mon, Aug 26, 2002 at 05:57:50PM +1000, Brendan O'Dea wrote:
> > If those package are still going to be shipped separately (because
> > they're going to evolve outside the perl core), then they should stay
> > in the archive and perl must add Provides for them. Hence, the user
> > can still
On Mon, Aug 26, 2002 at 09:33:51AM +0200, Jérôme Marant wrote:
>On Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea wrote:
>> Note that in addition, since perl 5.8.0 includes some modules which were
>> previously stand-alone, any package declaring a versioned[0] dependency
>> on:
>>
>> l
On Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea wrote:
> On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
> >perl 5.8 will enter unstable at the next dinstall run. Before it can
> >make testing though, we have to update the following 84 packages which
> >still depend on perlapi-5.
Le Sun, Aug 25, 2002 at 01:33:36PM -0700, Ryan Murray écrivait:
> while the build-depends on perl were updated, the build-depends for the
> new libdbi were not. You need to update all build-depends that might be
They were in 1.28-1.1 (NMU by Joey), but during the transition the
maintainer uploade
On Sun, Aug 25, 2002 at 07:39:54PM +0200, Raphael Hertzog wrote:
> Le Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea ?crivait:
> > On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
> > >perl 5.8 will enter unstable at the next dinstall run. Before it can
> > >make testing though, we
Le Sun, Aug 25, 2002 at 01:51:18PM -0400, Clint Adams écrivait:
> > Maybe a newer MU came out in between or something. I don't have the NMU
> > anymore, but IIRC it was a simple rebuild.
>
> Yes, two newer MU's actually. The latter was a rebuild for 5.8;
> unfortunately the build-deps weren't upd
> Maybe a newer MU came out in between or something. I don't have the NMU
> anymore, but IIRC it was a simple rebuild.
Yes, two newer MU's actually. The latter was a rebuild for 5.8;
unfortunately the build-deps weren't updated, so it was autobuilt
inconsistently.
Raphael Hertzog wrote:
> What happened to libdbi-perl ?
>
> Joey NMUed it in the pool, but it appears to not have been installed.
Maybe a newer MU came out in between or something. I don't have the NMU
anymore, but IIRC it was a simple rebuild.
--
see shy jo
Le Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea écrivait:
> On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
> >perl 5.8 will enter unstable at the next dinstall run. Before it can
> >make testing though, we have to update the following 84 packages which
> >still depend on perlapi
Brendan O'Dea wrote:
> On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
> >perl 5.8 will enter unstable at the next dinstall run. Before it can
> >make testing though, we have to update the following 84 packages which
> >still depend on perlapi-5.6.*. This list should take into account th
On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
> perl 5.8 will enter unstable at the next dinstall run. Before it can
> make testing though, we have to update the following 84 packages which
> still depend on perlapi-5.6.*. This list should take into account those
> packages that were a
On Sun, 25 Aug 2002, Steve Kowalik wrote:
> If they depend on those packages and perl (>= 5.8.0)?
If they have any sort of versioned dependency on provides (we should make a
list of those), actually.
But since this is a non-local check, and hard to write, I guess tailoring it
to detect dependenci
At 11:06 am, Sunday, August 25 2002, Henrique de Moraes Holschuh mumbled:
> On Sun, 25 Aug 2002, Brendan O'Dea wrote:
> > Note that in addition, since perl 5.8.0 includes some modules which were
> > previously stand-alone, any package declaring a versioned[0] dependency
> > on:
> >
> > libdi
On Sun, 25 Aug 2002, Brendan O'Dea wrote:
> Note that in addition, since perl 5.8.0 includes some modules which were
> previously stand-alone, any package declaring a versioned[0] dependency
> on:
>
> libdigest-md5-perl, libmime-base64-perl, libnet-perl,
> libtime-hires-perl, libstorab
On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
>perl 5.8 will enter unstable at the next dinstall run. Before it can
>make testing though, we have to update the following 84 packages which
>still depend on perlapi-5.6.*. This list should take into account those
>packages that were alrea
> "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
Martin> getpwnam.passwd = x as it is written in /etc/passwd.
Martin> getspwnam.passwd = encrypted password.
Perl doesn't supoprt getspnam(). It used to do a getspnam under the
covers in the getpwnam call in 5.00404 (I wrote the
Kirk Ismay wrote:
> I have just copied one of my perl programs from an old slink system to a
> new machine running potato. Its a perl program for managing users and such.
>
> On slink, getpwnam(foo) returns the hash for the password, on potato i get
> an x.
> Both are using shadow passwords.
>
On Wed, 10 Jan 2001, Matt Zimmerman wrote:
> On Wed, Jan 10, 2001 at 09:01:40AM -0500, Daniel Martin wrote:
>
> > Matt Zimmerman <[EMAIL PROTECTED]> writes:
> >
> > > Well, if someone would like to configure the MTA that runs
> > > bugs.debian.org to
> > > send CC's of all bug mail to another a
On Wed, Jan 10, 2001 at 09:01:40AM -0500, Daniel Martin wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:
>
> > Well, if someone would like to configure the MTA that runs bugs.debian.org
> > to
> > send CC's of all bug mail to another address, ...
>
> You mean something other than signing up
On Tue, Jan 09, 2001 at 04:06:35PM -0800, Ralph Jennings wrote:
The problem is not that easy to solve I think. Basicly the problem is
that you upgrade a tool that the install program depends on. If you install
the perl-5.6 package before anything alse things will probably work just
fine.
The prob
1 - 100 of 259 matches
Mail list logo
