Re: SRWare Iron: Chromium without the data-mining

[Josselin Mouette]

Le samedi 22 mai 2010 à 08:43 +0200, Tollef Fog Heen a écrit :
> | I don't see what you mean by "iffy" tabbed browsing, what's wrong with
> | tabbed browsing in Epiphany?
> 
> For me, at least two things:
> 
> - C-TAB/C-S-TAB doesn't work for switching tabs, I have to use
>   C-PgUp/PgDn.

This is the default GTK+ shortcut for that.

> - The tabs are always the same size, meaning it's hard to keep track
>   when I have many tabs.

There is an ongoing discussion upstream to change that, but this also
requires a global change at the GTK+ level and in the HIG, so that all
GNOME applications behave the same. This specific point is considered
critical for most MDI applications.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
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/1274771053.9909.7.ca...@meh

Re: lilo removal in squeeze (or, "please test grub2")

[Harald Braumann]

Hi,

On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:
> (4) Users need to test grub2 now.

I've been using grub2 for quite some time now on several different
systems with mixed success.

On simple standard system -- one disk, one kernel in /boot, no fancy
stuff -- it works quite well.

On other systems it often breaks miserably. Updates leave my system
unbootable every other time. One major problem are incompatible
versions of the boot loader installed in the MBR and grub.cfg.

Currently, automatic installation of grub in the MBR is a no-go for me,
because of #554790 but I can't prevent grub from automatically
updating grub.cfg which leads to incompatible versions, hence an
unbootable system. 

On some systems the generated grub.cfg is useless for me. On each
update I have to check for changes and incorporate them in my own
hand-edited version.

It is my belief, that the whole automagic configuration system as it
is now is far to complex and convoluted. It is too inflexible to
support any requirements by the user the developers haven't thought
about and in this case you have to work actively against the system to
get what you want. See #578576. I'm not sure if this can be fixed or
if the whole system has to be rethought. Currently I'd tend to the
latter.

And because of the tight dependency between the loader and grub.cfg
and zero-tolerance of the loader to unknown parameters in grub.cfg, it
is far too fragile and very easily leads to an unbootable system.

Because of this, coupled with the many open bugs and the lack of
documentation, I'm not sure if grub2 is ready to be released to the
unsuspecting public.

Cheers,
harry



-- 
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/20100525090027.ga30...@sbs288.lan

Processed: Re: Bug#582968: running apps that have sound cause system to hang

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 582968 general
Bug #582968 [sound] running apps that have sound cause system to hang
Warning: Unknown package 'sound'
Bug reassigned from package 'sound' to 'general'.
> --
Stopping processing here.

Please contact me if you need assistance.
-- 
582968: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582968
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.127477991228103.transcr...@bugs.debian.org

Re: lilo removal in squeeze (or, "please test grub2")

[Chris Carr]

On 25/05/2010 10:00, Harald Braumann wrote:

Hi,

On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:

(4) Users need to test grub2 now.


I've been using grub2 for quite some time now on several different
systems with mixed success.

[snip]

Because of this, coupled with the many open bugs and the lack of
documentation, I'm not sure if grub2 is ready to be released to the
unsuspecting public.


Just to add my 2p, I have had significant, foreseeable, nonunique 
problems with grub2 on several machines (#495433, #508405, #518835 are 
merely the ones I reported). I would agree with Harald's assessment that 
grub2 is not ready.


It appears from this thread that the maintainer status of grub2 is 
little better than that of lilo. It is therefore difficult to understand 
an argument in favour of removing lilo on the basis of a lack of 
maintainer(s), as that would also apply to grub2.


Given the importance of a reliable boot loader and the severity and 
urgency of any significant bugs in one, it is no surprise that volunteer 
maintainers are hard to find. Would it be sensible to consider creating 
a "boot loader" team to maintain one or more boot loaders, instead of 
waiting for individuals to step up?


CC


--
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/4bfba195.4050...@gmail.com

Re: Re: when to split a package into architecture: all and architecture: any halves

[Fabian Greffrath]

Personally I base my splitting on lintian's warning.


The package has a significant amount of architecture-independent data 
(over 4MB, or over 2MB and more than 50% of the package) in /usr/share 
but is an architecture-dependent package. This is wasteful of mirror 
space and bandwidth since it means distributing multiple copies of 
this data, one for each architecture.





--
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/4bfb9ff4.1010...@greffrath.com

Bug#583086: ITP: libcatalyst-plugin-unicode-encoding-perl -- Unicode-aware Catalyst plugin

[Antony Gelberg]

Package: wnpp
Severity: wishlist
Owner: Antony Gelberg 

  Package name: libcatalyst-plugin-unicode-encoding-perl
  Version : 1.0
  Upstream Authors : Christian Hansen , Masahiro Chiba, Tomas
Dorian 
  URL : http://search.cpan.org/dist/Catalyst-Plugin-Unicode-Encoding
  License : GPL / Artistic (as for Perl)
  Programming Lang: Perl
  Description : Unicode-aware Catalyst plugin

This module provides a simple way of making Catalyst webapps work with
Unicode.  On request, decodes all parameters from encoding into a sequence 
of logical characters. On response, encodes body into encoding.

use Catalyst qw[Unicode::Encoding];

MyApp->config( encoding => 'UTF-8' ); # A valid Encode encoding



-- 
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/20100525100057.9575.23205.report...@labrie.wayforth.com

Re: Bug#581488: general: lower vm.swappiness by default for desktop installations

[Josselin Mouette]

Le mercredi 12 mai 2010 à 21:22 +0200, Marcus Better a écrit :
> Recently I got the advice [1] to set vm.swappiness to 0, rather than
> the default 60. This improved things dramatically. Apparently Eclipse
> is no longer being swapped out preemptively all the time. The
> difference in perceived responsiveness is spectacular.
> 
> Shouldn't we provide a lower swappiness by default for desktop
> installs, at least those with a fair amount of RAM? This could improve
> the user experience on most modern desktop systems. Most users will
> probably never find out to tune this on their own. Ubuntu recommends a
> value of 10 for desktop systems [2, 3] (but ship with the default
> value).

The bug has been reassigned to desktop-base, but I don’t think it is the
appropriate place for that.

How about setting this default in a new, specific package, and have the
desktop environment metapackages recommend it?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
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/1274783426.9909.17.ca...@meh

Re: lilo removal in squeeze (or, "please test grub2")

[Steffen Möller]

Hello,

