FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-30-2011, 05:51 PM
Michael Biebl
 
Default Bits from the Release Team - Kicking off Wheezy

Am 30.03.2011 19:38, schrieb Josselin Mouette:
> Le mercredi 30 mars 2011 * 19:21 +0200, Luk Claes a écrit :
>> # remove obsolete libraries
>> Advocate: Barry deFreese and Luk Claes
>> State: confirmed
>> Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
>>
>> This worked quite well and should continue so we can get rid of obsolete
>> libraries IMHO. One of the main candidates are the old db libraries,
>> though there are also still some old gnome libraries and without doubt
>> others.
>
> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs,

HAL removal is already in progress, see [1]. Actually I've been working on that
for some time already. I wouldn't object obviously making that a release goal.

It seems certainly doable in time for wheezy. The only real blocker I currently
see, is our kfreebsd ports, which still rely on hal e.g. in GVFS, which is a
central part of the GNOME stack.

Michael


[1] http://wiki.debian.org/HALRemoval


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 03-30-2011, 06:11 PM
Michael Biebl
 
Default Bits from the Release Team - Kicking off Wheezy

Am 30.03.2011 19:21, schrieb Luk Claes:
> Regarding reliability I'm doing some work regarding NFS, though one of
> the main outstanding issues is the race between availability of the
> network devices and the end of the network init script AFAICS. It would
> also not be a bad idea to have a discussion on whether the default init
> system should change to one that is more suitable to guarantee the
> reliability of the boot like upstart or systemd.
>

...

> I would welcome a review of essential, required and standard though I
> don't know if many would welcome such an initiative which could
> potentially have quite some impact without much visible gain. Anyway
> it's something which should happen in the beginning of the cycle (after
> a discussion with both the involved maintainers as well as the
> developers body at large) or not at all IMHO.

One of the steps required to make it possible to test alternative init systems
(on a wider scale) is to get the Essential flag removed from sysvinit (and
possibly initscripts), so systemd and upstart can be installed without force.
This has been on my wishlist for squeeze and we should definitely get the
necessary changes into wheezy as early as possible during the development cycle.
Dunno if this warrants a separate release goal though.


Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 03-30-2011, 06:19 PM
 
Default Bits from the Release Team - Kicking off Wheezy

On Mar 30, Luk Claes <luk@debian.org> wrote:

> For the IPv6 and LFS legacy release goals I think it would be best if we
> would welcome massive (automatic?) tests to find all of the outstanding
> issues and get them fixed finally!
I fear that the major outstanding issue is ifupdown, which basically
does not support non-trivial dual stacked configurations and needs a
serious redesign.
e.g. vlan/bridging if-*.d scripts are run for every AFI.

--
ciao,
Marco
 
Old 03-30-2011, 06:23 PM
Christian PERRIER
 
Default Bits from the Release Team - Kicking off Wheezy

Quoting Josselin Mouette (joss@debian.org):

> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs, which are
> big things. Along the way I’d like to get rid of the least used GTK2
> libraries in favor of their GTK3 counterpart.

How about dropping defoma ?

The pkg-fonts team did that on fonts we maintain, but there are many
other fonts packages (some of them somehow abandoned or loosely
maintained) that need to do it.
 
Old 03-30-2011, 07:09 PM
Roger Leigh
 
Default Bits from the Release Team - Kicking off Wheezy

On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
> Release Goals
> -------------
> As a first step towards establishing release goals for wheezy, we will
> be reviewing each of the goals which we had for squeeze [RDO:SGoals] to
> see which have been achieved and which may no longer be relevant for
> other reasons.

Here's a list of things I'd like to see in squeeze, though I probably
won't have time to push them all myself:

