Re: support for merged /usr in Debian

[Paul Wise]

While reading the LWN article about this, I had a thought that might
be interesting.

The packages should all install to /usr and $something should
automatically manage the contents of /bin /sbin /lib (/boot?) based on
the tools needed to mount /usr (perhaps plus some more recovery
tools), just like we do with initramfs-tools/dracut automatically
managing the contents of the initramfs based on the tools needed to
mount the /usr partition. However, as Simon suggests it may not be
feasible to automatically determine what the contents of /bin /sbin
/lib should be.

https://lwn.net/Articles/670071/
https://lists.debian.org/msgid-search/568ce53e.9020...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Rudy Godoy MIA?

[Pedretti Fabio]

Hi, I tried to contact debian developer Rudy Godoy but I got no reply. A
package he maintains, torcs, is in need of an update since some years.

As explained here:
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa
I am sending this mail.

Re: vlan support en* or br*?

[Andreas Henriksson]

Hello.

On Thu, Jan 07, 2016 at 02:47:31AM +, Ben Hutchings wrote:
[...]
> The real problem is that vconfig (or rather the kernel interface it
> used) imposed any scheme at all.  Requiring a '.' is equally short-
> sighted. Let me give an example:

IMHO not equally, but yes... too shortsighted.

[...]
> But instead of letting the names depend on the underlying hardware
> configuration, some time ago I started naming them 'ext0' (modem) and
> 'wl0' (wireless AP) and it's pretty clear which of this is which.  When
> I changed the hardware and added VLANs there was very little need to
> change configuration outside of /etc/network/interfaces.

Seems like we're wandering into discussing best-practises and let me
share my view for the potential benefit of mailing list readers...

Obviously the below applies only to a "managed server", not to something
which is basically unmanaged/autoconfigured/zeroconf system (like a
roaming laptop or some embedded device).

I fully agree with giving meaningful "functional" names to your interfaces.
These should NOT be based on what hardware is used, protocol types, vlan, 
tunneled, or anything like that but instead on what they're used for,
eg. wan, lan, dmz, ... (or if you prefer: ext, int, ...)
(IMHO it's good to avoid numbers completely in these names, eg. if you
provide separation of your internal network in zones with different
"trust level" instead of int0 and int1, use eg. intwired and intwlan
or whatever your separation/trust-level is based on.)

Using functional names (hopefully/likely) means you've set up a reliable
way to get the same interface named and you're not subject to hardware
ordering, initialization ordering, someone enabling "predicable interface
naming" schemes, etc.

It also provides a good abstraction.
 - your firewall rules will be more functional and easier to read when you set
   them up as "... -i wan -o lan ..." rather than relying on some hardware
   name.
 - if you're ISP fscks their routing or similar partial outtakes you can simply
   set up a tunnel to somewhere, temporarily take down your "real" wan and name
   the tunnel wan and everything else on your system should be ready to go
   This has proven really useful when you provide a somewhat critical service
   in my experience.
 - ... many other reasons, zero cost abstractions are really useful.