On 05/23/2010 03:44 PM, Julien BLACHE wrote:
> Darren Salt  wrote:
>
> Hi,
>   
>> Working fine here on i386, whether booting a stock kernel (testing with
>> 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
>> on amd64 for some time now, but I've seen no problems with my custom kernels
>> (which are all initrd-free).
>> 
> No problems to report on amd64 either, with or without an initrd.
>   
this Grub thingy is something really tough to explain to migrators.
The worst is that while the boot prompt works, one loses the console
all too easily and does not get it back. And google says one should
edit files here and there to keep the gfxpayload.

Yes, I did all that. But I did not want to do that. And then I lost it
again at some later update.

Since the console is the entry to most newbies, whatever you do,
make it as easy as possible. If that is not possible, then please
leave LILO in.

Thanks

Steffen (who accepted to have lost his Console, no ALT-F1 any more)


-- 
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/4bfbb8bd.8050...@gmx.de

Bug#583101: ITP: gtk2hs-buildtools -- Tools to build the Gtk2Hs suite of User Interface libraries

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: gtk2hs-buildtools
  Version : 0.9
  Upstream Author : Axel Simon, Duncan Coutts, Manuel Chakravaty
* URL : http://www.haskell.org/gtk2hs/
* License : GPL-2
  Programming Lang: C, Haskell
  Description : Tools to build the Gtk2Hs suite of User Interface libraries

 This package provides a set of helper programs necessary to build the Gtk2Hs
 suite of libraries. These tools include a modified c2hs binding tool that is
 used to generate FFI declarations, a tool to build a type hierarchy that
 mirrors the C type hierarchy of GObjects found in glib, and a generator for
 signal declarations that are used to call back from C to Haskell. These tools
 are not needed to actually run Gtk2Hs programs.



--
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/20100525121729.25004.44585.report...@zezinho

Upstream stopped to ship tar.gz file. What to do?

[Artur R. Czechowski]

Hello,

Upstream of imms stopped to ship tar.gz file and ships only tar.bz2.
However, there is no new upstream release at the moment. The question is:
Shall I prepare new release of Debian package using tar.bz2 tarball?

There was a short discussion on #debian-devel, but there was no conclusion.
Possible answers are:
1. Definitely, if possible you shall keep the tarball the same as upstream
   tarball (unless other concerns are involved, like, for example, DFSG
   compliancy).
2. Absolutely not. Just stick to current tarball and switch when new upstream
   release will be available.
3. This is the sole maintainer's decision.

BTW, I'm doing also other changes in the package. So, changing the tarball
is not an only purpose of new package release.

Pro:
To verify if tarball content is the same as upstream ones, one need to fetch
both tarballs, unpack them and verify the checksum of each file, instead of
just checking the checksum of whole tarballs. But this is not a strong
argument because it's a difference between a shell one liners and a single
run of md5sum/sha1sum.

Con:
It clutters the archive with exactly the same content but differently
packaged. A little more bandwidth and disc space usage (well, it's not even
a promile, I suppose).

The second question is: in case new tarball shall be uploaded what is the best
approach?
1. Create a new upstream version like 3.1.0~rc8+bz-1?
2. Just do next release of debian package: 3.1.0~rc8-3 but remember about
   building the package with -sa option?

Best regards
Artur


-- 
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/20100525115813.ga2...@hell.pl

Re: Bug#581488: general: lower vm.swappiness by default for desktop installations

[Aaron Toponce]

On 5/12/2010 1:22 PM, Marcus Better wrote:
> Recently I got the advice [1] to set vm.swappiness to 0, rather than
> the default 60. This improved things dramatically. Apparently Eclipse
> is no longer being swapped out preemptively all the time. The
> difference in perceived responsiveness is spectacular.

You might also be interested in:

# sync; cat 3 > /proc/sys/vm/drop_caches

This is a nondestructive operation that will drop your clean caches,
clear up unused inodes, and free up available RAM. Usually, after
running my desktop for a few hours, depending on the applications I'm
running as well, this will free up about 1/2 of my installed RAM.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

Ferenc Wagner wrote:
> Stephen Powell  writes:
>>
>> Both grub-legacy and grub-pc use sectors on the hard disk outside of
>> the master boot record and outside of a partition ...
>
> You may want to try extlinux, it works much like LILO in this respect.

Well, I tried extlinux last night, and I am hopeful that this is going
to be a solution, at least for me.  extlinux seems to combine the best
parts of grub-pc and lilo.  Like grub-pc, extlinux understands the file
system, and can read the configuration file, kernel, and the initial
RAM file system image from the file system without needing a list of
specific blocks to read.  Thus, the boot loader does not need to be re-run
every time a kernel is installed or updated or an initial RAM file system
image is installed or updated.  The number of file systems it supports
is limited, but that's OK.  A separate /boot partition of the file system
type supported by the boot loader is acceptable.

But like lilo it stays out of unallocated (and therefore not backed up)
sectors.  The boot block of extlinux is installed in the boot sector
of a partition, and the second stage loader occupies a file within the
partition.  It does not use the master boot record.  It relies on a
master boot record program to chain load it from the partition boot
sector.  (I use the mbr package for that.)  It *does* support the
specification of an initial text video mode (vga option), though this
is not specifically documented.

Speaking of documentation, that seems to be its main weakness.
Documentation is sketchy and spread out over a number of different files.
I would have had a hard time configuring it if it weren't for
correct guesses based on my knowledge of how lilo is configured, which
newer users won't have.  It installs hook scripts that I don't want
(and that have bugs).  But after manual configuration and tweaking,
it works just fine.  Now, if it passes the backup / low-level-format /
restore test, I'll be good to go.  Stay tuned ...

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/1078928757.35141.1274793733671.javamail.r...@md01.wow.synacor.com

Re: Upstream stopped to ship tar.gz file. What to do?

[Paul Wise]

On Tue, May 25, 2010 at 7:58 PM, Artur R. Czechowski  wrote:

> Upstream of imms stopped to ship tar.gz file and ships only tar.bz2.

So they deleted existing tarballs and added new tar.bz2 tarballs?

> However, there is no new upstream release at the moment. The question is:
> Shall I prepare new release of Debian package using tar.bz2 tarball?

Send upstream Ubuntu's patch, make patches for the 2 bugs, poke them
to make a new release, fix the watch file etc and then upload that.

> There was a short discussion on #debian-devel, but there was no conclusion.
> Possible answers are:
> 1. Definitely, if possible you shall keep the tarball the same as upstream
>   tarball (unless other concerns are involved, like, for example, DFSG
>   compliancy).
> 2. Absolutely not. Just stick to current tarball and switch when new upstream
>   release will be available.
> 3. This is the sole maintainer's decision.

I prefer my solution, but otherwise 3, then 2 then 1.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Upstream stopped to ship tar.gz file. What to do?

[Russ Allbery]

"Artur R. Czechowski"  writes:

> Upstream of imms stopped to ship tar.gz file and ships only tar.bz2.
> However, there is no new upstream release at the moment. The question
> is:  Shall I prepare new release of Debian package using tar.bz2
> tarball?

> There was a short discussion on #debian-devel, but there was no conclusion.
> Possible answers are:
> 1. Definitely, if possible you shall keep the tarball the same as upstream
>tarball (unless other concerns are involved, like, for example, DFSG
>compliancy).
> 2. Absolutely not. Just stick to current tarball and switch when new upstream
>release will be available.

I'd go with 2.  I don't see any need to hurry with replacing the tarball
with a bzip2-compressed version until upstream releases a new release.

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

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote:
> William Pitcock  wrote:
>> This bug *can* be fixed, but not without a significant rewrite of the
>> way that lilo's stage2 loader code works.  Given that there is no
>> active upstream and that the Debian lilo package carries many patches
>> for bug fixes that are alleviated by standardizing on grub2, this
>> seems like the best option for Debian.
> 
> Agreed: dead (and buggy) softwares must be out of the distribution.
> Whatever happens. If LILO regains upstream coders, its return to the
> distribution is quite easy.

By that standard, grub-pc should be removed from the distribution.
It may have upstream support, but based on other posts I've seen, it
effectively has no maintainer.  Which is worse, a package with
effectively no upstream support or a package with effectively no
maintainer?  And grub-pc is buggier than lilo.

I understand the need to remove packages with no upstream support.
But asking users to test a package with umpteen known release-critical
bugs, most of which have apparently been fixed upstream, but have
not been fixed in Debian because there is no maintainer to download
a new upstream version, is not a reasonable request in my humble
opinion.  Get a maintainer for it, fix the known bugs, and *then*
ask the users to test it.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/1927842586.35924.1274795074336.javamail.r...@md01.wow.synacor.com

Re: Bug#581488: general: lower vm.swappiness by default for desktop installations

[David Weinehall]

On Tue, May 25, 2010 at 06:59:45AM -0600, Aaron Toponce wrote:
> On 5/12/2010 1:22 PM, Marcus Better wrote:
> > Recently I got the advice [1] to set vm.swappiness to 0, rather than
> > the default 60. This improved things dramatically. Apparently Eclipse
> > is no longer being swapped out preemptively all the time. The
> > difference in perceived responsiveness is spectacular.
> 
> You might also be interested in:
> 
> # sync; cat 3 > /proc/sys/vm/drop_caches

That'd be

sync; echo 3 > /proc/sys/vm/drop_caches



Kind regards: David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20100525142625.gg24...@test5.acc.umu.se

Re: lilo removal in squeeze (or, "please test grub2")

[David Weinehall]

On Tue, May 25, 2010 at 09:22:13AM -0400, Stephen Powell wrote:

[snip]

> Speaking of documentation, that seems to be its main weakness.
> Documentation is sketchy and spread out over a number of different files.
> I would have had a hard time configuring it if it weren't for
> correct guesses based on my knowledge of how lilo is configured, which
> newer users won't have.  It installs hook scripts that I don't want
> (and that have bugs).  But after manual configuration and tweaking,
> it works just fine.  Now, if it passes the backup / low-level-format /
> restore test, I'll be good to go.  Stay tuned ...

Perhaps you, with the experienced gained from your adventures with
extlinux, could help write some documentation?


Kind regards: David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20100525143916.gh24...@test5.acc.umu.se

Re: lilo removal in squeeze (or, "please test grub2")

[Ferenc Wagner]

Stephen Powell  writes:

> Ferenc Wagner wrote:
>
>> Stephen Powell  writes:
>>>
>>> Both grub-legacy and grub-pc use sectors on the hard disk outside of
>>> the master boot record and outside of a partition ...
>>
>> You may want to try extlinux, it works much like LILO in this respect.
>
> It does not use the master boot record.  It relies on a master boot
> record program to chain load it from the partition boot sector.  (I
> use the mbr package for that.)

The extlinux package itself also contains an mbr.bin, which you can use
(it's strong point is probably EBIOS support).

> Speaking of documentation, that seems to be its main weakness.
> Documentation is sketchy and spread out over a number of different files.

/usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
comprehensive according to my standards, at least as far as the core is
concerned.  What did you miss?  Some modules may be less well documented.

> It installs hook scripts that I don't want (and that have bugs).

I hope we can fix them soon (they are Debian specific additions).
-- 
Cheers,
Feri.


-- 
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/874ohwt3td@tac.ki.iif.hu

Re: Upstream stopped to ship tar.gz file. What to do?

[Peter Samuelson]

[Artur R. Czechowski]
> BTW, I'm doing also other changes in the package. So, changing the tarball
> is not an only purpose of new package release.
> 
> Pro:
> To verify if tarball content is the same as upstream ones, one need
> to fetch both tarballs, unpack them and verify the checksum of each
> file, instead of just checking the checksum of whole tarballs.

bzip2 only has one commonly used implementation, and it hasn't really
changed in a long time, and it doesn't have troublesome features like
gzip -n or --rsyncable, so usually you can check a published checksum
with:

gzip -cd foo.tar.gz | bzip2 -9 | md5sum -

(Most people use -9, anyway.)

I agree with Russ.  There's no compelling reason to upload a tar.bz2
that has the same content as an existing tar.gz.  At the very least,
you would have to give the tarball a new upstream version number.  Not
worth it.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20100525155518.gb18...@p12n.org

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
> Stephen Powell wrote:
>> (3) The need for special backup requirements will be 
>> used by the opponents of Linux at my place of employment 
>> to oppose further deployments of Linux, ...
> 
> What about the carrot approach?  Find an even better 
> backup method, compatible with Grub 2 and appealing 
> to your management for its efficiency.

You're missing the point.  The main selling point to management
is that Linux is free.  If they have to buy new backup software
in order to accommodate Linux' backup requirements, that will
kill it on the spot.  Whatever boot loader I use must not
require new backup software or impose special backup requirements.
And its not just money.  As a rule, people like what they know.
The backup people are Windows people, and they'd love an
excuse to complain to management about the backup requirements
of my Linux servers.  grub-legacy and grub-pc are non-starters
for me for that reason.  Until now, only lilo, as far as I knew,
met all my requirements.  It now appears that extlinux may also
work.  I'll soon know.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/351821928.39974.1274802154546.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Mark]

On Tue, May 25, 2010 at 8:42 AM, Stephen Powell wrote:

> On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
> > Stephen Powell wrote:
> >> (3) The need for special backup requirements will be
> >> used by the opponents of Linux at my place of employment
> >> to oppose further deployments of Linux, ...
> >
> > What about the carrot approach?  Find an even better
> > backup method, compatible with Grub 2 and appealing
> > to your management for its efficiency.
>
> You're missing the point.  The main selling point to management
> is that Linux is free.  If they have to buy new backup software
> in order to accommodate Linux' backup requirements, that will
> kill it on the spot.  Whatever boot loader I use must not
> require new backup software or impose special backup requirements.
> And its not just money.  As a rule, people like what they know.
> The backup people are Windows people, and they'd love an
> excuse to complain to management about the backup requirements
> of my Linux servers.  grub-legacy and grub-pc are non-starters
> for me for that reason.  Until now, only lilo, as far as I knew,
> met all my requirements.  It now appears that extlinux may also
> work.  I'll soon know.
>

Clonezilla is free, and when using the "saveparts" option to save an image
of one partition and not the full hard drive, it includes the MBR and
associated data.  You can then drop that partition image onto a new/blank
disk, that does not have anything in the MBR, and once Clonezilla restores
the image to the new partition, will put the MBR in place and the machine
boots on its own the next time, with no extra work (I just did this last
week with a new hard drive).  This has been my experience with using
Clonezilla and Lenny, at least.  So it may help in your case.

Mark

Re: Translations copyrights/licences

[Julien Valroff]

Le dimanche 23 mai 2010 à 09:01 +0100, Neil Williams a écrit :
> On Sun, 23 May 2010 07:53:14 +0200
> Julien Valroff  wrote:
> 
> > The sources contain gettext translations, the copyrights and licences
> > of which are sometimes unclearly stated, eg:
> 
> Nearly all packages with translations have "problems" like this. It
> isn't actually a problem, there's nothing realistic that can be done
> about it and nearly all packages with translations would have the same
> "problem". If we accept that this is an issue, we'll have 14,000 RC
> bugs overnight and we'll never release again.
[...]
> 
> I see no reason to specify these in debian/copyright.
[...]
> > How to deal with such unclear/incomplete headers?
> 
> As Debian Maintainer, you don't. Simple.

Thanks a lot to you and to Helge for your clear answers.
I will then follow your advise and not consider information for po
files ;)

Cheers,
Julien


-- 
Julien Valroff 
http://www.kirya.net
GPG key: 4096R/290D20C5 
092F 4CB5 5F19 E006 1CFD  B489 D32B 8D66 290D 20C5


-- 
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/1274805771.2652.19.ca...@gaia.kirya.net

Bug#583133: ITP: haskell-glib -- Binding to the GLIB library for Gtk2Hs

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: haskell-glib
  Version : 0.11.0
  Upstream Author : Axel Simon, Duncan Coutts
* URL : http://www.haskell.org/gtk2hs/
* License : LGPL-2.1
  Programming Lang: Haskell
  Description : Binding to the GLIB library for Gtk2Hs

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 The GNU Library is a collection of C data structures and utility function for
 dealing with Unicode. This package only binds as much functionality as
 required to support the packages that wrap libraries that are themselves based
 on GLib.



--
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/20100525164121.2702.80988.report...@zezinho

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark 
> On Tue, May 25, 2010 at 8:42 AM, Stephen Powell wrote:
>> On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
>>> Stephen Powell wrote:
 (3) The need for special backup requirements will be
 used by the opponents of Linux at my place of employment
 to oppose further deployments of Linux, ...
>>>
>>> What about the carrot approach?  Find an even better
>>> backup method, compatible with Grub 2 and appealing
>>> to your management for its efficiency.
>>
>> You're missing the point.  The main selling point to management
>> is that Linux is free.  ...
>
> Clonezilla is free, and when using the "saveparts" option to save an image
> of one partition and not the full hard drive, it includes the MBR and
> associated data.  You can then drop that partition image onto a new/blank
> disk, that does not have anything in the MBR, and once Clonezilla restores
> the image to the new partition, will put the MBR in place and the machine
> boots on its own the next time, with no extra work (I just did this last
> week with a new hard drive).  This has been my experience with using
> Clonezilla and Lenny, at least.  So it may help in your case.

Perhaps so.  But it's not what the backup people know.  They're very
comfortable with the backup software that they know and love for
backing up their Windows servers, which was purchased with Windows servers
in mind.  Do you think they're going to redo their whole backup architecture
just for a few Linux servers?  If I want to play in their sandbox, I have
to play by their rules.  That's the political reality.  At our shop, Linux
has a small beachhead on a vast continent controlled by Windows.  Over time,
the role of Linux may expand to the point where Linux is actually thought
about and planned for when decisions are made.  But that day is not today.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/479605722.42620.1274806845480.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Tue, 25 May 2010 12:03:17 -0400 (EDT), Boyd Stephen Smith Jr. wrote:
> Stephen Powell wrote:
>> 
>> You're missing the point.  The main selling point to management
>> is that Linux is free.
> 
> No software is entirely without cost.  Free Software is no exception.  There 
> are usually no up-front licening fees, sure.  However, volunteers work on 
> whatever they like, and if no one volunteers to maintain and support your 
> software you may have to pay for that.
> 
> Even with volunteers providing maintenance and support, your specific 
> requirements may differ from their goals and that will require effort to 
> resolve.
> ...
> Also, volunteers are rarely concerned with "market share", losing your 
> management as users is not necessarily a concern to them.  If it is a concern 
> for you, you may have to put forward some additional effort to address your 
> management's issues.

All excellent points, Boyd.  Fortunately in this case, extlinux appears
to be a viable solution.  I'll soon know.  The guy I need to see about
setting a test server to test the backup and restore scenario
has been off work with a sick child for the past couple of days, but when
he gets back I'll try to prove that it is 100% compatible with our
backup software.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/1557806589.43087.1274807547943.javamail.r...@md01.wow.synacor.com

Re: Translations copyrights/licences

[Darren Salt]

I demand that Helge Kreutzmann may or may not have written...

> Speaking both with my translator and my Debian Maintainer hat on, I can
> state the following:

> a) There are lots of "drive by" translators. Systems like launchpad or
>DDTP even *encourage* this. In this case, it is most likely not
>possible at all to contact individual translators.