• C.UTF-8 provided by default, to provide a guaranteed present
standard C locale (#609306). Looks like this is now in eglibc
(2.13-0exp3) in experimental, so the main remaining task is to
convert existing packages (lintian etc.) which currently generate
their own locales and/or use other locales to use C.UTF-8.
Thanks to Aurelien Jarno for pushing this.

As a followup, I would like to get the UTF-8 codeset and collation
hardcoded in libc6 directly and sharable by all UTF-8 locales to
reduce startup time and needless duplication (due to using a separate
codeset facet for each locale loaded). This would allow the
subsequent creation of a real "C" locale using a UTF-8 codeset.
Needs some digging into the eglibc locale code though.

• /run (as being currently discussed)

Easy enough to add the top-level directory. We do however need to
cope with handling upgrades, compatibility bind mounts and/or
symlinks etc. I've been working on an initscripts patch to handle
this, but it will need wider discussion and testing. Given the
historical usage of /var/run and /var/lock, we will need to keep
compatibility links in place for the foreseable future, if not
indefinitely, plus compatibility /lib/init/rw link to allow for
squeeze upgrades.

• dpkg-buildpackage support for build-arch and build-indep by default

AFAICT requires a mechanism to autodetect the presence of the targets
in the rules file to allow their use if present, falling back to the
build target if absent.

This is a long standing deficiency in our toolchain, which is
preventing correct support for Build-Depends-Indep/
Build-Conflicts-Indep in autobuilding, since the build target may or
may not require Build-Depends-Indep when doing binary-only builds
(and vice versa). Having the correct separation will permit sane
and reliable build dependency installation. This will become more
of an issue with arch-all autobuilding.

This is something we've wanted for years, but which has continually
been stalled by issues doing the migration. We've got support for
build-arch and build-indep in cdbs and dh, which makes over 50% of
the archive support them today. Developers can add the targets
today, and add

build: build-arch build-indep

to have their package build with both current and future versions of
the toolchain, with the appropriate bits being doing in each rule.
I've proposed a change to Policy to change this from "may be provided"
to "must" (#604397).

Some previous proposals have called for this to be enabled if >= a
certain Standards-Version is supported, or a flag in Build-Options
is enabled by the package. However, we want build-arch and
build-indep to be used *by default*. The maintainer should not need
to take additional, explict, action in order to have them used. I
therefore think autodetection is the most useful approach.

In the meantime, we should encourage maintainers to pre-emptively
adopt build-arch and build-indep, and could patch lintian to warn
if not present.

• Read-only root

Depends on /run. Having /run will allow remaining writable files
under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
Identifying and fixing/removing packages writing to /etc during
their normal operation would be a worthy release goal.

This will make Debian more secure to run, easier to deploy in a
cluster or netboot environment (no writable image overlay required),
keeping dpkg-managed filesystems completely read-only during normal
operation (other than /var).

• /usr "removal"

We should allow the installation and running of a system with no
/usr (where /usr is a symlink to / for backward compatibility).

Previously discussed on -devel. Initially, this is intended to be
optional, keeping all dpkg-managed files on a single filesystem.
In the future, we would have the option of dropping /usr entirely.

Work needing doing: identification and removal of duplicate paths
under / and /usr. If we want to support this on upgrades as well
as new installs, upgrades need considering here as well. Support
in debian-installer for disabling /usr would also be required.
Also, tools such as dpkg-shlibdeps, ld etc. would need checking
to make sure that building on such a system still results in
packages which are installable on old-style split systems, e.g.
when generating shlibs files etc.


I'm sure I'll have more to come!


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.
 
Old 03-30-2011, 07:45 PM
Michael Tautschnig
 
Default Bits from the Release Team - Kicking off Wheezy

[...]
> • Read-only root
>
> Depends on /run. Having /run will allow remaining writable files
> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
> Identifying and fixing/removing packages writing to /etc during
> their normal operation would be a worthy release goal.
>
> This will make Debian more secure to run, easier to deploy in a
> cluster or netboot environment (no writable image overlay required),
> keeping dpkg-managed filesystems completely read-only during normal
> operation (other than /var).
>
[...]

Here's an obviously incomplete list of such files, from a fairly comprehensive
desktop installation. I've taken these from my integrit configuration for a
lenny (!) system - I'd love not to be in need for such a list of exceptions.

/etc/aumixrc
/etc/mtab
/etc/motd
/etc/adjtime
/etc/resolv.conf
/etc/qt3/qt_plugins_3.3rc
/etc/network/run/ifstate
/etc/hotplug/.run/net.enable
/etc/cups/ppd/
/usr/share/ppd/custom/
/etc/cups/classes.conf
/etc/cups/printers.conf
/etc/cups/printers.conf.O
/etc/cups/cupsd.conf
/etc/printcap
/etc/lvm/cache/.cache
/etc/openvpn/openvpn-status.log
/etc/blkid.tab
/etc/blkid.tab.old
/etc/samba/dhcp.conf
/etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)

Hope this helps,
Michael
 
Old 03-30-2011, 07:50 PM
Ben Hutchings
 
Default Bits from the Release Team - Kicking off Wheezy

On Wed, Mar 30, 2011 at 08:19:52PM +0200, Marco d'Itri wrote:
> On Mar 30, Luk Claes <luk@debian.org> wrote:
>
> > For the IPv6 and LFS legacy release goals I think it would be best if we
> > would welcome massive (automatic?) tests to find all of the outstanding
> > issues and get them fixed finally!
> I fear that the major outstanding issue is ifupdown, which basically
> does not support non-trivial dual stacked configurations and needs a
> serious redesign.
> e.g. vlan/bridging if-*.d scripts are run for every AFI.

I agree that ifupdown is broken, but how is this connected to the
IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
ifconfig...

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110330195016.GV2356@decadent.org.uk">http://lists.debian.org/20110330195016.GV2356@decadent.org.uk
 
Old 03-30-2011, 09:39 PM
Peter Samuelson
 
Default Bits from the Release Team - Kicking off Wheezy

[Roger Leigh]
> As a followup, I would like to get the UTF-8 codeset and collation
> hardcoded in libc6 directly and sharable by all UTF-8 locales to
> reduce startup time and needless duplication

Collation is not just a function of character set, it's quite
locale-dependent. Not sure if the character class tables (<ctype.h>
functions, and the [:foo:] posix regex classes) could be shared across
UTF-8 locales. I rather suspect not.

When you take out collation and possibly character classes, I'm not
sure whether there's anything in the UTF-8 locales left to hardcode
into libc.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110330213930.GA3508@p12n.org">http://lists.debian.org/20110330213930.GA3508@p12n.org
 
Old 03-30-2011, 10:01 PM
 
Default Bits from the Release Team - Kicking off Wheezy

On Mar 30, Ben Hutchings <ben@decadent.org.uk> wrote:

> > > For the IPv6 and LFS legacy release goals I think it would be best if we
> > > would welcome massive (automatic?) tests to find all of the outstanding
> > > issues and get them fixed finally!
> > I fear that the major outstanding issue is ifupdown, which basically
> > does not support non-trivial dual stacked configurations and needs a
> > serious redesign.
> > e.g. vlan/bridging if-*.d scripts are run for every AFI.
> I agree that ifupdown is broken, but how is this connected to the
> IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
> ifconfig...
The problem is with all features implemented by external if-*.d scripts.
If e.g. a bridge is created by the first defined afi, the second script
will fail. And if it does not fail on up then everything will still
break on a down event, when the script run by the first AFI will destroy
the interface and ifupdown will be able to remove the IP address of the
second AFI.
Bugs were opened long ago, but there is no interest/manpower to fix
them (which is not surprising if you have ever looked at the ifupdown
source).

--
ciao,
Marco
 
Old 03-30-2011, 10:02 PM
Goswin von Brederlow
 
Default Bits from the Release Team - Kicking off Wheezy

Michael Tautschnig <mt@debian.org> writes:

> [...]
>> ? Read-only root
>>
>> Depends on /run. Having /run will allow remaining writable files
>> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
>> Identifying and fixing/removing packages writing to /etc during
>> their normal operation would be a worthy release goal.
>>
>> This will make Debian more secure to run, easier to deploy in a
>> cluster or netboot environment (no writable image overlay required),
>> keeping dpkg-managed filesystems completely read-only during normal
>> operation (other than /var).
>>
> [...]
>
> Here's an obviously incomplete list of such files, from a fairly comprehensive
> desktop installation. I've taken these from my integrit configuration for a
> lenny (!) system - I'd love not to be in need for such a list of exceptions.

I'm running a small server with squeeze (some beta but it won't have
become worse) with read-only / instaled that way from DI. Only needed
minimal fixes to work properly. Namely:

