Re: Packages removing alternatives on upgrade

2012-10-07 Thread Russ Allbery 
Ivan Shmakov  writes:

>   ?  How is the ‘if’ statement above different to, say:

> case "$1" in
> (remove)
> update-alternatives --remove  
> ;;
> esac

It's not; what it *is* different from is the more common case
construction, which instead looks like:

case "$1" in
(remove)
update-alternatives --remove  
;;
(upgrade|failed-upgrade|deconfigure)
;;
(*)
echo "Unknown call $@" >&2
exit 1
;;
esac

If the case doesn't have that default case, it doesn't have this problem,
but when you see the case statement, you usually see that form.

-- 
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/877gr1a84e@windlord.stanford.edu

Re: Packages removing alternatives on upgrade

2012-10-07 Thread Ivan Shmakov 
> Russ Allbery  writes:

[…]

 > It's an improvement.  Guillem makes a good argument that you should
 > drop deconfigure as well, which means that:

 > if [ "$1" = "remove" ] ; then
 > update-alternatives --remove  
 > fi

 > is probably the best thing to use right now.

[…]

 > (Note that while common, I've never been fond of that case statement
 > construction, since it means that we can't introduce new maintainer
 > script actions without modifying lots of maintainer scripts that may
 > not need to be modified otherwise.)

?  How is the ‘if’ statement above different to, say:

case "$1" in
(remove)
update-alternatives --remove  
;;
esac

-- 
FSF associate member #7257


-- 
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/86wqz1k2nb@gray.siamics.net

Re: Re: assumptions about the build environment.

2012-10-07 Thread Roger Leigh 
On Sun, Oct 07, 2012 at 11:54:40AM +0200, Eric Valette wrote:
> I'm currently trying to compile armhf package for the rasberry pi on
> a amd64 machine and naively though it would be easy to do with
> multiarch. I screwed my machines(replaced the dynamic linkers, ftp
> and other tools by arm binaries although I followed the scarce
> available documentation).
> 
> Natively compiling package as big as XBMC on the PI is a nightmare
> and current tools fails really short because you:
>   1) need a root filesystem for the machines. You can use debootstrap
> but will need many additionnal packages that are yet not build,
> 2) cannot install produced .deb in the root filesystem exept
> by running them on qemu which is..
> 
> Any hint?

schroot will let you run a non-native chroot with qemu, and you can
use this with sbuild for package building.  sbuild now also has
initial support or multiarch cross building.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20121007214110.gj18...@codelibre.net

Re: assumptions about the build environment.

2012-10-07 Thread Roger Leigh 
On Sun, Oct 07, 2012 at 10:58:31AM +0200, Jakub Wilk wrote:
> More questions about build env assumptions:
> 
> Can you assume that /sbin and /usr/sbin are within PATH?

At which point(s) during the build?

For sbuild:

During any command run as the build user (*not* root), it will
default to

my %common_keys = (
'PATH'  => {
DEFAULT => 
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
},

(from Sbuild::ConfBase).  They should be present when running commands
as root, though I'd have to double-check that.

> Can you assume that the SHELL environment variable (_not_ the
> makefile variable) is set to something §10.4-compliant?

It looks like we currently pass SHELL through, unless you configure it
otherwise.  Maybe this should be revisited?

> (My personal answers to these questions are: no and no.)

I think that this is correct (as the default behaviour; it could be
configured otherwise).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20121007213942.gi18...@codelibre.net

Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?

2012-10-07 Thread Julien Cristau 
On Fri, Oct  5, 2012 at 23:16:05 +0200, Andreas Beckmann wrote:

> Hi,
> 
> I haven't made a detailed analysis, yet, and cannot say how many
> packages would be affected. Right now I have about 100 candidate
> piuparts logs that should cover /var/run and /var/lock, but I haven't
> sorted them in "buggy", "depends on buggy", "other problem". I expect
> the buggy category to be around a dozen.
> 
> Would it be appropriate to file RC bugs against all the packages
> shipping anything in /var/run, /var/lock or /run?
> 
No, there's nothing wrong with that.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?

2012-10-07 Thread Thomas Goirand 

On 10/06/2012 03:16 PM, Thomas Goirand wrote:

On 10/06/2012 05:46 AM, Andreas Beckmann wrote:
Anyone who wants to take this easy job? Since I don't have to analyze 
piuparts logs for getting the data ... Andreas 

Hi,

I'll try to send bugs *with patches* over this week end.

Thomas Goirand (zigo)



This is done. For each package in the lists I sent a bug report
with a proposed debdiff. Since the var/run folder is to be used
at runtime, I couldn't always tell where to add the relevant
mkdir calls, but that was pretty rare. In most cases, adding it
into debian/.init was enough, and often, then mkdir
was there already (even with the package shipping the folder).
Also, some package were using dpkg-statoverride. I believe it
doesn't make sense for something in /var/run.

After doing this work, I also believe that ftp-master should
reject any package shipping a folder /var/run/.
On the 28 packages which I wrote a patch for, none seemed to
have valid reasons to ship that folder. Even those who were
having a lintian override file. So at least blocking if there's
no override seem to me the correct thing to do.

Cheers,

Thomas Goirand (zigo)


--
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/50719fc3.2000...@debian.org

Re: Re: assumptions about the build environment.

2012-10-07 Thread Eric Valette 

While working on debian one thing I have not managed to find is
documentation on what packages can and can't assume about the build
environment. Does such documentation exist and if not should it be
created.

Some specific cases i'm wondering about:

I just discovered that on my beagleboard XM (under armhf sid) nacl
(which previously build on a debian experimental armhf buildd but
not a debian unstable armhf buildd) will build if /sys is mounted
but will not build if it is not mounted. Can packages assume that
/sys will be mounted in the build environment or not?


I consider /sys almost as essential as /proc.  However I wonder
what a build process would need it for.


I will hijack this thread a bit and I know there is another one running 
on the subject, but assumption like this makes it impossible to cross 
compile most packages.


I'm currently trying to compile armhf package for the rasberry pi on a 
amd64 machine and naively though it would be easy to do with multiarch. 
I screwed my machines(replaced the dynamic linkers, ftp and other tools 
by arm binaries although I followed the scarce available documentation).


Natively compiling package as big as XBMC on the PI is a nightmare and 
current tools fails really short because you:
	1) need a root filesystem for the machines. You can use debootstrap but 
will need many additionnal packages that are yet not build,
2) cannot install produced .deb in the root filesystem exept by 
running them on qemu which is..


Any hint?



--
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/50715160.5050...@free.fr

Re: assumptions about the build environment.

2012-10-07 Thread Jakub Wilk 

More questions about build env assumptions:

Can you assume that /sbin and /usr/sbin are within PATH?

Can you assume that the SHELL environment variable (_not_ the makefile 
variable) is set to something §10.4-compliant?


(My personal answers to these questions are: no and no.)

--
Jakub Wilk


--
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/20121007085831.ga7...@jwilk.net