Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
For all the problems OdyX mentioned from testing, I've found a single cause and filed bug #705435. I've updated this page to demonstrate a functioning GNOME desktop on GNU/kFreeBSD: https://wiki.debian.org/Debian_GNU/kFreeBSD_Desktop#Wheezy_GNOME On 15/04/13 05:53, Christian PERRIER wrote: > I was balanced about working in tasksel to upload with the simple > "move to Recommends" fix but a brief discussion on IRC discouraged me. For something as important as dropping a desktop environment from the release, I'd like to have seen discussion take place with debian-bsd@ copied in; this came as just a bit of a surprise. > I think that nobody is prevented to fix the issue but I would ask > fixing it *and* dealing with things in tasksel's git, not just with an > NMU. Of course, someone else could NMU this and I'll help however I can, but... > And, well, doesn't this issue really fit the definition of > "important"? If the severity of this is downgraded, that as an incentive for this to be missed out of any NMU or refused an unblock. I felt certain this was an RC bug and/or policy violation. A package, a task, a whole desktop environment became uninstallable on two release architectures. We still have a tasksel option for GNOME (fails with apt error 100 due to this) and CD's are being built with its packages. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516bd05f.7010...@pyro.eu.org
Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
Steven Chamberlain (15/04/2013): > For all the problems OdyX mentioned from testing, I've found a single > cause and filed bug #705435. I've updated this page to demonstrate a > functioning GNOME desktop on GNU/kFreeBSD: > https://wiki.debian.org/Debian_GNU/kFreeBSD_Desktop#Wheezy_GNOME > > On 15/04/13 05:53, Christian PERRIER wrote: > > I was balanced about working in tasksel to upload with the simple > > "move to Recommends" fix but a brief discussion on IRC discouraged me. > > For something as important as dropping a desktop environment from the > release, I'd like to have seen discussion take place with debian-bsd@ > copied in; this came as just a bit of a surprise. The feedback I got to my mail to -bsd@ didn't sound like Gnome was actually usable, and that Xfce was a bad choice. And last I checked, not touching things when unsure is what we do at this very late stage of the freeze. > > And, well, doesn't this issue really fit the definition of > > "important"? > > If the severity of this is downgraded, that as an incentive for this to > be missed out of any NMU or refused an unblock. > > I felt certain this was an RC bug and/or policy violation. A package, a > task, a whole desktop environment became uninstallable on two release > architectures. We still have a tasksel option for GNOME (fails with apt > error 100 due to this) and CD's are being built with its packages. If you GNU/kFreeBSD folks want Gnome to be installable again, then fine. But you should have made it clear when I asked. I thought I made it clear I needed feedback, and I wrote “*right now*”. For unrelated reasons, d-i will need a new upload, so I can update tasksel today as well, before rc2 images get built again. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
On 15/04/13 11:14, Cyril Brulebois wrote: > But you should have made it clear when I asked. I thought I made it > clear I needed feedback, and I wrote “*right now*”. I replied to your mail same day and used the words 'should work'... > For unrelated reasons, d-i will need a new upload, so I can update > tasksel today as well, before rc2 images get built again. That would be really appreciated if you do have time. Is the necessary debian-cd change in effect yet though? http://anonscm.debian.org/viewvc/debian-cd/trunk/tasks/wheezy/Debian-gnome?r1=2363&r2=2541 Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516bd50d.4080...@pyro.eu.org
Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
On Mon, Apr 15, 2013 at 11:23:09AM +0100, Steven Chamberlain wrote: >On 15/04/13 11:14, Cyril Brulebois wrote: >> But you should have made it clear when I asked. I thought I made it >> clear I needed feedback, and I wrote “*right now*”. > >I replied to your mail same day and used the words 'should work'... > >> For unrelated reasons, d-i will need a new upload, so I can update >> tasksel today as well, before rc2 images get built again. > >That would be really appreciated if you do have time. > >Is the necessary debian-cd change in effect yet though? > >http://anonscm.debian.org/viewvc/debian-cd/trunk/tasks/wheezy/Debian-gnome?r1=2363&r2=2541 Yes, that's the one that we need AFAIK. It forces network-manager and network-manager-gnome to be included early onto Gnome CD/DVD sets, assuming that the packages exist. If they don't exist, that will be ignored. Also, for clarity: debian-cd builds use the version from svn rather than what's in the package. We don't need to wait for an upload or unblock. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415103018.ga30...@einval.com
Bug#703436: Multi-arch builds uses wrong UDEB_EXCLUDE
On 20/03/2013 15:46, Steve McIntyre wrote:
On Wed, Mar 20, 2013 at 10:30:55AM +0200, Robert Spencer wrote:
On 19/03/2013 18:09, Steve McIntyre wrote:
Ish. In fact, there's a deeper bug here - the udeb include/exclude
code is actually worse than you think. At the moment, we get away with
things only because the amd64 and i386 files provided with debian-cd
are identical. The code here just doesn't work properly with
multi-arch builds as there is no way to specify different files in
CONF.sh for the different arches. Equally, d-i only looks for its
include and exclude lists in one place on an install CD regardless of
architecture so there's currently no way of passing different config
for the different arches *anyway*.
As you might guess, this piece of the code hasn't been played with for
a while!
I'm thinking a better way to handle this would be to pick up on the
data files for all arches rather than just the first one, and merge
them. What do you think?
I'm not sure that I'm following you. Do you mean something like
default_netinst_udeb_include with the following in:
netcfg
ethdetect
Not quite, no. I'm thinking of keeping the per-arch include/exclude
files and merging at build time.
Understood.
And then if it's alpha include "fdisk-udeb" or amd64 or i386 include
"pcmciautils-udeb".
Alternatively if it's just the .disk/udeb_include and
.disk/udeb_exclude files you don't want duplicates in, then we can
filter them out while maintaining the order (I'm assuming the order
is important).
Filtering is fine, ordering doesn't matter at all AFAICS.
Okay, I hope the attached patch file is acceptable. It's for debian-cd
3.1.12.
The issue
that worries me more is the fact that different arches have different
lists that should go here, maybe with bad consequences if they're
wrong. Maybe I should be tweaking things in d-i too to add per-arch
control.
I think that would probably be best.
--
Robert Spencer
--- tools/start_new_disc~ 2013-04-01 01:26:54.0 +
+++ tools/start_new_disc 2013-04-15 11:13:35.0 +
@@ -170,12 +170,20 @@
echo " Adding udeb/base includes/excludes"
+# Check if the following has been set by CONF.sh
+if [ -z "$UDEB_INCLUDE" ]; then
+NO_UDEB_INCLUDE=1
+fi
+if [ -z "$UDEB_EXCLUDE" ]; then
+NO_UDEB_EXCLUDE=1
+fi
+
for ARCH in $ARCHES
do
if [ $ARCH != source ] ; then
# Netinst/businesscard CD have different
# udeb_include and udeb_exclude files
-if [ -z "$UDEB_INCLUDE" ] ; then
+if [ -n "$NO_UDEB_INCLUDE" ] ; then
case "$INSTALLER_CD"x in
"1"x)
UDEB_INCLUDE=$DI_DATA_DIR/"$ARCH"_businesscard_udeb_include;;
@@ -186,7 +194,7 @@
esac
fi
-if [ -z "$UDEB_EXCLUDE" ] ; then
+if [ -n "$NO_UDEB_EXCLUDE" ] ; then
case "$INSTALLER_CD"x in
"1"x)
UDEB_EXCLUDE=$DI_DATA_DIR/"$ARCH"_businesscard_udeb_exclude;;
@@ -200,14 +208,30 @@
# Sort out the udeb include and exclude files
if [ -n "$UDEB_INCLUDE" ] ; then
if [ -r "$UDEB_INCLUDE" ] ; then
-cat "$UDEB_INCLUDE" >> "$CDDIR/.disk/udeb_include"
+if [ -e "$CDDIR/.disk/udeb_include" ]; then
+if ! diff -q "$UDEB_INCLUDE" "$CDDIR/.disk/udeb_include"; then
+mv "$CDDIR"/.disk/udeb_include{,~}
+cat "$UDEB_INCLUDE" "$CDDIR/.disk/udeb_include~" | sort | uniq > "$CDDIR/.disk/udeb_include"
+rm "$CDDIR/.disk/udeb_include~"
+fi
+else
+cp "$UDEB_INCLUDE" "$CDDIR/.disk/udeb_include"
+fi
else
echo "WARNING: Unable to read UDEB_INCLUDE file $UDEB_INCLUDE"
fi
fi
if [ -n "$UDEB_EXCLUDE" ] ; then
if [ -r "$UDEB_EXCLUDE" ] ; then
-cat "$UDEB_EXCLUDE" >> "$CDDIR/.disk/udeb_exclude"
+if [ -e "$CDDIR/.disk/udeb_exclude" ]; then
+if ! diff -q "$UDEB_EXCLUDE" "$CDDIR/.disk/udeb_exclude"; then
+mv "$CDDIR"/.disk/udeb_exclude{,~}
+cat "$UDEB_EXCLUDE" "$CDDIR/.disk/udeb_exclude~" | sort | uniq > "$CDDIR/.disk/udeb_exclude"
+rm "$CDDIR/.disk/udeb_exclude~"
+fi
+else
+cp "$UDEB_EXCLUDE" "$CDDIR/.disk/udeb_exclude"
+fi
else
echo "WARNING: Unable to read UDEB_EXCLUDE file $UDEB_EXCLUDE"
fi
Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
Steven Chamberlain (15/04/2013): > I replied to your mail same day and used the words 'should work'... Well, maybe that's just me, but that “should work” is no certainty at all, nobody says “works for me” (quite the contrary, given Didier's feedback after that). This “should work” was also drown in a big “it's better to use xfce on kbsd at the moment” mail. That's why I initially suggested Christian not to touch tasksel at all, and why he downgraded the bug report the way he did. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))
Am 15.04.2013 12:14, schrieb Cyril Brulebois: > For unrelated reasons, d-i will need a new upload, so I can update > tasksel today as well, before rc2 images get built again. I don't want to sound like a broken record, but seeing that network-manager-gnome in task-gnome-desktop was demoted to Recommends in 3.14+nmu2, let me repeat it again: The recommends is pointless, task-gnome-desktop depends on gnome-core which already has a Recommends on network-manager-gnome. The dependency in task-gnome-desktop only made sense as long as it was a real Depends. Given that the NM-on-CD1 problem has been solved via debian-cd, the sanest thing to do is to just drop that from tasksel again. 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