Let me also state that even if you can enable predictable interface naming
using systemd, or whatever, these names are still not functional so you've
still failed to follow best practises if you rely on them. (Let alone if
you think eth* names are reliable you're simply wrong.)
Following these best-practises means the discussions about if systemd
enables predictable interface naming scheme or not is (for people
managing servers) completely uninteresting. You'll simply treat anything
which does not have a functional name as if it's an unused spare. You give
it a functional name /before/ even considering bringing UP the interface.
(I hope it's also obvious that in any zeroconf situation it's useful that an
interface gets the same (initially random as far as I'm concerned) for each
consecutive boot. But for your managed server usecase, this is completely
uninteresting.)

Regards,
Andreas Henriksson

Re: Rudy Godoy MIA?

[Tobias Frost]

Am Donnerstag, den 07.01.2016, 10:23 +0100 schrieb Pedretti Fabio:
> Hi, I tried to contact debian developer Rudy Godoy but I got no
> reply. A
> package he maintains, torcs, is in need of an update since some
> years.
> 
> As explained here:
> https://www.debian.org/doc/manuals/developers-reference/beyond-pkging
> .html#mia-qa
> I am sending this mail.

Plesae also forward your (non answered) communication to the MIA Team..
(https://wiki.debian.org/Teams/MIA)

-- 
tobi

Bug#810241: ITP: pulseaudio-dlna -- A lightweight streaming server which brings DLNA / UPNP and Chromecast support to PulseAudio and Linux

[Muammar El Khatib]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: pulseaudio-dlna
Version: 0.4.7
Upstream Author: Massimo Mund 
URL: https://github.com/masmu/pulseaudio-dlna
License: GPL-3
Description: A lightweight streaming server which brings DLNA / UPNP and
Chromecast support to PulseAudio and Linux.

pulseaudio-dlna can stream your current PulseAudio playback to different
UPNP devices (UPNP Media Renderers) or Chromecasts in your network. Its main
goals are: easy to use, no configuration hassle, no big dependencies.

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Re: support for merged /usr in Debian

[Marc Haber]

On Wed, 6 Jan 2016 09:57:26 +, Jonathan Dowland 
wrote:
>On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
>> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>> 
>> > https://wiki.debian.org/UsrMerge
>> 
>> Now that we have union mounts in Linux
>
>Do you mean overlayfs? If so can you or anyone vouch for its quality?

I am using Overlayfs for mini-buildd and sbuild systems, overlaying an
ext4fs with an tmpfs for build chroots.

Works like a charm, so far.

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

Re: overlayfs (was: Re: support for merged /usr in Debian)

[Matthias Klumpp]

I am using overlayFS in Limba[1], and it works well (and is really
fast!) for read-only filesystems, read-write sometimes has issues if
you are using multiple OverlayFS layers (which made me adjust the code
so this doesn't happen anymore).

2016-01-06 17:29 GMT+01:00 Jonathan Dowland :
> I wish I could, but I can't, sorry. All I know is I got mysterious ENOENT
> errors at unpredictable times at some point in the layer stack when using
> it as a docker back-end and developing docker images. I can't recall what
> version of overlayfs/kernel I was using at the time; probably latest RHEL
> 7.* but I'm not sure.

Did you use Linux 4.2 and were maybe hit by this bug:
https://lkml.org/lkml/2015/10/7/289 ?

Cheers,
Matthias

[1]: https://packages.debian.org/sid/limba

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Bug#810263: ITP: python-scales -- Metrics for Python

[Federico Ceratto]

Package: wnpp
Severity: wishlist
Owner: Federico Ceratto 

* Package name: python-scales
  Version : 1.0.9
  Upstream Author : The scales Authors
* URL : https://github.com/Cue/scales
* License : Apache-2.0, MIT
  Programming Lang: Python
  Description : Metrics for Python

Tracks server state and statistics, allowing you to see what your server is
doing. It can also send metrics to Graphite for graphing or to a file for crash
forensics.
It provides counters, timers, 1/5/15 minute averaged rates, hierarchical
metrics with aggregation.

The package will be maintained in collab-maint

Re: support for merged /usr in Debian

[Marc Haber]

On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
>On Jan 05, Ian Jackson  wrote:
>
>> People who have been using a configuration for many years naturally
>> become upset when they are told that it has been `unsupported' for all
>> of this time and that, implicitly, changes are going to be made which
>> will break it.
>I think that your summary is correct, and I am quite sure that it would 
>be a bad engineering practice to make technical decisions based on 
>people's emotions.

Unfortunately, it's emotions that take vendor decisions. Your attitude
is driving big users towards the paid-for Enterprise Linuxes, be it
logical or not, be it good engineering or not.

Do care about people, at least partially. Sound logic and technical
decisions are not always the right thing to do.

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

Re: vlan support en* or br*?

[Marc Haber]

On Wed, 06 Jan 2016 14:37:17 +, Ben Hutchings
 wrote:
>That's why I was suggesting a replacement package that would provide
>similar functionality but using 'ip' so not subject to the limitations
>of the vlan ioctl interface.

Do we already have such a replacement package?

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

Re: support for merged /usr in Debian

[Philip Hands]

Marc Haber  writes:

> On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
>>On Jan 05, Ian Jackson  wrote:
>>
>>> People who have been using a configuration for many years naturally
>>> become upset when they are told that it has been `unsupported' for all
>>> of this time and that, implicitly, changes are going to be made which
>>> will break it.
>>I think that your summary is correct, and I am quite sure that it would 
>>be a bad engineering practice to make technical decisions based on 
>>people's emotions.
>
> Unfortunately, it's emotions that take vendor decisions. Your attitude
> is driving big users towards the paid-for Enterprise Linuxes, be it
> logical or not, be it good engineering or not.

Even if that were true, I fail to understand why we should be worried.

If some (apparently irrational) people were to choose to pay for the
privilege to whine at someone else ... that's just fine isn't it?

The rationality and civility here is increased by their departure, and
somewhere else in the Free Software world they start paying some
company, which is likely to in part go towards funding more developer
time, from which we benefit.

I'm alsmost tempted to suggest that Marco revert to his more usual
brusqueness, in order to maximise the benefit.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Hardware detection

[Stefan Lippers-Hollmann]

Hi

On 2016-01-07, Stephan Foley wrote:
> Hello, I am working on a Fluxbox Debian Pure Blend:
> 
> https://wiki.debian.org/FluxBox/Blend
> 
> Currently, I am going to use discover, mdetect and read-edid for
> hardware discovery but found in the repos hwinfo which is used by
> Debian Edu and was wondering if this is a better tool. Description
> follows:
[...]

As someone working on Debian derived live systems since the earlier
kernel 2.4 days, I wonder why you think to need any of those on a 
modern linux system at all?

linux >= 2.6, udev and kmod do a great job to probe all 
auto-discoverable devices on their own. The things they miss either 
can't be detected automatically or at least not in a safe way. Neither
of which are typically found on systems supported by Debian systems
whose primary purpose is running/ showcasing/ using a window manager.
The i586/ i686 cutoff mostly prevents you from having to discover 
ISA devices or even weirder legacy system buses - and on embedded 
architectures with SDIO, similar non-discoverable buses and board 
specific boot procedures, you have bigger problems (e.g. getting FOSS 
display driver support) than anything discover/ mdetect/ hwinfo can 
help you with.

Regarding read-edid, why?! X.org does a pretty good job detecting your
screen, its native resolution and your common input devices these days
(I'm too lazy to check for the exact version, but for a few years 
already). The only time you might want to override the auto-detected
settings, is typically when automatic detection doesn't work (broken
EDID, weird setups, etc. - but this usually means older than ~15-20 
year old CRTs), in which case read-edid isn't very likely to help you 
either. Complex multi-screen setups just aren't something you can
detect, as nothing will tell you which monitor is left/ right/ top/
bottom - so the only thing you can do there is sticking to X.org's
defaults (clone) and providing an easy way to do xrandr based runtime
configuration (a feature typically covered by modern desktop 
environments).

These days, live systems basically need help (beyond the default 
features provided by a normal Linux/ Debian installation; the situation
slightly differs for kfreebsd or probably hurd) in two areas[0]:
- setting up a network connection (again, the kernel probes the required
  modules quite well, the problem is just a policy decision. Find 'the'
  network interface with a link beat and run a dhcp client, if that 
  doesn't help, the user needs to configure it manually anyways - same 
  for encrypted wlan, wwan, etc.) - and providing firmware blobs, if 
  needed.
- generating a fstab (and even this is largely optional these days, 
  considering today's RAM sizes, auto-discovering an existing swap isn't
  as critical as in the days of yore, the other disks/ partitions are
  typically handled quite well with udisk2 and policykit in the typical
  desktop environments, although probably not using fluxbox).

plus the things that aren't hardware dependent at all, like:
- finding~ and cooking the rootfs to appear writable
- forgetting stale state ((re-)generating machine IDs, clearing sshd keys,
  etc.)[1]
- setting up live users/ preseeding[2] a sane configuration environment
- intercepting reboot/ halt and properly shutting down the live 
  environment
- locales/ i18n/ keymaps
- ...

discover, hwinfo, hwdetect, kudzu, read-edid had their days of fame (or 
rather, they were a painful necessity), but at least on semi-modern linux
systems they are pretty much obsolete for a couple of years already for 
anything resembling a remotely 'normal' system (anything with VGA/ DVI/ 
HDMI/ DP, PCI(e), USB and BIOS|UEFI with ACPI). And at least for the non 
UEFI/ACPI armhf/ arm64 world, either of those tools come way too late (as 
you need a SOC/ board specific bootloader and configure it to use the 
proper dtb; beyond that, kernel/ udev should just work as well for most 
auto-detectable devices there as well).

Regarding "hardware detection", there typically is only one distant domain
which could need some further refinements - namely helping the user to
find missing firmware images for their devices (preventing them from just
working out of the box, aka welcome the non-free blobbyness of the real 
world) or identifying additional packages you might not want to preinstall,
but which are nevertheless useful (only) in combination with certain 
hardware (e.g. sane, if you have a scanner, fprintd if a fingerprint reader
is present, something like this) - isenkram is supposed to cover this.

You haven't really revealed if the target of your pure blend is an 
installed system or a live environment (the wiki page and your mail 
slightly tend towards a live system, but neither provide a definitive
answer), but in neither case it should be much of a concern how to
detect hardware (as that's either solved by d-i or your live framework 
in a desktop/ WM agnostic way) for you as blend maintainer. If you do,
you're quickly 

Re: support for merged /usr in Debian

[Russ Allbery]

Marc Haber  writes:

> Unfortunately, it's emotions that take vendor decisions. Your attitude
> is driving big users towards the paid-for Enterprise Linuxes, be it
> logical or not, be it good engineering or not.

...the ones that have already merged /usr and /?

I'm not sure I understand this reasoning.

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

Re: support for merged /usr in Debian

[Simon McVittie]

On 07/01/16 08:36, Paul Wise wrote:
> $something should
> automatically manage the contents of /bin /sbin /lib (/boot?) based on
> the tools needed to mount /usr (perhaps plus some more recovery
> tools)

I really don't think that's a good approach, particularly as a default.
We already have tools to make a minimal bootable environment that can
mount /usr and do some limited recovery, and the result is called an
initramfs. If you want a lighter-weight initramfs for environments where
those generated by initramfs-tools or dracut are overkill, Christian
Seiler has a nice proof-of-concept elsewhere in the thread, which
apparently compiles to less than 16K.

If you're using binaries in /usr and copying a dependency-closure subset
of them to the root filesystem, what makes that any better than using
binaries in /usr and copying a dependency-closure subset of them into
the initramfs? You basically end up doing a 2-phase boot (mount /usr,
then start the parallelizable part of the boot process) either way.

One key difference that I can see is that the initramfs has one job - it
mounts critical filesystems and is dropped from RAM - so any special
configuration that it needs doesn't interfere with normal operation. The
root filesystem (without /usr, if your /usr is separate) has two jobs:
it has to mount /usr, and it has to be the real root filesystem
afterwards. For instance, the tools in /bin and /sbin are reading the
same configuration in /etc, and system-integration glue in /etc or /lib,
that you use for the fully functional system, including arbitrary
/{etc,lib}/udev hooks (which might run helpers with long dependency
chains), arbitrary PAM modules, arbitrary NSS modules... all of which
you probably want, *later*, or you wouldn't have installed them, but not
before /usr comes up.

To make this plan work, you'd need to somehow make sure that all the
tools used between "start init" and "mount /usr" were running in a mode
where they avoided doing anything that couldn't be done before mounting
/usr. That sounds suspiciously like reinventing the initramfs, but with
the additional constraint that it has to work with the same /etc as the
fully-featured system.

If I absolutely had to implement your plan, I'd do it by writing a
minimal pid-1 which does the minimum necessary to mount /usr, then execs
the real init (sysvinit, systemd, whatever)... which, again, is sounding
suspiciously similar to an initramfs, in which the kernel executes a
script or binary (typically /init or /linuxrc) as pid 1, and that
process is expected to finish by exec'ing the real init.

If you're on an embedded platform where the bootloader doesn't
understand initramfs, it's entirely possible to embed a small initramfs
in the kernel image itself (AIUI, initramfs-capable kernels always have
one, but it's usually empty) - CONFIG_INITRAMFS_SOURCE is the option to
look for. Christian's 16K initramfs sounds ideal for that.

S

Bug#810289: ITP: helm -- Emacs incremental completion and selection narrowing framework

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: helm
  Version : 1.9.1
  Upstream Author : Thierry Volpiatto 
* URL : https://emacs-helm.github.io/helm/
* License : GPL-3
  Programming Lang: Emacs Lisp
  Description : Emacs incremental completion and selection narrowing 
framework

An alternative to Ido, very popular among Emacs users.  Upstream
description:

Helm is incremental completion and selection narrowing framework for
Emacs. It will help steer you in the right direction when you're
looking for stuff in Emacs (like buffers, files, etc).

Helm is a fork of anything.el originally written by Tamas Patrovic and
can be considered to be its successor. Helm sets out to clean up the
legacy code in anything.el and provide a cleaner, leaner and more
modular tool, that's not tied in the trap of backward compatibility.

I intend to maintain this as part of the pkg-emacsen team.

Bug#810288: ITP: perspective-el -- tagged workspaces in Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: perspective-el
  Version : 1.12
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/nex3/perspective-el
* License : GPL-3
  Programming Lang: Emacs Lisp
  Description : tagged workspaces in Emacs

A popular Emacs Lisp extension.  Upstream description:

This package provides tagged workspaces in Emacs, similar to
workspaces in windows managers such as Awesome and XMonad (and
somewhat similar to multiple desktops in Gnome or Spaces in OS X).

perspective.el provides multiple workspaces (or "perspectives") for
each Emacs frame. This makes it easy to work on many separate projects
without getting lost in all the buffers.

Each perspective is composed of a window configuration and a set of
buffers. Switching to a perspective activates its window
configuration, and when in a perspective only its buffers are
available by default.

I intend to maintain this as part of the pkg-emacsen team.

Re: Re: Hardware detection

[Stephan Foley]

Hello and thank you for this in depth answer!

On 2016-01-07, Stefan Lippers-Hollmann wrote:

As someone working on Debian derived live systems since the earlier
kernel 2.4 days, I wonder why you think to need any of those on a
modern linux system at all?


I am probably reading old references.

I read through your reply twice. Just to clarify, a major part of the
project is targeting thin clients and older hardware. Project will most
commonly be an install and not a live cd.


linux >= 2.6, udev and kmod do a great job to probe all
auto-discoverable devices on their own. The things they miss either
can't be detected automatically or at least not in a safe way.


So I will drop the hardware discovery packages.


You haven't really revealed if the target of your pure blend is an
installed system or a live environment (the wiki page and your mail
slightly tend towards a live system, but neither provide a definitive
answer), but in neither case it should be much of a concern how to
detect hardware (as that's either solved by d-i or your live framework
in a desktop/ WM agnostic way) for you as blend maintainer. If you do,
you're quickly leaving the pure-blend domain and venture into the
derivatives land[3].


This really struck a cord...the issue of not leaving the pure-blend domain.
I will keep this in mind.


You'll probably find an audience with more specific knowledge in these
particular areas on the debian-derivati...@lists.debian.org and
debian-l...@lists.debian.org lists.


I will note mailing lists for future reference.

Thanks again. I will need to go through your reply a couple of times to
catch the subtleties. It's a great reference and I appreciate you
taking the time to write it all out.

Steve

Bug#810290: ITP: mediawiki -- website engine for collaborative work

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: mediawiki
  Version : 1.25.5
  Upstream Author : MediaWiki developers 
* URL : https://www.mediawiki.org/
* License : GPL-2.0+
  Programming Lang: PHP
  Description : website engine for collaborative work

MediaWiki is a wiki engine (a program for creating a collaboratively
edited website). It is designed to handle heavy websites containing
library-like document collections, and supports user uploads of
images/sounds, multilingual content, TOC autogeneration, ISBN links,
etc.

Moreover, it keeps track of changes, so users can receive
notifications, view diffs and revert edits. This system has many
other features and can easily be extended.

This package was formerly in Debian and removed due to a lack of active
maintainers and updates. I am an active upstream developer who uses
the software.

Work-needing packages report for Jan 8, 2016

[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: 702 (new: 7)
Total number of packages offered up for adoption: 170 (new: 1)
Total number of packages requested help for: 49 (new: 0)

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



The following packages have been orphaned:

   apache-mod-auth-ntlm-winbind (#810285), orphaned today
 Installations reported by Popcon: 65

   exrtools (#810273), orphaned today
 Description: A collection of utilities for manipulating OpenEXR
   images
 Installations reported by Popcon: 140

   icicles (#809641), orphaned 5 days ago
 Description: emacs library that enhances minibuffer/input completion
 Installations reported by Popcon: 88

   libf2c2 (#810238), orphaned today
 Description: Shared libraries for use with FORTRAN applications
 Reverse Depends: f2c libf2c2-dev libsimgrid-dev
 Installations reported by Popcon: 1990

   ninja-build (#810025), orphaned 2 days ago
 Reverse Depends: meson
 Installations reported by Popcon: 475

   openmpi (#810079), orphaned yesterday
 Description: high performance message passing library -- header
   files
 Reverse Depends: abyss aces3 ampliconnoise blacs-mpi-test
   clustalw-mpi code-aster-mpi-engine code-saturne-bin
   coop-computing-tools cp2k elk-lapw (140 more omitted)
 Installations reported by Popcon: 8396

   ratfor (#810239), orphaned today
 Description: Rational Fortran preprocessor for Fortran 77
 Installations reported by Popcon: 72

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



The following packages have been given up for adoption:

   neotoma (#809925), offered 3 days ago
 Description: parser generator for Erlang
 Installations reported by Popcon: 1

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



For the following packages help is requested:

   apt-xapian-index (#567955), requested 2166 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: goplay muon muon-discover packagesearch
 Installations reported by Popcon: 44579

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

   awstats (#755797), requested 533 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4130

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

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

   cups (#532097), requested 2406 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 157847

   cyrus-sasl2 (#799864), requested 106 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw
   adcli autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper (125 more
   omitted)
 Installations reported by Popcon: 181276

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

   developers-reference (#759995), requested 495 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 17746

   devscripts (#800413), requested 100 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (27 more
   omitted)
 Installations reported by Popcon: 12823

   ejabberd (#767874), requested 430 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-mam-mnesia ejabberd-mod-message-log
   ejabberd-mod-muc-

Re: Hardware detection

[Daniel Reurich]

On 08/01/16 11:15, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2016-01-07, Stephan Foley wrote:
>> Hello, I am working on a Fluxbox Debian Pure Blend:
>>
>> https://wiki.debian.org/FluxBox/Blend
>>
>> Currently, I am going to use discover, mdetect and read-edid for
>> hardware discovery but found in the repos hwinfo which is used by
>> Debian Edu and was wondering if this is a better tool. Description
>> follows:
> [...]
> 
> As someone working on Debian derived live systems since the earlier
> kernel 2.4 days, I wonder why you think to need any of those on a 
> modern linux system at all?
>
One example: For the work I'm doing in Devuan for our desktop-base I
want to detect the display resolution & aspect ratio regardless of X so
we can install the best background theme images for grub, desktop
backgrounds for xfce and the display manager's login screen.  I've found
that this information is available via sysfs so no biggie really.


> linux >= 2.6, udev and kmod do a great job to probe all 
> auto-discoverable devices on their own. The things they miss either 
> can't be detected automatically or at least not in a safe way. Neither
> of which are typically found on systems supported by Debian systems
> whose primary purpose is running/ showcasing/ using a window manager.
> The i586/ i686 cutoff mostly prevents you from having to discover 
> ISA devices or even weirder legacy system buses - and on embedded 
> architectures with SDIO, similar non-discoverable buses and board 
> specific boot procedures, you have bigger problems (e.g. getting FOSS 
> display driver support) than anything discover/ mdetect/ hwinfo can 
> help you with.
> 
> Regarding read-edid, why?! X.org does a pretty good job detecting your
> screen

You can use capture the display configuration by looking /sys/class/drm/
for card*--/ and check the status file and
enabled file to find the currently connected and enabled displays.  Then
you can grep the modes file for those display's resolutions.  (For extra
info on the display, you can parse the edid file with parse-edid from
the readedid package as well)  As far as I can tell the displays
Native|best resolution in the modes file is always the first line.




-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Paul Wise]

On Fri, Jan 8, 2016 at 7:16 AM, Simon McVittie wrote:

> I really don't think that's a good approach, particularly as a default.
> We already have tools to make a minimal bootable environment that can
> mount /usr and do some limited recovery, and the result is called an
> initramfs. If you want a lighter-weight initramfs for environments where
> those generated by initramfs-tools or dracut are overkill, Christian
> Seiler has a nice proof-of-concept elsewhere in the thread, which
> apparently compiles to less than 16K.

The idea was for those who don't want an initramfs or can't use an
initramfs (someone mentioned some Debian platforms can't) but still
want /usr on a separate partition. Essentially it is what the Unix
people should have done back in the day instead of hardcoding the
contents of /bin /sbin /lib.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Marco d'Itri]

On Jan 08, Paul Wise  wrote:

> The idea was for those who don't want an initramfs or can't use an
> initramfs (someone mentioned some Debian platforms can't) but still
All platforms can use an initramfs.
It has been said that some have[citation needed] crappy boot loaders 
that do not support loading an initramfs, but you can still embed one in 
the kernel binary if you are building your own kernel anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#810304: ITP: stratagus -- Stratagus is a free cross-platform real-time strategy gaming engine.

[Alexandre Detiste]

Package: wnpp
Severity: wishlist
Owner: Alexandre Detiste 

* Package name: stratagus
  Version : 2.4.0
  Upstream Author : Stratagus Team
* URL : https://github.com/Wargus/
* License : GPL
  Programming Lang: C++ & Lua
  Description : Stratagus is a free cross-platform real-time strategy
gaming engine.

Stratagus is a fork of the Freecraft engine.

This generic engine that can be used to play 'wargus'
(Warcraft II or WCII-like "Aleonas Tales")
or 'stargus' (StarCraft) games.

Only wargus is in a good shape, it will be addressed in a other ITP.

Stratagus was once in Debian, but got removed years ago when Freecraft
was deemed in a better shape; nowadays "Freecraft" name seems to have
vanished from the surface of the earth and only links to minecraft-y stuff.

Thanks to the renewal of interrest brought by Stratagus's fork Wyrmsun;
development is lively again with a third of four completely different team
and long standing bugs have been fixed.



I plan to first continue to fix the upstream-provided debian/
directory with help from other Debian-using contributors
& then upload it to Debian inside the Games Team.

Re: support for merged /usr in Debian

[Svante Signell]

On Thu, 2016-01-07 at 22:46 +0100, Philip Hands wrote:
> Marc Haber  writes:
> 
> > On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
> > > On Jan 05, Ian Jackson  wrote:
> > > 
> > > > People who have been using a configuration for many years naturally
> > > > become upset when they are told that it has been `unsupported' for all
> > > > of this time and that, implicitly, changes are going to be made which
> > > > will break it.
> > > I think that your summary is correct, and I am quite sure that it would 
> > > be a bad engineering practice to make technical decisions based on 
> > > people's emotions.
> > 
> > Unfortunately, it's emotions that take vendor decisions. Your attitude
> > is driving big users towards the paid-for Enterprise Linuxes, be it
> > logical or not, be it good engineering or not.
> 
> Even if that were true, I fail to understand why we should be worried.

The problem is that with Debian heading down this road, the Debian GNU/Linux
distribution will not exist in 5 years from now. You will make yourselves
extinct due to the competition from commercial alternatives. And it will
definitely not foster new Free Software opportunities. This makes me very sad,
but that maybe is a natural evolution.

Re: support for merged /usr in Debian

[Marc Haber]

On Thu, 07 Jan 2016 14:48:56 -0800, Russ Allbery 
wrote:
>Marc Haber  writes:
>> Unfortunately, it's emotions that take vendor decisions. Your attitude
>> is driving big users towards the paid-for Enterprise Linuxes, be it
>> logical or not, be it good engineering or not.
>
>...the ones that have already merged /usr and /?

Yes. Those decisions are often taken for non-technical reasons, such
as availability or friendlyness of support and communities.

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