Bug#673614: ITP: python-pyramid-tm -- Transaction management for the Pyramid web framework

[Free Ekanayaka]

Package: wnpp
Owner: Free Ekanayaka 
Severity: wishlist

* Package name: python-pyramid-tm
  Version : 0.4
  Upstream Author : Rocky Burt, Chris McDonough
* URL or Web page : http://pypi.python.org/pypi/pyramid_tm
* License : BSD-derived (http://www.repoze.org/LICENSE.txt)
  Description : Transaction management for the Pyramid web framework

 The pyramid_tm package allows Pyramid requests to join the active
 transaction as provided by the transaction package.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87d35zguyc.fsf@orfeo.i-did-not-set--mail-host-address--so-tickle-me

Re: amd64 as default architecture

[Marc Haber]

On Sun, 20 May 2012 06:11:16 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 20, Ben Hutchings  wrote:
>> Then in wheezy+1:
>> 3. amd64 kernel flavour for i386 dropped.
>Why can't we use the multiarch package in wheezy?

Because changes of this magnitude less than a month before the first
target freeze date are a bad idea and should be done right after a
release so that the change get maximum exposure before it is
considered for a stable release?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sw0ev-0006cu...@swivel.zugschlus.de

Re: amd64 as default architecture

[Goswin von Brederlow]

Ben Hutchings  writes:

> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
>
> For some time we have also provided the amd64 kernel for i386, identical
> in all but the package metadata.  This has not always been perfectly
> compatible with i386 userland, but split 32/64-bit installations are
> increasingly used and I think most bugs have been flushed out by now.
> Thanks to multi-arch you can now add amd64 as a secondary architecture
> and install the kernel package from amd64, and if your system is running
> such a kernel then it can also support userland packages from amd64.
>
> So in wheezy I would like to see:
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').

Default image could be multiple archs. We had i386/amd64/ppc DVD images
in the past and that seems like the best default. It simply works (near
enough) everywhere. Doesn't work for all image types but where it does ...

> 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> a secondary architecture (debconf note?).

2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
installed the amd64 kernel image but also i386 on amd64.

Slightly OT but I wanted to mention it for its similarity:

One thing that should be tested and then documented prominently as yay
or nay in the wheezy upgrade notes is wether one can cross-grade from
i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
then migrate to a 64bit userspace.

> Then in wheezy+1:
> 3. amd64 kernel flavour for i386 dropped.
> 4. Kernel and common libraries for amd64 included in i386 installation
> media; kernel included on low-number disc.
> 5. Installer for i386 prefers amd64 kernel on any capable machine
> (that's a one-line change!) and adds amd64 as secondary architecture if
> this is selected.

D-I (libdebian-installer) must be multiarch aware for that then.
Otherwise it won't see the amd64 kernel in the first place.

> Eventually (wheezy+2? +3?) we would stop building a kernel package for
> i386.

As in drop the i386 arch?

> Does anyone see a problem with the above, in particular points 1 and 2?

No problem as such, just more ideas.

> (Also, much of the above applies to s390x vs s390.  And please let's
> have ppc64 and sparc64 soon!)
>
> Ben.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx53i4mv.fsf@frosties.localnet

Bug#673634: ITP: libjs-slidy -- slide shows in HTML and XHTML

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libjs-slidy
  Version : 0~20120214
  Upstream Author : Dave Raggett 
* URL : http://www.w3.org/Talks/Tools/Slidy2
* License : W3C-Software-20021231
  Programming Lang: JavaScript
  Description : slide shows in HTML and XHTML

 With HTML Slidy you can now create accessible slide shows with ease:
 .
  * Works across browsers and is operated like PowerPoint
* Advance to next slide with mouse click, space bar or swipe left
* Move forward/backward between slides with Cursor Left, Cursor
  Right, Pg Up and Pg Dn keys, or swipe left or right
* Home key for first slide, End key for last slide
* The "C" key for an automatically generated table of contents, or
  click on "contents" on the toolbar or swipe up or down
* Function F11 to go full screen and back
* The "F" key toggles the display of the footer
* The "A" key toggles display of current vs all slides
  * Try it now to see how to include notes for handouts (this is
explained in the notes following this slide)
* Font sizes automatically adapt to browser window size
  * use S and B keys for manual control (or < and >, or the - and +
keys on the number pad
  * Use CSS to set a relative font size on a given slide to make the
content bigger or smaller than on other slides
* Switching off JavaScript reveals all slides



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120520105836.10170.54793.report...@auryn.jones.dk

Re: amd64 as default architecture

[Thomas Goirand]

On 05/20/2012 10:16 AM, Ben Hutchings wrote:
> Does anyone see a problem with the above, in particular points 1 and 2?
>   
I agree with all you said (you know better than I), but what
I would really love to see would be the installer warning
people when they try to install the i386 version on a 64 bits
capable machine.

Yes, it's a bit stupid, but some users still don't understand
that amd64 arch also works on Intel! A very simple debconf menu
in the installer, explaining what's going on, would solve the issue.

Just my 2 cents,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8d109.4080...@goirand.fr

Re: amd64 as default architecture

[Sven Joachim]

On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:

> Slightly OT but I wanted to mention it for its similarity:
>
> One thing that should be tested and then documented prominently as yay
> or nay in the wheezy upgrade notes is wether one can cross-grade from
> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> then migrate to a 64bit userspace.

Won't work in wheezy, apt does not support crossgrades¹.  Making it a
release goal for wheezy+1 seems to be a good idea, but it's a long way
to get there.

Cheers,
   Sven


¹ Replacing foo:i386 with foo:amd64 is done by removing foo:i386 and
  then installing foo:amd64, which does not work for Essential packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa133y6m@turtle.gmx.de

Re: 'php5-suhosin' is missing for wheezy

[Thomas Goirand]

On 05/20/2012 01:29 AM, Christoph Anton Mitterer wrote:
> Hi...
>
>
> On Sat, 2012-05-19 at 15:10 +0200, Alain SAURAT wrote:
>   
>> This package is only avaible for squeeze and sid, is it normal ?
>> 
> In addition to what Cyril already mentioned, see also
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663954
>
> Cheers,
> Chris.
>   
And in addition to that, the Suhosin patch and module are available
for php 5.4 since only few days/weeks, so it's not surprising that
it's not in testing.

I'm not sure what will be the final decision with suhosin though...
Of course, more contributors to the PHP packaging would help!

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8d4c9.1080...@debian.org

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[David Kalnischkies]

On Sat, May 19, 2012 at 2:00 PM, Julian Andres Klode  wrote:
> = Flat Repository Format =
>
> A flat repository does not use the {{{dists}}} hierarchy of directories,
> and instead places meta index and indices directly into the archive root
> (or some part below it) In sources.list syntax, a flat repository is specified
> like this:
>
> {{{
>   deb uri directory/
> }}}

I don't think defining sources.list syntax in a client-agnostic document
is a good move. APT has the 'sources.list' manpage for it and other clients
might or might not have different ways to specify repositories.
(beside, that it would be deb-src, too)


> !InRelease, Release, Release.gpg meta-information are supported as well. 
> Diffs,
> Translations, and Contents indices are not defined for that repository format.
> Indices may be compressed just like in the standard Debian repository format.

Translations are supported, although with a different name: directory/en
(and co) instead of Translation-en. For Contents i am not sure, but i think
apt-file downloads these, too. (not sure if this should be a reason to include
it in a specification through or just keep it as some legacy cruft around)

Diffs are supported by apt, but it will not be used if not in Release.
(if no Release file is present, diffs will not be tried).
It's the same for the non-flat repository and true for other files as well
- and should be a reasonable thing to allow clients to do.


In that train of thought, I think it would be a good idea to require a
repository to have a Release (or InRelease) file including all files
[in their current state] composing this repository.
They are easy to create and this way a client could stop guessing if
they like to, avoiding possibly a lot of 404's.
Best combined with a strong recommendation on signing them.


Best regards

David Kalnischkies

P.S.: Could we please stop talking to three bugs and two mailinglists?
Especially as [0] suggests it is the wrong list…
[0] http://lists.debian.org/debian-devel/2012/05/msg00222.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caaz6_fbybj8mqxssmdjm3naxq9v62usw3w-3juea-8eng...@mail.gmail.com

Re: amd64 as default architecture

[David Kalnischkies]

On Sun, May 20, 2012 at 1:10 PM, Sven Joachim  wrote:
> On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>
>> Slightly OT but I wanted to mention it for its similarity:
>>
>> One thing that should be tested and then documented prominently as yay
>> or nay in the wheezy upgrade notes is wether one can cross-grade from
>> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> then migrate to a 64bit userspace.
>
> Won't work in wheezy, apt does not support crossgradesน.

There is no real reason to require apt to do the heavy lifting here.
It would be nice, but it is a one-time action, so a specialized tool wouldn't
hurt muscle memory too much. Install essentials and apt and you should
be good to go to proceed as usual, just with a different architecture…

Even most essentials are easy to crossgrade, the only really difficult one
is dpkg and it's dependencies as you have to take care of not breaking it
while it crossgrades itself.

(I think it is unlikely that apt will get support for that soon, if at all,
 given that it quiet easily becomes a quiet complicated situation in
 general in a codearea which isn't short on complexity already.
 And that just for the "once in a blue moon" encounter of a crossgrade?)


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAZ6_fD1OraGQoEWuWe&-1jxtcz+tq0d2x4v7vspfd8ba...@mail.gmail.com

Re: amd64 as default architecture

[Ben Hutchings]

On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> Ben Hutchings  writes:
> 
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
> >
> > For some time we have also provided the amd64 kernel for i386, identical
> > in all but the package metadata.  This has not always been perfectly
> > compatible with i386 userland, but split 32/64-bit installations are
> > increasingly used and I think most bugs have been flushed out by now.
> > Thanks to multi-arch you can now add amd64 as a secondary architecture
> > and install the kernel package from amd64, and if your system is running
> > such a kernel then it can also support userland packages from amd64.
> >
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
> 
> Default image could be multiple archs. We had i386/amd64/ppc DVD images
> in the past and that seems like the best default. It simply works (near
> enough) everywhere. Doesn't work for all image types but where it does ...

The default image *is* i386/amd64 netinst.

> > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > a secondary architecture (debconf note?).
> 
> 2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
> installed the amd64 kernel image but also i386 on amd64.

Would be good, but might not be possible in time for wheezy.

> Slightly OT but I wanted to mention it for its similarity:
> 
> One thing that should be tested and then documented prominently as yay
> or nay in the wheezy upgrade notes is wether one can cross-grade from
> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> then migrate to a 64bit userspace.

I don't believe this is easily doable yet.  (It was possible, with
difficulty, even before multi-arch.)

> > Then in wheezy+1:
> > 3. amd64 kernel flavour for i386 dropped.
> > 4. Kernel and common libraries for amd64 included in i386 installation
> > media; kernel included on low-number disc.
> > 5. Installer for i386 prefers amd64 kernel on any capable machine
> > (that's a one-line change!) and adds amd64 as secondary architecture if
> > this is selected.
> 
> D-I (libdebian-installer) must be multiarch aware for that then.
> Otherwise it won't see the amd64 kernel in the first place.

Yes.

> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > i386.
> 
> As in drop the i386 arch?

No, keep i386 userland only.  Though we might consider reducing even
that to a 'partial architecture' that has only libraries (similar to
ia32-libs today, only cleaner).

Ben.

> > Does anyone see a problem with the above, in particular points 1 and 2?
> 
> No problem as such, just more ideas.
> 
> > (Also, much of the above applies to s390x vs s390.  And please let's
> > have ppc64 and sparc64 soon!)
> >
> > Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

Re: amd64 as default architecture

[Marco d'Itri]

On May 20, Ben Hutchings  wrote:

> No, keep i386 userland only.  Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
Don't you believe in x32?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: amd64 as default architecture

[Ben Hutchings]

On Sun, 2012-05-20 at 16:41 +0200, Marco d'Itri wrote:
> On May 20, Ben Hutchings  wrote:
> 
> > No, keep i386 userland only.  Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> Don't you believe in x32?

What do you mean, 'believe'?  I'm aware it may allow some applications
to be somewhat more efficient than either i386 or amd64.  I doubt it's
worth adding to the Debian archive, but if we did then I imagine it
would also be as a partial architecture.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

Re: amd64 as default architecture

[Marco d'Itri]

On May 20, Ben Hutchings  wrote:

> > > No, keep i386 userland only.  Though we might consider reducing even
> > > that to a 'partial architecture' that has only libraries (similar to
> > > ia32-libs today, only cleaner).
> > Don't you believe in x32?
> What do you mean, 'believe'?  I'm aware it may allow some applications
> to be somewhat more efficient than either i386 or amd64.  I doubt it's
> worth adding to the Debian archive, but if we did then I imagine it
> would also be as a partial architecture.
I cannot see any use case, except supporting proprietary software, 
where a i386 userland-only port would be more useful of a x32 port 
(which would be userland-only by definition).
I think that we should be seriouly investigating the merits of a x32 
port once we are done with multiarch.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: amd64 as default architecture

[Andreas Barth]

* Marco d'Itri (m...@linux.it) [120520 17:31]:
> On May 20, Ben Hutchings  wrote:
> 
> > > > No, keep i386 userland only.  Though we might consider reducing even
> > > > that to a 'partial architecture' that has only libraries (similar to
> > > > ia32-libs today, only cleaner).
> > > Don't you believe in x32?
> > What do you mean, 'believe'?  I'm aware it may allow some applications
> > to be somewhat more efficient than either i386 or amd64.  I doubt it's
> > worth adding to the Debian archive, but if we did then I imagine it
> > would also be as a partial architecture.
> I cannot see any use case, except supporting proprietary software, 
> where a i386 userland-only port would be more useful of a x32 port 
> (which would be userland-only by definition).

Two issues:

1. Migration of existing systems is easier.
2. There are still machines bought new which aren't ready for x32.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520153906.gj2...@mails.so.argh.org

Re: amd64 as default architecture

[Mike Hommey]

On Sun, May 20, 2012 at 02:00:21PM +0100, Ben Hutchings wrote:
> On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> > Ben Hutchings  writes:
> > 
> > > Most new PCs have an Intel or AMD 64-bit processor, and
> > > popcon.debian.org shows amd64 numbers almost matching i386.
> > >
> > > For some time we have also provided the amd64 kernel for i386, identical
> > > in all but the package metadata.  This has not always been perfectly
> > > compatible with i386 userland, but split 32/64-bit installations are
> > > increasingly used and I think most bugs have been flushed out by now.
> > > Thanks to multi-arch you can now add amd64 as a secondary architecture
> > > and install the kernel package from amd64, and if your system is running
> > > such a kernel then it can also support userland packages from amd64.
> > >
> > > So in wheezy I would like to see:
> > > 1. Default architecture (top of the list for installation media/manual)
> > > being amd64 ('64-bit PC').
> > 
> > Default image could be multiple archs. We had i386/amd64/ppc DVD images
> > in the past and that seems like the best default. It simply works (near
> > enough) everywhere. Doesn't work for all image types but where it does ...
> 
> The default image *is* i386/amd64 netinst.
> 
> > > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > > a secondary architecture (debconf note?).
> > 
> > 2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
> > installed the amd64 kernel image but also i386 on amd64.
> 
> Would be good, but might not be possible in time for wheezy.
> 
> > Slightly OT but I wanted to mention it for its similarity:
> > 
> > One thing that should be tested and then documented prominently as yay
> > or nay in the wheezy upgrade notes is wether one can cross-grade from
> > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> > then migrate to a 64bit userspace.
> 
> I don't believe this is easily doable yet.  (It was possible, with
> difficulty, even before multi-arch.)
> 
> > > Then in wheezy+1:
> > > 3. amd64 kernel flavour for i386 dropped.
> > > 4. Kernel and common libraries for amd64 included in i386 installation
> > > media; kernel included on low-number disc.
> > > 5. Installer for i386 prefers amd64 kernel on any capable machine
> > > (that's a one-line change!) and adds amd64 as secondary architecture if
> > > this is selected.
> > 
> > D-I (libdebian-installer) must be multiarch aware for that then.
> > Otherwise it won't see the amd64 kernel in the first place.
> 
> Yes.
> 
> > > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > > i386.
> > 
> > As in drop the i386 arch?
> 
> No, keep i386 userland only.  Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).

How would plain x86 systems be supposed to boot, then?

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520162423.ga5...@glandium.org

Re: amd64 as default architecture

[Andrey Rahmatullin]

On Sun, May 20, 2012 at 06:24:23PM +0200, Mike Hommey wrote:
> > > > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > > > i386.
> > > 
> > > As in drop the i386 arch?
> > 
> > No, keep i386 userland only.  Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> 
> How would plain x86 systems be supposed to boot, then?
Using wheezy+1 (+2?).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: amd64 as default architecture

[Ben Hutchings]

On Sun, 2012-05-20 at 18:24 +0200, Mike Hommey wrote:
> On Sun, May 20, 2012 at 02:00:21PM +0100, Ben Hutchings wrote:
> > On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> > > Ben Hutchings  writes:
> > > 
> > > > Most new PCs have an Intel or AMD 64-bit processor, and
> > > > popcon.debian.org shows amd64 numbers almost matching i386.
> > > >
> > > > For some time we have also provided the amd64 kernel for i386, identical
> > > > in all but the package metadata.  This has not always been perfectly
> > > > compatible with i386 userland, but split 32/64-bit installations are
> > > > increasingly used and I think most bugs have been flushed out by now.
> > > > Thanks to multi-arch you can now add amd64 as a secondary architecture
> > > > and install the kernel package from amd64, and if your system is running
> > > > such a kernel then it can also support userland packages from amd64.
> > > >
> > > > So in wheezy I would like to see:
> > > > 1. Default architecture (top of the list for installation media/manual)
> > > > being amd64 ('64-bit PC').
> > > 
> > > Default image could be multiple archs. We had i386/amd64/ppc DVD images
> > > in the past and that seems like the best default. It simply works (near
> > > enough) everywhere. Doesn't work for all image types but where it does ...
> > 
> > The default image *is* i386/amd64 netinst.
> > 
> > > > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > > > a secondary architecture (debconf note?).
> > > 
> > > 2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
> > > installed the amd64 kernel image but also i386 on amd64.
> > 
> > Would be good, but might not be possible in time for wheezy.
> > 
> > > Slightly OT but I wanted to mention it for its similarity:
> > > 
> > > One thing that should be tested and then documented prominently as yay
> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> > > then migrate to a 64bit userspace.
> > 
> > I don't believe this is easily doable yet.  (It was possible, with
> > difficulty, even before multi-arch.)
> > 
> > > > Then in wheezy+1:
> > > > 3. amd64 kernel flavour for i386 dropped.
> > > > 4. Kernel and common libraries for amd64 included in i386 installation
> > > > media; kernel included on low-number disc.
> > > > 5. Installer for i386 prefers amd64 kernel on any capable machine
> > > > (that's a one-line change!) and adds amd64 as secondary architecture if
> > > > this is selected.
> > > 
> > > D-I (libdebian-installer) must be multiarch aware for that then.
> > > Otherwise it won't see the amd64 kernel in the first place.
> > 
> > Yes.
> > 
> > > > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > > > i386.
> > > 
> > > As in drop the i386 arch?
> > 
> > No, keep i386 userland only.  Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> 
> How would plain x86 systems be supposed to boot, then?

If by 'plain x86' you mean PCs with 32-bit processors, we would no
longer support them - *eventually*.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

removal of Qt3

[Ana Guerrero]

Hi,

A couple of weeks ago was the first anniversary of orphaning Qt3 in Debian
http://lists.debian.org/debian-devel/2011/05/msg00236.html
The orphaning bug is #625502

In this year, Qt3 has got a few QA uploads with the most relevant change
being support to multiarch. And, more importantly, nobody seemed to care
enough to step into maintaining it.

In the last days, I have taken a look into how much needed to be done to
remove Qt3 and there were slightly more than 50 packages depending directly
or indirectly from Qt3. A removal from Wheezy seemed doable
given that removing packages is never a problem during the Debian freeze ;-)

All the packages affected have a bug opened since more than one year and
half ago and I have pinged all the bugs with some maintainers responding
quick (thanks!). I also filed some removals for packages that
were clearly unmaintaineed and didn't seem worth keeping with ftp-masters
responding quick too (Thanks!). And a couple of QA upload
for orphaned software that were still useful without Qt3.

There is a wiki page tracking the status of the removal if you are curious:
http://wiki.debian.org/qt3-x11-freeRemoval

If in the future, you are reading this and you need Qt3 in Wheezy, you can
fetch it from Debian snapshots:
http://snapshot.debian.org/package/qt-x11-free/

Ana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520165820.ga16...@pryan.ekaia.org

Re: amd64 as default architecture

[Russ Allbery]

Ben Hutchings  writes:

> If by 'plain x86' you mean PCs with 32-bit processors, we would no
> longer support them - *eventually*.

Excactly like how we no longer support pure i386 systems (as opposed to
i486 or later).  And with the same sort of criteria, I suspect.  Note that
Ben is talking about 3-5 years into the future, if not more.

-- 
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
Archive: http://lists.debian.org/87aa12eom9@windlord.stanford.edu

Re: amd64 as default architecture

[Steve McIntyre]

Marco wrote:
>On May 20, Ben Hutchings  wrote:
>
>> No, keep i386 userland only.  Though we might consider reducing even
>> that to a 'partial architecture' that has only libraries (similar to
>> ia32-libs today, only cleaner).
>Don't you believe in x32?

Puke. Please, no. If it had happened back when amd64 was starting up,
it might have looked useful. Now it's a joke and a waste of time.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1swbsa-0004ak...@mail.einval.com

Re: amd64 as default architecture

[Josh Triplett]

Ben Hutchings wrote:
>On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
>> Ben Hutchings  writes:
>>> Eventually (wheezy+2? +3?) we would stop building a kernel package
>>> for i386.
>> 
>> As in drop the i386 arch?
> 
> No, keep i386 userland only.  Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).

I'd love to see that happen someday, but at the moment, new x86 systems
still get sold that don't support 64-bit.  Notably, many low-power Atom
processors still don't support 64-bit.  If at some point 64-bit becomes
a required feature on all new x86 processors, with a definite indication
that no new 32-bit-only processors will ever show up, then a few years
after that this change could become reasonable.

The rest of your plan, namely migrating the 64-bit kernel to a multiarch
package instead of an i386 package, seems appropriate as soon as testing
shows that multiarch can smoothly handle it (which probably means after
the wheezy release, for safety).  And automatically enabling multiarch
based on processor capabilities seems like a good plan as well;
eventually, that'll start becoming necessary for manageability, once new
partial architectures start showing up for more fine-grained processor
features.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520210223.GA13123@leaf

Re: amd64 as default architecture

[Ben Hutchings]

On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
> Ben Hutchings wrote:
> >On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings  writes:
> >>> Eventually (wheezy+2? +3?) we would stop building a kernel package
> >>> for i386.
> >> 
> >> As in drop the i386 arch?
> > 
> > No, keep i386 userland only.  Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> 
> I'd love to see that happen someday, but at the moment, new x86 systems
> still get sold that don't support 64-bit.  Notably, many low-power Atom
> processors still don't support 64-bit.

Right, though I think these are going into phones now, not netbooks.

> If at some point 64-bit becomes
> a required feature on all new x86 processors, with a definite indication
> that no new 32-bit-only processors will ever show up, then a few years
> after that this change could become reasonable.
[...]

So about 2030 then?  I don't believe we need to wait that long - for
example, we dropped support for 386-class processors in 2004 even though
Intel was still selling them (finally EOL'd in 9/2007, apparently).  But
certainly we should consider just how many systems might be affected by
changes in minimum specs.

(Should we consider gathering selected hardware specs in popcon?)

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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

Re: amd64 as default architecture

[Steve Langasek]

On Sun, May 20, 2012 at 05:39:06PM +0200, Andreas Barth wrote:
> > > > > No, keep i386 userland only.  Though we might consider reducing even
> > > > > that to a 'partial architecture' that has only libraries (similar to
> > > > > ia32-libs today, only cleaner).
> > > > Don't you believe in x32?
> > > What do you mean, 'believe'?  I'm aware it may allow some applications
> > > to be somewhat more efficient than either i386 or amd64.  I doubt it's
> > > worth adding to the Debian archive, but if we did then I imagine it
> > > would also be as a partial architecture.
> > I cannot see any use case, except supporting proprietary software, 
> > where a i386 userland-only port would be more useful of a x32 port 
> > (which would be userland-only by definition).

> 1. Migration of existing systems is easier.
> 2. There are still machines bought new which aren't ready for x32.

Any such machine would also need a 32-bit kernel, so doesn't seem to be what
we're talking about here.

-- 
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
Archive: http://lists.debian.org/20120521000754.ga4...@virgil.dodds.net

Re: amd64 as default architecture

[Wookey]

+++ Ben Hutchings [2012-05-21 00:30 +0100]:
> 
> (Should we consider gathering selected hardware specs in popcon?)

Yes please. This would really help arm people too. We currently have
to guess how many people we are cutting off when minimum support is
moved forward. 

Wookey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521002501.gk11...@stoneboat.aleph1.co.uk

Re: amd64 as default architecture

[Charles Plessy]

Le Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings a écrit :
> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
> > 
> > I'd love to see that happen someday, but at the moment, new x86 systems
> > still get sold that don't support 64-bit.  Notably, many low-power Atom
> > processors still don't support 64-bit.
> 
> Right, though I think these are going into phones now, not netbooks.

Fit-PC sells an excellent fanless mini-PC with an Atom Z510 that does not
support 64-bit instructions.  It consumes 8 W according to the manufacturer,
which is less than some Arm-based plug computers.  I am the happy owner of one
of them and would be quite sad to have to replace it in two years in order to
keep on using Debian Stable on my personal server.

By the way, are there plans to drop the support of the i386 architecture with
kFreeBSD as well ?

Cheers,

-- 
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
Archive: http://lists.debian.org/20120521004559.ga23...@falafel.plessy.net

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Marco d'Itri]

On May 18, Russ Allbery  wrote:

> I do this work in cases where keeping the patches separate is useful for
> some reason, but mostly it's not.
Some of my packages have 30-60 patches ("mature" software...), and 
merging them would make them impossibile to understand.
Is there a VCS workflow which would make such packages easier to manage 
than with quilt? (I like quilt, BTW.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: 'php5-suhosin' is missing for wheezy

[Christoph Anton Mitterer]

On Sun, 2012-05-20 at 19:26 +0800, Thomas Goirand wrote:
> And in addition to that, the Suhosin patch and module are available
> for php 5.4 since only few days/weeks, so it's not surprising that
> it's not in testing.
The earlier we see them in Debian the better, even if the current
suhosin version does not yet handle all new fields of 5.4 ... better
secure just (the old) parts,.. than nothing at all...


> I'm not sure what will be the final decision with suhosin though...
Well I fear it is to not include it anymore... which is very sad, given
the many critical holes PHP suffered from recently.


> Of course, more contributors to the PHP packaging would help!
Would surely be good =)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

gitpkg with a quilt export hook

[Brian May]

On 16 May 2012 19:45, Bastien ROUCARIES  wrote:
> You could use gitpkg with a quilt export hook. i use it regularly with
> imagemagick and it work perfectly (it is gitpkg over git over svn).

Out of curiosity, how do you use that and not have it include changes
to debian/*  ? That appeared to me my problem trying to use this
method. Especially as some of my git commits change files both inside
and outside debian/*

Thanks
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAA0ZO6DTeHx4Jve6RR=yns9zzt5j91ftx3bxodstogtvfnz...@mail.gmail.com

Re: amd64 as default architecture

[Henrique de Moraes Holschuh]

On Sun, 20 May 2012, Russ Allbery wrote:
> Ben Hutchings  writes:
> > If by 'plain x86' you mean PCs with 32-bit processors, we would no
> > longer support them - *eventually*.
> 
> Excactly like how we no longer support pure i386 systems (as opposed to
> i486 or later).  And with the same sort of criteria, I suspect.  Note that
> Ben is talking about 3-5 years into the future, if not more.

Try 10 years, if not 15.  We'll be able to support just i686 3 years from
now, I suppose, but even that is not certain.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521015921.ga3...@khazad-dum.debian.net

Re: removal of Qt3

[Paul Wise]

On Mon, May 21, 2012 at 12:58 AM, Ana Guerrero wrote:

> In the last days, I have taken a look into how much needed to be done to
> remove Qt3 and there were slightly more than 50 packages depending directly
> or indirectly from Qt3. A removal from Wheezy seemed doable
> given that removing packages is never a problem during the Debian freeze ;-)

Doesn't LSB compliance require Qt3 ?

Doesn't look like we can drop Qt3 completely unless we drop LSB or LSB
switches to Qt4.

-- 
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
Archive: 
http://lists.debian.org/CAKTje6FvUmL_4B8CB7f2LB2hKrx_w0CDn=-vvwhzhasddmb...@mail.gmail.com

Re: amd64 as default architecture

[Paul Wise]

On Mon, May 21, 2012 at 8:25 AM, Wookey wrote:
> +++ Ben Hutchings [2012-05-21 00:30 +0100]:
>>
>> (Should we consider gathering selected hardware specs in popcon?)
>
> Yes please. This would really help arm people too. We currently have
> to guess how many people we are cutting off when minimum support is
> moved forward.

There is smolt for that, but folks haven't packaged it for Debian yet:

https://fedorahosted.org/smolt/
http://bugs.debian.org/435058

-- 
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
Archive: 
http://lists.debian.org/caktje6g0w71sc1cemnthf0qeehpezsbwp86a2+awcrfrink...@mail.gmail.com

Re: amd64 as default architecture

[Miles Bader]

Paul Wise  writes:
> There is smolt for that, but folks haven't packaged it for Debian yet:
>
> https://fedorahosted.org/smolt/
> http://bugs.debian.org/435058

Hmm... from "http://smolts.org/static/stats/stats.html":

   The statistics script is no longer running and creating new
   data. We're in the process of decomissioning smolt. Please take a
   look at the census project if you'd like to help out with the
   replacement for smolt.

-miles

-- 
Quack, n. A murderer without a license.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87likmhyxw@catnip.gol.com

Re: amd64 as default architecture

[Paul Wise]

On Mon, May 21, 2012 at 1:42 PM, Miles Bader wrote:
> Paul Wise  writes:
>> There is smolt for that, but folks haven't packaged it for Debian yet:
>>
>> https://fedorahosted.org/smolt/
>> http://bugs.debian.org/435058
>
> Hmm... from "http://smolts.org/static/stats/stats.html":
>
>   The statistics script is no longer running and creating new
>   data. We're in the process of decomissioning smolt. Please take a
>   look at the census project if you'd like to help out with the
>   replacement for smolt.

Doesn't look like the replacement is useful yet:

https://fedorahosted.org/census/log/

-- 
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
Archive: 
http://lists.debian.org/caktje6e393tpwtjit13emgcry6o8uacc2hxc3whk0xoqoju...@mail.gmail.com

Moving the target of localization pokes (and eventually NMUs)...

[Christian PERRIER]

With the final steps of the release of Wheezy approaching, I will, from
now on, move the focus of my l10n attention to packages that are blocking
some of the localization goals.

One of them is 100% completeness for debconf translations in wheezy
for seven languages: Czech, Swedish, Spanish, Portuguese, German,
Russian and French.

As a consequence, I will now be nagging *hardly* the maintainers of
packages that are blocking this 100%  completeness. These packages are
listed on the following pages:
http://www.debian.org/international/l10n/po-debconf/cs
http://www.debian.org/international/l10n/po-debconf/sv
http://www.debian.org/international/l10n/po-debconf/es
http://www.debian.org/international/l10n/po-debconf/pt
http://www.debian.org/international/l10n/po-debconf/de
http://www.debian.org/international/l10n/po-debconf/ru
http://www.debian.org/international/l10n/po-debconf/fr

...at the top of each page.

For most, if not all, of them, there are pending translations in the
BTS. Fortunately, all of these are recent enough, and I hope
maintainers will be reactive to my pokes (if they aren't, then NMUs
will be on their way..:-)).

Packages that have something waiting in the BTS (I don't have info for
Portuguese that isn't using the l10n tracking robot):

postfixadmin (cs,sv,es,de,ru,fr)
glance (cs,sv,es,de,ru,fr)
xfonts-traditional (cs,sv,es,de,ru,fr)
xsp (sv)
auctex (es)
lxc (es)
gitalist (es)
graphite-carbon (es,de,ru,fr)
condor (fr)
mumble-django (de,fr)

dd-list of maintainers:

Condor Developers 
   condor

Daniel Baumann 
   lxc

Davide G. M. Salvetti 
   auctex

Debian Mono Group 
   xsp

Debian VoIP Team 
   mumble-django

Dylan R. E. Moonfire 
   xsp (U)

Ghe Rivero 
   glance (U)

Ian Jackson 
   xfonts-traditional

Jo Shields 
   xsp (U)

Jonas Genannt 
   gitalist
   graphite-carbon
   lxc (U)

Jonathan Yu 
   gitalist (U)

Julien Danjou 
   glance (U)

Kilian Krause 
   mumble-django (U)

Michael Hanke 
   condor (U)

Michael Ziegler 
   mumble-django (U)

Mirco Bauer 
   xsp (U)

Norman Messtorff 
   postfixadmin

OHURA Makoto 
   auctex (U)

Patrick Matthäi 
   mumble-django (U)

PKG OpenStack 
   glance

Thomas Goirand 
   glance (U)





-- 




signature.asc
Description: Digital signature

Re: amd64 as default architecture

[Aníbal Monsalve Salazar]

On Mon, May 21, 2012 at 01:11:21PM +0800, Paul Wise wrote:
>On Mon, May 21, 2012 at 8:25 AM, Wookey wrote:
>>On Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings wrote:
>>>
>>>(Should we consider gathering selected hardware specs in popcon?)
>>
>>Yes please. This would really help arm people too. We currently have
>>to guess how many people we are cutting off when minimum support is
>>moved forward.
>
>There is smolt for that, but folks haven't packaged it for Debian yet:
>
>https://fedorahosted.org/smolt/
>http://bugs.debian.org/435058

kmuto had/has a webpage about hardware used on machines running Debian.
I cannot recall its address at the moment.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521055255.ga5...@debian.org

Re: amd64 as default architecture

[Chow Loong Jin]

On 21/05/2012 08:45, Charles Plessy wrote:
> Le Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings a écrit :
>> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
>>>
>>> I'd love to see that happen someday, but at the moment, new x86 systems
>>> still get sold that don't support 64-bit.  Notably, many low-power Atom
>>> processors still don't support 64-bit.
>>
>> Right, though I think these are going into phones now, not netbooks.
> 
> Fit-PC sells an excellent fanless mini-PC with an Atom Z510 that does not
> support 64-bit instructions.  It consumes 8 W according to the manufacturer,
> which is less than some Arm-based plug computers.  I am the happy owner of one
> of them and would be quite sad to have to replace it in two years in order to
> keep on using Debian Stable on my personal server.
> 
> By the way, are there plans to drop the support of the i386 architecture with
> kFreeBSD as well ?

I thought we were discussing amd64 being the default architecture for new
installations, rather than the removal of the i386 architecture.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: removal of Qt3

[Neil Williams]

On Mon, 21 May 2012 13:03:04 +0800
Paul Wise  wrote:

> On Mon, May 21, 2012 at 12:58 AM, Ana Guerrero wrote:
> 
> > In the last days, I have taken a look into how much needed to be done to
> > remove Qt3 and there were slightly more than 50 packages depending directly
> > or indirectly from Qt3. A removal from Wheezy seemed doable
> > given that removing packages is never a problem during the Debian freeze ;-)
> 
> Doesn't LSB compliance require Qt3 ?

meh.
 
> Doesn't look like we can drop Qt3 completely unless we drop LSB or LSB
> switches to Qt4.

Does LSB matter? It is an archaic selection of packages which
completely useless for a universal operating system. (It also causes
severe hassle for automated dependency checks in Emdebian or any
Debian derivative.)

Why do we care about LSB? Why do we have to have *all* the LSB
packages when two lsb packages stand out from the rest.

http://qa.debian.org/popcon.php?package=lsb

If lsb-desktop becomes uninstallable it can be dropped like any
other package.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpcfGPqYVj4y.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On May 18, Russ Allbery  wrote:

>> I do this work in cases where keeping the patches separate is useful for
>> some reason, but mostly it's not.

> Some of my packages have 30-60 patches ("mature" software...), and 
> merging them would make them impossibile to understand.
> Is there a VCS workflow which would make such packages easier to manage 
> than with quilt? (I like quilt, BTW.)

In cases like that where quilt is already doing what I want, I've been
known to just check the patches into Git and make sure that I only do git
commits after quilt pop -a.  I do that with our local builds of Heimdal,
for example.

There are more complicated things that let you serialize your patches from
Git commits and turn them into quilt patch sets, but they're mostly ways
to do something quilt-like in Git while avoiding using quilt directly.  If
you're comfortable using quilt directly, I'm not sure they'll buy you
anything.

-- 
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
Archive: http://lists.debian.org/87wr46yqdy@windlord.stanford.edu