Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Ryan Finnie]

Package: wnpp
Severity: wishlist
Owner: Ryan Finnie 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: grub-finnix
  Version : 107
  Upstream Author : N/A, native package
* URL : N/A, native package
* License : GPL
  Programming Lang: Shell (dash-compatible /etc/grub.d hook)
  Description : Build a Finnix bootloader stanza on GRUB 2 systems

Extended description:
 grub-finnix is a GRUB2 configuration hook to boot Finnix, given a 
 compatible ISO.  The stanzas built utilize GRUB 2's loopback mount 
 support to boot a Finnix kernel and initrd, and passes the location of 
 the ISO to Finnix.  Finnix's first-stage initrd then searches for the 
 partition containing the specified ISO.
 .
 Note that there are certain restrictions regarding where the ISO may be 
 placed.  Please see README.Debian for installation instructions and 
 restrictions.

I talked about this briefly with Paul Wise, and while there are several 
existing packages which do similar GRUB loaders for other projects 
(grub-rescue-pc, grml-rescueboot), they are incredibly specialized to 
the target project.  It may be possible to abstract this sort of 
function into a shared package, but IMHO the shared code between them 
would be very small, and discrete packages for each targeted project 
would be better for maintenance.

The code is currently being developed at:
https://code.launchpad.net/~finnix/finnix/grub-finnix-pkg-debian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQqzdpAAoJEH5go6aGro2YV6cQAJOZaaPGxhjVOnNBRoHnm0IF
xJK6Y/HNEaa8rTaDYhlNHm7HRf0gXq6tjS0wvQ8GM2ZjRzScWSqm6j0RbIElEw8J
tBSVBsigkOWva8C+QY3zYIjAQo47vEe/pak0wVab7iO1nY0VB/BehqhWDoDM9Fvt
hy1oi1lVaRTbFEYZFfFvoyFCA610xPkdR4SFepOc3qXYuZPWK/cV24XxQ4c38sNy
LyAU2ykdutQL9IlJgikrI9ctN3ql1OrDn7xRr5c/Ps7E1c4NmmdwWaRJOnCe7o8e
d1DjA9L/LkkkEp/mdMFaFrfk0G30tEA2IFyoYTc5H8eGLRjWWCatT2Q8i60jB3G3
mRLV+BN4yZN8JQUesq9QI1/Lnreil6gYg6SR/E73dEF/MHKvTtwRscCfKgzIXYO7
U0BTtucsaUA1Nd/MPa4BUhhNLMC9mPx8PeCU2z2laY2rf1wkMQCvVMQAnIYOpxfp
SGFFthhMc75JiSgiCsp0NWkI2qa6ZX2x9/gLGFOPsNjMQQKpJhzrxt4HwTXgtb1m
jKcOJyNcgV2sUwMvK5Oy8QCnMM5LVgkvLNFvEfCPclToNRiKFd2Yv4qKyQPesO4B
igjTXpgucdhqMd5kqwhqqJPQ7YFOaitf8EdztuepK00pp2v3JZ/QWbLoyxYYX9Ra
7OHzoWXXtquwTGm8ZOLH
=0FAP
-END PGP SIGNATURE-


-- 
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/20121120075523.25161.82358.report...@sid.snowman.lan

Re: x32 port bootstrap is uploaded

[Helmut Grohne]

On Tue, Nov 20, 2012 at 03:10:04PM +0800, Thomas Goirand wrote:
> Can I also just add the above Debian repo, do --add-architecture,
> and start replacing some packages? How can I for example, replace
> perl, on a running server?

I would guess that using --add-architecture is a recipe for disaster at
this point. Since x32 is not supported in eglibc 2.13, Daniel Schepler
did the natural thing to do and used 2.16. So just installing libc6:x32
will pull in the corresponding libc6 for amd64 and upgrade your
libc6:amd64 due to the nature of m-a:same. Other packages will likely
have a similar effect. Proper x32 support can only reasonably be
achieved in the archive when eglibc is updated to >= 2.16. See #667023
and #672934 for further details. So by the end of the year we should be
there if Aurelien Jarno keeps his promise.

Helmut


-- 
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/20121120083834.ga17...@alf.mars

Re: Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Marco d'Itri]

On Nov 20, Ryan Finnie  wrote:

>   Description : Build a Finnix bootloader stanza on GRUB 2 systems
I think that you should add one or two lines to explain what Finnix is.
At least, the word "rescue" would help a lot...

>  Note that there are certain restrictions regarding where the ISO may be 
>  placed.  Please see README.Debian for installation instructions and 
>  restrictions.
Does this really have to be in the package description?
I think that we can assume the "you should read README.Debian for more 
information" part for all packages...

> I talked about this briefly with Paul Wise, and while there are several 
> existing packages which do similar GRUB loaders for other projects 
Hopefully the wide availability of well integrated rescue systems will 
make happy the few people who complain that in the future the root file 
system is going to be less and less useful as a rescue system.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Gentoo guys starting a fork of udev

[Jon Dowland]

On Mon, Nov 19, 2012 at 01:25:38PM -0600, Steve Langasek wrote:
>   "The core components are always built (which includes systemd itself, as
>   well as udevd and journald).
> 
>   For some uses the configure switches do not provide sufficient modularity. 
>   For example, they cannot be used to build only the man pages, or to build
>   only the tmpfiles tool or udevd."
> 
> I always have the feeling that everyone who is zealously advocating systemd
> simply didn't read the documentation first.

>From what I understand, the sentence above is assuming you are running "make".
Their makefile is well specified, so you can just build udevd by running "make
udevd". However, I have yet to see (and haven't tried) how easy it would be to
actually build all of the udev components from the sysemd source in the context
of a package. I.e., you could not rely on the output of "make install" putting
the files you need into a given directory, I think you'd need to cherry-pick
the files you *know* you need for udev, and tracking that set and changes to it
may prove a real pain.

(I think Matthias tried to make the same point, but I couldn't parse
his email.)


-- 
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/20121120093535.GC10807@debian

Re: debian-devel-digest Digest V2012 #1225

[Nathan]

Can you please remove me from this mailing list.

I've un-subscribed a number of times but I'm still receiving them.

Thanks


On Tue, 20 Nov 2012 02:15:50 -,  
 wrote:



Content-Type: text/plain

debian-devel-digest Digest  Volume 2012 : Issue 1225

Today's Topics:
  Re: Bits from the release team - Fre  [ Neil McGovern  
 ]
  Re: Bug#693637: ITP: q3map2 -- a qua  [ David Bate   
]
  Re: Gentoo guys starting a fork of u  [ Steve Langasek  
 ]
  Re: Gentoo guys starting a fork of u  [ Kevin Toppins  
  Re: Gentoo guys starting a fork of u  [ Matthias Klumpp  
  Re: Gentoo guys starting a fork of u  [ Marc Haber  
  x32 port bootstrap is uploaded[ Daniel Schepler  
  Bug#693738: ITP: r-cran-readbrukerfl  [ Sebastian Gibb  

  Re: Gentoo guys starting a fork of u  [ Paul Wise  ]



--
Using Opera's revolutionary email client: http://www.opera.com/mail/


--
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/op.wn2gi5s10rc...@uk-lon-w048.tradar.com

Re: Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Ryan Finnie]

On 11/20/2012 01:21 AM, Marco d'Itri wrote:
>>   Description : Build a Finnix bootloader stanza on GRUB 2 systems
> I think that you should add one or two lines to explain what Finnix is.
> At least, the word "rescue" would help a lot...

Good idea; looking back, I was writing the description from the view as
a distribution developer, not an end user.  How about:

Description: Boot a Finnix rescue/maintenance ISO from GRUB 2
 grub-finnix is a GRUB 2 configuration hook to boot compatible versions
 of Finnix, a Debian-based rescue and maintenance LiveCD distribution,
 from ISOs stored on the host filesystem. The stanzas built utilize GRUB
 2's loopback mount support to boot a Finnix kernel and initrd, and
 passes the location of the ISO to Finnix.  Finnix's first-stage initrd
 then searches for the partition containing the specified ISO.

>>  Note that there are certain restrictions regarding where the ISO may be 
>>  placed.  Please see README.Debian for installation instructions and 
>>  restrictions.
> Does this really have to be in the package description?
> I think that we can assume the "you should read README.Debian for more 
> information" part for all packages...

True, but that was more to guide the user, given the fact that the
package does absolutely nothing without user configuration.  Perhaps in
postinst I can read in /etc/default/grub-finnix, check if FINNIX_ISO is
set, and if not, mention that it must be configured from
/etc/default/grub-finnix.  The default file itself currently contains
some basic instructions and a mention of README.Debian for more detailed
information.  Suggestions?

RF



signature.asc
Description: OpenPGP digital signature

Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

"Source-only uploads are not allowed."
Why not? May I request a binNMU for the architecture (amd64) I upload?

I currently do not have facilities to build the package in question
with the host running Debian's kernel.
For the package in question it is important to build in the same
environment as the rest of the packages in the distribution.
The sole purpose of the package is to gather as much detail about the
environment as possible, which has been proven to be highly valuable
for security analysis and fixing highly strict test-suites.

Regards,

Dmitrijs.


-- Forwarded message --
From: Debian FTP Masters 
Date: 20 November 2012 11:02
Subject: procenv_0.9-1_source.changes REJECTED
To: James Hunt , x...@debian.org




Source-only uploads are not allowed.

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


-- 
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/canbhluij3vbbjykzsnpncg1kvvk2zmb7dfbyf6nhtvp9x5k...@mail.gmail.com

Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)

[Andrey Rahmatullin]

On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
> "Source-only uploads are not allowed."
> Why not? May I request a binNMU for the architecture (amd64) I upload?
> 
> I currently do not have facilities to build the package in question
> with the host running Debian's kernel.
> For the package in question it is important to build in the same
> environment as the rest of the packages in the distribution.
> The sole purpose of the package is to gather as much detail about the
> environment as possible, which has been proven to be highly valuable
> for security analysis and fixing highly strict test-suites.
The last iteration of this was started at
http://lists.debian.org/debian-devel/2012/10/msg00296.html

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#693792: ITP: ocproxy -- lwip based proxy for openconnect

[David Edmondson]

Package: wnpp
Severity: wishlist
Owner: David Edmondson 

* Package name: ocproxy
  Version : 0.9
  Upstream Author : David Edmondson 
* URL : http://dme.org/ocproxy
* License : BSD
  Programming Lang: C
  Description : lwip based proxy for openconnect

ocproxy is a user-level SOCKS and port-forwarding proxy for use with
openconnect. It allows openconnect to be used by a non-system
administrator and does not require the use of tunnel devices.


-- 
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/20121120114216.30254.225.report...@hotblack-desiato.hh.sledj.net

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Jon Dowland]

On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
> I currently do not have facilities to build the package in question
> with the host running Debian's kernel.

So how can you prove that the package builds?


-- 
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/20121120114516.GA13984@debian

New virtual packages: lv2-plugin and lv2-host

[Alessio Treglia]

Hi everybody,

virtual-package-list.txt.gz [1] says:

   1. Post to debian-devel saying what names you intend to use or what
  other changes you wish to make, and file a wish list bug against the
  package debian-policy.

So, here is my proposal:

--- debian-policy-3.9.4.0/virtual-package-names-list.txt.orig   2012-11-20
11:35:21.592679972 +
+++ debian-policy-3.9.4.0/virtual-package-names-list.txt2012-11-20
11:43:44.071171615 +
@@ -153,6 +153,8 @@
  of a sound card, with a tty interface
  x-audio-mixer   a utility to control the input and output levels
  of a sound card, X Window System interface
+ lv2-hostanything that can host LV2 audio plugins
+ lv2-plugin  an LV2 compliant audio plugin
  mp3-encoder an MP3 encoder package
  mp3-decoder an MP3 decoder package
  mpd-client  a client that can control the Music Player Daemon

Regarding LV2, you may find more information at http://lv2plug.in/.

Cheers,

[1] http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer| quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


-- 
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/CAMHuwoxaAjEwn79VGbg_z-3+C5y1QUrRzox-eKUXU=1ogld...@mail.gmail.com

Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)