> /etc/mtab

link to /proc/mounts (manually)

I think this is going to be the default in the future but for some
reason wasn't added before squeeze froze.

> /etc/motd
> /etc/adjtime
> /etc/resolv.conf

No problems with those three. Network is configured static so dhcp-client
doesn't rewrite resolv.conf. The resolvconf package fixes the
resolv.conf write problem with dhcp-client and read-only /, right?

> /etc/network/run/ifstate

linked to /dev/shm (automatic if /dev/shm exists during install, so
purge + reinstall of ifupdwon fixes this)

Patch to use /lib/init/rw unconditionally on new installs is pending (as
seen on irc today).

> /etc/lvm/cache/.cache

Configurable in /etc/lvm/lvm.conf. If /run is adapted in debian then
changing the default location shouldn't be a problem.

> /etc/blkid.tab
> /etc/blkid.tab.old

hmm, don't have a problem with that. Shouldn't using lvm trigger that?


While read-only / does not (yet) quite work out of the box it is already
easily configurable that way. At least for a simple server.

I think it would be a worthy release goal to have it work out of the box
and even have a read-only / as a default template in Debian-Installer.

Other than the above one additional config is verry usefull:

$ cat /etc/apt/apt.conf.d/00read-only
DPkg {
// Auto re-mounting of a readonly /usr
Pre-Invoke { "mount -o remount,rw /"; };
Pre-Invoke { "mount -o remount,rw /usr"; };
Post-Invoke { "mount -o remount,ro /usr || true"; };
Post-Invoke { "mount -o remount,ro / || true"; };
};


> /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)

Don't have that. Fix denyhosts to link that to /var/ (or /run when we
have it).

> Hope this helps,
> Michael

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3l8s1w7.fsf@frosties.localnet">http://lists.debian.org/87d3l8s1w7.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 09:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org