> b) In structured projects (Debian, Fedora, OOo, KDE, GNOME) there are
>often language teams. In this case, translations are often
>"channeled" via the team. So if you want, you can try to collect
>the names in the copyright, but a team adress is more valuable.

To me, this all doesn't matter so long as who changed what is recorded and I
can get (or generate) a series of diffs which I can then commit where
appropriate. If I can't, then I'm not really interested.

[snip]
-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Travel less. Share transport more.   PRODUCE LESS CARBON DIOXIDE.

Without fools there would be no wisdom.


-- 
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/51227c3724%li...@youmustbejoking.demon.co.uk

Browser's and Distro's (was: SWR Iron: Chromium without the data-mining)

[C. Gatzemeier]

Am Tue, 18 May 2010 22:36:56 +0200
schrieb Christoph Anton Mitterer :

> Hi.
> 
> AFAIK, even Chrome has disabled most tracking stuff per default
> (except those things which FF/etc. do too).

You may be raising a good point.

As it is now: the first thing firefox seems to do when it's run, is to
connect to search engines and have them set cookies, then, there are
"intelligent Bookmarks" that connect to aggregators, while no "cookie
safe" (or "cs lite"), "noscript" and "better privacy" are installed and
set up properly by default. And the website blocking feature even seems
to send URL hashes somewhere by default. The receiver might even not
need to compute that hash himself anymore to join that info into
their database.

I don't know, would that make users look as if they were sold to some
company? They certainly seem exposed to any kind of tracking by
default. 

Would it be a responsible and sane decision for any
distribution to turn that off, while providing simple buttons to allow
things selectively? (i.e. noscript option to enable scripts for
particular sites one want's to use, but not for any goo-analytics
goo-mail, goo-login, goo-website or flashy goo-toolkit someone was
lured to inject into your browser.)

I mean what do you think of a distro when you notice it
started pushing all interactions with its websites to some goo-analytics
tracking?

With "so easy to use" social network clients ( i.e. with maybe only
freebee fishnet like servers put up centrally, that track any business
and social interactions) installed in a distro, at least you can choose
not to use them.
And you can work on implementing/improving alternative, easy to use
free software tools that function in a distributed, peer based manner to
help people connect in their real social network in more direct ways.

But with browsers and websites set to injecting scripts, you actively
need to turn things off.

I'm really wondering about what you guys think of this.

Kind regards,
Christian


-- 
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/20100525204443.14237bcdc.gatzeme...@tu-bs.de@tu-bs.de

Bug#583151: ITP: geronimo-jpa-2.0-spec -- Geronimo JSR-317 Java Persistence (JPA) 2.0 Spec API

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: geronimo-jpa-2.0-spec
  Version : 1.1
  Upstream Author : Apache Software Foundation (ASF)
* URL : 
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.1/
* License : Apache-2.0
  Programming Lang: Java
  Description : Geronimo JSR-317 Java Persistence (JPA) 2.0 Spec API

  The Java Persistence API is the Java API for the management of persistence and
  object/relational mapping for Java EE and Java SE environments. 
  .
  The goal of this specification is to provide an object/relational mapping
  facility for the Java application developer using a Java domain model
  to manage a relational database.
  .
  Persistence in this context covers three areas:
   - The API itself, defined in the javax.persistence package.
   - The Java Persistence Query Language (JPQL).
   - Object/relational metadata.
  .
  The Java Persistence 2.0 specification addresses improvements in the areas of
  domain modeling, object/relational mapping, EntityManager and Query
  interfaces, and the Java Persistence query language. It adds an API for
  criteria queries, a metamodel API, and support for validation.
  .
  This package contains only API of JSR-317 spec. Apache OpenJPA and Eclipselink
  are implementations of this spec.

This library is needed to package OpenJPA and EclipseLink, which in turn,
they are needed to package Spring Framework 3.0.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche



-- 
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/20100525192104.ga27...@miguel.cc

Re (3): lilo removal in squeeze (or, "please test grub2")

[peasthope]

From:   Stephen Powell 
Date:   Tue, 25 May 2010 11:42:34 -0400 (EDT)
> The backup people are Windows people, and they'd love an
> excuse to complain to management about the backup requirements
> of my Linux servers.

Implies that you don't have responsibility for 
backing the Linux systems.  Too bad; or maybe 
you'd rather not have the extra chore.

Regards,... Peter E.

-- 
Carnot is waiting for a disk replacement; Web pages may not work.
Google "pathology workshop".
In ETHNO click here -> Desktops.OpenDoc http://carnot.pathology.ubc.ca/.


-- 
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/171056505.51375.497...@cantor.invalid

The story behind UPG and umask.

[C. Gatzemeier]

Hi,
am glad UPGs and the default umask finally got some momentum.

Technical issues below.


For anybody who has any doubt about UPGs or thinks it's insecure, here
is a explanation snippet from [0]:

~
(This should be true, but still needs the fixes from below.)

It is easy for multiple users to collaborate on debian systems.

Just keep in mind that access permission to a file always depends on
the permissions of the file itself AND the permissions of the directory
path to it. By default files are readable for whoever has access to
them, just as paper files are, but not writeable. If you don't want
others to read your files, keep them in a private/ subdirectory. The
path into your home directory is not restricted, just as the path
others can take to ring your bell at home is not restricted. As a
matter of fact you may post some files on your door, for others or to
read. For example many programs read config files that you deposit in
your home path. Besides, other users can drop files (for you
personally) in your ~/incomming/ directory.

All this can work because the primary group of each user is set to a
private user group (UPG) by default. (A group without any mentioned
members in /etc/group, named equal to the user.) This allows to grant
write permissions to created files for the group by default. No one
exept the owning user will be able to write to the file. Exept that is,
if it has been created in a group directory...

Group directories (directories with the set-group-id flag set) are
special places (that again all users are able to visit) where the
members of the group that owns the directory can write files in it.
According to the set-group-id flag files created in the group directory
will belong to the creating user who wrote the file and to the group
*the directory belongs to*. The result is that all members of the group
can work on the files in a groupdir of theirs. Other than that, group
directories work just like home directories. So if a file for example
should be readable only by group members, again put it into a private
subdirectory.

Group directories may be set up by regular users in their home
directories, or by the system administrator or (automatically) by
the addgroup command under /home/group. 
~~



It seems things quite used to work before PAM was introduced while it
didn't support any UPG detection at that time, but now pam_umask is
here to help us out and we get the chance to fix it better then before.


Some additions I'd like to make:


* Things like ssh can and should keep requiring private permissions!
  Instead tools/scripts should be patched to adequately write these
  files with the umask set accordingly. (If they are not already,
  simply by having them manually override the default umask.)


According to [1,2] a UPG is identifiable by

1) A group of the same name as the username

2) A special case is true: The group is set as the main group of the
   user (in /etc/passwd) while the user is NOT added to his group
   in /etc/groups.

3) UID==GID was questioned to be a requrement, probably because it was
   seen that it isn't be enforced, but it can be of great help if you
   are looking at a filesystem (removable drive) without knowing the
   corresponding passwd/groups file.

   So maybe it is sane that UID==GID is a requirement, and its only an
   adduser bug when it does not skip IDs that have been taken by non
   UPG groups when creating users, and thus does not deliver that
   requirement.


With 2) you can still see that the group has been set up as a UPG even
if additional users are added to the group.

Explicitly it allows to detect that:

 A) Those users were added intentionally to the UPG and the umask 
should still be set to 002. (In general you create separate groups
to enable user collaboration on UPG systems, so tools may
very well give a warning/hint about it if you try to add a
user to a UPG.)

 B) The group can be deleted if the user is deleted.


Kind regards,
Christian

[0]https://wiki.ubuntu.com/MultiUserManagement
[1]https://bugs.launchpad.net/gst/+bug/488158
[2]http://lists.alioth.debian.org/pipermail/adduser-devel/2008-February/003161.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100525220935.201d11b8c.gatzeme...@tu-bs.de@tu-bs.de

Bug#583157: ITP: haskell-gio -- Binding to the GIO

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: haskell-gio
  Version : 0.11.0
  Upstream Author : Peter Gavin, Andy Stewart