[Dmitrijs Ledkovs]

On 20 November 2012 11:14, Andrey Rahmatullin  wrote:
> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
>> "Source-only uploads are not allowed."
>> Why not? May I request a binNMU for the architecture (amd64) I upload?
>>
>> I currently do not have facilities to build the package in question
>> with the host running Debian's kernel.
>> For the package in question it is important to build in the same
>> environment as the rest of the packages in the distribution.
>> The sole purpose of the package is to gather as much detail about the
>> environment as possible, which has been proven to be highly valuable
>> for security analysis and fixing highly strict test-suites.
> The last iteration of this was started at
> http://lists.debian.org/debian-devel/2012/10/msg00296.html
>

I am sorry, if I was not clear. I am aware of the "last iteration",
but I am not enquiring about the default policy within debian as to
how we should upload by default.
I am asking why, when I had a reason to do so, was not able to do a
source-only upload.
Is this a feature of dak, or a policy enforcement?

If it's a policy enforcement, I am ok with it. Otherwise, I'd would
like to see dak accept those. I have a vague recollection of a UDD
presentations which did list count of DDs doing source-only uploads.

Regards,

Dmitrijs.


-- 
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/canbhlujhme6yf+xsjorlkj_xtf62s6xehew8f+zehojpktk...@mail.gmail.com

Re: x32 port bootstrap is uploaded

[Wookey]

+++ Helmut Grohne [2012-11-20 09:38 +0100]:
> On Tue, Nov 20, 2012 at 03:10:04PM +0800, Thomas Goirand wrote:
> > Can I also just add the above Debian repo, do --add-architecture,
> > and start replacing some packages? How can I for example, replace
> > perl, on a running server?
> 
> I would guess that using --add-architecture is a recipe for disaster at
> this point. Since x32 is not supported in eglibc 2.13, Daniel Schepler
> did the natural thing to do and used 2.16. So just installing libc6:x32
> will pull in the corresponding libc6 for amd64 and upgrade your
> libc6:amd64 due to the nature of m-a:same. Other packages will likely
> have a similar effect. Proper x32 support can only reasonably be
> achieved in the archive when eglibc is updated to >= 2.16. See #667023
> and #672934 for further details. So by the end of the year we should be
> there if Aurelien Jarno keeps his promise.

The same is true of arm64. I've been running eglibc-2.16 on amd64
(quantal, not unstable, admittedly) and not noticed any issues there,
apart from quite a few build-failures, (due to gets removal and
embedded gnulib copies for which I've filed patches) but I'm only
using it on headless machines so far.

It looks like aurel just uploaded eglibc-2.16 to experimental today so
it'll get rather easier to test. (cheers Aurelien)
http://packages.qa.debian.org/e/eglibc/news/20121120T100339Z.html

I'll test cross-toolchains builds with those packages forthwith.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20121120122100.gx24...@stoneboat.aleph1.co.uk

Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)

[Henrique de Moraes Holschuh]

On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote:
> I am sorry, if I was not clear. I am aware of the "last iteration",
> but I am not enquiring about the default policy within debian as to
> how we should upload by default.
> I am asking why, when I had a reason to do so, was not able to do a
> source-only upload.
> Is this a feature of dak, or a policy enforcement?

Both.

-- 
  "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/20121120122309.gb22...@khazad-dum.debian.net

Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)

[Andrey Rahmatullin]

On Tue, Nov 20, 2012 at 12:08:13PM +, Dmitrijs Ledkovs wrote:
> If it's a policy enforcement, I am ok with it. Otherwise, I'd would
> like to see dak accept those. I have a vague recollection of a UDD
> presentations which did list count of DDs doing source-only uploads.
source+all uploads probably?
Also, I'm subscribed.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 11:45, Jon Dowland  wrote:
> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
>> I currently do not have facilities to build the package in question
>> with the host running Debian's kernel.
>
> So how can you prove that the package builds?
>

I can give you my sbuild log I did before uploading, but that does not
prove anything.
It turns out that for the package in question, fails to build on older
kernels & my machine has a newer kernel than buildds.

Is there any current facility to find out about buildd hosts
configuration, e.g. kernel versions?
E.g. at lest the minimal version available _across_ all architectures?

Regards,

Dmitrijs.


-- 
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/canbhlujxk0gx97izifouhpi0cdpwbcamzuxf-a1fkxrzwpj...@mail.gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 20/11/2012 13:37, Dmitrijs Ledkovs a écrit :
> On 20 November 2012 11:45, Jon Dowland  wrote:
>> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs
>> wrote:
>>> I currently do not have facilities to build the package in
>>> question with the host running Debian's kernel.
>> 
>> So how can you prove that the package builds?
>> 
> 
> I can give you my sbuild log I did before uploading, but that does
> not prove anything.

That's why we currently require a binary together with the source. It
tautologically proves that you successfully built it.

Furthermore, maintainers should build their packages is a clean sid
chroot. Note that you can very well build in a virtual machine running
Debian if your host is not Debian and you want to make sure to use a
Debian kernel during build.

> It turns out that for the package in question, fails to build on
> older kernels & my machine has a newer kernel than buildds.
> 
> Is there any current facility to find out about buildd hosts 
> configuration, e.g. kernel versions? E.g. at lest the minimal
> version available _across_ all architectures?
> 

I don't know of any summary for this information, but you can find out
from build logs on https://buildd.debian.org. Of course you need to
find a recent build log.


On Barber:
Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64)

On Brahms:
Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQq3+jAAoJEJOUU0jg3ChApg0P/1RfJ3+3POn6f/LmGiIJf85n
GcpmIA834Ae//V5AvR/hYHrV2oUGj3iyXJJjCeUZWaO02BRzOJDNSIxfP+xex1yI
OgT+dyWRXancqt87vMNg+X0DFveRPS4TYQuECVuO72Q3j+smEjp7MJEvlZK3KEKw
VXbHryS85vOFQDuWdz7Ambt8x+S4IBvXacaBP8KsZt/AiEQJkgK5/L5YOrCblMfq
nQJW7G+eq3dvrUZX7jANSUwaSoyHA4NG4UAzI4HacJWSjjYUbEtxE5us/l3aOwcC
7c8MAulUVoZDOayWN0IM2dnvJiJMQ/r6nBMvPxEcbVpwtFRNgT4FeT1ZQn8cYeNi
Z/6Hxmh76KY37qNYvoY3hcqMO9SPGzPkVDvLspCuBlcK7eE2ie0ri9vGE2Ze9c8I
HPBA1DKNxnVv5eIxo7U1ZXeIxwc97grOvRcPB6xfOJ9WHsfgmoaUONn4+Kp+/msl
Hv9b8hW9+IgJgITN4IKUTRzbsvQCyyFqKZJV+OlSq75xgKtX3EqMpWdfIaAa81sR
8qYQ2UAgkqMWkboEJPMoAll7ZBW8v8Us7QRkAErTD5A1fgzogT2ap6JxWUOKqh37
yXna2q9DLpto2MwnETsU/1qkSX9BTq/2RsNvc/ou+Ch4W+SOYpz4XIpaySn2uI9r
8K/xa3cTGlZJu0h8tZXq
=DIS1
-END PGP SIGNATURE-


-- 
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/50ab7fb3.5010...@debian.org

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 13:03, Thibaut Paumard  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Le 20/11/2012 13:37, Dmitrijs Ledkovs a écrit :
>> On 20 November 2012 11:45, Jon Dowland  wrote:
>>> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs
>>> wrote:
 I currently do not have facilities to build the package in
 question with the host running Debian's kernel.
>>>
>>> So how can you prove that the package builds?
>>>
>>
>> I can give you my sbuild log I did before uploading, but that does
>> not prove anything.
>
> That's why we currently require a binary together with the source. It
> tautologically proves that you successfully built it.
>

Sure it proves that _I_ built it, but it doesn't prove that it will
build on the buildds.
Hence, my point that in real terms neither debs nor sbuild logs prove anything.
See the case about the minimal expected kernel.

> Furthermore, maintainers should build their packages is a clean sid
> chroot. Note that you can very well build in a virtual machine running
> Debian if your host is not Debian and you want to make sure to use a
> Debian kernel during build.
>

I did built in sbuild, but not a VM. Is there pbuilder/sbuild backed
by qemu/kvm available anywhere to make that easier to do?

>> It turns out that for the package in question, fails to build on
>> older kernels & my machine has a newer kernel than buildds.
>>
>> Is there any current facility to find out about buildd hosts
>> configuration, e.g. kernel versions? E.g. at lest the minimal
>> version available _across_ all architectures?
>>
>
> I don't know of any summary for this information, but you can find out
> from build logs on https://buildd.debian.org. Of course you need to
> find a recent build log.
>

Ok, I will look at it.

>
> On Barber:
> Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64)
>
> On Brahms:
> Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64)

What's this:
lucatelli
Kernel: Linux 3.2.0-0.bpo.3-octeon
https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&ver=3.2~rc1-1~exp3&arch=mips&stamp=1353416035

Why is distribution (experimental) building on an out of date backported kernel?

Also MIPS is ahead of x86_64 =)

Regards,

Dmitrijs.


--
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/CANBHLUgoUnAy+uAQCd0O4JmehEbEtWd+JUM7kzw6vDp=wf-...@mail.gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Ben Hutchings]

On Tue, 2012-11-20 at 12:37 +, Dmitrijs Ledkovs wrote:
> On 20 November 2012 11:45, Jon Dowland  wrote:
> > On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
> >> I currently do not have facilities to build the package in question
> >> with the host running Debian's kernel.
> >
> > So how can you prove that the package builds?
> >
> 
> I can give you my sbuild log I did before uploading, but that does not
> prove anything.
> It turns out that for the package in question, fails to build on older
> kernels & my machine has a newer kernel than buildds.

It's a bit ironic that a program that tries to tell you everything about
its run-time environment, depends on such details of its compile-time
environment.

> Is there any current facility to find out about buildd hosts
> configuration, e.g. kernel versions?
> E.g. at lest the minimal version available _across_ all architectures?

The minimum version should be whatever is in stable, i.e. 2.6.32.  This
is also the minimum version it needs to run on (think partial upgrades).

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


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

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 13:47, Ben Hutchings  wrote:
> On Tue, 2012-11-20 at 12:37 +, Dmitrijs Ledkovs wrote:
>> On 20 November 2012 11:45, Jon Dowland  wrote:
>> > On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
>> >> I currently do not have facilities to build the package in question
>> >> with the host running Debian's kernel.
>> >
>> > So how can you prove that the package builds?
>> >
>>
>> I can give you my sbuild log I did before uploading, but that does not
>> prove anything.
>> It turns out that for the package in question, fails to build on older
>> kernels & my machine has a newer kernel than buildds.
>
> It's a bit ironic that a program that tries to tell you everything about
> its run-time environment, depends on such details of its compile-time
> environment.
>

It is ironic in an amusing way. The maintainer is fixing this.

>> Is there any current facility to find out about buildd hosts
>> configuration, e.g. kernel versions?
>> E.g. at lest the minimal version available _across_ all architectures?
>
> The minimum version should be whatever is in stable, i.e. 2.6.32.  This
> is also the minimum version it needs to run on (think partial upgrades).
>

To be clear both at build time & run time. So why the mipsel buildd
above is running a much newer kernel, since this can be leak into the
build packages...? Or is it a new port for wheezy or something? (e.g.
no previous released stable available)

Regards,

Dmitrijs.


-- 
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/CANBHLUhnkjLUs4=xzhaxvk4nwcptn_0dxb_n1gycbuo12wa...@mail.gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[martin f krafft]

also sprach Thibaut Paumard  [2012.11.20.1403 +0100]:
> That's why we currently require a binary together with the source. It
> tautologically proves that you successfully built it.

Nope, it does not. It could also prove that you know how to use
changestool to engineer a .changes file combining a source package
with an older DEB file, or even an empty DEB file.

Point being, there is no way to prove that a package builds. And
even if you built it and included it in the upload, you might have
done so on a non-clean chroot or in another whack environment with
e.g. build-dependencies installed without having them listed in
debian/control.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"stab it and steer"
 -- sailor


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#693800: ITP: tandem-mass -- mass spectrometry software for protein identification

