Question about having an always clean base system in Debian Sid
Hi all! I'm new on the list so I hope my question is not stupid and I'm asking it in the good list. I have Sid installed on my computer and I would like to know how to keep my base system (~prequired, ~pimportant, ~pstandard) always clean and up to date automatically: if package A is no longer needed it should be removed automatically and if package B is new and with one of the 3 priority above it should be installed automatically. For the autoremove problem I found a solution: I put all ~prequired, ~pimportant, ~pstandard packages in "automatically installed" state and put "~prequired, ~pimportant, ~pstandard" in the APT::NeverAutoRemove directive of the apt.conf file. In this case every package that is repacked with a new priority not in the 3 above will be automatically removed unless there is a dependence on it. For the autoinstall problem I didn't face the situation yet but I don't know how I'll do. I also would like to have it working similarly for the tasks: for example if I have a task "Mail server" installed depending on Sendmail and that the new version of this task now depends on Postfix, I would like Sendmail to be automatically removed and Postfix to be automatically installed. The technique above doesn't work for the tasks. Do you have any idea? Is the technique I used bad and dirty? Thanks in advance. Geek87 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about having an always clean base system in Debian Sid
On Wednesday 27 January 2010, Geek87 wrote: > I also would like to have it working similarly for the tasks: for > example if I have a task "Mail server" installed depending on Sendmail > and that the new version of this task now depends on Postfix, I would > like Sendmail to be automatically removed and Postfix to be > automatically installed. The technique above doesn't work for the tasks. I don't think that's possible as the package management system does not keep any state information about which tasks are installed. You have to see tasks and tasksel as an optional convenience feature, not as something that's a part of the core package management (unlike for example meta packages). Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Status of netcfg-static
Hello,
I am wondering what netcfg-static is good for. Looks like it is an (outdated)
subset of the more generic netcfg. Unfortunately, even the common code of the
two programs seem to have diverged over time (no wonder, duplicated code
almost always suffers from this disease).
Given that the netcfg/disable_dhcp option exists, is netcfg-static really
needed?
BTW: anybody sees how the GET_STATIC state in netcfg.c is supposed to work:
case GET_STATIC:
{
int ret;
/* Misnomer - this should actually take care of activation */
if ((ret = netcfg_get_static(client)) == 10)
state = GET_INTERFACE;
else if (ret)
state = GET_METHOD;
else
state = QUIT;
break;
}
AFAICS, netcfg_get_static() never returns anything other than 0 or 10. So
the GET_METHOD state would never be set.
Here is a first attempt to bring those two programs in sync again. There are
more differences (especially in the GET_INTERFACE state), but I have not done
a closer look at them yet.
diff --git a/netcfg-static.c b/netcfg-static.c
index 1cd2799..3b9faca 100644
--- a/netcfg-static.c
+++ b/netcfg-static.c
@@ -1,7 +1,9 @@
/*
- netcfg-static.c - Configure a static network for the debian-installer
+ netcfg-static.c - Configure a static network
+ for the debian-installer
Copyright (C) 2000-2002 David Kimdon
+and others (see debian/copyright)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -18,6 +20,7 @@
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+
#include
#include
#include
@@ -27,13 +30,20 @@
#include
#include "netcfg.h"
-int main(int argc, char** argv)
+int main(int argc, char *argv[])
{
int num_interfaces = 0;
static struct debconfclient *client;
static int requested_wireless_tools = 0;
-enum { BACKUP, GET_INTERFACE, GET_HOSTNAME_ONLY, GET_STATIC, WCONFIG,
WCONFIG_ESSID, WCONFIG_WEP, QUIT} state = GET_INTERFACE;
+enum { BACKUP,
+ GET_INTERFACE,
+ GET_HOSTNAME_ONLY,
+ GET_STATIC,
+ WCONFIG,
+ WCONFIG_ESSID,
+ WCONFIG_WEP,
+ QUIT } state = GET_INTERFACE;
/* initialize libd-i */
di_system_init("netcfg-static");
@@ -46,7 +56,20 @@ int main(int argc, char** argv)
client = debconfclient_new();
debconf_capb(client, "backup");
-while (1) {
+/* Check to see if netcfg should be run at all */
+debconf_get(client, "netcfg/enable");
+if (!strcmp(client->value, "false")) {
+struct in_addr null_ipaddress;
+char *hostname = NULL;
+
+null_ipaddress.s_addr = 0;
+netcfg_get_hostname(client, "netcfg/get_hostname", &hostname, 0);
+
+netcfg_write_common(null_ipaddress, hostname, NULL);
+return 0;
+}
+
+for (;;) {
switch(state) {
case BACKUP:
return 10;
@@ -81,21 +104,21 @@ int main(int argc, char** argv)
case WCONFIG:
if (requested_wireless_tools == 0) {
+di_exec_shell_log("apt-install wireless-tools");
requested_wireless_tools = 1;
-di_exec_shell("apt-install wireless-tools");
}
state = WCONFIG_ESSID;
break;
case WCONFIG_ESSID:
-if (netcfg_wireless_set_essid (client, interface, NULL))
+if (netcfg_wireless_set_essid(client, interface, NULL) == GO_BACK)
state = BACKUP;
else
state = WCONFIG_WEP;
break;
case WCONFIG_WEP:
-if (netcfg_wireless_set_wep (client, interface))
+if (netcfg_wireless_set_wep(client, interface) == GO_BACK)
state = WCONFIG_ESSID;
else
state = GET_STATIC;
diff --git a/netcfg.c b/netcfg.c
index 16823c1..9834f63 100644
--- a/netcfg.c
+++ b/netcfg.c
@@ -1,6 +1,6 @@
/*
netcfg.c - Configure a network via DHCP or manual configuration
- for debian-installer
+ for the debian-installer
Copyright (C) 2000-2002 David Kimdon
and others (see debian/copyright)
@@ -18,7 +18,7 @@
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
-
+
*/
#include
@@ -61,6 +61,12 @@ response_t netcfg_get_method(struct debconfclient *client)
int main(int argc, char *argv[])
{
int num_interfaces = 0;
+static struct debconfclient *client;
+static int requested_wireless_tools = 0;
+char **ifaces;
+char *defiface
Re: Status of netcfg-static
On Wednesday 27 January 2010, Josef Wolf wrote:
> I am wondering what netcfg-static is good for. Looks like it is an
> (outdated) subset of the more generic netcfg.
No. It's used for s390:
installer/build/pkg-lists/netboot/s390.cfg:1:netcfg-static
installer/build/pkg-lists/generic/s390.cfg:3:netcfg-static
> Unfortunately, even the
> common code of the two programs seem to have diverged over time (no
> wonder, duplicated code almost always suffers from this disease).
>
> Given that the netcfg/disable_dhcp option exists, is netcfg-static
> really needed?
Yes.
> BTW: anybody sees how the GET_STATIC state in netcfg.c is supposed to
> work:
I would need to look into that.
> Here is a first attempt to bring those two programs in sync again. There
> are more differences (especially in the GET_INTERFACE state), but I have
> not done a closer look at them yet.
> -enum { BACKUP, GET_INTERFACE, GET_HOSTNAME_ONLY, GET_STATIC,
> WCONFIG, WCONFIG_ESSID, WCONFIG_WEP, QUIT} state = GET_INTERFACE; +
> enum { BACKUP,
> + GET_INTERFACE,
> + GET_HOSTNAME_ONLY,
> + GET_STATIC,
> + WCONFIG,
> + WCONFIG_ESSID,
> + WCONFIG_WEP,
> + QUIT } state = GET_INTERFACE;
Wireless is useless for s390 (and static network config is almost per
definition not suitable for wireless), so the wireless bits should not be
synced.
> -while (1) {
> +/* Check to see if netcfg should be run at all */
[...]
On s390 network configuration is required.
> netcfg.c - Configure a network via DHCP or manual configuration
> - for debian-installer
> + for the debian-installer
This is incorrect.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wed, Jan 27, 2010 at 03:13:58PM +0100, Josef Wolf wrote: > I am wondering what netcfg-static is good for. It is used for s390. > Given that the netcfg/disable_dhcp option exists, is netcfg-static really > needed? In the meantime this is correct. DHCP can be used on s390 with some constraints, but it needs to be disabled by default. Bastian -- The man on tops walks a lonely street; the "chain" of command is often a noose. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wednesday 27 January 2010, Bastian Blank wrote: > In the meantime this is correct. DHCP can be used on s390 with some > constraints, but it needs to be disabled by default. Is it useful in practice though? I rather doubt anyone would want to set up an s390 box using DHCP. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wed, Jan 27, 2010 at 04:42:15PM +0100, Frans Pop wrote: > On Wednesday 27 January 2010, Bastian Blank wrote: > > In the meantime this is correct. DHCP can be used on s390 with some > > constraints, but it needs to be disabled by default. > Is it useful in practice though? I rather doubt anyone would want to set up > an s390 box using DHCP. Not sure. Bastian -- Power is danger. -- The Centurion, "Balance of Terror", stardate 1709.2 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
unused and removable partman templates
AFAICS, the following templates are all not used anywhere: partman-jfs/check_failed partman-reiserfs/check_failed partman-ext3/check_failed partman-ext2r0/check_failed partman-xfs/check_failed Meanwhile, partman-basicfilesystems/check_failed is generic template that could take the place of any of those if there were later needed. Similarly, there are generic partman-basicfilesystems/progress_checking, create_failed, specify_mountpoint, no_mount_point, and these are unused: partman-jfs/progress_checking partman-reiserfs/progress_checking partman-ext3/progress_checking partman-ext3/create_failed While these are used but could be switched to use the generic templates easily: partman-ext2r0/progress_checking partman-jfs/create_failed partman-reiserfs/create_failed partman-ext2r0/create_failed partman-xfs/create_failed partman-*/no_mount_point partman-*/specify_mountpoint My partman may be rusty, would appreciate a double-check. -- see shy jo signature.asc Description: Digital signature
Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
Source: gcc-4.4
Version: 1:4.4.3-1
Severity: wishlist
Tags: d-i patch
X-Debbugs-CC: debian-boot@lists.debian.org
Please consider the attached patch which adds a udeb for libgcc1 containing
only libgcc_s.so.1. That file is needed for the (directfb based) graphical
installer because of pthread_cancel(). See #373253 for background.
Until now we've been copying libgcc_s.so.1 from the host system at build
time, but it would be much cleaner to install it from a udeb.
I've tested the patch on amd64 and it creates the udeb correctly.
Please review the patch carefully as there may be aspects that I've missed
in the complexity of the build system or arch-specific considerations.
The file/udeb is currently only needed for amd64, i386 and powerpc, but it
seems most logical to just build the udeb for all architectures.
From my test build:
$ debc libgcc1-udeb_4.4.3-2~fjp_amd64.udeb
libgcc1-udeb_4.4.3-2~fjp_amd64.udeb
---
new debian package, version 2.0.
size 43198 bytes: control archive= 330 bytes.
277 bytes,10 lines control
Package: libgcc1-udeb
Source: gcc-4.4 (4.4.3-2~fjp)
Version: 1:4.4.3-2~fjp
Architecture: amd64
Maintainer: Debian GCC Maintainers
Installed-Size: 104
Depends: libc6-udeb (>= 2.10)
Section: debian-installer
Priority: extra
Description: GCC support library
drwxr-xr-x root/root 0 2010-01-27 20:19 ./
drwxr-xr-x root/root 0 2010-01-27 20:19 ./lib/
-rw-r--r-- root/root 90040 2010-01-27 20:19 ./lib/libgcc_s.so.1
diff -u gcc-4.4-4.4.3/debian/control.m4 gcc-4.4-4.4.3/debian/control.m4
--- gcc-4.4-4.4.3/debian/control.m4
+++ gcc-4.4-4.4.3/debian/control.m4
@@ -188,6 +188,14 @@
environment.
')`'dnl
+Package: libgcc1-udeb`'LS
+XC-Package-Type: udeb
+Architecture: ifdef(`TARGET',`all',`any')
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library`'ifdef(`TARGET)',` (TARGET)', `')
+
Package: libgcc2`'LS
Architecture: ifdef(`TARGET',`all',`m68k')
Section: ifdef(`TARGET',`devel',`libs')
diff -u gcc-4.4-4.4.3/debian/control gcc-4.4-4.4.3/debian/control
--- gcc-4.4-4.4.3/debian/control
+++ gcc-4.4-4.4.3/debian/control
@@ -36,6 +36,14 @@
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
+Package: libgcc1-udeb
+XC-Package-Type: udeb
+Architecture: any
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: libgcc2
Architecture: m68k
Section: libs
diff -u gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
--- gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
+++ gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
@@ -14,8 +14,10 @@
p_lgcc = libgcc$(GCC_SONAME)
p_lgccdbg = libgcc$(GCC_SONAME)-dbg
+p_lgccudeb = libgcc$(GCC_SONAME)-udeb
d_lgcc = debian/$(p_lgcc)
d_lgccdbg = debian/$(p_lgccdbg)
+d_lgccudeb = debian/$(p_lgccudeb)
p_l32gcc = lib32gcc$(GCC_SONAME)
p_l32gccdbg = lib32gcc$(GCC_SONAME)-dbg
@@ -42,7 +44,10 @@
dh_installdirs -p$(p_lgcc) \
$(docdir)/$(p_lgcc) \
$(libdir)
-
+ dh_installdirs -p$(p_lgccudeb) \
+ $(libdir)
+
+ cp $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgccudeb)/$(libdir)/.
ifeq ($(with_shared_libgcc),yes)
mv $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgcc)/$(libdir)/.
endif
@@ -57,8 +62,9 @@
debian/dh_rmemptydirs -p$(p_lgcc)
debian/dh_rmemptydirs -p$(p_lgccdbg)
dh_strip -v -p$(p_lgcc) --dbg-package=$(p_lgccdbg)
- dh_compress -p$(p_lgcc) -p$(p_lgccdbg)
- dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_strip -v -p$(p_lgccudeb)
+ dh_compress -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
ifeq ($(with_shared_libgcc),yes)
dh_makeshlibs -p$(p_lgcc) -V '$(p_lgcc) (>= $(DEB_LIBGCC_SOVERSION))' \
-- -v$(DEB_LIBGCC_VERSION)
@@ -68,17 +74,17 @@
endif
cat debian/$(p_lgcc)/DEBIAN/shlibs >> debian/shlibs.local
endif
- dh_shlibdeps -p$(p_lgcc)
- dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) \
+ dh_shlibdeps -p$(p_lgcc) -p$(p_lgccudeb)
+ dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb) \
-- -v$(DEB_LIBGCC_VERSION) $(common_substvars)
mkdir -p $(d_lgcc)/usr/share/lintian/overrides
echo '$(p_lgcc): package-name-doesnt-match-sonames' \
> $(d_lgcc)/usr/share/lintian/overrides/$(p_lgcc)
- dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg)
- dh_md5sums -p$(p_lgcc) -p$(p_lgccdbg)
- dh_builddeb -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_md5sums -p$(p_lgcc) -p$(p_lgccudeb)
+ dh_builddeb -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
trap '' 1 2 3 15; touch $@; mv $(install_stamp)-tmp $(install_stamp)
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
-- Forwarded Message -- From: Matthias Klose On 27.01.2010 21:03, Frans Pop wrote: > Please consider the attached patch which adds a udeb for libgcc1 > containing only libgcc_s.so.1. That file is needed for the (directfb > based) graphical installer because of pthread_cancel(). The patch itself looks ok, some other questions: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? This way you don't need to copy the file, and you don't need to add additional constraints for freezes on the gcc-4.4 package. You could even copy the whole packaging and conditionalize on the source package name for this new source package to minimize the maintainance effort and get the updates/patches. With --enable-languages=c --disable-bootstrap, the additional build time penalty is the extra build of a one stage compiler for gcc. - you don't need the package for m68k/hppa yet, but if you do build for every architecture anyway, please don't build the package for these archs, but libgcc2, libgcc4, and libgcc6 udebs. - the patch should be prepared for gcc-4.5 as well. If there are additional constraints for uploads of the gcc-4.4 source package during freeze times, I would prefer the approach to build the udeb's from a separate source. Matthias --- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
Thanks a lot for the quick reply. On Wednesday 27 January 2010, Matthias Klose wrote: > The patch itself looks ok, some other questions: > > - did you consider building the udeb from a separate source package, > build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. > - you don't need the package for m68k/hppa yet, but if you do build > for every architecture anyway, please don't build the package for > these archs, but libgcc2, libgcc4, and libgcc6 udebs. For my current patch that would mean also adding those udebs in the control.m4 file, correct? And to avoid needing to code exceptions in rules.d/binary-libgcc.mk it's probably simplest to just do that even if we don't use them. > - the patch should be prepared for gcc-4.5 as well. Will do if we decide on keeping it in gcc. > If there are additional constraints for uploads of the gcc-4.4 source > package during freeze times, I would prefer the approach to build the > udeb's from a separate source. No, given how the udeb will be used there are no additional restrictions. And now that migration to testing of udebs is supported in britney, there's also no longer any inconvenience there. (That was an important consideration why I've personally not pushed for this change in the past.) The only point for attention is that if gcc would get uploaded after the final upload of D-I for a release, FTP-masters will need to keep a copy of the version included in that D-I build [1]. But that's something that already also done for other packages and is an item for the D-I and Debian release managers, not for the gcc maintainers. Because of the above I think building the udeb from gcc is the most logical choice. Cheers, FJP [1] They create a special suite for that purpose. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Spam cleaning in list archives: one last effort needed
Christian Perrier wrote: > The remaining months, that should be targeted by anybody but > me, Frans Pop, Holger Wansing and Lee Winter, are: > * March 1999 to May 2000 > * October 2000 to July 2002 > * May and June 2004 I just see that as of yesterday the whole archive has now been scanned by at least 5 persons. Yay! The honor of filling in the last bits goes to Nicolas Bertolissio for bringing 2001/04-09 to 5 scans. It's also nice to see that quite a few months have had 6 or even 7 scans, which reduces the risk of spams being left over because one person missed it. Because of that such additional scans are quite nice, but not a must. Of course, from now on scanning a month should be rather boring as you should encounter only very few spams. Maybe an opportunity pick a few threads and read up on the history of the project instead ;-) My thanks (as the person who kicked of this little - or not so little - project) to everybody who's contributed to the cleanup. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Build failures for hd-media
Since 2 or 3 days, I'm having build failures on my local daily build for i386. They are restricted to hd-media target only: .../... rm -rf ./tmp/hd-media/syslinux/* mkdir -p ./tmp/hd-media/syslinux TYPE=standard INCLUDE_GTK= DESKTOP= \ syslinux-cfgs boot/x86 ./tmp/hd-media/syslinux mkfs.msdos -i deb1 -n "Debian Inst" -C ./tmp/hd-media/boot.img 244736 mkfs.msdos 3.0.8 (23 Jan 2010) # syslinux is used to make the image bootable syslinux ./tmp/hd-media/boot.img mcopy -i./tmp/hd-media/boot.img ./tmp/hd-media/vmlinuz ::linux Cannot initialize '::' Bad target ::linux make[2]: *** [arch_boot] Error 1 make[1]: *** [_build] Error 2 make: *** [build_hd-media] Error 2 I can of course provide the full build log if that's not enough. -- signature.asc Description: Digital signature