* URL : http://www.haskell.org/gtk2hs/
* License : GPL
  Programming Lang: Haskell
  Description : Binding to the GIO

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 GIO is striving to provide a modern, easy-to-use VFS API that sits at the
 right level in the library stack. The goal is to overcome the shortcomings of
 GnomeVFS and provide an API that is so good that developers prefer it over raw
 POSIX calls. Among other things that means using GObject. It also means not
 cloning the POSIX API, but providing higher-level, document-centric
 interfaces.



--
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/20100525201549.10886.93145.report...@zezinho

Re: lilo removal in squeeze (or, "please test grub2")

[Joachim Wiedorn]

Harald Braumann  wrote on Tue, 25 May 2010:
> 
> On simple standard system -- one disk, one kernel in /boot, no fancy
> stuff -- it works quite well.

This is enough to use grub2 for new installing of Debian.

> On other systems it often breaks miserably. Updates leave my system
> unbootable every other time. One major problem are incompatible
> versions of the boot loader installed in the MBR and grub.cfg.
> 
> Currently, automatic installation of grub in the MBR is a no-go for me,
> because of #554790 but I can't prevent grub from automatically
> updating grub.cfg which leads to incompatible versions, hence an
> unbootable system. 

And these problems say, we still need an alternative - I would say: LiLO.

William Pitcock  wrote on Sat, 22 May 2010:
> 
> After some discussion about lilo on #debian-devel in IRC, it has pretty
> much been determined that kernel sizes have crossed the line past where
> lilo can reliably determine the payload size.

But not all kernels are to large - especially the custom kernels - and
LiLO can be used for this special situation. Until which size of kernel 
is LiLO usable?

My suggestion / recommendation is now:

  a) using grub2 as default boot manager for new installations (d-i)
 and for updating grub.

  b) provide LiLO in squeeze as alternative for grub2. The
 limitations must be said while installing the lilo package.
 I think it must not be a proposal in d-i.

Because I still use LiLO for all my systems, I could support the
maintaining of LiLO. Would this a way for you, William?

Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

Re: The story behind UPG and umask.

[Harald Braumann]

On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:

> The
> path into your home directory is not restricted, just as the path
> others can take to ring your bell at home is not restricted. 

Depends on adduser settings. Both, world readable and private home
directories are common.

> All this can work because the primary group of each user is set to a
> private user group (UPG) by default. 

This is a bold assumption. In a system where user management is
external (e.g. LDAP), anything is possible and there are no defaults.

> According to [1,2] a UPG is identifiable by

This is wrong. There is no way to differentiate UPG - non-UPG. But I'm
repeating myself ...

Cheers,
harry


-- 
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/20100525204751.gb30...@sbs288.lan

Re: The story behind UPG and umask.

[Michael Banck]

On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
> 3) UID==GID was questioned to be a requrement, probably because it was
>seen that it isn't be enforced, but it can be of great help if you
>are looking at a filesystem (removable drive) without knowing the
>corresponding passwd/groups file.
> 
>So maybe it is sane that UID==GID is a requirement, and its only an
>adduser bug when it does not skip IDs that have been taken by non
>UPG groups when creating users, and thus does not deliver that
>requirement.

I think it is not sane to make this a requirement for UPG, but it would probably
be sufficient proof of UPG.

Seems worthwhile to change adduser how you suggest to me, is there a bug
filed to this end?


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/20100525205411.gd27...@nighthawk.chemicalconnection.dyndns.org

RFH: bashisms in configure script

[Raphael Geissert]

Hi everyone,

dash recently added support for the magic variable $LINENO, which was the last 
piece to make it POSIX compliant. However, this change made the autoconf-
generated configure scripts use dash to execute the script's code. Without 
support for LINENO, configure scripts exec to bash automatically.

With this behaviour change, bashisms in configure scripts are now making 
packages FTBFS[1]. Due to some bugs in checkbashisms, most of the code in 
configure scripts was skipped, making those bashisms invisible.

An archive-wide check of the source packages gives an estimate of over 3425 
source packages with bashisms in *any file*. This doesn't necessarily mean that 
we are drowned by bashisms, as some of those may already be fixed by Debian-
provided packages or might affect unused code (either at the build process or 
code not included in the final binary package.)

A rough estimate of the number of source packages with bashisms in configure 
scripts (false positives included and not necessarily autoconf's configure 
script) is 1504.

SUMMARY:

1. If your name is on the list at [2] please check at [3] the .dsc file that 
corresponds to the source packages you co-/maintain, review and fix.  The .dsc 
files contain checkbashisms' output.
2. Do the same for other packages in the list: review, file report[4], and try 
to provide a patch/NMU.
3. Do the same for other packages in [3] (which are not necessarily in the 
list below): review, file report[4], try to provide a patch/NMU.


Please encourage others to work on these issues.

Normally I would process the results and file the bug reports myself but I 
don't have and won't have time to do it any time soon. I've already tried to 
find some time yesterday and today to work on checkbashisms to come up with bug 
fixes[4], and am probably  going to find a bit more to only fast-process the 
results of a new run against the binary packages.

Thanks in advance!

(before anybody asks/complains, the list of maintainers is too big to be 
attached to the email, even if compressed.)

[1] http://bugs.debian.org/582952
[2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
[3] http://people.debian.org/~geissert/source-bashisms/
[4] Please set "User: debian-rele...@lists.debian.org" and "Usertags: goal-
dash" when filing the report. Severity should be important (or serious if it 
makes the package FTBFS.)
[5] See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497489#13 and 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497489#40

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


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

Improving in-place upgrades of Ada packages from Lenny to Squeeze

[Ludovic Brenta]

Over the last two weeks I have been testing upgrades of Ada packages
from Lenny to Sid and Squeeze in a chroot.  The picture is not as pretty
as it should be.  In a nutshell, when you change /etc/apt/sources.list
from lenny to squeeze (unstable, actually) and do "aptitude update", you
end up with a lot of broken packages and must intervene manually to
resolve the problem (i.e. remove the broken packages, install new
versions).

The following packages upgrade seamlessly:

* adabrowse
* adacontrol
* asis-programs
* ghdl
* gnat
* gnat-4.3 deleted, replaced with gnat-4.4
* gnat-gps
* libaws-bin
* libaws-doc
* libgnat{vsn,prj}-dev
* libgnat{vsn,prj}4.3-dev deleted, replaced with gnat{vsn,prj}4.4-dev
* libgtkada2-bin
* libgtkada2-doc

In the case of gnat-4.3 and gnat-4.4, this is because of the "gnat"
package that selects and depends on the default version of the compiler.

In the case of libgnat{vsn,prj}4.3-dev, this is only because I recently
added dummy transition packages, libgnat{vsn,prj}-dev in gnat-4.4 (=
4.4.4-4).

The following packages upgrade seamlessly but can silently cause
third-party packages to FTBFS; this is a violation of the Debian Policy
for Ada[1]:

* libadasockets-dev (see #580907)

The following packages are "obsolete or locally created" and marked as
broken by the removal of gnat-4.3:

* libasis-dev  (libasis2008-dev available but not installed)
* libaunit-dev (libaunit1-dev available)
* libaws-dev   (libaws2.7-dev available)
* libflorist-dev   (libflorist2009-dev available)
* libgnademysql-dev(no replacement available)
* libgnadeodbc-dev (libgnadeodbc1-dev available)
* libgnadepostgresql-dev   (no replacement available)
* libgnadesqlite-dev   (libgnadesqlite3-1-dev available)
* libgnomeada2-dev (libgnomeada2.14.2-dev available)
* libtemplates-parser-dev  (libtemplates-parser11.5-dev available)
* libtexttools-dev (libtexttools2-dev available)
* libxmlada-dev(libxmlada3.2-dev available)

The following packages are "obsolete or locally created" but not marked
as broken (even though they are); in Lenny, they lack a dependency on
gnat-4.3:

* libahven-dev (libahven1-dev available)
* libalog-dev  (libalog1-{base|full}-dev available)
* libopentoken-dev (libopentoken2-dev available)

The reason for all this is that when a package libX2-dev Conflicts: with
and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
and install libX2-dev; instead, it marks libX1-dev as broken and leaves
libX2-dev uninstalled.  As a consequence, upgrades from Lenny to Sid
currently require manual intervention; this precludes unattended
upgrades.  The proper resolution of these dependencies is to remove the
broken packages.  The dependency resolver in aptitude never suggests
that; instead all the solutions I've looked at involved holding the
broken packages in their current state, essentially halting the upgrade.

The reason why all packages must change names is to ensure consistency
of programs at the source and binary level; the rules of the Ada
language guarantee that an executable program always consists of object
files that are consistent both with their sources and with one another.
Full details in [1,2].

Given the constraints that:
(a) all -dev packages must change names due to the above;
(b) we would like to make upgrades as seamless as possible, and even
permit unattended upgrades,

can anyone recommend a way to achieve that goal?

[1] http://people.debian.org/~lbrenta/debian-ada-policy.html
[2] http://www.adaic.com/standards/05rm/html/RM-10-1-4.html, clause 5

-- 
Ludovic Brenta.


-- 
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/87ljb78ysx@ludovic-brenta.org

Re: RFH: bashisms in configure script

[Petter Reinholdtsen]

[Raphael Geissert]
> Hi everyone,
>
> dash recently added support for the magic variable $LINENO, which
> was the last piece to make it POSIX compliant. However, this change
> made the autoconf- generated configure scripts use dash to execute
> the script's code. Without support for LINENO, configure scripts
> exec to bash automatically.

What about reverting this change in dash until after Squeeze is
released?  Now seem like a bad time to make thousand of packages in
Debian fail to build from source. :)

Or perhaps can this feature be made to turn on or off using some 'set'
command, configuration file or command line argument to dash, to allow
us to keep the old behaviour for Squeeze while allowing users to
convert dash to be POSIX compliant locally?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flpr0jvenf@login2.uio.no

Re: RFH: bashisms in configure script

[Kurt Roeckx]

On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
> [1] http://bugs.debian.org/582952
> [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt

That is just a list of all packages per person?  It's listing
packages that have no shell script in it at all, and also
don't have a .dsc file.


Kurt


-- 
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/20100525215130.ga19...@roeckx.be

Re: RFH: bashisms in configure script

[Frans Pop]

> dash recently added support for the magic variable $LINENO, which was
> the last piece to make it POSIX compliant. However, this change made the
> autoconf- generated configure scripts use dash to execute the script's
> code. Without support for LINENO, configure scripts exec to bash
> automatically.

Isn't it a bit late in the release cycle for a change with such a major 
impact?

> An archive-wide check of the source packages gives an estimate of over
> 3425 source packages with bashisms in *any file*.

This and the file under [2] must contain a *huge* amount of false 
positives.

For example, almost all udebs are listed. Why? Because udebs execute 
busybox shell as /bin/sh, which happens to be fairly compatible with bash.

I think this needs to be trimmed quite a bit before it's useful.

Cheers,
FJP


-- 
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/201005252356.00453.elen...@planet.nl

Re: RFH: bashisms in configure script

[Julien Cristau]

On Tue, May 25, 2010 at 23:45:56 +0200, Petter Reinholdtsen wrote:

> What about reverting this change in dash until after Squeeze is
> released?  Now seem like a bad time to make thousand of packages in
> Debian fail to build from source. :)
> 
That's the plan, see #582952.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: RFH: bashisms in configure script

