Re: [Pkg-scala-maint] Binary blobs in source packages

[Joachim Breitner]

Hi,

Am Mittwoch, den 14.12.2011, 17:44 + schrieb Wookey:
> I anyone is aware of packages where it really isn't possible to do an
> automatic bootstrap without a circular dependency (for the initial
> bootstrap build), I would like to know about it. 

again, GHC comes to mind. When I ported it to s390x, I had to use an old
version (6.4.2), find some 64bit patches that were used by someone to
port it to powerpc64 (https://slyfox.ath.cx/ghc/patches/6.4.2/) and
built it partly on s390, copied the generated C files, and then finished
the build on s390x. Then I used that to build 6.10.1, working around a
bug by manually building one file of the compiler without optimization.
And then I build 7.0.4 (the current version) using that file.

Certainly not something that is worth automating...

If you get the impression that upstream does not care too much about
exotic architectures – then you are right. Unfortunately, that is
nothing that we can change easily.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Managing left-over configuration files

[Malte Forkel]

Am 14.12.2011 11:30, schrieb David Kalnischkies:
> Hi,
> 
> in general, such questions are better suited for debian-mentors@,
> but here we go:
>
> ...
> 
> I think what you mean is best described/covered with the advice to
> have a look at the manpage of 'dpkg-maintscript-helper', but i must
> confess that the question isn't all that clear to me with the 'sed' either.
> 
> 

Thanks for your suggestions.

'dpkg-maintscript-helper' looks just like what I was looking for.
Unfortenately, I have to support pre-Squeeze systems as well, and dpkg
in Lenny does not have 'dpkg-maintscript-helper' yet. So I might have to
provide to some kind of fallback hack. As a first attempt, I added some
code to postinst to remove the old conffiles from the system and also
remove their entries from '/var/lib/dpkg/info/.list

As suggested, I'll take my problems to debian-mentors...

Malte



-- 
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/jccoa0$q44$1...@dough.gmane.org

Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Roger Leigh]

On Wed, Dec 14, 2011 at 03:31:41PM -0600, Jonathan Nieder wrote:
> Two clarifications:
> 
> Jonathan Nieder wrote:
> > Roger Leigh wrote:
> 
> >> The question that needs answering is this:
> >>
> >>   "what are the reasons, today, for a separate /usr?"
> >
> > No, I don't think an answer to that precise question today would be
> > especially helpful.
> 
> I'd like to apologize for this response.  Hearing use cases is always
> welcome, especially when they are given in the spirit of being helpful
> rather than defensiveness.

No worries, sorry if my initial response was also rather aggressive.
I would simply like to have some critical thought put into considering
/why/ we have things the way they are, rather than having "historical
reasons" as a rather unsatisfying answer, especially when those reasons
may no longer be applicable.

> > As far as I can tell, it is not especially
> > unsensible to use separate partitions for /usr, /etc, /var, /boot, and
> > /opt.
> 
> It occured to me too late that it might sound like I am saying a /etc
> partition separate from / can work.  By "separate" I only meant
> "distinct" (i.e., the /usr, /etc, /var, etc inodes all coming from
> different mounts).
> 
> I also think I misunderstood your message.  What kind of unification
> are you advocating?  Fedora's setup, for example, allows /usr to be a
> separate filesystem.

I'm not currently really advocating for any specific unification now.
While I think in the long run it would make sense to merge the
content of / and /usr, I don't think wheezy is the right time for it.
We might want to do some groundwork though, such as not having
duplicate paths on / and /usr.

There are two different questions here:
- do we want do permit /usr as a separately-mountable filesystem?
- do we want /usr at all?

The udev concerns the first; though being able to mount /usr in
the initramfs would ameliorate that.  Long-term though, we might
want to do away with it entirely and leave it as a compatibility
symlink (for new installs).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.



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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Roger Leigh]

On Wed, Dec 14, 2011 at 10:43:38PM +0100, J.A. Bezemer wrote:
> 
> On Wed, 14 Dec 2011, Roger Leigh wrote:
> 
> [..]
> >The same argument applies to encryption.  / and /usr both contain a
> >selection of programs, libraries etc.  If you're encrypting one, why
> >would you not encrypt all of it?
> 
> Speed.
[...]
> encrypted. But this actually does _not_ slow things down: the Linux
> disk cache is sensibly caching the decrypted data, so often-used
> stuff from /bin and /lib happily remains in already-decrypted cache.
> The interesting stuff from /usr is generally too large and too
> seldomly used to remain cached.

This was brought up last time this came up on -devel.  And I think
it kind of misses the point.

You are encrypting / and not encrypting /usr.  That's fine.  But
it's a workaround.  It's not addressing the *real* goal, which is
to encrypt /etc.

That is to say, /usr is a split of /convenience/.  The real solution
would be to have /etc as a separately-mounted encrypted filesystem.
So really, keeping /usr separate is a different issue, IMHO.  This
isn't a reason to keep the /usr split, it's a reason to support
mounting an encrypted /etc in the initramfs.  Such a solution would
also satisfy those that want a read-only root but writable /etc for
admin convenience.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Marco d'Itri]

On Dec 15, Roger Leigh  wrote:

> That is to say, /usr is a split of /convenience/.  The real solution
> would be to have /etc as a separately-mounted encrypted filesystem.
> So really, keeping /usr separate is a different issue, IMHO.  This
> isn't a reason to keep the /usr split, it's a reason to support
> mounting an encrypted /etc in the initramfs.  Such a solution would
> also satisfy those that want a read-only root but writable /etc for
> admin convenience.
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Roger Leigh]