[Olivier Langella]

Package: wnpp
Severity: wishlist
Owner: Olivier Langella 


* Package name: tandem-mass
  Version : 20121001
  Upstream Author : The Global Proteome Machine Organization
* URL : http://www.thegpm.org/TANDEM/
* License : Artistic License 1.0
  Programming Lang: C++
  Description : mass spectrometry software for protein identification

 X! Tandem can match tandem mass spectra with peptide sequences, in a
 process that is commonly used to perform protein identification.
 .
 This software has a very simple, unsophisticated application
 programming interface (API): it simply takes an XML file of
 instructions on its command line, and outputs the results into an XML
 file, which has been specified in the input XML file. The output file
 format is described at
 \fI`http://www.thegpm.org/docs/X_series_output_form.pdf'\fR.
 .
 Unlike some earlier generation search engines, all of the X! Series
 search engines calculate statistical confidence (expectation values)
 for all of the individual spectrum-to-sequence assignments. They also
 reassemble all of the peptide assignments in a data set onto the
 known protein sequences and assign the statistical confidence that
 this assembly and alignment is non-random. The formula for which can
 be found here. Therefore, separate assembly and statistical analysis
 software, e.g. PeptideProphet and ProteinProphet, do not need to be
 used.


-- 
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/20121120135802.16517.38955.report...@shyrka.moulon.inra.fr

Re: New virtual packages: lv2-plugin and lv2-host

[Ian Jackson]

Alessio Treglia writes ("New virtual packages: lv2-plugin and lv2-host"):
> virtual-package-list.txt.gz [1] says:
> 
>1. Post to debian-devel saying what names you intend to use or what
>   other changes you wish to make, and file a wish list bug against the
>   package debian-policy.
> 
> So, here is my proposal:
...
> + lv2-hostanything that can host LV2 audio plugins
> + lv2-plugin  an LV2 compliant audio plugin
...
> Regarding LV2, you may find more information at http://lv2plug.in/.

Reading that, I'm not sure why these virtual packages would be
useful.

An lv2-plugin could be almost anything AFAICT, so depending on "some
LV2 plugin" is not very useful.

And an lv2-host could include something which can use only plugins
with certain features.

Ian.


-- 
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/20651.37708.390965.378...@chiark.greenend.org.uk

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Philipp Kern]

Dmitrijs,

am Tue, Nov 20, 2012 at 02:03:52PM + hast du folgendes geschrieben:
> To be clear both at build time & run time. So why the mipsel buildd
> above is running a much newer kernel, since this can be leak into the
> build packages...? Or is it a new port for wheezy or something? (e.g.
> no previous released stable available)

sometimes buildds need newer kernels because certain bugs are fixed
there but not in stable or because the HW is unsupported with the stable
kernel.

As Ben said the minimum kernel baseline is currently stable's, even
though it's possible that we run oldstable kernels for a while after the
next stable is release.

The buildds might run any kernel version between stable's and
unstable's, mostly through backports. But for some new ports or machines
selfbuilt kernels are also possible.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 20/11/2012 14:35, Dmitrijs Ledkovs a écrit :

> What's this: lucatelli Kernel: Linux 3.2.0-0.bpo.3-octeon 
> https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&ver=3.2~rc1-1~exp3&arch=mips&stamp=1353416035
>
>  Why is distribution (experimental) building on an out of date
> backported kernel?
> 

The buildd hosts are production machines, they're not guaranteed or
even supposed to run SID (packages are built in chroots).

When your package fails to build due to a *buggy* kernel, you can
request for an upgrade on this buildd.

Why does the running kernel matter for procenv build? Does procenv run
on another kernel than that of the machine it was built on?

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQq5bVAAoJEJOUU0jg3ChAlg4P/jUyJVYa4/CQsGtkuVfYd1Kw
RRuvp/97mAlfdiqXtQ2DLuqh0FJ08O655WCVtZyBFYxwSVg4ufQB/7XQnPlcx1Z5
xYcfJaZnROvvvXdMig6HXgm67UYs5Oxpti3wTch5WUbLpUnjJ4o1wWmw4RONs2Wr
nduA1zSHgDZ/6kK5Gohf8mmstYY8U1f8AeQcxn+zD/o5JnP1t9IFoba4mjRZEIvF
3ianfL7iV1Ou85NZK6mZpqYMJ2XmN2aMVKxGp5H63osR04ecYxnwoQFHWzgnte2/
N8siXnRLgpPPNo7g4EoVrlnbfCG/O0TR0BaAfMeY/dyHxn0RLijYiuPItZKV8zOD
Dt4XjBqfJQw1WrmxnetKTmoqOIB9s6ShQxunftyRrisXevvn4b+o8z+lWubI33Nl
6HSdJ4k0fvrZgIMnocyQzsqT62n5QVsuyVq5+kViZBOFXs2Ov1y4DRuTIaLgdKSI
hIDWlYcCG7VejNZd+T92E57Umx+SebgmK5rqpMUp7wV47XOrPQEnGitpmGkjI7/e
dtunD5y1+qPaLQyIgFjtxtjdxdHS7MAA1NVfloHw6tiX5LqonlWUAm0JeubAm/dU
vPRpFr7dJLGzWfvVVSuVSRB7HEVbl0i2W22xjTZ4Nq27dO94rxsjHXrspyTYH2dn
UMC3ePHjeohtsiPVyRW5
=q+9D
-END PGP SIGNATURE-


-- 
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/50ab96d5.2000...@debian.org

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 14:28, Philipp Kern  wrote:
> Dmitrijs,
>
> am Tue, Nov 20, 2012 at 02:03:52PM + hast du folgendes geschrieben:
>> To be clear both at build time & run time. So why the mipsel buildd
>> above is running a much newer kernel, since this can be leak into the
>> build packages...? Or is it a new port for wheezy or something? (e.g.
>> no previous released stable available)
>
> sometimes buildds need newer kernels because certain bugs are fixed
> there but not in stable or because the HW is unsupported with the stable
> kernel.
>
> As Ben said the minimum kernel baseline is currently stable's, even
> though it's possible that we run oldstable kernels for a while after the
> next stable is release.
>
> The buildds might run any kernel version between stable's and
> unstable's, mostly through backports. But for some new ports or machines
> selfbuilt kernels are also possible.
>

Sure. Thank you for details.

Regards,

Dmitrijs.


-- 
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/CANBHLUjRqJ_OSaUVSUXmuAH5doH1G7xcznYP74KyEC=nd5j...@mail.gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 14:42, Thibaut Paumard  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Le 20/11/2012 14:35, Dmitrijs Ledkovs a écrit :
>
>> What's this: lucatelli Kernel: Linux 3.2.0-0.bpo.3-octeon
>> https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&ver=3.2~rc1-1~exp3&arch=mips&stamp=1353416035
>>
>>  Why is distribution (experimental) building on an out of date
>> backported kernel?
>>
>
> The buildd hosts are production machines, they're not guaranteed or
> even supposed to run SID (packages are built in chroots).
>
> When your package fails to build due to a *buggy* kernel, you can
> request for an upgrade on this buildd.
>
> Why does the running kernel matter for procenv build? Does procenv run
> on another kernel than that of the machine it was built on?
>

Well the code in it's current form was discovered to rely on newer
kernel features.
Now I am trying to establish a baseline that could be reasonably
relied upon and I have passed these details to upstream now.
Currently it builts fine, but fails to run on an older kernel,
upstream is working on fixing this runtime error.

Regards,

Dmitrijs.


--
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/canbhluihcgbvo_rczzwrqg0w5ktvjhrjqrzfr4utwg7o9k4...@mail.gmail.com

Re: Comments on Mate DE

[Michael Schmitt]

Sorry to be a bit late there :)

Am 21.09.2012 16:41, schrieb Jon Dowland:

That's not really of any interest to -devel, and I guess you're quoting
info from private mail here. Please let's keep this list useful.
I disagree. It was very useful to get a glimpse on why he had / has so 
many issues with an OS that I use everyday on many different boxes 
without any of the issues he mentioned. As it turns out, the first mail 
in this thread itself was somewhat the problem. A problem that just may 
happen every once in a while here.


Too sad that "superuserlaptop" did never answer here publicly anymore...

regards
Michael


--
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/50aba3c4.3040...@gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Luca Capello]

Hi there!

On Tue, 20 Nov 2012 14:35:08 +0100, Dmitrijs Ledkovs wrote:
> I did built in sbuild, but not a VM. Is there pbuilder/sbuild backed
> by qemu/kvm available anywhere to make that easier to do?

There is, but I doubt the built package will be accepted, we already had
this problem in the past:

  

=
$ apt-cache search qemu builder
qemubuilder - pbuilder using QEMU as backend
$ apt-cache show qemubuilder
Package: qemubuilder
Source: cowdancer
[...]
Description-en: pbuilder using QEMU as backend
 pbuilder implementation for QEMU.
 .
 qemubuilder create -- builds QEMU cow base image.
 .
 qemubuilder update -- updates QEMU cow base image.
 .
 qemubuilder build -- builds package inside QEMU cow base image.
 .
 Gives a pbuilder interface for emulated cross-building environments
 using qemu.
 .
 pbuilder is a tool for building and testing Debian package inside a
 clean chroot, and qemubuilder implements similar experience over
 emulated CPUs. This tool allows building package inside emulated
 Debian environment for different CPU architectures supported by qemu.
Homepage: http://wiki.debian.org/qemubuilder
[...]
$ 
=

Thx, bye,
Gismo / Luca


pgpsaQpjsmlDF.pgp
Description: PGP signature

Re: x32 port bootstrap is uploaded

[Wookey]

+++ Daniel Schepler [2012-11-20 07:51 -0800]:
> Once upon a time, Thomas Goirand wrote:
> > Can I also just add the above Debian repo, do --add-architecture,
> > and start replacing some packages? How can I for example, replace
> > perl, on a running server?
> 
> That should work, as long as you make sure to exclude x32 from the
> main Debian repo.  i.e. make /etc/apt/sources.list look something
> like:
> 
> deb [ arch=amd64,i386 ] http://http.debian.net/debian/ sid main contrib 
> non-free
> deb [ arch=x32 ] http://87.98.215.228/debian/ sid main byhand partial

Do tell us what breaks if you try this :-)

> In the case of perl, I'm not sure how well it will work in practice,
> given that it would have to cross-grade all the arch-dependent perl
> packages at the same time.  So you might have to help "apt-get install
> perl:x32" with some more packages, and depending on how many of the
> dependencies support multi-arch or not, it might end up deleting more
> than you'd want.  Plus, since I don't see any Multi-Arch: foreign tag
> on the perl package currently, things depending on perl will probably
> also need cross-grading or removing.  (And I don't know if such a
> Multi-Arch tag would be a good idea, depending on how it would
> interact with the perlapi-* virtual dependency.)

There is an (experimental) multiarchified perl here:
http://people.debian.org/~wookey/bootstrap/ubunturepo/pool/main/p/perl/perl_5.14.2-13multiarch1.dsc

It seems to work fine as perl for normal use and even for
cross-building XS modules, but I have found a couple of issues using
the native perl during cross-builds (po4a seems bust).

The thread discussing this is here:
http://lists.debian.org/debian-perl/2012/09/msg0.html

That may or may not improve your cross-grading experience.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20121120163720.gb24...@stoneboat.aleph1.co.uk

Re: debian mate

[Michael Schmitt]

Am 05.11.2012 00:41, schrieb Andrew Kolotenko:

On Mon, 2012-11-05 at 02:57 +0400, Виталий Короневич wrote:

debian gnome-edition - ok
debian kde-edition - ok
debian lxde-edition - ok
debian xfce-edition - ok
when will debian mate-edition?

what for? the ones above are enough imho
For you maybe, for many others as well, but for many many others not so 
much.


I tend to urge friends to use GNU/Linux instead of Windows and do 
support them with their machines if they choose to go along with my 
suggestion. I was successful there in only five cases so far (all with 
Gnome and up to now squeeze) and made a small test with (up to now) four 
of them. More thorough with at least two of them. Outcome: All of them 
choose MATE over any other DE currently in Debian (details of the tests 
at the end of the mail[1]).
Sadly I don't have more impressive statistics to present. For all we 
know it could have been just a coincidence. If it were a hundred friends 
maybe 96 would have choosen gnome-shell or KDE? But I think it is save 
to assume it would be rather in between those two extremes.
Anyway, I understand the problems but I think Debian / ftp-masters and 
those of us sitting somewhere in the queue a package has to go through 
may want to balance the social / political and technical problem here 
again. I know there is already progress on getting Mate in Debian, there 
are already willing maintainers, it is just not possible to get all 
technical problems resolved before wheezy gets released. Even if all 
problems would be solved today, I doubt it would be accepted for wheezy 
anymore. Only if the balance between technical and political / social 
problem would be re-evaluated AND an exception would be granted, many 
future users of wheezy will have a happy-wheezy-year-2013.


regards
Michael

[1] All of them was given a laptop with a more or less current sid with 
Gnome3, KDE, Xfce and MATE preinstalled. With two of them I did a 
complete data-migration from their main-computers, and hooked up their 
displays and external devices, so it ran basically as their 
main-machine. I asked them to testdrive every DE for at least two days 
and helped them whenever questions arose and tried to fix the problems 
as good as every DE supports a fix for the particular problems. With the 
two other people (I did not have the nerve / time to go through that 
another two times *sic*) I just sat with them together for some hours 
presenting gnome3 (fallback and shell) and MATE and I asked them to test 
and do stuff (with me sitting besides and answering / fixing) they would 
normally do on their main squeeze-boxes. Including getting pics from the 
digicam, using pendrives and mobile phones, surfing the web, using IM, 
file-management, overall DE-dive-through for changing settings and 
appearance.



--
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/50abb738.4080...@gmail.com

Bug#693813: ITP: impress.js -- JavaScript library to create presentations in browsers

[Cédric Boutillier]

Package: wnpp
Severity: wishlist
Owner: "Cédric Boutillier" 

* Package name: impress.js
  Version : 0.5.3
  Upstream Author : Bartek Szopka
* URL : https://github.com/bartaz/impress.js
* License : Expat or GPL-2+
  Programming Lang: JavaScript
  Description : JavaScript library to create presentations in browsers

Impress.js is a framework written in JavaScript to create HTML
presentations, which can be shown with a web browser. It provides
transforms and transition effects between slides based on CSS3.

This package is a dependency of mdpress (#692864) and will be maintained
under the umbrella of the Debian JavaScript team.

Cheers,

Cédric


--
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/20121120170101.3349.36049.report...@losange.proba.jussieu.fr

Re: x32 port bootstrap is uploaded

[Adam Borowski]

On Tue, Nov 20, 2012 at 04:37:20PM +, Wookey wrote:
> +++ Daniel Schepler [2012-11-20 07:51 -0800]:
> > Once upon a time, Thomas Goirand wrote:
> > > Can I also just add the above Debian repo, do --add-architecture,
> > > and start replacing some packages? How can I for example, replace
> > > perl, on a running server?
> > 
> > That should work, as long as you make sure to exclude x32 from the
> > main Debian repo.  i.e. make /etc/apt/sources.list look something
> > like:
> > 
> > deb [ arch=amd64,i386 ] http://http.debian.net/debian/ sid main contrib 
> > non-free
> > deb [ arch=x32 ] http://87.98.215.228/debian/ sid main byhand partial
> 
> Do tell us what breaks if you try this :-)

Having tested this with Raspbian, it's fun only if both repositories go in
lockstep: there might be a hiccup if one arch is updated in one dinstall run
and another arch in the next one, but there are no major problem.  Add
delays -- or worse, patches on one of the sides -- and it all gets stuck.

Unless Daniel runs a buildd that _swiftly_ updates packages once they hit
unstable, _and_ he carries a partial repo with amd64 builds of all patched
packages, expect lots of manual work.  Easiest way: have pbuilder ready, and
build amd64 binaries of any Raspbian or x32 modified packages the moment apt
complains.

Sorry but multiarch doesn't make using out of sync repositories nice.
Single-arch chroots are the easy way for now.

-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
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/20121120170311.ga21...@angband.pl

Re: debian mate

[Michael Schmitt]

Am 05.11.2012 00:41, schrieb Wouter Verhelst:

On Mon, Nov 05, 2012 at 02:57:35AM +0400, Виталий Короневич wrote:

debian gnome-edition - ok
debian kde-edition - ok
debian lxde-edition - ok
debian xfce-edition - ok
when will debian mate-edition?

When someone (you?) does the work to package (the relevant parts of) mate.
There is already one, see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783


regards
Michael



--
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/50abb9d2.8070...@gmail.com

Re: x32 port bootstrap is uploaded

[Daniel Schepler]

On Mon, Nov 19, 2012 at 11:47 AM, Daniel Schepler  wrote:
> Later I'll try to document this a bit more on the wiki, [snip]
OK, I've now created http://wiki.debian.org/X32Port .
-- 
Daniel Schepler


-- 
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/CADf0C46P44e4Tr1R2NkDgLPHuQ3jRQ5K5pW+6h0RD9==zrh...@mail.gmail.com

Re: Fwd: procenv_0.9-1_source.changes REJECTED

[Dmitrijs Ledkovs]

On 20 November 2012 16:12, Luca Capello  wrote:
> Hi there!
>
> On Tue, 20 Nov 2012 14:35:08 +0100, Dmitrijs Ledkovs wrote:
>> I did built in sbuild, but not a VM. Is there pbuilder/sbuild backed
>> by qemu/kvm available anywhere to make that easier to do?
>
> There is, but I doubt the built package will be accepted, we already had
> this problem in the past:
>

Just to be clear, I don't want to upload binaries. On the contrary, I
have uploaded a source-only changes which got rejected.
In the current instance, I want sid chroot on stable kernel. I will
look into qemubuilder if it can do that. Thanks for that tip.

>   
>

Seems like an old thread. I am on the side that binaries should be
built on bare metal by a native compiler.

Regards,

Dmitrijs.

> =
> $ apt-cache search qemu builder
> qemubuilder - pbuilder using QEMU as backend
> $ apt-cache show qemubuilder
> Package: qemubuilder
> Source: cowdancer
> [...]
> Description-en: pbuilder using QEMU as backend
>  pbuilder implementation for QEMU.
>  .
>  qemubuilder create -- builds QEMU cow base image.
>  .
>  qemubuilder update -- updates QEMU cow base image.
>  .
>  qemubuilder build -- builds package inside QEMU cow base image.
>  .
>  Gives a pbuilder interface for emulated cross-building environments
>  using qemu.
>  .
>  pbuilder is a tool for building and testing Debian package inside a
>  clean chroot, and qemubuilder implements similar experience over
>  emulated CPUs. This tool allows building package inside emulated
>  Debian environment for different CPU architectures supported by qemu.
> Homepage: http://wiki.debian.org/qemubuilder
> [...]
> $
> =
>
> Thx, bye,
> Gismo / Luca


-- 
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/canbhlui7q2zkhmxutefmfjem0fsa1mp3bpybe0nwpauqmwq...@mail.gmail.com

Bug#693819: ITP: highlight.js -- JavaScript syntax highlighting library for many languages

[Cédric Boutillier]

Package: wnpp
Severity: wishlist
Owner: "Cédric Boutillier" 

* Package name: highlight.js
  Version : 7.3
  Upstream Author : Ivan Sagalaev 
* URL : http://softwaremaniacs.org/soft/highlight/en/
* License : BSD-3-clause
  Programming Lang: JavaScript
  Description : JavaScript syntax highlighting library for many languages

Highlight.js is a JavaScript library which automatically detects the
language of code blocks in a web page, and provides syntax highlighting
for them. The library supports more than fifty languages and is bundled
with more than twenty style themes.

This package is a dependency for mdpress (#692864) and will be
maintained under the umbrella of the Debian JavaScript team.

Cheers,

Cédric


--
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/20121120172704.25287.26550.report...@losange.proba.jussieu.fr

Re: debian mate

[Michael Schmitt]

Am 05.11.2012 00:51, schrieb John Paul Adrian Glaubitz:

On Mon, Nov 05, 2012 at 02:57:35AM +0400, Виталий Короневич wrote:

debian gnome-edition - ok
debian kde-edition - ok
debian lxde-edition - ok
debian xfce-edition - ok

Those aren't really editions comparable to Ubuntu's editions or
Fedora's spins. You just install a regular Debian and choose the
desktop enviroment you want.


when will debian mate-edition?

This isn't as easy and straight-forward as you might think. There are
many problems that need to be solved with MATE first before it can
enter Debian. Some of these are discussed here [1].

One of the biggest problems with MATE so far is that it currently
depends on libraries and other things that have been deprecated and
removed in Debian and should not be reintroduced to Debian.
Can we agree on something more friendly like "it would be not optimal to 
reintroduce these packages"? Or at least elaborate a bit why they should 
not be re-introduced. It would not be the first time something like that 
happened in Debian.



  Thus, the
MATE developers are working to port MATE to more recent libraries
which are available in Debian.
And whatever they or anybody else does in that regard, it will come to 
late for wheezy.



Furthermore, work has to be done to make sure MATE co-installs
seamlessly with anything from GNOME which isn't that trivial.
Apparently it is easy enough, as they got that already done months ago. 
At least I run MATE on many sid-boxes with Gnome3 co-installed and no 
issues apart from that damn mime-types-thingy brokenness when one has 
more than one DE installed.



There
are many binaries and libraries which still exist in GNOME3 and
installing MATE could possibily break these.
Could but don't afai(and many others)ct and most importantly should not, 
as that was one of the first goals of MATE. And from what I've heard 
from the MATE-devs (#mate@freenode) they tend to disagree there in a 
rather strong fashion. :)



I'm actually helping the MATE developers to get MATE ready for Debian,
but don't expect that to happen anytime soon.

Expect the worst, hope for the best! ;)

regards
Michael


I'm also working on getting mdm ready, a fork of gdm 2.20. Currently,
I'm not really happy with the code, however.

Adrian


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783





--
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/50abbfec.1050...@gmail.com

Re: Gentoo guys starting a fork of udev

[Marc Haber]

On Tue, 20 Nov 2012 10:13:28 +0800, Paul Wise  wrote:
>There is no reason for kFreeBSD and Hurd to stop Debian's Linux ports
>from using systemd or upstart by default once wheezy is released. We
>can keep sysvinit/openrc/busybox init/etc for kFreeBSD, Hurd and users
>who need or prefer them.

Aren't the systemd makers trying hard to move existing functionality
from udev, consolekit, policykit and syslogd into systemd, effectively
making those unavailable for non-Linux?

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/e1tasuu-0001kx...@swivel.zugschlus.de

Re: Gentoo guys starting a fork of udev

[Matthias Klumpp]

Hi!

2012/11/20 Marc Haber :
> On Tue, 20 Nov 2012 10:13:28 +0800, Paul Wise  wrote:
>>[...]
> Aren't the systemd makers trying hard to move existing functionality
> from udev, consolekit, policykit and syslogd into systemd, effectively
> making those unavailable for non-Linux?
No, not really... ConsoleKit is replaced by a systemd-associated
daemon (logind) because of several design flaws of CK. This change
brought us e.g. full multiseat support.
Udev is already Linux-only, and it work fine without systemd.
PolicyKit has to stay separate, there are no plans in that direction -
it also would not make sense from an architectual point of view. But
systemd is using PolKit, of course.
For syslogd, systemd provides journald for those who want to use it,
but the Journal is no dependency of systemd. If applications use
existing syslog calls, nothing will change. For journald-specific
extra functionality (adding metadata), software can use journald-APIs,
which would make this software Linux-specific. But Lennart is thinking
about making this library work on non-Linux OSes too, which would
solve this "problem" too.
(Since most stuff uses syslog calls, this is not an issue. Also,
systemd does not require journald, even for Fedora it is not safe yet
if they will use the journal or not)
Cheers,
Matthias


-- 
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/caknhny_vvkstewypj9sauezw+wvhh4lycgzcn_qbzd3id8x...@mail.gmail.com

Re: debian mate

[Josselin Mouette]

Le mardi 20 novembre 2012 à 18:37 +0100, Michael Schmitt a écrit : 
> > One of the biggest problems with MATE so far is that it currently
> > depends on libraries and other things that have been deprecated and
> > removed in Debian and should not be reintroduced to Debian.
> Can we agree on something more friendly like "it would be not optimal to 
> reintroduce these packages"? Or at least elaborate a bit why they should 
> not be re-introduced. It would not be the first time something like that 
> happened in Debian.

Because nobody knows anymore how to maintain libraries as complex as
bonobo, for example. And I’m pretty sure the MATE developers don’t have
the expertise.

Even worse, they forked stuff like GConf using sed to rename it
mateconf, while GConf is still available in a much more modern version
in wheezy, 100% binary-compatible while being ported to D-Bus.

I don’t think we should allow libraries from clueless developers to be
introduced into the archive.

> > Furthermore, work has to be done to make sure MATE co-installs
> > seamlessly with anything from GNOME which isn't that trivial.
> Apparently it is easy enough, as they got that already done months ago. 
> At least I run MATE on many sid-boxes with Gnome3 co-installed and no 
> issues apart from that damn mime-types-thingy brokenness when one has 
> more than one DE installed.

Maybe you can try to understand how XDG mime works. But maybe this is
too much to ask to people who forked libraries that are still available.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1353438775.9228.4.camel@pi0307572

Re: Where could I upload x32 port bootstrap?

[Thorsten Glaser]

Ben Hutchings  decadent.org.uk> writes:

> 64-bit architecture that supports a 32-bit userland.  I think the only
> interesting difference is that x32 has 64-bit time_t.

And double the GPRs (General Purpose Registers), and each of them
in double the width. I expect this to help modern compilers a lot.

bye,
//mirabilos


-- 
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/loom.20121120t204112-...@post.gmane.org

Bug#693829: ITP: python-iapws -- Python implementation of the international APWS-IF97 steam tables

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: python-iapws
  Version : 1.0.0
  Upstream Author :  jjgomera 
* URL : http://pypi.python.org/pypi/iapws
* License : GPL
  Programming Lang: Python
  Description : Python implementation of the international APWS-IF97 steam 
tables

 This is a python class to model a state for liquid water or steam
 with the Industrial Formulation IAPWS-IF97.
 .
 Further information on the standard is available at http://www.iapws.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/20121120194206.20690.14758.report...@ailm.sceal.ie

Re: Something like nocompress DEB_BUILD_OPTION

[Thorsten Glaser]

Dmitrijs Ledkovs  debian.org> writes:

> Gzip is ok, but many packages these days use xz -9 --extreme deb

xz is fine but -9 is abuse of the flexibility…
maybe I should export XZ_DEFAULTS=--memlimit=150MiB
in my build chroots… hmm… something to think about…
(for m68k, I might actually use less, setting it to
80MiB would force compression down to -4 which, with
--extreme possibly, is enough, there)

//mirabilos


-- 
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/loom.20121120t204607-...@post.gmane.org

Bug#693831: ITP: flextra -- Trajectory model for tracing air transport phenomena

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: flextra
  Version : 5.0
  Upstream Author : Andreas Stohl
* URL : http://transport.nilu.no/flexpart
* License : GPL
  Programming Lang: Fortran
  Description : Trajectory model for tracing air transport phenomena

 Trajectory models are important tools for studying transport phenomena
 in the atmosphere. In the environmental sciences, they are often used to
 establish source-receptor relationships of air pollutants.
 .
 FLEXTRA can be used to calculate different types of forward or backward
 trajectories, and has facilities to estimate the uncertainty of trajectories.
 It is specifically designed to compute long time sequences of trajectories
 for many receptor locations.
 .
 FLEXTRA may be used with the Metview meteorological workstation to
 visualize trajectories.


-- 
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/20121120195100.20754.61898.report...@ailm.sceal.ie

Bug#693833: ITP: flexpart -- Particle Dispersion model for tracing air transport phenomena

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: flexpart
  Version : 90.02
  Upstream Author : Andreas Stohl
* URL : http://transport.nilu.no/flexpart
* License : GPL
  Programming Lang: Fortran
  Description : Particle Dispersion model for tracing air transport 
phenomena

 The FLEXPART model is a Lagrangian Particle Dispersion Model
 developed at the Norwegian Institute for Air Research in the
 Department of Atmospheric and Climate Research.
 The model development team consists of Andreas Stohl
 (who originally wrote FLEXPART), Sabine Eckhardt,
 Harald Sodemann, and John Burkhart.


-- 
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/20121120200939.20865.68819.report...@ailm.sceal.ie

Bug#693834: ITP: metview -- Interactive data visualization and analysis environment

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: metview
  Version : 4.3.4
  Upstream Author : ECMWF http://www.ecmwf.int
* URL : https://software.ecmwf.int/wiki/display/METV/Home
* License : Apache
  Programming Lang: C++
  Description : Interactive data visualization and analysis environment

 Metview has been designed as a flexible, modular and extendible system
 able to accommodate the evolving needs of the user.
 The system is based on the ECMWF standards for graphics (Magics) and
 data access (MARS) but can also access locally stored data.
 The user interface is based on Motif and Qt. Metview is a
 fully distributed system where modules can run on different workstations and 
servers.
 .
 Metview is a cooperative project between ECMWF and INPE/CPTEC, Brazil.
 ECMWF has also been assisted by a staff member of Météo-France.


--
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/20121120201915.20930.7457.report...@ailm.sceal.ie

Re: History of Debian bootstrapping/porting efforts

[Thorsten Glaser]

Johannes Schauer dixit:

>If you were ever involved in porting Debian to a new architecture or
>know how a port was done, please do not hesitate to either write me an

For reviving m68k:

> - did you cross compile parts of Debian? How much? How hard was it?

Only to test kernels and a few userspace issues. I was lucky I could
use packages from both etch-m68k (a snapshot of mostly sid at the time
when etch was released) and unstable (mostly broken by then) as basis.

> - did you natively compile on another distribution (openembedded,
>   gentoo)

No, just on old Debian, peu à peu, until I could get cowbuilder
running and create a clean build chroot, after which I rebuilt
all not-cleanly-built packages. (I prefer cowbuilder over sbuild
a lot!)

> - how did you go about finding reduced build dependencies? What were
>   the heuristics you used? How did you find dependency cycles to break
>   and how did you pick a solution?

Fully manually. I mostly drew ASCII files like this:

sourcepkg1
sourcepkg2
sourcepkg3
sourcepkg4
sourcepkg5
sourcepkg3
sourcepkg6
sourcepkg2

The web view on packages.debian.org was, and still is, a *huge*
help for drawing those, especially as it also includes packages
from debian-ports unstable in their sid view (I just wish they’d
also include d-p unreleased suite in it, even without a link but
just an inclusion in the version table would be superb).

Then I worked on them from right to left, occasionally patching
a huge dependency out or breaking a B-D loop by hand, sometimes
also installing older versions of B-Ds manually, or even building
versions older than sid but newer than what I had.

Sometimes, package maintainers were a huge help in tracking down
optional dependencies or things I could turn off for bootstrapping;
too bad we still don’t have build profiles in Debian proper.
Other times, I did that using human judgment ;)

> - how long did the port take you?

After about a year, doing this “on the side”, i.e. not concentrating
on it a lot, and considering the very slow speed of the systems, most
things were working. One has to consider I learned about how Debian
really works during that time, too…

> - what were the most common bugs you filed when introducing the new
>   architecture?

Dropping of B-D or versioning them proper or making them arch-specific.
For some packages (mostly toolchain, some device drivers like libdri)
also patch inclusion.

Almost all maintainers and the kernel team were very helpful and
happy to include arch-specific patches that did not touch MI parts,
and some accepted MI patches as well. For some, I went upstream,
which took months(!) longer in most cases.

>   Build-Depends: huge (>= 1.0) [i386 arm] , tiny

Yeah, waiting for it…

As for the rest, we already talked on the mailing list.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
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/pine.bsm.4.64l.1211202112490.29...@herc.mirbsd.org

Re: debian mate

[Michael Schmitt]

Am 20.11.2012 20:12, schrieb Josselin Mouette:

Le mardi 20 novembre 2012 à 18:37 +0100, Michael Schmitt a écrit :

One of the biggest problems with MATE so far is that it currently
depends on libraries and other things that have been deprecated and
removed in Debian and should not be reintroduced to Debian.

Can we agree on something more friendly like "it would be not optimal to
reintroduce these packages"? Or at least elaborate a bit why they should
not be re-introduced. It would not be the first time something like that
happened in Debian.

Because nobody knows anymore how to maintain libraries as complex as
bonobo, for example. And I’m pretty sure the MATE developers don’t have
the expertise.
The MATE-maintainers (especially including upstream team, which is 
growing) said explicitly they are willing to maintain the legacy code as 
long as the replacement is not there. As bad as the bonobo code may be, 
it was in Debian for years and we all know that is not the only code in 
Debian which at least some Debian maintainers / developers think is to 
the utmost extent horrible and it is nevertheless in debian. At least I 
can't comment on this, as I am not a coder, not a maintainer nor a 
developer, I just have open eyes and ears.
I am pretty sure your assessment "they don't have the expertise" would 
fit in e.g. your opinion to many other maintainers. Same goes probably 
for other maintainers and developers as well.



Even worse, they forked stuff like GConf using sed to rename it
mateconf, while GConf is still available in a much more modern version
in wheezy, 100% binary-compatible while being ported to D-Bus.
I noticed that, they noticed and acknowledged that, they simply did not 
know better at that time. Such things happen, even in Debian, but 
basically everywhere. Human nature. We can't know everything and what 
one may consider to be important, others may find silly. For example 
keeping track of a gnome component after the Gnome-devs did go on the 
(for the MATE devs) horrible and insane gnome3-trek may not seem to be 
so urgent, especially in the beginning of the fork. No problem for me 
understanding how something like that could slip through. Now they know 
that, now they even keep track on other components as well (including 
finding bugs in current gnome3-code), backport stuff from various 
gnome3-components and elsewhere.



I don’t think we should allow libraries from clueless developers to be
introduced into the archive.
Wow, that's kinda harsh. :( But then again, I read statements like that 
more often than I would like to in almost any technical oriented place, 
especially on debian IRC-Channels from other maintainers about code or 
other Debian coders in general. I can't comment on that either (me = no 
clue about any programming language) much, just that I tend to think 
"The only code that is ok is the code that I wrote" that kind of 
attitude may apply to many coders...
Let's ignore that imho rude assessment and consider that no one is born 
as a master in anything. And, let's think about other distros that 
already include MATE or will include it in their next release. So, 
Debian would not be the only one. I guess if a serious (security?) bug 
would be found in the code, those combined forces should be able to fix it.



Furthermore, work has to be done to make sure MATE co-installs
seamlessly with anything from GNOME which isn't that trivial.

Apparently it is easy enough, as they got that already done months ago.
At least I run MATE on many sid-boxes with Gnome3 co-installed and no
issues apart from that damn mime-types-thingy brokenness when one has
more than one DE installed.

Maybe you can try to understand how XDG mime works. But maybe this is
too much to ask to people who forked libraries that are still available.
I don't know what I should make of that. I am not part of the actual 
forking / maintaining team, I am just a user. So don't confuse me with 
them. Actually they helped me to understand the issue better. An issue 
not at all limited to MATE. Plain fdo issue (I noticed it first with 
Gnome + KDE or Xfce), Now I think about digging deeper to be able to 
write a high-quality wishlist bugreport for fdo. No worries, I wouldn't 
even think of pestering the debian BTS with that, I'll go straight 
upstream. ;)
And... you do know about what issue I am talking here exactly? Or was 
that just some rude comment my parser did not parse right? ;)


In general, I have no real idea how the common Debian users will react 
to wheezy, but I am sure, with MATE, a drop-in-and-feature-complete 
replacement for the most used desktop environment in squeeze it will be 
at least on the desktop-front a pleased reaction. In its current state, 
from a technical point of view it might not be ideally (but I am sure 
there are even more not-ideal packages in Debian right now), but not 
THAT bad after all. And from a political / social point of view, just 
the only sane option to do (if we have

Re: Gentoo guys starting a fork of udev

[Kevin Toppins]

> Me too, please read:
> http://catb.org/jargon/html/T/top-post.html

Oh crap, my apologies.

I honestly forgot that the reply was still at the bottom of my email.

I did not intentionally leave it there.

It certainly wasn't some passive-aggressive kind of post-reply, I do
apologize for it being there.

-Kev

Re: debian mate

[Jon Dowland]

On Tue, Nov 20, 2012 at 06:37:48PM +0100, Michael Schmitt wrote:
> And whatever they or anybody else does in that regard, it will come
> to late for wheezy.

All of MATE will come too late for Wheezy. It's already too late for
Wheezy.


-- 
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/20121120220730.GB13984@debian

Re: debian mate

[Michael Schmitt]

Am 20.11.2012 23:07, schrieb Jon Dowland:

On Tue, Nov 20, 2012 at 06:37:48PM +0100, Michael Schmitt wrote:

And whatever they or anybody else does in that regard, it will come
to late for wheezy.

All of MATE will come too late for Wheezy. It's already too late for
Wheezy.
That may be common thinking, agreed. But I am that extremely worried 
about the current upgrade solution in wheezy, sorry... I think Debian 
should try to get it in. And freeze means "not released yet" last I 
checked. And Debian is the perfect example for a project that does 
rather release a month or two (or even longer) if needed, to get things 
right.


regards
Michael


--
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/50ac002d.9010...@gmail.com

Re: debian mate

[Carlos Alberto Lopez Perez]

On 20/11/12 22:55, Michael Schmitt wrote:
> 
> If one likes Gnome2.x or MATE or not is a question of taste, to
> acknowledge that many users are just mad about Gnome3 is a fact. To
> offer no real sane upgrade-path for those users is... dunno how to say
> it in another way, it is just insane! I did invest some time with
> thinking about all of this including talking to some MATE folks and
> current squeeze-gnome-users, and again thinking and thinking... imho it
> must be done everything possible to try to circumvent that imho probable
> desaster for the desktop users. Especially when I think of the real
> *average next door users* not the techie guys who may be happy (or at
> least not cry to loud about it) to invest some time tweaking their Xfce
> or KDE to behave more or less like their old gnome2 did. And if you
> really insist, I can give you detailed reports about what kind of
> problems those users have with the current DEs in Debian including
> gnome3, but I don't want to bloat this mail anymore. I just can
> guarantee you now, the panel in gnome3-fallback being black is not one
> of them. ;)
> 
> From my point of view, as said I can't comment much on the technical
> aspects here. I can just ask those who may have the ability to do so, to
> do it in a fair way, with as less prejudice as possible. Again, for the
> users that will have an issue with the current envisioned upgrade-path.
> For those users not so keen about adding a third-party repo to their
> sources.list, those users not knowing about the possibility to do so,
> those users that will get pissed.
> 
> regards
> Michael
> 
> P.S.: I know there is already work in progress for MATE for jessie, I
> just think that is too late. But I don't want to trip on anyones toes
> here

AFAIK is completely impossible that Debian ships MATE for Wheezy. Wheezy
has been frozen time ago and by policy no new packages are allowed in
the archive for testing during the freeze.

If you want a "classical" desktop your main options are: gnome3-classic,
XFCE and LXDE. You have also cinnamon on sid (it won't make to wheezy)

Gnome3-classic (fallback) is the option more like to what was gnome2. I
have been using it for a while and is a good option if you want a
desktop like gnome2.

What bothers me is that gnome3-classic will be deprecated with the next
release of GNOME. I hope that MATE can make into Debian for Jessie.


Regards!



signature.asc
Description: OpenPGP digital signature

Re: debian mate

[Russ Allbery]

Michael Schmitt  writes:

> That may be common thinking, agreed. But I am that extremely worried
> about the current upgrade solution in wheezy, sorry... I think Debian
> should try to get it in.

We are way, way too late in the release process for something that
substantial.  There are other alternatives to GNOME 3 already available in
wheezy for those who really dislike GNOME 3.  (Xfce, for example, seems to
have become a popular alternative to both KDE 4 and GNOME 3 among the
people I know who disliked the direction of those two projects.)

> And freeze means "not released yet" last I checked. And Debian is the
> perfect example for a project that does rather release a month or two
> (or even longer) if needed, to get things right.

As a user of Debian, I would very much prefer that Debian not delay the
release by even two months for MATE.  Nothing against MATE, but
introduction of a new desktop environment, even one with arguably nice
upgrade properties from a desktop environment in the last stable release,
is not the sort of emergency that should warrant postponing the release.

This is how freezes work.  If someone wants substantial new development
(and MATE, regardless of what it was forked from, still amounts to
substantial new development from a packaging perspective) in the next
release of Debian, it needs to be in unstable before the freeze.  If it
isn't, oh well, better luck for the next stable release.

As Debian gets larger and larger, we're going to have to get more and more
strict about this policy.  Every project thinks their needs are
particularly important, but down that path lies never releasing at all.
If it needs to be in the next stable, it needs to be in before the
release, period.  Anything else that isn't a bug fix to an existing
package will not be included, and the bar to override that default needs
to be quite high.

-- 
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/87r4nnq59x@windlord.stanford.edu

Fallback for GNOME in jessie [was: debian mate]

[Josselin Mouette]

Le mardi 20 novembre 2012 à 23:14 +0100, Carlos Alberto Lopez Perez a
écrit : 
> What bothers me is that gnome3-classic will be deprecated with the next
> release of GNOME. I hope that MATE can make into Debian for Jessie.

This is a problem that needs tackling for jessie one way or another.
This might require changes in the installer to select a different
default desktop depending on the hardware.

The best that could happen is someone picking up the pieces and
maintaining them. Ubuntu will certainly have to do it with some of them
for Unity, but the work will remain to be done for the panel and
metacity. Of course it is much better to start at 3.6 instead of 2.32
like MATE did, since modules have been ported to GTK3 and tons of bugs
have been fixed, especially in gnome-panel.

In the long term, I wonder how we can make things like MATE, GNOME and
cinnamon to coexist, with GNOME moving more and more features from
gnome-settings-daemon (which is an easily shared component) to
gnome-shell. It is much better for the development of GNOME itself, but
makes it harder for us to have a non-3D alternative.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1353451511.9228.123.camel@pi0307572

Re: History of Debian bootstrapping/porting efforts

[Johannes Schauer]

Hi,

On Tue, Nov 20, 2012 at 09:22:40PM +, Thorsten Glaser wrote:
> For reviving m68k:

Thanks for your detailed explanations! I added a summary of it to the
m68k section of the wiki page [1], extending the notes entered there by
Ingo Jürgensmann. Thanks to both of you!

> > - how did you go about finding reduced build dependencies? What were
> > the heuristics you used? How did you find dependency cycles to break
> > and how did you pick a solution?
> 
> Fully manually. I mostly drew ASCII files like this:
> 
> sourcepkg1
>   sourcepkg2 sourcepkg3 sourcepkg4 sourcepkg5 sourcepkg3
>   sourcepkg6 sourcepkg2
> 
> [...]
> 
> Then I worked on them from right to left, occasionally patching a huge
> dependency out or breaking a B-D loop by hand, sometimes also
> installing older versions of B-Ds manually, or even building versions
> older than sid but newer than what I had.

Since yesterday, my tools can now finally turn the whole dependency
graph into an acyclic graph by braking only a small number of build
dependencies (using an approximative solution to the minimal feedback
arc set problem) and output a final build order to build all of Debian
starting from an initial minimal build system (priority:essential plus
build-essential plus debhelper).

Detailed explanations can be found in the email I wrote to our
debian-bootstrap mailinglist:

http://lists.mister-muffin.de/pipermail/debian-bootstrap/2012-November/000425.html

A summary: Using the results I got from Daniel Scheplers x32
bootstrapping work, droppable build dependencies from Thorsten Glaser,
Patrick McDermott and my Gentoo work, I was able to reduce the original
923 nodes SCC into one SCC with 159 nodes and another with 42 nodes:

http://mister-muffin.de/p/NRTs.png http://mister-muffin.de/p/myFd.png

Those two graphs were easily breakable into a DAG by just removing 4 and
2 build dependencies respectively using the feedback arc set algorithm I
wrote over the weekend.

The same algorithm can also be applied to the full 923 node SCC for
Debian Sid, resulting in 90 build dependencies to be dropped to make the
graph acyclic and making a final build order possible with (close to)
minimal changes. For this to happen, only 50 source packages have to be
modified.

> > Build-Depends: huge (>= 1.0) [i386 arm] , tiny
> 
> Yeah, waiting for it…

As build profiles do not exist yet, there might be instances where my
algorithm chooses build dependencies that are not droppable in practice.

One obvious example is the dependency cycle:

src:pkg-config <--> libglib2.0-dev

So I'm now implementing a facility that allows to explicitly mark build
dependencies as unbreakable so that the algorithm finds an alternative
solution or throws an error. The above case for example has no
alternative solution as the cycle is of length two and has no other way
of braking it than building pkg-config without libglib2.0-dev. Since
this is unlikely to be possible and since the assumption is that only
build dependencies might be dropped when necessary but not binary
dependencies, a possible solution might be cross compilation.

Looking at the cross build dependency graph and braking its dependency
cycles is the next step I will take.

cheers, josch

[1] http://wiki.debian.org/DebianBootstrap/History


-- 
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/20121120225523.GA18533@hoothoot

Re: Something like nocompress DEB_BUILD_OPTION

[Guillem Jover]

On Tue, 2012-11-20 at 19:48:25 +, Thorsten Glaser wrote:
> Dmitrijs Ledkovs  debian.org> writes:
> > Gzip is ok, but many packages these days use xz -9 --extreme deb
> 
> xz is fine but -9 is abuse of the flexibility…
> maybe I should export XZ_DEFAULTS=--memlimit=150MiB
> in my build chroots… hmm… something to think about…
> (for m68k, I might actually use less, setting it to
> 80MiB would force compression down to -4 which, with
> --extreme possibly, is enough, there)

XZ_DEFAULTS will not be honoured because dpkg-deb is not using the
xz command, but the liblzma shared library.

Thanks,
Guillem


-- 
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/20121120231250.ga21...@gaara.hadrons.org

Re: Something like nocompress DEB_BUILD_OPTION

[Guillem Jover]

On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
> Okay. I did some tests with various packages. From binary only to text
> only. 

Thanks for the tests Bastian. It would still be nice to see a bigger
sample, if the tests only consisted of these 4 packages, though.

> Package   | gzip -6  | gzip -9  | gzip | xz -1
> --+--+-+-
> libc6 |  4339010 |  4321933 | 0.5% |  2938132
> perl-modules  |  3874170 |  3822719 | 1.5% |  3248392
> gnome-user-guide  |  9217494 |  9172395 | 0.5% |  7589076
> linux-image-3.2.0-4-amd64 | 32928159 | 3258 |  | 25945856
> 
> "gzip -9" is always much slower then "gzip -6". It is at most 2% better.
> "xz -1" is usualy faster then "gzip -9" and much better. However most
> packages only needs seconds to compress, so the difference will no
> really matter.
> 
> So instead of switching to gzip -6, a switch to xz -1 would make more
> sense in term of size and also speed.

> So my proposal would be:
> - Don't do anything for Wheezy.
>   Any change may break the CD creation.
> - Switch to xz per default for Jessie.
>   xz -3 is often faster in compressing stuff then gzip -9. -6 needs a
>   lot of memory, especially for compressing the files, so reducing the
>   default to -3 may make sense and does not cost much.

I've already mentioned in some other thread that for dpkg 1.17.x (that
is after wheezy), I'll be switching dpkg-deb to xz as the default
compressor, as that seemed the consensus; but that does not mean that
if the default compression level for gzip is suboptimal (as it seems
it is), that cannot be changed too.

For changing xz default compression level I'd like to see the
implications on a wider dataset, also we should take into account that
compression is only done once, so I don't think that's such an issue,
if the time and memory are not really onerous.

Thanks,
Guillem


-- 
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/20121120232155.gb21...@gaara.hadrons.org

Re: debian mate

[Adam D. Barratt]

On 20.11.2012 22:27, Russ Allbery wrote:

Michael Schmitt  writes:


That may be common thinking, agreed. But I am that extremely worried
about the current upgrade solution in wheezy, sorry... I think 
Debian

should try to get it in.


We are way, way too late in the release process for something that
substantial.


With all relevant hats on, very much agreed.


And freeze means "not released yet" last I checked.


It means "working to get what we have in to a state that we can / are 
happy to release". The day before a planned release fits your "not 
released yet" definition; I assume you wouldn't suggest making such 
significant changes at that point. To reiterate, the day of the freeze 
was already too late.


As Debian gets larger and larger, we're going to have to get more and 
more

strict about this policy.  Every project thinks their needs are
particularly important, but down that path lies never releasing at 
all.

If it needs to be in the next stable, it needs to be in before the
release, period.  Anything else that isn't a bug fix to an existing

  ^^
  freeze ;-)

package will not be included, and the bar to override that default 
needs

to be quite high.


Regards,

Adam


--
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/ef5c113d0545bcd3e5e33b00cc37a...@mail.adsl.funky-badger.org

Re: x32 port bootstrap is uploaded

[Guillem Jover]

On Tue, 2012-11-20 at 15:10:04 +0800, Thomas Goirand wrote:
> Daniel wrote:
> > wget http://87.98.215.228/debian/dists/archive.pub
> > debootstrap --arch=x32 --components=main,byhand,partial \
> >  --keyring=`pwd`/archive.pub \
> >  sid /root/x32-chroot/ http://87.98.215.228/debian/
> 
> Can I also just add the above Debian repo, do --add-architecture,
> and start replacing some packages? How can I for example, replace
> perl, on a running server?

In addition to what other have said, I'd strongly recommend against
using apt when attempting cross-grades, as the way apt currently
supports it is by removing the old instance and installing the new
one, which might render your system unusable. Also to perform some
cross-gradings you might need for some shared libraries to be marked
M-A:same which they might not yet be.

You can use bare dpkg, which does support cross-grading natively, but
then you might end up running into dependency-hell...

See my example cross-grading session in
.
Altough splitting the --unpack and --configure stages should make the
cross-grade easier.

Thanks,
Guillem


-- 
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/20121120233046.gc21...@gaara.hadrons.org

Re: Something like nocompress DEB_BUILD_OPTION

[Dmitrijs Ledkovs]

On 20 November 2012 23:21, Guillem Jover  wrote:
> On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote:
>> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
>> Okay. I did some tests with various packages. From binary only to text
>> only.
>
> Thanks for the tests Bastian. It would still be nice to see a bigger
> sample, if the tests only consisted of these 4 packages, though.
>
>> Package   | gzip -6  | gzip -9  | gzip | xz -1
>> --+--+-+-
>> libc6 |  4339010 |  4321933 | 0.5% |  2938132
>> perl-modules  |  3874170 |  3822719 | 1.5% |  3248392
>> gnome-user-guide  |  9217494 |  9172395 | 0.5% |  7589076
>> linux-image-3.2.0-4-amd64 | 32928159 | 3258 |  | 25945856
>>
>> "gzip -9" is always much slower then "gzip -6". It is at most 2% better.
>> "xz -1" is usualy faster then "gzip -9" and much better. However most
>> packages only needs seconds to compress, so the difference will no
>> really matter.
>>
>> So instead of switching to gzip -6, a switch to xz -1 would make more
>> sense in term of size and also speed.
>
>> So my proposal would be:
>> - Don't do anything for Wheezy.
>>   Any change may break the CD creation.
>> - Switch to xz per default for Jessie.
>>   xz -3 is often faster in compressing stuff then gzip -9. -6 needs a
>>   lot of memory, especially for compressing the files, so reducing the
>>   default to -3 may make sense and does not cost much.
>
> I've already mentioned in some other thread that for dpkg 1.17.x (that
> is after wheezy), I'll be switching dpkg-deb to xz as the default
> compressor, as that seemed the consensus; but that does not mean that
> if the default compression level for gzip is suboptimal (as it seems
> it is), that cannot be changed too.
>
> For changing xz default compression level I'd like to see the
> implications on a wider dataset, also we should take into account that
> compression is only done once, so I don't think that's such an issue,
> if the time and memory are not really onerous.

While I appreciate the discussions around default compression
algorithms and their setting, I'd rather this thread to stay on-topic.

Does the idea of providing a standard interface to disable compression
make sense? In the approximately similar fashion that noopt and
nostrip are justified?

This should be a standard interface via DEB_BUILD_OPTIONS, because
dh_builddeb / dpkg-deb is not the only way to build compliant binary
packages.

Please continue discussing default compression options, but please use
another thread/topic.

Just as I do now, I will continue to want the nocompress option
regardless of current or future default/non-default compression
algorithms and options. I'd like to gather consensus on how (in)sane
this idea is though before submit a patch for debian policy.

Regards,

Dmitrijs.


-- 
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/CANBHLUh_y+X=bzga5rldy+fvvmcmso0gwhamibc28y+erga...@mail.gmail.com

Re: New virtual packages: lv2-plugin and lv2-host

[Alessio Treglia]

Hi Ian,

thanks for the quick reply!

On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
 wrote:
> An lv2-plugin could be almost anything AFAICT, so depending on "some
> LV2 plugin" is not very useful.
>
> And an lv2-host could include something which can use only plugins
> with certain features.

Altough dillo doesn't support Javascript, it Provides www-browser and
that looks correct to me as it is definitely "something that can
browse HTML files".

Maybe a better proposal would be the following:

   lv2-hostanything that can load LV2 plugins

Cheers!

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer| quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


-- 
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/camhuwoz85f2qi-y28-wnjptvnenhykm9s+b_r7ryxyxfmi7...@mail.gmail.com

Re: debian mate

[Michael Schmitt]

Hi Russ,

as I see you, as a member of ctte, are kind of in favour of MATE for 
jessie and not wheezy... :(


Am 20.11.2012 23:27, schrieb Russ Allbery:

Michael Schmitt  writes:


That may be common thinking, agreed. But I am that extremely worried
about the current upgrade solution in wheezy, sorry... I think Debian
should try to get it in.

We are way, way too late in the release process for something that
substantial.  There are other alternatives to GNOME 3 already available in
wheezy for those who really dislike GNOME 3.  (Xfce, for example, seems to
have become a popular alternative to both KDE 4 and GNOME 3 among the
people I know who disliked the direction of those two projects.)
Xfce or KDE might not be a catastrophe, but you must see the same issue 
as I see. You may not be as "paranoid" as I am, but we all know how 
"users" tend to be: annoying, complaining, crying. humans at its best! 
:) They have no right to complain, we all know that too, but does that 
prevent them from doing so? And the only perspective I can see there is 
trying to minimize the possible fallout...



And freeze means "not released yet" last I checked. And Debian is the
perfect example for a project that does rather release a month or two
(or even longer) if needed, to get things right.

As a user of Debian, I would very much prefer that Debian not delay the
release by even two months for MATE.  Nothing against MATE, but
introduction of a new desktop environment, even one with arguably nice
upgrade properties from a desktop environment in the last stable release,
is not the sort of emergency that should warrant postponing the release.
Considering that the talk about MATE in Debian did start in around april 
2012 iirc, it really does not look like an emergency at all! *lol*


But I am not sure it would need that much more time. Sure, depending on 
when wheezy will actually be released. I did bet for 2013-02-17 as 
release-date, no idea if that comes even close, but I don't see why mate 
packages could be that difficult at all. Basically the work was already 
done for the gnome2 packages, only some modifications may have been 
needed to use that as a base for MATE. No real idea though, as I am just 
a user and don't have the expertise to assess that, but as some folks 
upstream had already months to work on the packages... I don't see a 
general issue there. At least when I ask them in what shape the packages 
are, they admit they may not be prime-time ready but from what I could 
get there is more or less just some minor fixes are needed (some last 
thoughts are missing though in that discussion). As said (and let me 
emphasize this) there are already packages for wheezy, they are just not 
yet perfect.
Do you remember the fame and glory Debian got for that little overdue in 
sarge? It had good technical reasons to be so late (even if I don't 
remember the details anymore)... but consider what it might have "cost" 
the project in the long run. Sure, those "what might and might not have 
been, if..." games tend to go nowhere, but they might give some ideas if 
one agrees to get in those thoughts a bit deeper...
And now, I see a similar situation coming, just the other way around. 
Roughly one year "too late" for sarge, does not compare to one or two 
months later as planned, IF it would even need that long (which I doubt).


But nice, we do agree that MATE is from a users point of view the BEST 
alternative for gnome2? And gnome2 was not "a DE in then to be 
oldstable" it is "*THE* DE of then oldstable". After months of playing 
around again and again with gnome3-shell and -fallback, Xfce and KDE 
forward and backward and always not being happy, feeling incomplete and 
a curse here and there in a "specific direction"... I just gave me a 
bump and installed mate from a third party repo and even if it had some 
*minor* glitches back then, I had tears in my eyes to have my gnome2 
back! You can't imagine what I felt that first minute after login... and 
as I try to keep it family and US-friendly, I don't go in any more 
detail there. ;)


And MATE is not "new" it is gnome2 with a new name, which runs 
remarkable well, stable and effortless. I guess 99% code-equal with the 
last gnome 2.x release. Yes, it has bugs. Old gnome 2.x ones got fixed, 
new ones got introduced (count: 1 afaict, a regression which is already 
been worked on).



This is how freezes work.  If someone wants substantial new development
(and MATE, regardless of what it was forked from, still amounts to
substantial new development from a packaging perspective) in the next
release of Debian, it needs to be in unstable before the freeze.  If it
isn't, oh well, better luck for the next stable release.
I know how that works "in general", I know that it is most likely too 
late... but just "most likely"... ;)



As Debian gets larger and larger, we're going to have to get more and more
strict about this policy.

Ok, somewhat ack.


Every project thinks their nee

Bug#693859: ITP: pixz -- parallel, indexing version of xz

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: pixz
  Version : 0.0.0+git$something
  Upstream Author : Dave  Vasilevsky 
* URL : https://github.com/vasi/pixz
* License : BSD 2-clause
  Programming Lang: C
  Description : parallel, indexing version of xz

This is another parallel xz compressor/decompressor.
Better long description to follow. 

You can look at pxz to get the general idea.  Or imagine multithreaded
xz.

So why another parallel xz in the archive.

- - This one seems about 25% faster compressing in some simple tests I
  ran (compressing a 2.7G file with 6 threads, maximum compression).
  Decompression seems to be a wash between xz, pxz, and pixz on files
  produced by xz. On files produced by pixz, pixz is noticably faster 

- - More importantly it does not seem to suffer from (because of being 
"indexable")

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686502

  i.e. busybox xz also works on the output of pixz

The lack of releases is a bit annoying; perhaps upstream can be
convinced to make some tags.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iJwEAQECAAYFAlCsOlsACgkQTiiN/0Um85nQ/AP+P9p1aoYfBz5uedA56KOO4r1i
ZWXGcvGnVWRWjpqlueo/MP6xLP7rNpcOU6nkef9QC5iTJVBseWsItdDGnZ5lXhDZ
UzO1MW8dXlCEDTg6qXECKrarTjzKWvvOY8syr+reKY49BBdHc60I7nv4ElXvC4X8
6omfI8s4AifX55n0/gI=
=ULCR
-END PGP SIGNATURE-


-- 
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/20121121022011.24499.34110.reportbug@zancas.localnet

Re: debian mate

[Russ Allbery]

Michael Schmitt  writes:

> as I see you, as a member of ctte, are kind of in favour of MATE for
> jessie and not wheezy... :(

I have no opinion on MATE.  I personally switched from GNOME 2 to Xfce on
the one system where I use an integrated desktop when gnome-shell wouldn't
run due to the age of the graphics and the fallback for some reason didn't
function properly.  (This was *right* after it landed in unstable, and I
suspect this is a bug that was fixed eons ago.  I'd been meaning to try
Xfce since I make a personal policy of changing desktop environments every
few years -- I used to use GNUstep before GNOME 2 -- so I didn't bother to
pursue it further.)

I can say that, as a light GNOME user, switching to Xfce was trivial.  It
took me all of an hour.  But I can be a somewhat atypical user.

I haven't evaluated the quality of the MATE libraries or their
maintenance.  In general, I'm supportive of being discriminating about
what packages we include in the archive, since we're promising bug and
security support, but I'm also in favor of being inclusive and, in
general, welcoming packages for anything that people want to work on.

> Xfce or KDE might not be a catastrophe, but you must see the same issue
> as I see. You may not be as "paranoid" as I am, but we all know how
> "users" tend to be: annoying, complaining, crying. humans at its best!
> :) They have no right to complain, we all know that too, but does that
> prevent them from doing so? And the only perspective I can see there is
> trying to minimize the possible fallout...

I don't believe avoiding user complaints is a primary development goal for
Debian.  One of the great things about working on Debian is that we are
not a popularity-driven or market-share-driven project.  We want to do the
right thing for our users, but that isn't the same thing as avoiding
complaints.

In the specific case of releases, we have a stark tradeoff when it comes
to freeze deadlines and release time frames.  On one hand, some users will
always want something that missed the freeze deadline.  On the other hand,
*all* of our users who want to run stable and not testing or unstable are
hurt by release delays.

The way that we, as a project, have chosen (after *much* discussion and
some experimentation with alternatives) to resolve this conflict is with a
freeze that's advertised well in advance, and a clear policy of what's
acceptable after that deadline.  There are other alternatives to managing
a release cycle.  They all have different problems.  This one seems to be
the best compromise.

> But I am not sure it would need that much more time.

It always takes more time to introduce things at the last minute.  That's
why we don't have this discussion every time, and instead have developed
some clear guidelines for how to make this decision.

We can literally have this discussion forever.  There's always just one
more thing that someone thinks is really important.  The advantage of
having clear guidelines is that we can say that it doesn't matter.  It
missed the freeze.  It's too late.  Best of luck next time.

It sounds harsh, and to some extent it *is* harsh, but I'm serious when I
say that without this sort of policy Debian will literally become
unreleasable.

> But nice, we do agree that MATE is from a users point of view the BEST
> alternative for gnome2?

No, I have no opinion on that.  After all, my personal experience is that
Xfce is a fine alternative for GNOME 2 if one doesn't like GNOME 3 for
some reason.  :)

> And I know what you have in mind there, with "but down that path lies
> never releasing at all" it does just not fit here. Something like this
> does not happen regularly.

Quite to the contrary: something like this has happened, about this time
in the release process, in every release of Debian that had a freeze since
I started using the distribution.  :)

> That all said, I need to express my apologies for such long mails for an
> idea where almost anybody seems to be against it. :( I know for a fact
> what a wonderful operating system and community (with its humanly common
> exceptions *g*) Debian is and my contribution today (which some may
> consider to be annoying as hell) is this tl;dr-candidate for some
> readers. :) But imho the only right thing to do right now, even if it is
> so damn late... :/

Oh, I have no objection to you expressing your opinion!  By all means,
that's what the mailing list is for.  But a lot of past experience has
completely convinced me of the merits of hard release freezes.

We have backports.debian.org for those things that are just desperately
needed but didn't make it into the release.  If MATE makes it into
unstable/testing and is proven stable, backporting it to wheezy would be a
viable option.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Bug#693859: ITP: pixz -- parallel, indexing version of xz

[Adam Borowski]

On Tue, Nov 20, 2012 at 10:20:11PM -0400, David Bremner wrote:
> * Package name: pixz

> So why another parallel xz in the archive.
> 
> - - This one seems about 25% faster compressing in some simple tests I
>   ran (compressing a 2.7G file with 6 threads, maximum compression).

You mean, 25% faster while taking 500% more CPU?  Or "25% faster than
parallel implementation X, a few hundred percent than xz"?

>   Decompression seems to be a wash between xz, pxz, and pixz on files
>   produced by xz. On files produced by pixz, pixz is noticably faster 
> 
> - - More importantly it does not seem to suffer from (because of being 
> "indexable")
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686502
> 
>   i.e. busybox xz also works on the output of pixz

If busybox unxz fails to handle concatenated streams, that's a rather severe
bug.  I'm not sure if the xz format specification mentions this explicitely,
but that's a rather widely used idiom among Unix compressors.


-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
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/20121121024512.ga6...@angband.pl

Re: debian mate

[Michael Schmitt]

Am 20.11.2012 23:14, schrieb Carlos Alberto Lopez Perez:

On 20/11/12 22:55, Michael Schmitt wrote:

If one likes Gnome2.x or MATE or not is a question of taste, to
acknowledge that many users are just mad about Gnome3 is a fact. To
offer no real sane upgrade-path for those users is... dunno how to say
it in another way, it is just insane! I did invest some time with
thinking about all of this including talking to some MATE folks and
current squeeze-gnome-users, and again thinking and thinking... imho it
must be done everything possible to try to circumvent that imho probable
desaster for the desktop users. Especially when I think of the real
*average next door users* not the techie guys who may be happy (or at
least not cry to loud about it) to invest some time tweaking their Xfce
or KDE to behave more or less like their old gnome2 did. And if you
really insist, I can give you detailed reports about what kind of
problems those users have with the current DEs in Debian including
gnome3, but I don't want to bloat this mail anymore. I just can
guarantee you now, the panel in gnome3-fallback being black is not one
of them. ;)

 From my point of view, as said I can't comment much on the technical
aspects here. I can just ask those who may have the ability to do so, to
do it in a fair way, with as less prejudice as possible. Again, for the
users that will have an issue with the current envisioned upgrade-path.
For those users not so keen about adding a third-party repo to their
sources.list, those users not knowing about the possibility to do so,
those users that will get pissed.

regards
Michael

P.S.: I know there is already work in progress for MATE for jessie, I
just think that is too late. But I don't want to trip on anyones toes
here

AFAIK is completely impossible that Debian ships MATE for Wheezy. Wheezy
has been frozen time ago and by policy no new packages are allowed in
the archive for testing during the freeze.
So much for the general rules... but exceptions ARE possible! And I just 
try to make a case here about how important it might be!



If you want a "classical" desktop your main options are: gnome3-classic,
XFCE and LXDE. You have also cinnamon on sid (it won't make to wheezy)
It is *not* about me and I know already all available options in all 
possible flavors and directions available as of today for wheezy.



Gnome3-classic (fallback) is the option more like to what was gnome2. I
have been using it for a while and is a good option if you want a
desktop like gnome2.
It may be for you or for some others, but not for all a viable option. 
Most definitely not for me, the local and remote folks I asked around 
the globe. Don't get me wrong most of them could probably "get along" 
with the fallback mode after some degree of tweaking, but they would 
miss A LOT! Some examples? In no particular order: The complete 
infrastructure under gnome-fallback is a *completely* *different* horse. 
Some would say it is not even a horse, it is rather a mule! That "mule" 
behaves utterly different when it comes to several aspects. The panel 
(no free arranging of applets / starters; not all applets ported; simple 
right-click does not work anymore, alt or even alt+super+click is needed 
now; menus arranged in a completely different and un-logical 
fashion;...). No language / keyboard settings in GDM anymore (Oops, you 
speak a different language with a different keyboard layout then the 
system default? Hope you did not use any fancy symbols for your password 
then!). The control-center, a lot of stuff is missing. Gone are the days 
you can keep your laptop running when closing the lid. Want to prohibit 
display blanking? Sorry, gone too. That list goes on and on (ask the web 
for a more comprehensive list) and some of those shortcomings can be 
tweaked away, which means effort and grief in varying degree. In short, 
gnome3-fallback just looks at the upper surface almost like gnome2 did, 
but is, behaves, works completely different. Fun fact there... I happen 
to be forced to work with Redmond OS since windows 95. From Windows 95 
up to Windows 7 the design did change *a lot*, it got more features, 
some options got re-arranged *slightly* but the overall way to handle a 
windows-system has never changed a bit. It was always the same as I sat 
in front of a new windows release the first time. Five minutes and I 
found everything and realised that "under the hood" everything is 
actually almost exactly the same as before. *No* research to get going 
necessary! I don't want to praise MS here (crap and the wrong 
development model remains crap and wrong) but they got one thing right, 
don't shock your users too much!



What bothers me is that gnome3-classic will be deprecated with the next
release of GNOME. I hope that MATE can make into Debian for Jessie.
I kind of insist it being in jessie ;) And yes, that makes another good 
point why the gnome3-fallback just can't feel like the real thing. It is 
suppos

Re: debian mate

[Matt Zagrabelny]

Hi Michael,

On Tue, Nov 20, 2012 at 9:03 PM, Michael Schmitt  wrote:
> Am 20.11.2012 23:14, schrieb Carlos Alberto Lopez Perez:
>
>> On 20/11/12 22:55, Michael Schmitt wrote:
>>>
>>> If one likes Gnome2.x or MATE or not is a question of taste, to
>>> acknowledge that many users are just mad about Gnome3 is a fact. To
>>> offer no real sane upgrade-path for those users is... dunno how to say
>>> it in another way, it is just insane! I did invest some time with
>>> thinking about all of this including talking to some MATE folks and
>>> current squeeze-gnome-users, and again thinking and thinking... imho it
>>> must be done everything possible to try to circumvent that imho probable
>>> desaster for the desktop users. Especially when I think of the real
>>> *average next door users* not the techie guys who may be happy (or at
>>> least not cry to loud about it) to invest some time tweaking their Xfce
>>> or KDE to behave more or less like their old gnome2 did. And if you
>>> really insist, I can give you detailed reports about what kind of
>>> problems those users have with the current DEs in Debian including
>>> gnome3, but I don't want to bloat this mail anymore. I just can
>>> guarantee you now, the panel in gnome3-fallback being black is not one
>>> of them. ;)
>>>
>>>  From my point of view, as said I can't comment much on the technical
>>> aspects here. I can just ask those who may have the ability to do so, to
>>> do it in a fair way, with as less prejudice as possible. Again, for the
>>> users that will have an issue with the current envisioned upgrade-path.
>>> For those users not so keen about adding a third-party repo to their
>>> sources.list, those users not knowing about the possibility to do so,
>>> those users that will get pissed.
>>>
>>> regards
>>> Michael
>>>
>>> P.S.: I know there is already work in progress for MATE for jessie, I
>>> just think that is too late. But I don't want to trip on anyones toes
>>> here
>>
>> AFAIK is completely impossible that Debian ships MATE for Wheezy. Wheezy
>> has been frozen time ago and by policy no new packages are allowed in
>> the archive for testing during the freeze.
>
> So much for the general rules... but exceptions ARE possible! And I just try
> to make a case here about how important it might be!
>
>
>> If you want a "classical" desktop your main options are: gnome3-classic,
>> XFCE and LXDE. You have also cinnamon on sid (it won't make to wheezy)
>
> It is *not* about me and I know already all available options in all
> possible flavors and directions available as of today for wheezy.

I'm guessing that by the time wheezy is released MATE will be in
unstable and the wheezy-backports won't be far behind. It is a
sensible compromise.

Remember, Debian is more that just a Desktop operating system. Let's
work within policy and be respectful to those who are working hard to
get the release ready.

Cheers,

-mz


-- 
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/caolfk3xq2cntrywk1lgjslglrhxv1yrfrbshoahrn3lprr_...@mail.gmail.com

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-11-14 22:02, Niels Thykier wrote:
> Hi,
> 
> We are considering removing the following packages from testing as
> they have unfixed RC bugs filed against them. [...]
>

ferm, apt-2p2 and mediawiki-math has been fixed in sid and by the looks
of it all of them are already unblocked.

> Should you need a bit more time than given, please do not hesitate to
> contact us.  It is also easier for us if we can avoid having to
> reintroduce a removed package.
> 
> [...]
>

sympa got a deadline extension.

> Thanks,
> Niels (on behalf of the Release Team)
> 
> [...]

So no removals in this round! \o/

~Niels


-- 
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/50ac8507.9070...@thykier.net