[Neil Williams]

On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert  wrote:

> dash recently added support for the magic variable $LINENO, which was the 
> last 
> piece to make it POSIX compliant. However, this change made the autoconf-
> generated configure scripts use dash to execute the script's code. Without 
> support for LINENO, configure scripts exec to bash automatically.

Can't we just patch this OUT of dash until after the release??? (or
forever? or just on buildd's?)

All this work for ONE VARIABLE???!?!?!

> An archive-wide check of the source packages gives an estimate of over 3425 
> source packages with bashisms in *any file*. This doesn't necessarily mean 
> that 
> we are drowned by bashisms, as some of those may already be fixed by Debian-
> provided packages or might affect unused code (either at the build process or 
> code not included in the final binary package.)

This is just scare mongering - there are packages there which have
nothing to do with autoconf or have any configure script of any kind,
even the simplest perl script packages!

> A rough estimate of the number of source packages with bashisms in configure 
> scripts (false positives included and not necessarily autoconf's configure 
> script) is 1504.

Which, at a rough estimate, would take at least a year to fix, not
including all the transitions that would result.

./configure is a *generated* script too, if dash cannot handle it, dash
has to be crippled to let the other packages continue working. Unless
autoconf itself has already been patched to fix all of these issues when
regenerating ./configure from configure.ac, all this would be a waste
of effort anyway.

This sounds more like a grave bug in dash by breaking everything else.
I can't believe this can happen. It's plain crazy.

> Please encourage others to work on these issues.

Please fix dash instead.
 
> Normally I would process the results and file the bug reports myself but I 
> don't have and won't have time to do it any time soon. I've already tried to 
> find some time yesterday and today to work on checkbashisms to come up with 
> bug 
> fixes[4], and am probably  going to find a bit more to only fast-process the 
> results of a new run against the binary packages.
> 
> Thanks in advance!

... for nothing. I'm in no mood to thank anyone for this one.
 
> (before anybody asks/complains, the list of maintainers is too big to be 
> attached to the email, even if compressed.)

Which is reason enough to fix dash, not thousands of other packages
which were fine until this change.

One package (one variable) cannot be allowed to break over a THOUSAND
source packages. 

Has someone put the clock back to 1st April? This just has to be a sick
joke.

Someone please tell me this broken version of dash hasn't been uploaded
yet.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpZG2uezv6dR.pgp
Description: PGP signature

Re: RFH: bashisms in configure script

[Kurt Roeckx]

On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote:
> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
> > [1] http://bugs.debian.org/582952
> > [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
> 
> That is just a list of all packages per person?  It's listing
> packages that have no shell script in it at all, and also
> don't have a .dsc file.

They do contain shell scripts, the maintainer script.  But they
clearly don't generate a warning.


Kurt


-- 
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/20100525220435.ga19...@roeckx.be

Re: RFH: bashisms in configure script

[Kurt Roeckx]

On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
> 1. If your name is on the list at [2] please check at [3] the .dsc file that 
> corresponds to the source packages you co-/maintain, review and fix.  The 
> .dsc 
> files contain checkbashisms' output.

I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
possible bashism in ./configure line 147 ($BASH_SOMETHING):
 $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || { 
BASH_ENV=; export BASH_ENV; }

This is autogenerated code by autoconf (2.59).  I think that code
that makes sure it behaves the way you want under bash isn't
really going to be a problem if you run it with something else.


Kurt


-- 
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/20100525220732.ga19...@roeckx.be

Re: RFH: bashisms in configure script

[Emilio Pozuelo Monfort]

On 25/05/10 23:45, Petter Reinholdtsen wrote:
> What about reverting this change in dash until after Squeeze is
> released?  Now seem like a bad time to make thousand of packages in
> Debian fail to build from source. :)

See bug #582952.

Emilio


-- 
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/4bfc465d.1080...@debian.org

Re: RFH: bashisms in configure script

[Neil Williams]

On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert  wrote:

A much more sane list is in the bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952

124 source packages. Bad, but not as crazy as 1,540.

(I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
stretch.)

Please, let's get some accurate figures before raising things like
this. (Oh, and yes, putting a patched dash into unstable and putting
this broken one into experimental is a VERY good idea IMHO. It's kinda
why we have experimental in the first place. Sheesh! This thing
gonna give me nightmares.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpexJad0mjTS.pgp
Description: PGP signature

Re: RFH: bashisms in configure script

[David Weinehall]

On Tue, May 25, 2010 at 11:10:10PM +0100, Neil Williams wrote:
> On Tue, 25 May 2010 16:13:36 -0500
> Raphael Geissert  wrote:
> 
> A much more sane list is in the bug report:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952
> 
> 124 source packages. Bad, but not as crazy as 1,540.
> 
> (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
> stretch.)
> 
> Please, let's get some accurate figures before raising things like
> this. (Oh, and yes, putting a patched dash into unstable and putting
> this broken one into experimental is a VERY good idea IMHO. It's kinda
> why we have experimental in the first place. Sheesh! This thing
> gonna give me nightmares.)

You're getting things the wrong way around.  The version of dash that
will be put in experimental will be the correct one, the one in unstable
will be the crippled one.  The reason things fails isn't because of
dash, but because of sloppy programming on behalf of people that still
believe that bash is the say all and end all when it comes to shell
scripts.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20100525221823.gk24...@test5.acc.umu.se

Re: RFH: bashisms in configure script

[Kurt Roeckx]

On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
> 
> 1. If your name is on the list at [2] please check at [3] the .dsc file that 
> corresponds to the source packages you co-/maintain, review and fix.  The 
> .dsc 
> files contain checkbashisms' output.

Is there some kind of documentation on what those errors really
mean?


Kurt


-- 
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/20100525222056.ga20...@roeckx.be

Bug#583168: ITP: haskell-hsp -- Haskell library for writing dynamic server-side web pages

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: mascell...@poisson.phc.unipi.it

   Package name: haskell-hsp
Version: 0.5.2
Upstream Author: Joel Bjornson, Niklas Broberg
URL: http://hackage.haskell.org/package/hsp
License: BSD
Description: Haskell library for writing dynamic server-side web pages

Haskell Server Pages (HSP) is an extension of vanilla Haskell, targetted
at the task of writing dynamic server-side web pages. Features include
an embedded XML syntax and a (low-to-mid-level) programming model for
writing dynamic web pages.

Rationale: it is a dependency of happstack (bug #569501).

Regards, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org











signature.asc
Description: OpenPGP digital signature

Re: Bug#581488: general: lower vm.swappiness by default for desktop installations

[Philipp Kern]

On 2010-05-25, Aaron Toponce  wrote:
> On 5/12/2010 1:22 PM, Marcus Better wrote:
>> Recently I got the advice [1] to set vm.swappiness to 0, rather than
>> the default 60. This improved things dramatically. Apparently Eclipse
>> is no longer being swapped out preemptively all the time. The
>> difference in perceived responsiveness is spectacular.
> You might also be interested in:
>
> # sync; cat 3 > /proc/sys/vm/drop_caches
>
> This is a nondestructive operation that will drop your clean caches,
> clear up unused inodes, and free up available RAM. Usually, after
> running my desktop for a few hours, depending on the applications I'm
> running as well, this will free up about 1/2 of my installed RAM.

Why would I want to drop my caches?  In fact I even use Tux on Ice for
hibernation so that I can keep my buffer cache, otherwise it takes ages
for the buffer cache to be loaded in after restore...

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhvojpr.8ec.tr...@kelgar.0x539.de

Bug#583169: ITP: haskell-sendfile -- Haskell portable sendfile library

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: mascell...@poisson.phc.unipi.it

   Package name: haskell-sendfile
Version: 0.6.1
Upstream Author: Matthew Elder 
URL: http://hackage.haskell.org/package/sendfile
License: BSD
Description: Haskell portable sendfile library

This Haskell library exposes zero-copy sendfile functionality in a
portable way. sendfile is a non standard system call that copies data
between one file descriptor and another. This library uses the native
implementations where possible (for example, under Linux or FreeBSD) and
provides an Haskell replacement in other cases, thus providing a
portable interface.

Rationale: it is a dependency of happstack (bug #569501).

Regards, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org













signature.asc
Description: OpenPGP digital signature

Re: The story behind UPG and umask.

[Stephen Gran]

This one time, at band camp, Michael Banck said:
> On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
> > 3) UID==GID was questioned to be a requrement, probably because it was
> >seen that it isn't be enforced, but it can be of great help if you
> >are looking at a filesystem (removable drive) without knowing the
> >corresponding passwd/groups file.
> > 
> >So maybe it is sane that UID==GID is a requirement, and its only an
> >adduser bug when it does not skip IDs that have been taken by non
> >UPG groups when creating users, and thus does not deliver that
> >requirement.
> 
> I think it is not sane to make this a requirement for UPG, but it would 
> probably
> be sufficient proof of UPG.
> 
> Seems worthwhile to change adduser how you suggest to me, is there a bug
> filed to this end?

adduser has had bugs filed in the past asking for uid to be equal to gid
by default, and I have so far rejected them as not worth the complexity
for the aesthetic pleasure of having numbers match.  Is there some
problem with username == primary group name?

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: RFH: bashisms in configure script

[Darren Salt]

I demand that Kurt Roeckx may or may not have written...

> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
>> 1. If your name is on the list at [2] please check at [3] the .dsc file
>> that corresponds to the source packages you co-/maintain, review and fix.
>> The .dsc files contain checkbashisms' output.

> I get alot of them that have:
> possible bashism in ./configure line 22 ($BASH_SOMETHING):
> elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
> possible bashism in ./configure line 147 ($BASH_SOMETHING):
>  $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || {
BASH_ENV=; export BASH_ENV; }

> This is autogenerated code by autoconf (2.59).  I think that code that
> makes sure it behaves the way you want under bash isn't really going to be
> a problem if you run it with something else.

I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly odd
because testing with dash has shown up an actual bashism in xine-lib's
configure.ac (which I've just fixed upstream): use of "test x == y".

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.

This tagline was stolen by the International Brotherhood of Tagline Thieves.


-- 
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/512296bb08%li...@youmustbejoking.demon.co.uk

Bug#583170: ITP: haskell-hsemail -- Haskell parser for email messages and SMTP conversations

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: mascell...@poisson.phc.unipi.it

   Package name: haskell-hsemail
Version: 1.6
Upstream Author: Peter Simons  and others
URL: http://hackage.haskell.org/package/hsemail
License: BSD
Description: Haskell parser for email messages and SMTP conversations

This Haskell library is parser for email messages (as described in RFC
2822) and SMTP conversation (as described in RFC 2821).

Rationale: it is a dependency of happstack (bug #569501).

Regards, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org















signature.asc
Description: OpenPGP digital signature

Re: RFH: bashisms in configure script

[Stephen Gran]

This one time, at band camp, Kurt Roeckx said:
> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
> > 
> > 1. If your name is on the list at [2] please check at [3] the .dsc file 
> > that 
> > corresponds to the source packages you co-/maintain, review and fix.  The 
> > .dsc 
> > files contain checkbashisms' output.
> 
> Is there some kind of documentation on what those errors really
> mean?

They largely mean that checkbashisms is an overly blunt tool for the job
at hand.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: RFH: bashisms in configure script

[Emilio Pozuelo Monfort]

On 25/05/10 23:13, Raphael Geissert wrote:
> Normally I would process the results and file the bug reports myself but I 
> don't have and won't have time to do it any time soon. I've already tried to 
> find some time yesterday and today to work on checkbashisms to come up with 
> bug 
> fixes[4], and am probably  going to find a bit more to only fast-process the 
> results of a new run against the binary packages.

It would also be good to build all the archive (or all the affected packages)
with and without LINENO support in dash, and then debdiff'ing them and check if
they are equal or not.

And I've seen configure scripts with the following bashism that checkbashisms
didn't find:

if test "x$foo" == "xyes"; then

("==" is a bashism, should be "=").

Emilio


-- 
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/4bfc50b3.40...@debian.org

Software untuk Toko/Swalayan/Restoran/dll -- Gratis -- Terbatas -- Ayo Cepat Download !!

[PT Asli Indonesia 2]

Software AlfaPOS (Point of Sales)

Software AlfaPOS sudah terbukti sukses diimplementasikan diberbagai jenis 
bisnis retail sejak tahun 2006.

Bidang usaha yang wajib menggunakan AlfaPOS :
- Swalayan/Minimarket/Supermarket
- Toko Komputer/HP/Elektronik/Kelontong/ATK/Buku/Fotokopi
- Toko Bangunan/Keramik/Alat Rumah Tangga
- Toko Pakaian/Butik/Distro/Tas/Sepatu/Sandal/Perhiasan/Aksesoris Pria Wanita
- Toko Furniture/Oleh-Oleh/Kue/Merchandise
- Apotek/Bengkel/Dealer Motor/Showroom/Koperasi Karyawan/Cafe/Restoran

Fasilitas dan Keunggulan :
- Front Office : Penjualan Tunai/Kredit, Pembayaran Cicilan Pelanggan, Retur 
Penjualan, Service, dll
- Back Office : Master Data, Pembelian, Inventory, Reporting, Utility Manager, 
dll
- Sistem promosi : 8 macam diskon, voucher belanja, point reward, komisi sales, 
penjadwalan harga jual, dll
- Fasilitas plus : Membership management, multi user, multi cara bayar, AR/AP, 
petty cash
- Sudah teruji sejak tahun 2006 sukses menangani berbagai jenis bisnis
- Layanan support yang baik dari tim yang professional

Alamat Download :
http://alfapos4.ifastnet.com
http://alfapos4.phpnet.us

Bagi yang internetnya agak lambat, kami menyediakan paket CD berisi semua 
installer, ebook manual, video panduan, dll.
Untuk order CD via Pos, silahkan transfer ke BCA, atas nama Fatkul Amri, nomor 
rekening 629-014-6303,
sebesar Rp 50 rb (sdh termasuk paket CD + ongkos kirim). File2 dalam CD kurang 
lebih 500MB.
Setelah transfer, kirim SMS ke 0817-9151-359 dengan menyebutkan nama dan alamat 
lengkap.

Jika perlu informasi dan support, silahkan menghubungi :
- Jakarta, Bpk Toni, (021) 30075400, 0856-4855-3477
- Jakarta, Bpk Toha, (021) 30123430, 8297832, 0817-127-823
- Surabaya, Bpk Zubin, (031) 72794177, 83386707, 0857-3110-8601
- Malang, Bpk Wawan, (0341) 402160, 402168, 0856-4641-4385
- Bali, Bpk Doni, (0361) 7875755
- Balikpapan, Bpk Ghimoyo, (0542) 7000100, 8879990, 0811-598-998


Jika ingin jadi distributor/agen, silahkan hubungi 0817-9155-632.


--
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/alfadev1a79b49cba7bb468083030d58f24de...@alfadev1

Re: RFH: bashisms in configure script

[Peter Samuelson]

[Kurt Roeckx]
> I get alot of them that have:
> possible bashism in ./configure line 22 ($BASH_SOMETHING):
> elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
> possible bashism in ./configure line 147 ($BASH_SOMETHING):
>  $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || { 
> BASH_ENV=; export BASH_ENV; }

And more false positives:

possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z "$BASH_VERSION$ZSH_VERSION" \
&& (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
possible bashism in ./configure line 367 (should be >word 2>&1):
$as_echo "$as_me:${as_lineno-$LINENO}: error: $1" >&$3

Both were produced by autoconf 2.65.

First is a false positive for the same reason Kurt's example is.
Second is a false positive because $3 in this instance is a numbered
file descriptor.

Peter


-- 
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/20100525230926.gc18...@p12n.org

proper umask default setting / disabling UPGs / release notes / steps to take

[C. Gatzemeier]

The umask used to be (and should be again now) settable
centrally. (/etc/login.defs or /etc/default/login LSB?)

Setting the umask in /etc/profile and multiple other rc
files (instead centrally in login.defs) was only necessary while
pam_umask was not available, and to be depreciated.

All the times since 94'
http://lists.debian.org/msgid-search/m0piquw-0002dgc.ijack...@nyx.cs.du.edu
until PAM was included without support for it, the login package seems
to have done the umask adjustment for UPG users, that pam_umask is
requested to do again, now that it is available.

To disable UPGs you currently need to change two settings, one in
in /etc/login.defs and one in /etc/adduser.conf.


So for a release note draft we can note:

* A link to a (maybe improved version) of the users perspective on
  UPGs. https://wiki.ubuntu.com/MultiUserManagement

* That existing users with UPG will now again get a correct
  UPG-default-umask.

* That since existing users should have been set up with UPGs by the
  debian defaults all the time, this should be no security compromise.

* That a central UMASK setting is now again possible in login.defs that
  can do a much better job than the umask lines in
  existing /etc/profile files etc.

* That all umask settings have to be removed from
  preexisting /etc/profile ~/.bashrc and other shell rc files to take
  advantage from the improvements.

* The option to disabling UPGs alltogether in adduser.conf and
  login.defs.


As for a list of steps to do:

1) remove/comment out any umask settings in all shell configuration
   files shiped in debian (i.e. /etc/profile) and add a comment
   pointing to the right place for the global default umask setting.

   It might be /etc/default/login (LSB?), pam_umask looks at both.

2) Adjust /etc/login.defs:
   Refer to the text from:
   https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/487729)
   
   Correct the comment about USERGROUPS_ENAB (now used by pam_umask).
   
   Or point to /etc/default/login (LSB?), pam_umask looks
   at both.

   UMASK 022 should be set in login.defs or /etc/default/login,
   and pam_umask's usergroups feature should be mentioned in the
   comment.


3) Enable pam_umask by fixing the issues related to the first couple
   of points of the howto at https://wiki.ubuntu.com/MultiUserManagement



If anyone knows where this umask/UPG/multi-user issue is tracked, could
you please add this accordingly?

Kind regards,
Christian


-- 
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/20100526012624.3b063ed1c.gatzeme...@tu-bs.de@tu-bs.de

Re: The story behind UPG and umask.

[Steve Langasek]

On Tue, May 25, 2010 at 11:30:49PM +0100, Stephen Gran wrote:
> This one time, at band camp, Michael Banck said:
> > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
> > > 3) UID==GID was questioned to be a requrement, probably because it was
> > >seen that it isn't be enforced, but it can be of great help if you
> > >are looking at a filesystem (removable drive) without knowing the
> > >corresponding passwd/groups file.