On Thu, Dec 15, 2011 at 01:57:20PM +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh  wrote:
> 
> > That is to say, /usr is a split of /convenience/.  The real solution
> > would be to have /etc as a separately-mounted encrypted filesystem.
> > So really, keeping /usr separate is a different issue, IMHO.  This
> > isn't a reason to keep the /usr split, it's a reason to support
> > mounting an encrypted /etc in the initramfs.  Such a solution would
> > also satisfy those that want a read-only root but writable /etc for
> > admin convenience.
> You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
> /usr/ :-)

Well, I think I still need persuading that this is the right direction
to move the files.  I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
to resize the rootfs (but this has always been an issue with upgrades,
it's really the admin's responsibility to deal with partition sizing
prior to upgrading).

WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. "init" or "initramfs" to mark them as being required for mounting
in the initramfs.  This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Zachary Harris]

  Ok, ok, ok, I think I may have got it. Some of your comments helped
get me on the proper track of distro-oriented thinking where different
systems are picking and choosing a different subset of available
packages, but those packages have predefined locations where they have
to put things. It has rightly been pointed out to me by others here that
what is really needed is for libraries to be placed where they are
needed according to the a posteriori knowledge of the selection of
programs in /{s,}bin _on the local system_.

  So, I realized, how about a _package_ (I propose the name fhslib) that
effectively does something like this:

1) Check ldd /{s,}bin/* for dependencies in /usr, and put copies of
of the those libraries in /lib.
2) Keep track (somewhere in /var) of what fhslib has put in /lib.
3) When other packages are installed or removed, fhslib gets
triggered to update.

  Then we continue on as currently, with library package maintainers
doing their best to be reasonable in where they think a library
generally properly belongs, so that on any given system fhslib will
hopefully only duplicate a small handful of libraries to pick up the slack.
  On my box fhslib would result in a reasonable redundancy of 4M:

$ ldd /{s,}bin/* | /bin/grep usr | cut -f2 -d">" | cut -f1 -d"(" |
sort -u | xargs du -Lhc ; sudo du -sh /lib ; du -sh /usr/lib
1.7M/usr/lib/libcrypto.so.0.9.8
148K/usr/lib/libdbus-glib-1.so.2
60K/usr/lib/libdiscover.so.2
168K/usr/lib/libexpat.so.1
220K/usr/lib/libfuse.so.2
288K/usr/lib/libgobject-2.0.so.0
20K/usr/lib/libgthread-2.0.so.0
68K/usr/lib/libhal.so.1
44K/usr/lib/libhal-storage.so.1
28K/usr/lib/libnfnetlink.so.0
328K/usr/lib/libnl.so.1
352K/usr/lib/libntfs-3g.so.75
160K/usr/lib/libntfs.so.10
44K/usr/lib/libpcsclite.so.1
348K/usr/lib/libssl.so.0.9.8
96K/usr/lib/libz.so.1
4.0Mtotal

370M/lib
2.1G/usr/lib

Not being a package developer (yet!?), I am naive as to how much work it
would take to put fhslib together. Unless someone else really wants to
jump on it, I'd be willing to take this as an opportunity to learn a
little Debian package management and give back to the community that has
given me so much ("free beer").

-Zach

PS I think I would like fhslib to have a priority of "important" so that
someone who installs even a basic Debian system can expect FHS
compliancy. Indeed, in some sense it may be the most "minimal" systems
where it is most important.

Bug#652203: ITP: libchi-driver-memcached-perl -- Distributed cache via memcached (memory cache daemon)

[James Bromberger]

Package: wnpp
Severity: wishlist
Owner: James Bromberger 

* Package name: libchi-driver-memcached-perl
  Version : 0.14
  Upstream Author : Jonathan Swartz 
* URL : http://search.cpan.org/~jswartz/CHI-Driver-Memcached/
* License : Artistic
  Programming Lang: Perl
  Description : Distributed cache via memcached (memory cache daemon)
 A CHI driver that uses Cache::Memcached to store data in the specified
 memcached server(s).
 .
 CHI::Driver::Memcached::Fast and CHI::Driver::Memcached::libmemcached are
 also available as part of this distribution. They work with other Memcached
 clients and support a similar feature set. Documentation for all three
 modules is presented below



-- 
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/20111215132134.3138.80276.report...@rivendell.james.rcpt.to

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Simon McVittie]

On Thu, 15 Dec 2011 at 13:29:18 +, Roger Leigh wrote:
> ... albeit introducing some problems with users who would need
> to resize the rootfs (but this has always been an issue with upgrades,

... particularly if general-purpose libraries (GLib, D-Bus, OpenSSL, Expat,
HAL, zlib...) gradually creep from /usr/lib into /lib over time, whenever
someone wants to use them in a binary that gets run from udev.

In practice, the rootfs is far from being either minimal (because in
principle, every library required by any udev hook, NSS module or PAM module
has to go there, regardless of whether this particular system has that module)
or a complete/usable environment for system rescue (numerous Essential:yes
packages are not present, including about half of coreutils and nearly
all of dpkg).

S


-- 
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/20111215140404.ga2...@reptile.pseudorandom.co.uk

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

[Ian Jackson]

Svante Signell writes ("[Fwd: [ISC-Bugs #25979] What happened to the dhcp patch 
in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> Dear Debian/Hurd, GNU/Hurd and Debian-devel people. This arrived today.
> Any ideas on how to proceed? Is it possible to create a Hurd-specific
> fork of the latest ISC-DHCP release? DHCP is an essential package in the
> Debian Installer.

I went and read the Debian bug report.  The difficulty seems to be
with the patch "fix_ftbfs4hurd.dpatch".  I have to say that on reading
that patch I understood upstream's reluctance.  I don't think it looks
to me like a correct and appropriate fix for build portability
problems.

Unfortunately the upstream bug tracker is secret so we can't see any
discussion there, but the initial message sent to dhcp-bugs@isc
doesn't seem really to explain the thinking behind the patch.

Where can I find the detailed explanation of why this patch is
required and how it works to fix the problems ?  At the moment I can't
even seem to find an error message from an FTBFS log.

Ian.


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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Riku Voipio]

On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote:
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy

I think we would need a very, very good reason to migrate away from /usr.
Fedora already is going the other way (/lib,bin to /usr). Going the other
way would increase fragmentation in Linux and make essentially FHS history.

Moving everything to /usr is also less work, no need to get rid of the
--prefix=/usr in most packages in debian...

Riku


-- 
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/20111215171753.ga32...@afflict.kos.to

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Marco d'Itri]

On Dec 15, Roger Leigh  wrote:

> > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
> > /usr/ :-)
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).

> WRT mounting additional filesystems in the initramfs, how difficult
> would it be to add an additional mount option to /etc/fstab entries,
> e.g. "init" or "initramfs" to mark them as being required for mounting
> in the initramfs.  This could include /, /usr, /etc and anything else
> the admin deems necessary for booting, and would just be checked and
> added when creating/updating the initramfs.
/ is already mountable, while /etc obviously could not be if you want to
look at fstab. I see no compelling reasons to create standalone file
systems for the other directories, which are small and static.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Roger Leigh]

On Thu, Dec 15, 2011 at 07:17:53PM +0200, Riku Voipio wrote:
> On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote:
> > Well, I think I still need persuading that this is the right direction
> > to move the files.  I still think that moving /usr to / is a better
> > strategy
> 
> I think we would need a very, very good reason to migrate away from /usr.
> Fedora already is going the other way (/lib,bin to /usr). Going the other
> way would increase fragmentation in Linux and make essentially FHS history.
> 
> Moving everything to /usr is also less work, no need to get rid of the
> --prefix=/usr in most packages in debian...

Hi Riku,

I think an important point to consider is that /usr would not
disappear.  It could be replaced by a symlink for new installs.
This would permit older installs to continue to use /usr, but
the files would end up on / for new installs.  So no changes
to --prefix would be needed, and the Debian packages themselves
could still provide files in /usr.

So none of this would break any FHS paths, or make us incompatible
with Fedora.  In both situations, the same files will be present
in /bin and /usr/bin (and the same for all common subdirectories).

Doing this would be a simple change to debian-installer.  It might
require a few other minor tweaks e.g. to dpkg-shlibdeps when
considering library search paths, but this isn't new--we've
already gone down this route for GNU/Hurd in the past.


Regards,
Roger
-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: RFC/RFR: dh-exec -- Scripts to help with executable debhelper files

[Gergely Nagy]

Gergely Nagy  writes:

> For now, it can only substitute environment variables, and stuff
> dpkg-architecture(1) knows about (yes, it will work just fine even when
> $DEB_HOST_MULTIARCH and similar aren't available in the environment),
> but there's possibility to add more helpers, as the need arises, and a
> suitable syntax can be agreed upon.
>
> (There's also a rename-capable .install helper in the sources, but
> because the syntax used by it is bad to say the least, it's disabled for
> now).

After a night of very little sleep, I came up with a hack so funny, that
it even scares me. Nevertheless, since I had nightmares ever since, I'm
going to tell you all, dear readers, so the horror can be shared by
many, and in years to come, we can frighten little children with it.

I rewrote the .install helper so that it uses a nicer syntax:

,
| #! /usr/bin/dh-exec
| etc/sample.conf => /etc/my-package/my-package.conf
| examples/* /usr/share/doc/my-package/examples
`

The syntax itself isn't all that bad. But the implementation! OH MY!

To make it behave nicely, and not break dh_install in various
interesting ways, the requirement was that it must be dh_install that
will put the files to their final place. The script must not fiddle with
the destination at all.

Another requirement I had was that I do not wish to litter the source
tree, so copying the file to a new name within the source tree was ruled
out aswell.

I didn't want to leave temporary files behind, as those would need extra
care to get properly cleaned up.

And then it dawned on me: why not abuse debian/tmp for this purpose? It
will be deleted by dh_prep on clean, so whatever I put there, will be
cleaned up.

If I use a suitable temporary directory under debian/tmp, then it should
not conflict with anything else, either.

So I went ahead and did that. The new helper will take the input
mentioned above, copy etc/sample.conf to something like
debian/tmp/dh-exec.DEADBEEF/etc/my-package/my-package.conf, and rewrite
its output to look like this:

,
| dh-exec.DEADBEEF/etc/my-package/my-package.conf /etc/my-package
| examples/* /usr/share/doc/my-package/examples
`

As far as I see, this should cause no ill side-effects, apart from
strangely named directories under debian/tmp.

The code is available on the feature/exec-install/arrow-syntax[1] branch
of my repository[2].

 [1]: https://github.com/algernon/dh-exec/tree/feature/exec-install/arrow-syntax
 [2]: https://github.com/algernon/dh-exec

Let me know what you think.

-- 
|8]


-- 
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/87fwgl7nan.fsf@algernon.balabit

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Joey Hess]

Roger Leigh wrote:
> I think an important point to consider is that /usr would not
> disappear.  It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs.  So no changes
> to --prefix would be needed, and the Debian packages themselves
> could still provide files in /usr.

Didn't the hurd port try this several years ago? My impression was that
they didn't feel it had been worth the pain, perhaps it's not so easy.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Thomas Goirand]

On 12/15/2011 09:29 PM, Roger Leigh wrote:
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy, albeit introducing some problems with users who would need
> to resize the rootfs (but this has always been an issue with upgrades,
> it's really the admin's responsibility to deal with partition sizing
> prior to upgrading).
>   
This would be *really* a big issue for *a lot* of users. And I'd be one
of these
guys with about 100 servers to reinstall from scratch. I don't like using
a /boot partition, so I have a rootfs of 1 GB of RAID1, then home, usr,
var, tmp
and swap mounted on LVM over RAID10. Please don't do that unless you make
a special tool to resize my disks on-the-fly (eg: without shutting down my
running services).

Also, I really fail to see how this would be an improvement for our users.
It's just an argument for making our lives of lazy library maintainer
more easy.
Plus having very few tools on the boot partition makes it possible to store
them on a slower disk that will be less accessed than the faster one holding
your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my
/usr
is faster than the rootfs).

Thomas




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

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Thomas Goirand]

On 12/16/2011 01:24 AM, Roger Leigh wrote:
> Hi Riku,
>
> I think an important point to consider is that /usr would not
> disappear.  It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs.  So no changes
> to --prefix would be needed, and the Debian packages themselves
> could still provide files in /usr.
>   
Feel free to experiment such non-sense on your own computers,
but please do not impose this to everyone.

Oh, and when I'm at it, how do you implement /usr as read only,
(over nfs for example)? This is a quite common setup in large
organization / universities.
> Doing this would be a simple change to debian-installer.
And a hell for upgrades on *a lot* of existing systems.
>   It might
> require a few other minor tweaks
Yeah, right... A few other minor tweaks... Good luck with them!
Seriously, how much wrong could it go?

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/4eea4c1b.2060...@goirand.fr

Re: RFC/RFR: dh-exec -- Scripts to help with executable debhelper files

[Josselin Mouette]

Le jeudi 15 décembre 2011 à 18:33 +0100, Gergely Nagy a écrit : 
> ,
> | #! /usr/bin/dh-exec
> | etc/sample.conf => /etc/my-package/my-package.conf
> | examples/* /usr/share/doc/my-package/examples
> `
> 
> The syntax itself isn't all that bad. But the implementation! OH MY!
[snip]

> Let me know what you think.

Well, thanks for making my point. Implementing these (useful) features
in debhelper would be less pain to write and less eyesore for looking at
the implementation.

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


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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Josselin Mouette]

Le vendredi 16 décembre 2011 à 03:35 +0800, Thomas Goirand a écrit : 
> Oh, and when I'm at it, how do you implement /usr as read only,
> (over nfs for example)? This is a quite common setup in large
> organization / universities.

No, it is not. With a packaging system it is not suitable to have a
NFS-shared /usr.

OTOH it is a common setup to share / over NFS.

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


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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Russ Allbery]

Thomas Goirand  writes:

> Oh, and when I'm at it, how do you implement /usr as read only,
> (over nfs for example)? This is a quite common setup in large
> organization / universities.

I really don't believe this is true any more.  We used to do stuff like
this and stopped doing it a long time ago, and that's what I hear from my
peers.  Local disk space is cheap and local package management is now
easy, and doing this sort of trick is now really a waste of time and a
good way to make all your computers unnecessarily slow.

There are still some diskless systems, but those systems don't mount /usr
over NFS.  They mount / over NFS, which is a different problem entirely.

Mounting /usr but not / is not a diskless configuration; it's a very rare
hybrid mode with a small local disk, and now that local disk is so cheap
(even with embedded devices with flash memory), it's mostly just a bad
idea.

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

Re: RFC/RFR: dh-exec -- Scripts to help with executable debhelper files

[Vincent Danjean]

Le 15/12/2011 18:33, Gergely Nagy a écrit :

,
| dh-exec.DEADBEEF/etc/my-package/my-package.conf /etc/my-package
| examples/* /usr/share/doc/my-package/examples
`

As far as I see, this should cause no ill side-effects, apart from
strangely named directories under debian/tmp.

[...]

Let me know what you think.


How to you handle --list-missing from dh_install? I use it in my
package to be sure to detect when a new file is added by upstream.

  Regards,
Vincent


--
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


--
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/4eea503a.6060...@free.fr

Re: RFC/RFR: dh-exec -- Scripts to help with executable debhelper files

[Gergely Nagy]

Josselin Mouette  writes:

> Le jeudi 15 décembre 2011 à 18:33 +0100, Gergely Nagy a écrit : 
>> ,
>> | #! /usr/bin/dh-exec
>> | etc/sample.conf => /etc/my-package/my-package.conf
>> | examples/* /usr/share/doc/my-package/examples
>> `
>> 
>> The syntax itself isn't all that bad. But the implementation! OH MY!
> [snip]
>
>> Let me know what you think.
>
> Well, thanks for making my point. Implementing these (useful) features
> in debhelper would be less pain to write and less eyesore for looking at
> the implementation.

Perhaps. But the executable thing is what is in debhelper, not the
variable expansion, nor the renaming at dh_install time. I'm offering a
solution to make these cases simpler and standard.

It's certainly a possiblity to persuade me that this is a stupid idea,
and then we'll end up with no simple, standardish solution, and everyone
will roll their own, like we used to do with patch systems in the days
of yore.

And for the record, I'm seeking input on the dh-exec implementation
here. Keep the anti-executable-debhelper-foo thing in the other thread,
please.

-- 
|8]


--
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/87pqfp4nk7@luthien.mhp

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Michael Biebl]

On 15.12.2011 20:27, Thomas Goirand wrote:
> 
> Also, I really fail to see how this would be an improvement for our users.
> It's just an argument for making our lives of lazy library maintainer
> more easy.

The question is, if moving files around is a good way to spend
maintainers time. I think not. Our ressources are already stretched
thin, and there are better ways to invest our time.


> Plus having very few tools on the boot partition makes it possible to store
> them on a slower disk that will be less accessed than the faster one holding
> your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my
> /usr
> is faster than the rootfs).

You can keep /usr on a separate partition. You just need to use an
initramfs then, which will mount /usr.
Adding support for that to initramfs-tools should not be too hard.
dracut already supports this.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Vincent Danjean]

Le 13/12/2011 22:32, Roger Leigh a écrit :

On Tue, Dec 13, 2011 at 09:08:10PM +, brian m. carlson wrote:

On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:

If you have a few minutes to spare, some testing of the packages
would be appreciated, so make sure there are no corner cases we've
missed.  Upgrading initscripts should result in /etc/mtab being
switched to a symlink at the next reboot.  /lib/init/rw will also
no longer mount a tmpfs on reboot, though the directory itself will
need to remain until wheezy+1, due to the upgrade ordering--packages
migrate after initscripts has run its postinst, requiring its
continued presence.

I'd be grateful for any feedback.


I tried to make a symlink /etc/mtab -> /proc/mounts on my laptop.
Now, I get this:
root@eyak:# mount /srv/crypt/
BIG FAT WARNING: This version of mount.crypt does not support unmounting crypto 
volumes through umount(8) on systems with read-only mtab yet.
Password:

I have this line in /etc/fstab:
/dev/mapper/group-crypt /srv/crypt cryptdefaults,relatime,noauto 0 2

If I remove /etc/mtab, recreate it from a copy of /proc/mounts,
run "mount /srv/crypt", and run "diff -u /etc/mtab /proc/mounts",
I get:
--- /etc/mtab   2011-12-15 21:31:50.851308910 +0100
+++ /proc/mounts2011-12-15 21:32:14.386314020 +0100
@@ -14,5 +14,4 @@
 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc 
rw,nosuid,nodev,noexec,relatime 0 0
-/dev/mapper/_dev_dm_3 /srv/crypt ext3 rw,relatime 0 0
-/dev/dm-3 /srv/crypt crypt rw,noauto,relatime 0 0
+/dev/mapper/_dev_dm_3 /srv/crypt ext3 
rw,relatime,errors=continue,barrier=1,data=ordered 0 0

So mount.crypt add (and use for umount) the line:
/dev/dm-3 /srv/crypt crypt rw,noauto,relatime 0 0

  Regards,
Vincent

--
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


--
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/4eea5a05.6070...@free.fr

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

Package: partman-auto
Severity: normal

In all of the recent discussions about separate /usr partitions, most
people seem to acknowledge them as unusual, special-purpose
configurations, even those who use them.  To the extent they have a use
at all, they primarily have a use for people who have very specific
reasons for wanting them, and all of those people will know how to
handle partitioning.  To a lesser extent, that holds true for having
separate partitions for /var, /tmp, or other top-level directories.  It
seems likely that any such setup will have custom requirements.

Meanwhile, we don't want to steer any new users towards a setup with a
pile of different partitions, which makes their system more complex with
more potential failure modes.

In the most recent thread, I noticed that someone mentioned they
primarily chose a setup with a separate /usr partition because the
installer offered such a setup as one of the standard guided
partitioning options.

Please consider removing the option in the guided partitioner for
separate /usr, /var, and /tmp partitions; that would leave only the "All
files in one partition" and "Separate /home partition" setups, both of
which potentially make sense for users of the guided partitioner.
Anyone desiring a setup with more separate partitions should have no
trouble using the manual partitioner to create whatever custom
configuration they desire.

- Josh Triplett



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

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Luca Capello]

Hi there!

On Thu, 15 Dec 2011 18:19:54 +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh  wrote:
>
>> > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
>> > /usr/ :-)
>> Well, I think I still need persuading that this is the right direction
>> to move the files.  I still think that moving /usr to / is a better
>> strategy, albeit introducing some problems with users who would need
> /usr to / does not allow any new features, while / to /usr allows
> implementing new features like creating OS snapshots at file system
> level (something which Fedora already supports) or a real complete OS
> image (to be NFS-shared, replicated, etc).

Maybe a naive comment, but I would say that there should be a list of
all the benefits for any change, being it / -> /usr or /usr -> /, then
deciding which is the Right Thing™ would be "easier" (doing so we can
also document our choices).

So THANK YOU Marco for explaining (another) one for / -> /usr, I was
thinking of asking Roger about it [1] before reading your reply ;-)

[1] 

Thx, bye,
Gismo / Luca


pgpjzNKXwDI5W.pgp
Description: PGP signature

Bug#652284: ITP: libkmod -- a library to handle kernel modules

[Marco d'Itri]

Package: wnpp
Severity: wishlist
Owner: "Marco d'Itri" 

* Package name: libkmod
  Version : 1
  Upstream Author : ProFUSION embedded systems
* License : LGPLv2 or later
  Programming Lang: C
  Description : a library to handle kernel modules

libkmod provides an API for insertion, removal, configuration and
listing of kernel modules and the related user space tools.


See http://www.politreco.com/2011/12/announce-kmod-1/ for details.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#652286: ITP: libobject-authority-perl -- Perl module to add an AUTHORITY method to your class

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libobject-authority-perl
  Version : 0.004
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/~tobyink/Object-AUTHORITY-0.004/
* License : GPL-1 or Artistic, LGPL, BSD, MIT/X, etc.)
  Programming Lang: Perl
  Description : Perl module to add an AUTHORITY method to your class

Object::AUTHORITY adds an AUTHORITY function to your package, which
works along the same lines as the VERSION function. The authority it
takes as an argument should be a URI identifying the person, team,
organisation or trained chimp responsible for the release of the
package. The pseudo-URI scheme cpan: is the most commonly used
identifier.

Object::AUTHORITY is a new dependency of libhtml-data-parser-perl.



-- 
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/20111215221839.8560.8255.report...@island.zedat.fu-berlin.de

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Marco d'Itri]

On Dec 15, Josh Triplett  wrote:

> Anyone desiring a setup with more separate partitions should have no
> trouble using the manual partitioner to create whatever custom
> configuration they desire.
I agree.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Tanguy Ortolo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Josh Triplett, 2011-12-15 21:46+0100:
> Please consider removing the option in the guided partitioner for
> separate /usr, /var, and /tmp partitions; that would leave only the "All
> files in one partition" and "Separate /home partition" setups, both of
> which potentially make sense for users of the guided partitioner.

Well, if separating /usr is not quite so common indeed, separating /tmp
or /var is really common, however, especially for server. But anyway, as
you say people that usually install their servers organize their file
systems by hand anyway.

- -- 
Tanguy Ortolo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJO6mxwAAoJEOryzVHFAGgZdFUQAIj7p+rYSDBe6HrTMuqktWwh
Mgs3pBejs0X0xkXr/H0EBks0V0bRmTmIAyWJVhoJkdGVofVp/sQDlKZ81E+C+TFB
LGhpj/4gRWq5vtxAfw2GGIZx/2nHI4P4qvQiN7vQYXs0NG+wmYLvdY4F9vwWp4yk
PeeZE4k8ZGSjtasWg9PCAYbHm092ndyIIkE+i+iSmAprMTLQ46nWv1WmHY2z/WmW
J4r2+Fz8c1vIDkVwaVPSNsMpU+Venx6ZKwDqPRop+Fexb6dpCCpW+SDdD8iFg8BE
oMB8eJNPiH4pDvy+s+7ivwsWGW0ILWdCRysrWHFFfjKHIqQrtCM4gkcJkq8/JFK3
k1VeH5oGqpVRApYXPiyZS0NCh7MubnP8TEzuPawy4GhczIBzYyK20dFr4FgTv+1Z
zahM8+LgNyDjR0vF2WVNsXQmJqYuPRBNXGYgNTDvBEBJIMo19/84SqSYxm9OlAbg
YZRasT8F7J2bbaY3biai02trlYxO6nl7R0FiLvNMT3P6B5PpPhiRw/QJBONuBxK9
J+BpjwFfzfdzdIjkTVF3lGRnp5DpPijKhJv33ZUWUumaYdJJQtfDVeDoqfL5avB6
bj0n5Ptbo267Eu6u4kjtAwvaBJQkGXB0puy74zx/ZFhszw8bxGPZwH+Uoxc+CV17
DRPPbJQcdS2CDsXLWdh3
=luMZ
-END PGP SIGNATURE-


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

Bug#652291: ITP: googlefontdirectory-tools -- various tools for generating, analysing and manipulating font files

[Martin Erik Werner]

Package: wnpp
Severity: wishlist
Owner: Martin Erik Werner 
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: wnpp

* Package name: googlefontdirectory-tools
  Version : N/A (20111215)
  Upstream Author : Dave Crossland 
* URL : http://code.google.com/p/googlefontdirectory/
* License : Apache-2.0
  Programming Lang: python, fontforge, bash
  Description : various tools for generating, analysing and manipulating 
font files

 This package contains a collection of tools used by the Google Font Directory
 to work with fonts.
 .
 The package includes scripts to:
  * Analyse bounding boxes
  * Compare Unicode points and glyph names
  * Generate namelist files
  * Setting GASP tables in font files
  * Generate ttf and otf fonts from sfd source files
  * Generate font files with a subset of characters
  * Auto-set and analyse PREP hinting and hinting tables
  * Generate sfd source files from ttf fonts



-- 
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/20111215224921.18214.34353.reportbug@mell

Bug#652292: ITP: libobject-role-perl -- base class for non-Moose roles

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libobject-role-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/~tobyink/Object-Role-0.001/
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : base class for non-Moose roles

The idea of Object::Role is to be a base class for roles like
Object::DOES, Object::Stash and Object::ID. It handles parsing of import
arguments, installing methods into the caller's namespace (like
Exporter, but using a technique that is immune to namespace::autoclean)
and tracking which packages have consumed your role.

While Object::Role is a base class for roles, it is not itself a role,
so does not export anything. Instead, your role must inherit from it.

libobject-role-perl is a dependency of libobject-authority-perl.



-- 
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/20111215225059.16359.15096.report...@island.zedat.fu-berlin.de

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russ Allbery]

Josh Triplett  writes:

> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.  To the extent they have a use
> at all, they primarily have a use for people who have very specific
> reasons for wanting them, and all of those people will know how to
> handle partitioning.  To a lesser extent, that holds true for having
> separate partitions for /var, /tmp, or other top-level directories.  It
> seems likely that any such setup will have custom requirements.

I don't think these things are alike.  Separating /var and /tmp from the
rest of the file systems is done because those partitions contain varying
amounts of data and often fill if something goes wrong, but can fill
without impacting the rest of the system and allowing easy recovery if
they're not on the same partition as everything else.

Separating /var continues to be good and recommended practice if you're
running anything that's likely to produce a lot of output, IMO.  (/tmp
should probalby just be tmpfs, but that's another discussion.)

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

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

Russ Allbery wrote:
>Josh Triplett  writes:
>> In all of the recent discussions about separate /usr partitions, most
>> people seem to acknowledge them as unusual, special-purpose
>> configurations, even those who use them.  To the extent they have a use
>> at all, they primarily have a use for people who have very specific
>> reasons for wanting them, and all of those people will know how to
>> handle partitioning.  To a lesser extent, that holds true for having
>> separate partitions for /var, /tmp, or other top-level directories.  It
>> seems likely that any such setup will have custom requirements.
> 
> I don't think these things are alike.  Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.

Exactly what I had in mind when I said "To a lesser extent". :)

I still think the general statement applies: "It seems likely that any
such setup will have custom requirements.".  Anyone installing a server
probably either wants one of the two other guided setups (all-in-one or
separate /home) or wants the manual partitioner because they have
specific ideas about which partitions and sizes they want.  Thus, I
think the guided partitioner shouldn't offer a generic
pile-o'-partitions option, and particularly not one with a separate
/usr.

- Josh Triplett


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

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Roger Leigh]

On Thu, Dec 15, 2011 at 09:35:17PM +0100, Vincent Danjean wrote:
> Le 13/12/2011 22:32, Roger Leigh a écrit :
> >On Tue, Dec 13, 2011 at 09:08:10PM +, brian m. carlson wrote:
> >>On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:
> >>>If you have a few minutes to spare, some testing of the packages
> >>>would be appreciated, so make sure there are no corner cases we've
> >>>missed.  Upgrading initscripts should result in /etc/mtab being
> >>>switched to a symlink at the next reboot.  /lib/init/rw will also
> >>>no longer mount a tmpfs on reboot, though the directory itself will
> >>>need to remain until wheezy+1, due to the upgrade ordering--packages
> >>>migrate after initscripts has run its postinst, requiring its
> >>>continued presence.
> >>>
> >>>I'd be grateful for any feedback.
> 
> I tried to make a symlink /etc/mtab -> /proc/mounts on my laptop.
> Now, I get this:
> root@eyak:# mount /srv/crypt/
> BIG FAT WARNING: This version of mount.crypt does not support unmounting 
> crypto volumes through umount(8) on systems with read-only mtab yet.
> Password:
> 
> I have this line in /etc/fstab:
> /dev/mapper/group-crypt /srv/crypt cryptdefaults,relatime,noauto 0 2

Possibly related: #622693
Fixed upstream, but needs the utab patch integrating.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

[brian m. carlson]

On Thu, Dec 15, 2011 at 02:15:11PM +, Ian Jackson wrote:
> Svante Signell writes ("[Fwd: [ISC-Bugs #25979] What happened to the dhcp 
> patch in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> > Dear Debian/Hurd, GNU/Hurd and Debian-devel people. This arrived today.
> > Any ideas on how to proceed? Is it possible to create a Hurd-specific
> > fork of the latest ISC-DHCP release? DHCP is an essential package in the
> > Debian Installer.
> 
> I went and read the Debian bug report.  The difficulty seems to be
> with the patch "fix_ftbfs4hurd.dpatch".  I have to say that on reading
> that patch I understood upstream's reluctance.  I don't think it looks
> to me like a correct and appropriate fix for build portability
> problems.

Hurd doesn't support PATH_MAX.  So trying to allocate memory based on
PATH_MAX isn't going to work on Hurd.  However, with glibc (and with
POSIX 1003.1-2008) we can simply mark the destination buffer to realpath
as NULL and the appropriate amount of memory will be automatically
allocated.  Not all systems support this, though.

I cannot comment on the remainder of the patch, but the PATH_MAX issue
is a pretty common one for Hurd, and assuming PATH_MAX is a compile-time
constant is a bad idea anyway, since it's not allowed by POSIX.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Roger Leigh]

On Fri, Dec 16, 2011 at 03:35:55AM +0800, Thomas Goirand wrote:
> On 12/16/2011 01:24 AM, Roger Leigh wrote:
> > Hi Riku,
> >
> > I think an important point to consider is that /usr would not
> > disappear.  It could be replaced by a symlink for new installs.
> > This would permit older installs to continue to use /usr, but
> > the files would end up on / for new installs.  So no changes
> > to --prefix would be needed, and the Debian packages themselves
> > could still provide files in /usr.
> >   

> > Doing this would be a simple change to debian-installer.
> And a hell for upgrades on *a lot* of existing systems.

The point of the above was to show that it could be made that upgrades
would be unaffected by the change: it would only occur for new
installs.  I'm not saying that's the only way or the best way, just
that it's one possibility to consider.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russ Allbery]

Josh Triplett  writes:

> I still think the general statement applies: "It seems likely that any
> such setup will have custom requirements.".

I guess this is what I don't agree with.

> Anyone installing a server probably either wants one of the two other
> guided setups (all-in-one or separate /home) or wants the manual
> partitioner because they have specific ideas about which partitions and
> sizes they want.

I don't see separating /var and /tmp from / as being related to servers,
personally.

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

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russell Coker]

On Fri, 16 Dec 2011, Russ Allbery  wrote:
> I don't see separating /var and /tmp from / as being related to servers,
> personally.

None of my servers have a separate /var.  Of the servers I run which have /tmp 
as a separate filesystem it's a tmpfs.

I have used a /var/log filesystem on occasion.  I also regularly use 
filesystems such as /mysql and /mail to gain benefits that some people might 
gain from using a separate /var.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201112161134.31242.russ...@coker.com.au

Work-needing packages report for Dec 16, 2011

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 393 (new: 6)
Total number of packages offered up for adoption: 141 (new: 0)
Total number of packages requested help for: 61 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   ddns3-client (#652029), orphaned yesterday
 Description: Issues dynamic DNS v3 requests
 Installations reported by Popcon: 43

   magicfilter (#652289), orphaned today
 Description: automatic printer filter
 Installations reported by Popcon: 475

   mirror (#652125), orphaned yesterday
 Description: keeps FTP archives up-to-date
 Installations reported by Popcon: 195

   tth (#652131), orphaned today
 Description: TeX/LaTeX to HTML converter
 Installations reported by Popcon: 181

   weathermap4rrd (#651929), orphaned 2 days ago
 Installations reported by Popcon: 50

   zvbi (#652225), orphaned today
 Description: Vertical Blanking Interval (VBI) utilities
 Reverse Depends: alevtd libzvbi-dev libzvbi0 scantv vlc-plugin-zvbi
   xawtv zapping zvbi
 Installations reported by Popcon: 3347

387 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 141 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#646208), requested 54 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (181 more
   omitted)
 Installations reported by Popcon: 60366

   apt-xapian-index (#567955), requested 682 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 49164

   asymptote (#517342), requested 1021 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 2917

   athcool (#278442), requested 2606 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 99

   balsa (#642906), requested 81 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg debreaper
 Installations reported by Popcon: 271

   bastille (#592137), requested 495 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 278

   boinc (#511243), requested 1071 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1864

   cardstories (#624100), requested 234 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 564 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n gecko-mediaplayer mozplugger
 Installations reported by Popcon: 9490

   cryptsetup (#600777), requested 421 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7186

   cvs (#354176), requested 2121 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more
   omitted)
 Installations reported by Popcon: 18046

   dctrl-tools (#448284), requested 1510 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   postgresql-server-dev-all simple-cdd (1 more omitted)
 Installations reported by Popcon: 14737

   debtags (#567954), requested 682 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popc

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

[Ben Hutchings]

On Fri, 2011-12-16 at 00:15 +, brian m. carlson wrote:
> On Thu, Dec 15, 2011 at 02:15:11PM +, Ian Jackson wrote:
> > Svante Signell writes ("[Fwd: [ISC-Bugs #25979] What happened to the dhcp 
> > patch in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> > > Dear Debian/Hurd, GNU/Hurd and Debian-devel people. This arrived today.
> > > Any ideas on how to proceed? Is it possible to create a Hurd-specific
> > > fork of the latest ISC-DHCP release? DHCP is an essential package in the
> > > Debian Installer.
> > 
> > I went and read the Debian bug report.  The difficulty seems to be
> > with the patch "fix_ftbfs4hurd.dpatch".  I have to say that on reading
> > that patch I understood upstream's reluctance.  I don't think it looks
> > to me like a correct and appropriate fix for build portability
> > problems.
> 
> Hurd doesn't support PATH_MAX.  So trying to allocate memory based on
> PATH_MAX isn't going to work on Hurd.  However, with glibc (and with
> POSIX 1003.1-2008) we can simply mark the destination buffer to realpath
> as NULL and the appropriate amount of memory will be automatically
> allocated.  Not all systems support this, though.
> 
> I cannot comment on the remainder of the patch, but the PATH_MAX issue
> is a pretty common one for Hurd, and assuming PATH_MAX is a compile-time
> constant is a bad idea anyway, since it's not allowed by POSIX.

Indeed, for any system with an extensible VFS it makes a lot more sense
to implement only pathconf() than to specify a constant value that
covers all possible filesystems.  But as you say there's a lot of
software that depends on that constant.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

[Russ Allbery]

Ben Hutchings  writes:

> Indeed, for any system with an extensible VFS it makes a lot more sense
> to implement only pathconf() than to specify a constant value that
> covers all possible filesystems.  But as you say there's a lot of
> software that depends on that constant.

Thanks to a lot of work by the Hurd folks, there's quite a bit less than
there used to be.  :)

I haven't looked at the patch in this thread, but most of the time that
I've seen PATH_MAX used in software, it's indicated a design flaw in an
interface: use of static buffers for file paths rather than adjusting to
arbitrary length of file names.  You can arguably "fix" it by defining
PATH_MAX to something arbitrary, but usually the better fix is to go back
and fix the incorrect choice of API to use a caller-provided buffer or to
do memory allocation instead.

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

Bug#652318: ITP: ruby-indentation -- Ruby extensions for Array and String classes

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: ruby-indentation
  Version : 0.0.6
  Upstream Author : Prometheus Computing
* URL or Web page : http://github.com/samueldana/indentation
* License : MIT 
  Description : Ruby extensions for Array and String classes
 A library of extensions to Ruby's Array and String classes that allow
 indentation manipulation of Strings and Arrays of Strings.




-- 
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/87vcphpacv.wl%tak...@asis.media-as.org

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Christian PERRIER]

(reducing CC as I guess that most are subscribed to -devel)

Quoting Russ Allbery (r...@debian.org):

> I don't think these things are alike.  Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.
> 
> Separating /var continues to be good and recommended practice if you're
> running anything that's likely to produce a lot of output, IMO.  (/tmp
> should probalby just be tmpfs, but that's another discussion.)

I'm inclined to follow this advice and would indeed propose that the
"atomic" partman-auto recipe is kept, however without a separate /usr
partition (discussions on -devel and the current practice convinced me
that a separate /usr is seomthing that probably belongs to the former
century..:-)


So, would it be OK for participants in this discussion is we, in the
installer, just drop separate /usr but keep the atomic recipe (which
is not the default choice, by the way)?




signature.asc
Description: Digital signature

Re: RFC/RFR: dh-exec -- Scripts to help with executable debhelper files

[Gergely Nagy]

Vincent Danjean  writes:

> Le 15/12/2011 18:33, Gergely Nagy a écrit :
>> ,
>> | dh-exec.DEADBEEF/etc/my-package/my-package.conf /etc/my-package
>> | examples/* /usr/share/doc/my-package/examples
>> `
>>
>> As far as I see, this should cause no ill side-effects, apart from
>> strangely named directories under debian/tmp.
> [...]
>> Let me know what you think.
>
> How to you handle --list-missing from dh_install? I use it in my
> package to be sure to detect when a new file is added by upstream.

It shouldn't affect list-missing. The => adds new files to
debian/tmp/dh-exec.BLAH/, which will be handled by dh_install anyway. So
they don't show up as false positive.

If upstream installs new files, that's entirely handled by dh_install,
and the => functionality has no effect on it at all.

(To the best of my knowledge, dh_install --list-missing will list files
under debian/tmp that weren't copied anywhere. The new stuff put there
by dh-exec-install won't show up as false positives, and it doesn't hide
mask out anything, so --list-missing should be unaffected.)

-- 
|8]


--
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/87wr9xc8go@luthien.mhp