> > >So maybe it is sane that UID==GID is a requirement, and its only an
> > >adduser bug when it does not skip IDs that have been taken by non
> > >UPG groups when creating users, and thus does not deliver that
> > >requirement.

> > I think it is not sane to make this a requirement for UPG, but it would 
> > probably
> > be sufficient proof of UPG.

> > Seems worthwhile to change adduser how you suggest to me, is there a bug
> > filed to this end?

> adduser has had bugs filed in the past asking for uid to be equal to gid
> by default, and I have so far rejected them as not worth the complexity
> for the aesthetic pleasure of having numbers match.  Is there some
> problem with username == primary group name?

pam_umask requires both username == primary group name and uid == gid before
it will assume UPG are in place when using its 'usergroups' option, and I am
not willing to diverge from upstream on this as this would mean admins
coming from other systems may get an unpleasant surprise when they find that
Debian gives a more relaxed umask than they were expecting in some corner
cases.

So either someone should convince Linux-PAM upstream to change the behavior
of pam_umask, or adduser should enforce the same rules as other
implementations, if pam_umask is to be involved here.  Beyond that, I have
no particular opinion on this question.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[owens]

>
>
>
> Original Message 
>From: zlinux...@wowway.com
>To: debian-devel@lists.debian.org, debian-u...@lists.debian.org,
>debian-b...@lists.debian.org
>Subject: Re: Re (2): lilo removal in squeeze (or, "please test
>grub2")
>Date: Tue, 25 May 2010 13:00:45 -0400 (EDT)
>
>>On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark 
>>> On Tue, May 25, 2010 at 8:42 AM, Stephen Powell
>wrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
> Stephen Powell wrote:
>> (3) The need for special backup requirements will be
>> used by the opponents of Linux at my place of employment
>> to oppose further deployments of Linux, ...
>
> What about the carrot approach?  Find an even better
> backup method, compatible with Grub 2 and appealing
> to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  ...
>>>
>>> Clonezilla is free, and when using the "saveparts" option to save
>an image
>>> of one partition and not the full hard drive, it includes the MBR
>and
>>> associated data.  You can then drop that partition image onto a
>new/blank
>>> disk, that does not have anything in the MBR, and once Clonezilla
>restores
>>> the image to the new partition, will put the MBR in place and the
>machine
>>> boots on its own the next time, with no extra work (I just did
>this last
>>> week with a new hard drive).  This has been my experience with
>using
>>> Clonezilla and Lenny, at least.  So it may help in your case.
>>
>>Perhaps so.  But it's not what the backup people know.  They're very
>>comfortable with the backup software that they know and love for
>>backing up their Windows servers, which was purchased with Windows
>servers
>>in mind.  Do you think they're going to redo their whole backup
>architecture
>>just for a few Linux servers?  If I want to play in their sandbox, I
>have
>>to play by their rules.  That's the political reality.  At our shop,
>Linux
>>has a small beachhead on a vast continent controlled by Windows. 
>Over time,
>>the role of Linux may expand to the point where Linux is actually
>thought
>>about and planned for when decisions are made.  But that day is not
>today.
>>
>>-- 
>>  .''`. Stephen Powell
>> : :'  :
>> `. `'`
>>   `-
>>
>>
+1
I have been where Steven is and agree with his approach.
Larry
>>-- 
>>To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
>>with a subject of "unsubscribe". Trouble? Contact
>listmas...@lists.debian.org
>>Archive: http://lists.debian.org/479605722.42620.1274806845480.JavaM
>ail.r...@md01.wow.synacor.com
>>
>>



--
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/380-220105225234210...@netptc.net

Re: RFH: bashisms in configure script

[Raphael Geissert]

Kurt Roeckx wrote:

> On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote:
>> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
>> > [1] http://bugs.debian.org/582952
>> > [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
>> 
>> That is just a list of all packages per person?  It's listing
>> packages that have no shell script in it at all, and also
>> don't have a .dsc file.
> 
> They do contain shell scripts, the maintainer script.  But they
> clearly don't generate a warning.

I accidentally screwed the call to dd-list(1) and I made it list all the 
maintainers of every package in the archive. I've fixed it already some 
hours ago.

The .dsc files are at:
 http://people.debian.org/~geissert/source-bashisms/

(there's a sub-directory called 'empty' that has all the, empty, .dsc 
files.)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthpu6$vt...@dough.gmane.org

Re: RFH: bashisms in configure script

[Raphael Geissert]

Neil Williams wrote:

> On Tue, 25 May 2010 16:13:36 -0500
> Raphael Geissert  wrote:
> 
>> dash recently added support for the magic variable $LINENO, which was the
>> last piece to make it POSIX compliant. However, this change made the
>> autoconf- generated configure scripts use dash to execute the script's
>> code. Without support for LINENO, configure scripts exec to bash
>> automatically.
> 
> Can't we just patch this OUT of dash until after the release??? (or
> forever? or just on buildd's?)

The plan for now is to disable support for LINENO, as mentioned in the br.

> 
> All this work for ONE VARIABLE???!?!?!

POSIX compliance too.

> 
>> An archive-wide check of the source packages gives an estimate of over
>> 3425 source packages with bashisms in *any file*. This doesn't
>> necessarily mean that we are drowned by bashisms, as some of those may
>> already be fixed by Debian- provided packages or might affect unused code
>> (either at the build process or code not included in the final binary
>> package.)
> 
> This is just scare mongering - there are packages there which have
> nothing to do with autoconf or have any configure script of any kind,
> even the simplest perl script packages!
> 

The dd-list was bogus and I fixed it already. The .dsc files in the 
directory did not change, however.

> ./configure is a *generated* script too, if dash cannot handle it, dash
> has to be crippled to let the other packages continue working. Unless
> autoconf itself has already been patched to fix all of these issues when
> regenerating ./configure from configure.ac, all this would be a waste
> of effort anyway.

It is not about whether dash can handle it or not. The bashisms don't come 
from autoconf, the come from what the author's added to configure.in{,.in}.

> Someone please tell me this broken version of dash hasn't been uploaded
> yet.

dash isn't broken. It is in testing already.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqbf$1n...@dough.gmane.org

Re: The story behind UPG and umask.

[C. Gatzemeier]

Am Tue, 25 May 2010 22:47:51 +0200
schrieb Harald Braumann :

> On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
> 
> > The
> > path into your home directory is not restricted, just as the path
> > others can take to ring your bell at home is not restricted. 
> 
> Depends on adduser settings. Both, world readable and private home
> directories are common.

Thanks! Adding ...the path to your home *is by default* not
restricted,... seems to be more precise.


> 
> > All this can work because the primary group of each user is set to a
> > private user group (UPG) by default. 
> 
> This is a bold assumption. In a system where user management is
> external (e.g. LDAP), anything is possible and there are no defaults.

We were just stating different assumptions, yes. Maybe also
adding ...this can work in a default installation because...?

> 
> > According to [1,2] a UPG is identifiable by
> 
> This is wrong. There is no way to differentiate UPG - non-UPG. But I'm
> repeating myself ...

I've gone though your related posts that I found on the web. (Wasn't
subscribed before, so answering here.)

OK, the definitionn is wrong, or not complete, in the sense that it does
not catch all possible UPGs.

The auto-umask adjusing feature won't work for all possible UPG
implementations, but it should work safely for the default debian
installation, without compromising security in other environments.

So yes, you can setup UPGs with UID!=GID, but then you'll also
have to set the umask manually to make it work (globally or in gecos or
ldap etc.).

The UID==GID and username==groupname restriction of the
pam_umask's "usergroups" option ensures that the umask is only relaxed
automatically in very specific defined cases.

That's why I'am thinking the UID==GID restriction pam_umask makes (and
login made before) can be sane choice. (Others seem to use it also,
and it is upstream.)

The mentioned three points of the current implementation I found on the
web even allow intentional addititions of users to the UPG as a quick
way to set up trusted (sub-)users without requiring extra groups and
groupdirs to work with files in your sub-user's account. And it allows
proper removal of a UPG together with the user, if it is unused.

> Let me quote from the comments in /etc/login.defs:
>
> #UMASK 022 is the "historical" value in Debian for UMASK when it was
> used

Right, that UMASK value was commented out when it needed to be
dispersed into shell rc files, due to PAM not supporting "usergroups"
yet.

And below that comes "USERGROUPS_ENAB yes" which also
"historicaly" did adjust the umask for UPG users. 

Of course we agree that UPGs and all related automatic umask adjustment
should be configurable, i.e. they can be disabled.

Cheers,
Christian


-- 
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/20100526023653.46c6bc5cc.gatzeme...@tu-bs.de@tu-bs.de

Re: RFH: bashisms in configure script

[Raphael Geissert]

Darren Salt wrote:

> I demand that Kurt Roeckx may or may not have written...
> 
>> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
>>> 1. If your name is on the list at [2] please check at [3] the .dsc file
>>> that corresponds to the source packages you co-/maintain, review and
>>> fix. The .dsc files contain checkbashisms' output.
> 
>> I get alot of them that have:
>> possible bashism in ./configure line 22 ($BASH_SOMETHING):
>> elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1;
>> then possible bashism in ./configure line 147 ($BASH_SOMETHING):
>>  $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || {
> BASH_ENV=; export BASH_ENV; }

Yes, $BASH_SOMETHING is just used to make it easier to see that the 
following code (probably a bashism) is only executed after checking the 
shell is actually bash. That and the other FP are the most common ones, yet 
not that easy to fix (the latter, of course, the former is not a FP.)

> I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly
> odd because testing with dash has shown up an actual bashism in xine-lib's
> configure.ac (which I've just fixed upstream): use of "test x == y".

Could you please send me by email the files with false negatives? those are 
very likely bugs in checkbashisms' quotes handling code.

Thanks.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqk6$1n...@dough.gmane.org

Re: RFH: bashisms in configure script

[Raphael Geissert]

Kurt Roeckx wrote:

> On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
>> 
>> 1. If your name is on the list at [2] please check at [3] the .dsc file
>> that
>> corresponds to the source packages you co-/maintain, review and fix.  The
>> .dsc files contain checkbashisms' output.
> 
> Is there some kind of documentation on what those errors really
> mean?
> 

Yes, most are documented at the following page. I'm going to add more info 
about recently-added and some undocumented checks in a moment.

https://wiki.ubuntu.com/DashAsBinSh

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqtn$1n...@dough.gmane.org

Re: The story behind UPG and umask.

[C. Gatzemeier]

Am Tue, 25 May 2010 23:30:49 +0100
schrieb Stephen Gran :

> adduser has had bugs filed in the past asking for uid to be equal to
> gid by default, and I have so far rejected them as not worth the
> complexity for the aesthetic pleasure of having numbers match.  Is
> there some problem with username == primary group name?

I think ensuring UID==GID by default allows having
automatic umask relaxation for UPGs to work and not 
compromising security, even in corner cases when the system is setup in
other environments. Besides making UPGs and permissions more cleanly
visible/detectable/adjustable on removable filesystems or tarballs
(where you can only see numerical IDs).

Cheers,
Christian


-- 
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/20100526024848.3e6888dec.gatzeme...@tu-bs.de@tu-bs.de

Re: RFH: bashisms in configure script

[Raphael Geissert]

Emilio Pozuelo Monfort wrote:
> It would also be good to build all the archive (or all the affected
> packages) with and without LINENO support in dash, and then debdiff'ing
> them and check if they are equal or not.

A full archive rebuild was already done by Lucas (see the br against dash 
for details.)
One with a version of dash without support for LINENO is useless, as that's 
what it used to be.

> And I've seen configure scripts with the following bashism that
> checkbashisms didn't find:
> 
> if test "x$foo" == "xyes"; then
> 
> ("==" is a bashism, should be "=").

Please send me those configure scripts by email (preferably adding a comment 
at the end of the same line that says BASHISM, so that I can just inject it 
into my testsuite.)

Thanks.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqr9$1n...@dough.gmane.org

Re: RFH: bashisms in configure script

[Raphael Geissert]

Hi,

Given the recent responses I'm providing some more info, updates, and hints.

Raphael Geissert wrote:
> This doesn't necessarily mean that we are drowned by bashisms, as some of
> those may already be fixed by Debian- provided packages or might affect
> unused code

s/packages/patches/

> (before anybody asks/complains, the list of maintainers is too big to be
> attached to the email, even if compressed.)

If you were one of those who checked the dd-list.txt file right after I sent 
my original email and up to two hours later, please re-check it. It was 
bogus.

dd-list.txt *only* contains the list of maintainers/packages with bashisms 
in a 'configure' script. A new list for maintainers/packages with any kind 
of bashism (or false positive) in any file can now be found at:

Information about bashisms (how to fix them) and how to understand 
checkbashisms' output can be found at:

https://wiki.ubuntu.com/DashAsBinSh

* Common false positive:

<--->
possible bashism in ./configure line nnn (should be >word 2>&1):
$as_echo "$as_me:${as_lineno-$LINENO}: error: $1" >&$3
<--->

This one is safe. It is generated by autoconf and $3 points to a numeric 
file descriptor.

<--->
some sort of detection in *.diff or *.dpatch files
<--->
In this case those files use a shell wrapper that executes another program 
to process the file. checkbashisms attempts to detect them, but it fails in 
some cases.

<--->
"unsafe echo with backslash:"
<--->
If the output of echo is piped to grep, verified with test/[ or case; in 
most cases it is just some shell code that is used to determine whether the 
"echo" command expands backlashes by default.


* Not false positives, just indicators[1], but common too:
$BASH
RANDOM=
(OS|MACH)TYPE=
HOST(TYPE|NAME)=
BASH(_SOMETHING)=

[1] they help identify shell tests.


Yes, I'm aware of the high number of false positives and indicators noise. 
There are some false negatives too.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthsoh$7u...@dough.gmane.org

Re: Bug#582831: ITP: png2ico -- png2ico converts PNG files to Windows icon resource files.

[Guillem Jover]

Hi!

On Sun, 2010-05-23 at 18:38:26 -0500, Chris Silva wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Chris Silva 
> 
> 
> * Package name: png2ico
>   Version : 12.08.02-1
>   Upstream Author : Matthias S. Benkmann 
> * URL : http://www.winterdrache.de/freeware/png2ico/
> * License : GPL-2
>   Programming Lang: G++
>   Description : png2ico converts PNG files to Windows icon resource files.
> 
> png2ico takes the input files and stores them in the out
> put file as a Windows icon resource. Usually the input
> files would all represent the same image in different
> resolutions (common resolutions are 16x16, 32x32 and 64x64).
> A program reading the icon resource will pick the image
> closest to its desired resolution and will then scale it
> if necessary.

Are you aware of icoutils, which is already in the archive? Is there
anything png2ico can do which icoutils cannot? And in that case
couldn't that be added to icoutils instead, to avoid adding more of
the same to the archive?

regards,
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/20100526014640.gc4...@gaara.hadrons.org

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote:
> Stephen Powell wrote:
>> ... I installed the mbr package ...
> 
> The extlinux package itself also contains an mbr.bin, which you can use
> (it's strong point is probably EBIOS support).

So it does.  Well, I've now installed extlinux' version
of mbr.bin to the master boot record and purged the mbr package.
extlinux' built-in version of a master boot record boot loader works great.
>>
>> Speaking of documentation, that seems to be its main weakness.
>> Documentation is sketchy and spread out over a number of different files.
> 
> /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
> comprehensive according to my standards, at least as far as the core is
> concerned.  What did you miss?  Some modules may be less well documented.

Yes, I found those two files.  Reference documentation for each specific
boot loader option is there, but what is lacking is tutorial-type stuff.
For example, there is a global options section at the beginning that applies
to all bootable images, and there are options which are specific to each
boot image.  I guessed at that mainly based on how /etc/lilo.conf works,
but I'm not sure it was directly stated anywhere.  It may be hinted at
in the description of some individual configuration option but not explained
"up front".  Also, there's no example configuration file.  There are little
pieces of configuration files but no complete typical configuration file.
A "picture" is worth a thousand words.

>> It installs hook scripts that I don't want (and that have bugs).
> 
> I hope we can fix them soon (they are Debian specific additions).

Remember, I'm used to using lilo.  And based on analogies with lilo,
I built a /boot/extlinux/extlinux.conf file that looks like this:

-

DEFAULT Linux
APPEND root=/dev/sda2 ro vga=779
TIMEOUT 50
PROMPT 1
LABEL Linux
KERNEL ../vmlinuz
INITRD ../initrd.img
LABEL LinuxOLD
KERNEL ../vmlinuz.old
INITRD ../initrd.img.old

-

The kernel and initial RAM disk images are specified via the
traditional symlinks.  As long as the symlinks are maintained
properly, my config file never needs updating, just like lilo's.
Consequently, I really don't want the extlinux hook scripts to
execute at all when I install or remove a kernel.  I solved that
temporarily by issuing

   chmod -x /etc/kernel/postinst.d/extlinux
   chmod -x /etc/kernel/postrm.d/extlinux

That works for now; but if a package upgrade for extlinux is ever
downloaded, I'm afraid that new versions of the hook scripts will
be copied into these directories which are marked executable, and
my hand-made configuration file will get wiped out.  I would suggest
testing the existence of some flag file.  If the flag file exists,
then invoking update-extlinux should be bypassed.  Thus, if the user
doesn't want his hand-made /boot/extlinux/extlinux.conf file to be
tampered with, he can create that flag file via "touch" and the hook
script will not run update-extlinux.  Strictly speaking, this is
an enhancement request.

Second, it is important that any script run as a hook script not
produce any output at all to standard output.  I found that out the
hard way when I was writing my own hook scripts for use with lilo.
That's because they run under debconf, which has redirected standard
output for its own purposes.  Thus, anything written to standard
output is (1) never seen by the user and (2) has a good chance of
messing up debconf, which is examining the output.  The invocation
of update-extlinux should have a redirection on it to redirect
output to standard error.  For example,

   update-extlinux >&2

This is a bona-fide bug.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/630546796.56099.1274837814099.javamail.r...@md01.wow.synacor.com

Re: Bug#582831: ITP: png2ico -- png2ico converts PNG files to Windows icon resource files.

[Chris]

On Wed, 26 May 2010 03:46:40 +0200
Guillem Jover  wrote:

> Hi!
> 
> On Sun, 2010-05-23 at 18:38:26 -0500, Chris Silva wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Chris Silva 
> > 
> > 
> > * Package name: png2ico
> >   Version : 12.08.02-1
> >   Upstream Author : Matthias S. Benkmann 
> > * URL : http://www.winterdrache.de/freeware/png2ico/
> > * License : GPL-2
> >   Programming Lang: G++
> >   Description : png2ico converts PNG files to Windows icon
> > resource files.
> > 
> > png2ico takes the input files and stores them in the out
> > put file as a Windows icon resource. Usually the input
> > files would all represent the same image in different
> > resolutions (common resolutions are 16x16, 32x32 and 64x64).
> > A program reading the icon resource will pick the image
> > closest to its desired resolution and will then scale it
> > if necessary.
> 
> Are you aware of icoutils, which is already in the archive? Is there
> anything png2ico can do which icoutils cannot? And in that case
> couldn't that be added to icoutils instead, to avoid adding more of
> the same to the archive?
> 
> regards,
> guillem
> 
> 
> 


Guillem - 

Thanks for the heads-up! I'll take a look over the weekend at it.

-- 
Regards,

Chris


-- 
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/20100525205517.7af44...@makeworld.com

Re: lilo removal in squeeze (or, "please test grub2")

[Daniel Baumann]

On 05/26/2010 03:36 AM, Stephen Powell wrote:
> That works for now; but if a package upgrade for extlinux is ever
> downloaded, I'm afraid that new versions of the hook scripts will
> be copied into these directories which are marked executable, and
> my hand-made configuration file will get wiped out.  I would suggest
> testing the existence of some flag file.  If the flag file exists,
> then invoking update-extlinux should be bypassed.  Thus, if the user
> doesn't want his hand-made /boot/extlinux/extlinux.conf file to be
> tampered with, he can create that flag file via "touch" and the hook
> script will not run update-extlinux.  Strictly speaking, this is
> an enhancement request.

as of current git, you can now use EXTLINUX_UPDATE=false in
/etc/default/extlinux to prevent having update-extlinux do anything.

> Second, it is important that any script run as a hook script not
> produce any output at all to standard output.  I found that out the
> hard way when I was writing my own hook scripts for use with lilo.
> That's because they run under debconf, which has redirected standard
> output for its own purposes.  Thus, anything written to standard
> output is (1) never seen by the user and (2) has a good chance of
> messing up debconf, which is examining the output.  The invocation
> of update-extlinux should have a redirection on it to redirect
> output to standard error.  For example,
> 
>update-extlinux >&2

none of the hooks is doing this (initramfs-tools, grub, etc), might
needs further convincing.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
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/4bfca228.5000...@debian.org

Re: RFH: bashisms in configure script

[Lucas Nussbaum]

Hi,

I'm still feeling uneasy about this whole bash->dash thing. We sacrified
a lot of usability in the name of POSIX compliance (only a minority of
users care) and a few seconds spared during boot (who cares? I only boot
my laptop for kernel upgrades).

Was is really the right path to follow? Wouldn't it have been easier to
work on bash to make sure that it supports everything POSIX requires,
and to improve its performance a bit?

Now we are going to patch configure scripts to make sure that they can
run correctly with dash. What's next? Rewrite C programs that use
GCC-specific extensions?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100526060532.ga9...@xanadu.blop.info

Re: RFH: bashisms in configure script

[Lucas Nussbaum]

On 25/05/10 at 23:10 +0100, Neil Williams wrote:
> On Tue, 25 May 2010 16:13:36 -0500
> Raphael Geissert  wrote:
> 
> A much more sane list is in the bug report:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952
> 
> 124 source packages. Bad, but not as crazy as 1,540.
>
> (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
> stretch.)

No. 124 is the number of packages that failed to build. Not the number
of source packages that silently generated incorrect binary packages.

 - Lucas


-- 
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/20100526060740.gb9...@xanadu.blop.info

Re: RFH: bashisms in configure script

[Raphael Hertzog]

On Tue, 25 May 2010, Peter Samuelson wrote:
> And more false positives:
> 
> possible bashism in ./configure line 44 ($BASH_SOMETHING):
> if test -z "$BASH_VERSION$ZSH_VERSION" \
> && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
> possible bashism in ./configure line 367 (should be >word 2>&1):
> $as_echo "$as_me:${as_lineno-$LINENO}: error: $1" >&$3
> 
> Both were produced by autoconf 2.65.
> 
> First is a false positive for the same reason Kurt's example is.
> Second is a false positive because $3 in this instance is a numbered
> file descriptor.

Same goes for dpkg, it only has those two warnings.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100526062150.ga16...@rivendell

Re: RFH: bashisms in configure script

[Luk Claes]

On 05/26/2010 08:05 AM, Lucas Nussbaum wrote:
> Hi,
> 
> I'm still feeling uneasy about this whole bash->dash thing. We sacrified
> a lot of usability in the name of POSIX compliance (only a minority of
> users care) and a few seconds spared during boot (who cares? I only boot
> my laptop for kernel upgrades).

Many desktop users boot regulary, besides if you have a difficult to
reach SLA, it's nice to have a fast boot...

> Was is really the right path to follow? Wouldn't it have been easier to
> work on bash to make sure that it supports everything POSIX requires,
> and to improve its performance a bit?
> 
> Now we are going to patch configure scripts to make sure that they can
> run correctly with dash. What's next? Rewrite C programs that use
> GCC-specific extensions?

Making sure they run correctly with dash is one solution, making sure
they run with bash is another one...

Regarding C, that's kind of happening with gcc becoming more and more
compliant with the standard...

Cheers

Luk


-- 
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/4bfcbf41.5060...@debian.org

Re: RFH: bashisms in configure script

[Yves-Alexis Perez]

On mar., 2010-05-25 at 19:35 -0500, Raphael Geissert wrote:
> > ./configure is a *generated* script too, if dash cannot handle it, dash
> > has to be crippled to let the other packages continue working. Unless
> > autoconf itself has already been patched to fix all of these issues when
> > regenerating ./configure from configure.ac, all this would be a waste
> > of effort anyway.
> 
> It is not about whether dash can handle it or not. The bashisms don't come 
> from autoconf, the come from what the author's added to configure.in{,.in}. 

I beg to differ, at least some of them don't come from configure.*. One
example is
http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc 
where I can't really fine the >&$3 call (nor any >& for that matter) in the 
configure.* files.

And here, just a quick test shown that:

cor...@hidalgo: grep -c '>&' /usr/share/*/config.{guess,sub}
/usr/share/automake-1.11/config.guess:13
/usr/share/automake-1.7/config.guess:13
/usr/share/misc/config.guess:13
/usr/share/automake-1.11/config.sub:5
/usr/share/automake-1.7/config.sub:5
/usr/share/misc/config.sub:5
cor...@hidalgo: dpkg -S /usr/share/*/config.{guess,sub}
automake: /usr/share/automake-1.11/config.guess
automake1.7: /usr/share/automake-1.7/config.guess
autotools-dev: /usr/share/misc/config.guess
automake: /usr/share/automake-1.11/config.sub
automake1.7: /usr/share/automake-1.7/config.sub
autotools-dev: /usr/share/misc/config.sub

Interestingly, they don't seem to be caught by checkbashisms (maybe I
still have a non working version?)

cor...@hidalgo: checkbashisms /usr/share/*/config.{guess,sub}
possible bashism in /usr/share/automake-1.11/config.guess line 95 (trap with 
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/automake-1.7/config.guess line 95 (trap with 
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/misc/config.guess line 95 (trap with signal 
numbers):
trap 'exit 1' 1 2 15

Cheers,
-- 
Yves-Alexis


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

Re: RFH: bashisms in configure script

[Yves-Alexis Perez]

On mer., 2010-05-26 at 08:29 +0200, Yves-Alexis Perez wrote:
> > It is not about whether dash can handle it or not. The bashisms
> don't come 
> > from autoconf, the come from what the author's added to
> configure.in{,.in}. 
> 
> I beg to differ, at least some of them don't come from configure.*.
> One
> example is
> http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc 
> where I can't really fine the >&$3 call (nor any >& for that matter) in the 
> configure.* files. 

Ok, sorry, didn't see earlier in the thread that it was a false
positive.

Cheers,
-- 
Yves-Alexis


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