freeze exceptions for accidential systemd entanglements?

[Joey Hess]

#732054 has util-linux shipping a systemd timer which can trivially be
replaced with a cron.weekly script. (Incidentally the systemd
integration is a bit broken, see #767194.)

I'm surprised to see this happened, and doubt there are many other cases
like this. At least there are apparently no others involving timers
currently in the archive[1].

How would the release team feel about a freeze exception for this
specific case, where a 2 line cron.daily script can replace the timer,
and get SSD trimming happening consistently whether or not systemd is
used?

-- 
see shy jo

[1] 
https://packages.debian.org/search?searchon=contents&keywords=.timer&mode=path&suite=unstable&arch=any


signature.asc
Description: Digital signature

Bug#766283: please announce release name for jessie+1 in time for jessie to support it

[Joey Hess]

Package: release.debian.org
Severity: normal

debootstrap needs to contain the name of jessie+1 release, in order to
support debootstrapping that on a jessie system.

In the wheezy release process, we didn't learn the name of jessie until
it was too late to get debootstrap to support it. (#706788) That was
later fixed in R1.

I feel that was a process failure, and ask the release team to please
tell us what name to use for jessie+1 in debootstrap, ideally before the
freeze. Also, please adjust your procedures so that happens
automatically going forward.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: git-annex is marked for autoremoval from testing

[Joey Hess]

git-annex 5.20140927 contains a security fix. I had meant to upload this
urgency=high but forgot in the midst of dealing with problems with
buildds and the haskell toolchain. Can an urgency hint please be added?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#760050: not a good idea imho

[Joey Hess]

This close to the freeze is not time to be introducing new breakage like #763078

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#707137: pu: package tasksel/3.14.1

[Joey Hess]

Adam D. Barratt wrote:
> What's the plan for fixing this in unstable / jessie? (Partly because
> the preferred workflow is fix sid, propose fix, upload, and partly
> because dak requires that unstable >= stable.)

The fix is in unstable, and was uploaded with urgency=high

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#707137: pu: package tasksel/3.14.1

[Joey Hess]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu

Unfortunately, wheezy shipped with a tasksel that, on a desktop system,
selects both the desktop and the ssh server tasks for installation by
default. This was not intentional. The intent was to default to
selecting the desktop task on desktop systems, and the ssh server task
on all other systems.

A typo in the code prevented this from working correctly, and apparently
I was the only one who was aware of how it was intended to work, and I
was not able to participate in testing wheezy installations prior to
release. I only learned of this issue on wheezy release day when
observing users mentioning that both tasks were selected.

This is not a good behavior to have in stable, because a user who is not
paying much attention can end up with a ssh server installed
unintentionally, and be vulnerable to automated password probes.
We can assume that users who are installing servers
a) intend to run ssh (or will notice and de-select it if not) and
b) can take responsibility for using it securely.
But not so for all desktop users.

I have uploaded tasksel to s-p-u with this patch. I recommend it be
included in the next point release.

diff --git a/debian/changelog b/debian/changelog
index 5e17347..2d20341 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+tasksel (3.14.1) stable; urgency=low
+
+  * Fix broken test for non-desktop systems which caused the ssh server task
+to be selected by default on systems with a desktop.
+
+ -- Joey Hess   Tue, 07 May 2013 13:57:43 -0400
+
 tasksel (3.14+nmu2) unstable; urgency=low
 
   * Downgrade network-manager-gnome from Depends to Recommends. It's
diff --git a/tests/server b/tests/server
index e8ca610..3aeff7c 100755
--- a/tests/server
+++ b/tests/server
@@ -1,7 +1,12 @@
 #!/bin/sh
+
+if ! [ "$NEW_INSTALL" ]; then
+   exit 3
+fi
+
 /usr/lib/tasksel/tests/desktop
 ret=$?
-case ret in
+case $ret in
0|2) # is desktop
exit 3 # not server
;;

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#702151: RM: haskell-tls-extra/0.4.6.1-1

[Joey Hess]

Attached are minimal patches that seem to work. The haskell-certificate
change is direct from upstream git rev 
a156d857189fc880f7d0a2de3310e750994c766b, 
like vincenthz suggested. The minor haskell-tls-extra change mirrors what's
currently in upstream too.

I've tested using tls-debug's tls-retrievecertificate --verify -c, and
it looks correct both for sites with a valid trust chain
(www.google.com, www.box.com), as well as failing properly for sites
with self-signed and non-valid CAs (dev.mutt.org, munin.varnish-software.com).

The only site it doesn't seem to like that I've found is db.debian.org,
which Chromium says has a valid chain, but this fails for:

joey@wren:~/tmp/tls-debug-0.1.1>dist/build/tls-retrievecertificate/tls-retrievecertificate
 -d db.debian.org --verify -c
connecting to db.debian.org on port 443 ...
## Certificate 1 ##
serial:   98
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"ca.debian.org")),([2,5,4,10],(Printable,"Debian"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"db.debian.org")),([2,5,4,10],(Printable,"Debian"))]
validity: (2013-03-01,31765s,True) to (2014-03-01,31765s,True)
## Certificate 2 ##
serial:   3
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"ca.debian.org")),([2,5,4,10],(Printable,"Debian"))]
validity: (2008-05-13,33200s,True) to (2018-05-10,33200s,True)
## Certificate 3 ##
serial:   16757532242060383272
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
validity: (2008-05-13,29276s,True) to (2018-05-11,29276s,True)
### certificate chain trust
chain validity : rejected: CertificateRejectOther "certificate is not allowed 
to sign another certificate"
time validity : accepted

However, the most recent upstream versions of tls-* behave identically,
so if this is a bug, it's a separate one. I've let upstream know.

Can someone get the packages updated with these patches and the binnmus
scheduled?

-- 
see shy jo
diff -ur orig/haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs
--- orig/haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs	2012-05-16 04:30:24.0 -0400
+++ haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs	2013-03-10 13:58:39.0 -0400
@@ -64,14 +64,19 @@
 		| otherwise   -> extensionGet xs
 	Left _-> extensionGet xs
 
-data ExtBasicConstraints = ExtBasicConstraints Bool
+data ExtBasicConstraints = ExtBasicConstraints Bool (Maybe Integer)
 	deriving (Show,Eq)
 
 instance Extension ExtBasicConstraints where
 	extOID = const [2,5,29,19]
-	extEncode (ExtBasicConstraints b) = [Start Sequence,Boolean b,End Sequence]
-	extDecode [Start Sequence,Boolean b,End Sequence] = Right (ExtBasicConstraints b)
-	extDecode [Start Sequence,End Sequence] = Right (ExtBasicConstraints False)
+	extEncode (ExtBasicConstraints b Nothing)  = [Start Sequence,Boolean b,End Sequence]
+	extEncode (ExtBasicConstraints b (Just i)) = [Start Sequence,Boolean b,IntVal i,End Sequence]
+
+	extDecode [Start Sequence,Boolean b,IntVal v,End Sequence]
+		| v >= 0= Right (ExtBasicConstraints b (Just v))
+		| otherwise = Left "invalid pathlen"
+	extDecode [Start Sequence,Boolean b,End Sequence] = Right (ExtBasicConstraints b Nothing)
+	extDecode [Start Sequence,End Sequence] = Right (ExtBasicConstraints False Nothing)
 	extDecode _ = Left "unknown sequence"
 
 data ExtKeyUsage = ExtKeyUsage [ExtKeyUsageFlag]
diff -ur orig/haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs
--- orig/haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs	2013-01-20 10:49:28.0 -0400
+++ haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs	2013-03-10 14:23:34.0 -0400
@@ -92,7 +92,7 @@
 Just (ExtKeyUsage l) -> elem KeyUsage_keyCertSign l
 Nothing  -> False
 			case extensionGet es of
-Just (ExtBasicConstraints True)
+Just (ExtBasicConstraints True _)

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

Cyril Brulebois wrote:
> Joey Hess  (07/02/2013):
> > This can be done easily, just upload d-i to t-p-u. d-i uploads are 
> > already built with udebs from testing, for similar reasons.
> > 
> > There seems to be an unholy fear of using t-p-u for anything these days,
> > which I don't really understand. Even when not using it causes massive
> > and unnecessary logjams in unstable during the freeze.
> 
> 

Yes, that's a good example of spreading FUD aboput using t-p-u, rather
than just using it and dealing with any breakage.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

Bdale Garbee wrote:
> patch d-i to build successfully against the syslinux in sid

syslinux is GPL'd, so this would result in shipping d-i images in wheezy
which contain a GPL'd binary for which there is no source in wheezy.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

Bdale Garbee wrote:
> Sure seems like d-i is something we should build using the components
> of the release it will be contained in and not unstable... but I
> haven't tried to think hard about what that might imply that's
> problematic.  And I certainly don't think this is something we should
> even consider changing at this late date in for wheezy release cycle!

This is not desirable outside the freeze because packages in unstable
that are used to build d-i then don't get tested until they land in
testing.

It might be desirable during the freeze.

> wiggle the d-i build processing to fetch syslinux from testing

This can be done easily, just upload d-i to t-p-u. d-i uploads are 
already built with udebs from testing, for similar reasons.

There seems to be an unholy fear of using t-p-u for anything these days,
which I don't really understand. Even when not using it causes massive
and unnecessary logjams in unstable during the freeze.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#688983: unblock: tasksel/3.13

[Joey Hess]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: d-i

Please unblock tasksel 3.13. Diff is attached.

The most important fixes in here are a workaround for #651495,
so xfce will have a working mixer, and dropping gnash from kde,
so konqueror doesn't segfault. I believe that the lxde maintainers
also consider switching from gdm3 to lightdm important.

unblock tasksel/3.13

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
see shy jo
diff --git a/debian/changelog b/debian/changelog
index 3ca2b4e..6e4f99d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+tasksel (3.13) unstable; urgency=low
+
+  [ Christian Perrier ]
+  * Replace gdm3 by lightdm in lxde-desktop task. Closes: #683345
+
+  [ Joey Hess ]
+  * Don't force browser-plugin-gnash onto desktops that don't themselves
+pull it in. This means gnome still installs it, but kde, xfce,
+and lxde do not. Closes: #655841
+  * Use dh_perl -d, as tasksel does not need perl, only perl-base.
+Closes: #686021
+  * Add gstreamer0.10-alsa to task-xfce-desktop, as a workaround for
+bug #651495, which was resulting in the mixer being broken.
+  
+  [ Debconf translations ]
+  * Brazilian Portuguese (Adriano Rafael Gomes).  Closes: #685181
+
+ -- Joey Hess   Sun, 02 Sep 2012 20:51:05 -0400
+
 tasksel (3.12) unstable; urgency=low
 
   [ Andrew Lee (李健秋) ]
@@ -5,12 +24,12 @@ tasksel (3.12) unstable; urgency=low
 
   [ Joey Hess ]
   * xfce: Use network-manager-gnome.
-Rationalle: Everyone I've polled who has installed xfce for nontechnical
+Rationale: Everyone I've polled who has installed xfce for nontechnical
 users has had to switch out wicd due to its non-user-friendliness,
 which includes not managing wireless interfaces at all by default,
-and presenting the user with a secreen full of dozens of configuration
+and presenting the user with a screen full of dozens of configuration
 settings when a network requires a password.
-Technical  users who want wicd will have no difficulty installing it.
+Technical users who want wicd will have no difficulty installing it.
 
   [ Christian Perrier ]
   * Use xul-ext-mozvoikko instead of transitional mozvoikko in
diff --git a/debian/control b/debian/control
index 16949fb..54b082e 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Section: admin
 Priority: important
 Architecture: all
 Pre-Depends: debconf (>= 1.5.34) | cdebconf (>= 0.106)
-Depends: ${misc:Depends}, ${perl:Depends}, liblocale-gettext-perl, apt, tasksel-data
+Depends: ${misc:Depends}, liblocale-gettext-perl, apt, tasksel-data
 Conflicts: debconf (<< 1.4.27), base-config (<< 2.32)
 Description: Tool for selecting tasks for installation on Debian systems
  This package provides 'tasksel', a simple interface for users who
@@ -41,7 +41,10 @@ Depends: ${misc:Depends},
 	desktop-base,
 	menu
 Recommends:
-# The default desktop is gnome, but any can be used with this task.
+# One of the actual desktop tasks is needed to get a full desktop environment.
+# The order here is significant when installing this task manually;
+# when tasksel installs this task it instead selects one of these based
+# on the tasksel/desktop debconf setting.
 	task-gnome-desktop | task-kde-desktop | task-lxde-desktop | task-xfce-desktop,
 # For use by third-party apps.
 	xdg-utils,
@@ -57,10 +60,6 @@ Recommends:
 # sound
 	alsa-utils,
 	alsa-base,
-# flash -- Note that gnome recommends browser-plugin-gnash;
-# if this is changed here to a different flash player, it should
-# also be changed there.
-	browser-plugin-gnash,
 # ensure pm-utils is available
 	pm-utils
 
@@ -161,7 +160,7 @@ Description: LXDE desktop environment
  expect to have available on the desktop.
 Depends: ${misc:Depends}, 
 	task-desktop,
-	gdm3,
+	lightdm,
 	lxde
 Recommends:
 	lxtask,
@@ -242,7 +241,9 @@ Recommends:
 # make hyphenation work
 	hyphen-en-us,
 # gui for configuration of the print server
-	system-config-printer
+	system-config-printer,
+# workaround #651495
+	gstreamer0.10-alsa
 
 Package: task-laptop
 Architecture: all
diff --git a/debian/po/pt_BR.po b/debian/po/pt_BR.po
index b9566fd..bdab99d 100644
--- a/debian/po/pt_BR.po
+++ b/debian/po/pt_BR.po
@@ -1,24 +1,19 @@
-#
-#Translators, if you are not familiar with the PO format, gettext
-#documentation is worth reading, especially sections dedicated to
-#this format, e.g. by running:
-# info -n '(gettext)PO Files'
-# info -n '(gettext)Header Entry'
-#
-#Some information specific to po-debconf are available at
-#/usr/share/doc/po-debconf/README-trans
-#

debhelper 9.20120830

[Joey Hess]

This debhelper release is ready to migrate tomorrow, and
fixes a single RC bug. I have a new RC bug fix ready to be
released once this one migrates so would appreciate a speedy
unblock.

Complete diff:

diff --git a/autoscripts/preinst-sgmlcatalog b/autoscripts/preinst-sgmlcatalog
index 41f55d6..96f0673 100644
--- a/autoscripts/preinst-sgmlcatalog
+++ b/autoscripts/preinst-sgmlcatalog
@@ -1,7 +1,8 @@
-if [ "$1" = "upgrade" ] && ! dpkg-query -S #CENTRALCAT# >/dev/null 2>&1; then
+if test -f #CENTRALCAT# -a "(" "$1" = "upgrade" -o "$1" = "install" -a -n "$2" 
")" && 
+   ! dpkg-query -S #CENTRALCAT# >/dev/null 2>&1; then
# If the dpkg-query command returns non-zero, the central catalog is
# not owned by any package. This is due to an old behaviour of
# debhelper. Now that file becomes a conffile. In order to avoid a
# question during installation, we remove the old non-conffile.
-   rm -f #CENTRALCAT#
+   mv #CENTRALCAT# #CENTRALCAT#.old
 fi
diff --git a/debian/changelog b/debian/changelog
index 0bb44d6..b4d4824 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+debhelper (9.20120830) unstable; urgency=low
+
+  * dh_installcatalogs: Adjust catalog conffile conversion to avoid
+dpkg conffile prompt when upgrading from a removed package.
+Closes: #681194
+
+ -- Joey Hess   Thu, 30 Aug 2012 11:04:10 -0400
+
 debhelper (9.20120608) unstable; urgency=low
 
   * dh: When there's an -indep override target without -arch, or vice versa,

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Upcoming d-i beta2, round 2

[Joey Hess]

Cyril Brulebois wrote:
> please find below a number of unblock/unblock-udeb requests I'm mostly
> OK with as far as d-i is concerned. I added some comments so that one
> can grasp what impact this or that change has; some of them are marked
> “KiBi-upload”s, basically due to some needed, tiny fix-ups (e.g. fixes
> for syntax errors in shell scripts, or re-uploading without files from
> git checkouts).
> 
> It would be nice if someone could check nothing broken slipped in for
> the ones marked as such; others should be OK to copy/paste in someone's
> hints file, but I'm OK with some other eyes going over those diffs. ;)

Please don't forget tasksel 3.12.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#683216: Acknowledgement (unblock: tasksel/3.12)

[Joey Hess]

tasksel 3.12 also removes the contrib package
opendict-plugins-lingvosoft from the Recommends of task-serbian.
Which was a violation of a policy "must", and so a RC bug.

tasksel is ready to migrate tomorrow if unblocked.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#683216: unblock: tasksel/3.12

[Joey Hess]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

3.12 contains no code changes, but several changes to task contents.

Possibly the most important change is adding synaptic back to the gnome
desktop task, which had stopped installing it due to pre-freeze changes
to the gnome package recommends. Arguably RC, and certianly the kind of
thing freezes exist to give time to be caught by QA.

As long as the task packages remain (co)installable in this new version,
I'd rate the risk of it breaking things to be low; the installed sizes
of some tasks will change but the documentation and CD layout is not
yet final anyway.

unblock tasksel/3.12

diff -Nru tasksel-3.11/debian/changelog tasksel-3.12/debian/changelog
--- tasksel-3.11/debian/changelog   2012-07-08 12:45:44.0 -0400
+++ tasksel-3.12/debian/changelog   2012-07-21 19:41:41.0 -0400
@@ -1,3 +1,66 @@
+tasksel (3.12) unstable; urgency=low
+
+  [ Andrew Lee (李健秋) ]
+  * Really depending on gdm3 in task-lxde-desktop (Closes: #680519).
+
+  [ Joey Hess ]
+  * xfce: Use network-manager-gnome.
+Rationalle: Everyone I've polled who has installed xfce for nontechnical
+users has had to switch out wicd due to its non-user-friendliness,
+which includes not managing wireless interfaces at all by default,
+and presenting the user with a secreen full of dozens of configuration
+settings when a network requires a password.
+Technical  users who want wicd will have no difficulty installing it.
+
+  [ Christian Perrier ]
+  * Use xul-ext-mozvoikko instead of transitional mozvoikko in
+task-finnish-desktop. Closes: #680952
+  * Remove freedict-*, openddict-* and texlive-* from bosnian,
+croatian and serbian tasks. Thanks to Josip Rodin for
+reporting and investigating. Closes: #565209
+  * Replace apache2-mpm-prefork by apache2. Closes: #678749
+  * Replace qpopper and uw-imapd by dovecot-{pop3d,imapd} in the mail server
+task. Closes: #560696
+  * Create en "english" task with both British and American
+dictionaries and word lists. Consequently drop the "british"
+task and modify british-desktop. Closes: #545047
+  * Changes related to hunspell used in favoir of aspell:
+- Add hunspell-ro to romanian-desktop. Closes: #583195
+- Add hunspell-be to belarusian-desktop.
+- Replace myspell-en-us by hunspell-en-us in *-desktop.
+- Use hunspell-gl-es instead of hunspell-gl in galician-desktop.
+- Add hunspell-ml to malayalam-desktop.
+- Replace myspell-ru by hunspell-ru in russian-desktop.
+- Replace myspell-fr-gut by hunspell-fr in french-desktop.
+- Add hunspell-ne to nepali-desktop.
+- Add hunspell-sr to serbian-desktop.
+- Add hunspell-vi to vietnamese-desktop.
+- Add hunspell-eu-es to basque-desktop.
+  * Remove the mention that poppler-data is non-free in
+tasks descriptions.
+  * Replace synaptic by apper in kde-desktop. Closes: #681964
+
+  [ Translations of programs ]
+  * Uyghur added. Closes: #627005
+
+  [ Translations of debconf templates ]
+  * Uyghur added. Closes: #627005
+
+  [ Translations of tasks ]
+  * Uyghur added. Closes: #627005
+  * Fix an horrible grammar error in the translation of
+"standard" in French. Thanks to Cyril Brulebois for
+hitting me with a cluebat.
+
+  [ Aron Xu ]
+  * Update input method support and Chinese tasks. Closes: #681466
+
+  [ Joey Hess ]
+  * Add synaptic to task-gnome-desktop. It had been pulled in by
+nautilus, but that Recommends has been dropped.
+
+ -- Joey Hess   Sat, 21 Jul 2012 19:41:30 -0400
+
 tasksel (3.11) unstable; urgency=low
 
   [ Josh Triplett ]
diff -Nru tasksel-3.11/debian/control tasksel-3.12/debian/control
--- tasksel-3.11/debian/control 2012-07-08 13:00:20.0 -0400
+++ tasksel-3.12/debian/control 2012-07-21 19:36:48.0 -0400
@@ -83,6 +83,8 @@
libreoffice-evolution,
 # temporarily moved from task-desktop due to #525077
gimp,
+# Package management.
+   synaptic,
 # firefox (ne iceweasel) is the most popular web browser at the moment,
 # although both gnome and kde offer their own too
iceweasel,
@@ -94,7 +96,7 @@
 # make thesaurus work
mythes-en-us,
 # make spellchecker work
-   myspell-en-us,
+   hunspell-en-us,
 # make hyphenation work
hyphen-en-us,
 # gui for configuration of the print server
@@ -130,8 +132,8 @@
kdesudo,
 # KDE libreoffice integration
libreoffice-kde,
-# Package management. (Replace with a KDE-specific one when available.)
-   synaptic,
+# Package management.
+   apper,
 # temporarily moved from task-desktop due to #525077
gimp,
 # firefox (ne iceweasel) is the most popular web browser at the moment,
@@ -145,7 +147,7 @@
 # make thesaurus work
mythes-en-us,
 # make spellchecker work
-   myspell-en-us,
+   hunspell-en-us,
 # make hyphenation work
  

Re: The status of desktop-base in wheezy

[Joey Hess]

Adam D. Barratt wrote:
> Please don't rush the changes in order to make the freeze date.
> Getting exceptions for updates introducing the new artwork won't be
> an issue (well, unless you leave them until the week before release,
> but don't do that :P).

The last time we rushed new artwork into a release with a freeze
exception, it introduced a serious bug into d-i's menu system that
had to be fixed in a point release (#650979). 

Why are we encouraging doing this again?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: installer location on mirrors

[Joey Hess]

Joerg Jaspert wrote:
> I understand it right that doing it this way (ie. current symlink stays
> around), it won't break anything, so we can "just do it for all suites"?!

It appears that debmirror will be broken, if it helps. :/

I can't find anything that will break in debian-cd.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: installer location on mirrors

[Joey Hess]

Joerg Jaspert wrote:
> I don't think the installer images should be in dists/ as they are now,
> but get their own location, installer/. For various reasons, including
> the - wth was it added there in the first place, - currently an
> installer update move from one suite to another means real
> copies/moves. Why, pool/ got rid of that for our packages, why do we
> have it for the installer? Also, its really big and doesn't belong into
> dists/, which is more like a set of "Package indices".

It seems like pool/main/d/debian-installer/$ARCH/$version would be a
good place to put it. Unless having non-debs in pool would break
something's assumptions.

If it's in pool, then dists could just link to the right one, ie:

dists/sid/main/installer-i386/current -> 
../../../../pool/main/d/debian-installer/i386/20120508

I think this preserves backwards compatability in a clean way that
won't need further work later, while meeting your goals.

>  wheezy -> 20120508

> There is one drawback I see outright - we no longer have a "current"
> link. I might miss something here, but is the current link really
> required, if we build it up like the above?

What if a user is installing stable and cannot remember the release code
name? (Not hypothetical; I couldn't tell you the current release
codename offhand.) The advantage of keeping the symlink in dists is that
it's right there with the other files for whatever dist the user
navigates to. Also it avoids special cases.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: merging w3c-dtd-xhtml and w3c-sml-lib: ten days to object or find issues

[Joey Hess]

Nicholas Bamber wrote:
> Yes and it is not present in 1.2-2. Nor does w3c-sgml-lib exist in
> stable. So actually if we just let it go to testing everything would
> be fine. ;-) Seriously I will not do that unless you are happy with
> it

joey@wren:~>sudo apt-get install wdg-html-validator
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  w3c-dtd-xhtml w3c-sgml-lib
Suggested packages:
  wdg-html-reference
The following NEW packages will be installed:
  w3c-dtd-xhtml w3c-sgml-lib wdg-html-validator
0 upgraded, 3 newly installed, 0 to remove and 438 not upgraded.
Need to get 1,057 kB of archives.
After this operation, 4,832 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://mirror.bytemark.co.uk/debian/ unstable/main w3c-sgml-lib all 1.2-2 
[568 kB]
Get:2 http://mirror.bytemark.co.uk/debian/ unstable/main w3c-dtd-xhtml all 
1.2-2 [9,012 B]
Get:3 http://mirror.bytemark.co.uk/debian/ unstable/main wdg-html-validator all 
1.6.2-7 [480 kB]
Fetched 1,057 kB in 0s (7,612 kB/s) 
Selecting previously unselected package w3c-sgml-lib.
(Reading database ... 154522 files and directories currently installed.)
Unpacking w3c-sgml-lib (from .../w3c-sgml-lib_1.2-2_all.deb) ...
Selecting previously unselected package w3c-dtd-xhtml.
Unpacking w3c-dtd-xhtml (from .../w3c-dtd-xhtml_1.2-2_all.deb) ...
Selecting previously unselected package wdg-html-validator.
Unpacking wdg-html-validator (from .../wdg-html-validator_1.6.2-7_all.deb) ...
Processing triggers for man-db ...
Setting up w3c-sgml-lib (1.2-2) ...
Setting up w3c-dtd-xhtml (1.2-2) ...
Setting up wdg-html-validator (1.6.2-7) ...
joey@wren:~>validate index.html
*** Errors validating index.html: ***
[ snip 200+ lines of bogus errors ]
Error at line 3, character 13:  there is no attribute "XMLNS"
joey@wren:~>sudo dpkg --purge  w3c-sgml-lib
dpkg: dependency problems prevent removal of w3c-sgml-lib:
 w3c-dtd-xhtml depends on w3c-sgml-lib (= 1.2-2).
dpkg: error processing w3c-sgml-lib (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 w3c-sgml-lib

-- 
see shy jo


signature.asc
Description: Digital signature

Re: merging w3c-dtd-xhtml and w3c-sml-lib: ten days to object or find issues

[Joey Hess]

Nicholas Bamber wrote:
> Hmm well the old vesion of w3c-dtd-xhtml provided w3c-dtd-xhtml. This
> one does not. Still I see it showing up as a Provides in PTS. I am not
> sure if something needs to be done in some mysterious Debian server to
> resolve that but the 1.2-2 version of w3c-sgml-lib does NOT have a
> Provides clause.

w3c-sgml-lib 1.2-1 does provide/conflict/replace w3c-dtd-xhtml.

> Please could you send me one or more HTML files that you would accept
> as an objective test as whether wdg-html-validator is working and what
> you expect as an output.

See end of transcript in my previous mail.

>   Also what happens when you force through the installation of
> w3c-dtd-xhtml version 1.2-2 and w3c-sgml-lib? Does
> wdg-html-validator behave itself for you then?

update-xmlcatalog: error: entity already registered with a different value
 Entity   : [delegatePublic publicIdStartString="-//W3C//ENTITIES Latin 1 for 
XHTML//EN"]
 Old value: [catalog="file:///etc/xml/w3c-sgml-lib.xml"]
 New value: [catalog="file:///etc/xml/w3c-dtd-xhtml.xml"]
dpkg: error processing w3c-dtd-xhtml (--install):

And in this state, no, validate does not work.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: merging w3c-dtd-xhtml and w3c-sml-lib: ten days to object or find issues

[Joey Hess]

Nicholas Bamber wrote:
>   Please send me instructions for how it working fine and not
> afterwards because I tried to test it.

w3c-sgml-lib provides/conflicts w3c-dtd-xhtml, and w3c-markup-validator
depends on both packages, so this happens:

joey@wren:~>validate index.html
joey@wren:~>sudo apt-get install w3c-dtd-xhtml
Reading package lists... Done
Building dependency tree   
Reading state information... Done
w3c-dtd-xhtml is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 332 not upgraded.
joey@wren:~>sudo apt-get install w3c-sgml-lib 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  w3c-dtd-xhtml
The following NEW packages will be installed:
  w3c-sgml-lib
0 upgraded, 1 newly installed, 1 to remove and 332 not upgraded.
Need to get 616 kB of archives.
After this operation, 3,834 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://mirror.bytemark.co.uk/debian/ unstable/main w3c-sgml-lib all 1.2-1 
[616 kB]
Fetched 616 kB in 0s (7,302 kB/s)
dpkg: w3c-dtd-xhtml: dependency problems, but removing anyway as you requested:
 wdg-html-validator depends on w3c-dtd-xhtml.
(Reading database ... 154372 files and directories currently installed.)
Removing w3c-dtd-xhtml ...
Selecting previously unselected package w3c-sgml-lib.
(Reading database ... 154310 files and directories currently installed.)
Unpacking w3c-sgml-lib (from .../w3c-sgml-lib_1.2-1_all.deb) ...
Setting up w3c-sgml-lib (1.2-1) ...
[master c4e89ec] committing changes in /etc after apt run
 Author: joey 
 10 files changed, 804 insertions(+), 84 deletions(-)
 create mode 100644 sgml/w3c-sgml-lib.cat
 delete mode 100644 xml/w3c-dtd-xhtml.xml
 rewrite xml/w3c-dtd-xhtml.xml.old (82%)
 create mode 100644 xml/w3c-sgml-lib.xml
joey@wren:~>validate index.html   
*** Errors validating index.html: ***
Error at line 2, character 53:  cannot find
"REC-xhtml1-20020801/xhtml1-strict.dtd"; tried
"/usr/share/xml/xhtml/schema/dtd/1.0/REC-xhtml1-20020801/xhtml1-str
ict.dtd",
"/usr/local/share/sgml/REC-xhtml1-20020801/xhtml1-strict.dtd",
"/usr/share/sgml/REC-xhtml1-20020801/xhtml1-strict.dtd"
Error at line 2, character 53:  DTD did not contain element declaration for
document type name
Error at line 3, character 13:  there is no attribute "XMLNS"
Error at line 3, character 43:  element "HTML" undefined
Error at line 4, character 6:  element "HEAD" undefined
Error at line 5, character 7:  element "TITLE" undefined
Error at line 7, character 6:  element "BODY" undefined
Error at line 8, character 3:  element "P" undefined
Error at line 8, character 24:  element "STRONG" undefined
zsh: exit 9 validate index.html
joey@wren:~>cat index.html 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>

ikiwiki


Ikiwiki is a wiki compiler.



-- 
see shy jo


signature.asc
Description: Digital signature

Re: merging w3c-dtd-xhtml and w3c-sml-lib: ten days to object or find issues

[Joey Hess]

Nicholas Bamber wrote:
> I am just about to upload w3c-sgml-lib that also generates
> w3c-dtd-xhtml (which will depend on w3c-sgml-lib and consist of
> links). I have endeavoured to fix all conflicts and ensure that
> nsgmls, wdg-html-validator, w3c-markup-validator still work. I have
> to put a caveat on that. As far as I can see wdg-html-validator no
> longer works at all well. So I mean that my new versions do not make
> it worse.

It was working 100% fine before your change, and now it fails miserably.
#669480

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#665852: UI still refers to volatile.debian.org

[Joey Hess]

Philipp Kern wrote:
> On Tue, Mar 27, 2012 at 07:14:10AM +0200, Christian PERRIER wrote:
> > If I'm correct there is no more volatile at all.
> 
> There's still the $codename-updates suite.  I personally don't care if it's 
> not
> deactivatable in d-i, but given that security updates are, it probably makes
> sense.

Yes, and leaving the code for it in also keeps support for installing
lenny. Although that is not a priority.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: tasksel changes for stable

[Joey Hess]

Steve McIntyre wrote:
> Hmmm. How big is the difference for the KDE CD? Considering we already
> have size issues, I'm loath to add anything extra. Unless there's a
> really compelling reason to add things, can we just take the change to
> drop gnash?

Could do. I have not actually run the numbers on the kdeaccessibility
change. My idea is to include it in the task, but not on the CD. It can
be pulled in from the network with whatever other stuff already didn't
fit on the CD.

-- 
see shy jo


signature.asc
Description: Digital signature

tasksel changes for stable

[Joey Hess]

I'm hoping to get a new tasksel into an upcoming stable point release
to fix two bugs in the KDE desktop task.

Apparently konqueror is basically unusable since it crashes on websites
with flash. Removing browser-plugin-gnash from the task will "fix" that,
and the only collateral damange is that gnash won't be used by
iceweasel. It seems unlikely that any ongoing deployments of stable have
flash as a critical component, and yet are relying on iceweasel using
gnash for flash. So I feel this is a safe enough change to make.

The addition of kdeaccessibility is not technically release critical,
however, accessability is an important goal for Debian, and I feel
fixing the oversight of not including it is an appropriate change to
stable. The impact to the size of the KDE CD has been considered.

Full proposed patch follows. Note that the other desktop tasks will
still install the same packages as before; the common desktop task
used to pull in browser-plugin-gnash, so it needed to be removed from
there and explicitly added the xfce-desktop and lxde-desktop.
gnome-desktop does not need it explicitly listed since gnome already
pulls it in.

diff --git a/debian/changelog b/debian/changelog
index 96e128a..f941797 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+tasksel (2.88squeeze1) UNRELEASED; urgency=low
+
+  * konqueror-nsplugins crashes konqueror when browsing websites with flash.
+See #549309
+To work around that, remove browser-plugin-gnash from the KDE desktop
+task. Closes: #655841
+  * kde-desktop: Add kdeaccessibility. Closes: #610790
+
+ -- Joey Hess   Sat, 22 Jan 2011 15:22:59 -0400
+
 tasksel (2.88) unstable; urgency=low
 
   * Make gnome-core key, as of 1:2.30+7 it includes the rest of the stuff
diff --git a/tasks/desktop b/tasks/desktop
index c4533fe..0cc30a6 100644
--- a/tasks/desktop
+++ b/tasks/desktop
@@ -62,8 +62,5 @@ Packages-list:
 # sound
   alsa-utils
   alsa-base
-# flash -- Note that gnome recommends browser-plugin-gnash; if this is changed
-# here to a different flash player, it should also be changed there.
-  browser-plugin-gnash
 # ensure pm-utils is available
   pm-utils
diff --git a/tasks/kde-desktop b/tasks/kde-desktop
index c8dfb38..82b3966 100644
--- a/tasks/kde-desktop
+++ b/tasks/kde-desktop
@@ -11,6 +11,8 @@ Key:
   kdm
 Packages: task-fields
 Packages-list:
+# accessibility support
+  kdeaccessibility
 # enable debian menus
   menu-xdg
 # package management. Need something here, but please, no kpackage.
diff --git a/tasks/lxde-desktop b/tasks/lxde-desktop
index 68e5677..3526334 100644
--- a/tasks/lxde-desktop
+++ b/tasks/lxde-desktop
@@ -19,3 +19,6 @@ Packages-list:
   openoffice.org-gtk
 # Support for scanners
   xsane
+# flash -- This one is used only because it's the one gnome currently
+# recommends.
+  browser-plugin-gnash
diff --git a/tasks/xfce-desktop b/tasks/xfce-desktop
index 6c441a8..030e16a 100644
--- a/tasks/xfce-desktop
+++ b/tasks/xfce-desktop
@@ -37,3 +37,6 @@ Packages-list:
   xfce4-power-manager
 # network management
   wicd
+# flash -- This one is used only because it's the one gnome currently
+# recommends.
+  browser-plugin-gnash

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian artwork for Wheezy

[Joey Hess]

Paul Wise wrote:
> The desktop artwork for wheezy was discussed last month:
> 
> http://lists.debian.org/debian-desktop/2011/10/threads.html#3
> 
> Here is my summary mail from that thread:
> 
> http://lists.debian.org/debian-desktop/2011/10/msg00014.html
> 
> The KDE and GNOME teams both do not want any Debian-specific artwork
> enabled by default.

Not quite, Joss doesn't want icon/theme changes but is open to a desktop
background in http://lists.debian.org/debian-desktop/2011/10/msg00022.html

I personally feel sticking with upstream desktop branding, possibly
lightly altered to add a Debian logo in the login or desktop background
is the right choice.

> AFAICT neither of them have asked d-i folks to
> remove it from the task-desktop package deps though.

tasksel only pulls in desktop-base, it does not itself have
anything to do with the theme.

If we're removing spacefun then d-i can revert to the old "klowner" boot
logo, possibly updated in some way for wheezy, but the current one will
work ok. Reverting abbc21a955dc2f9b2fc134e796ef0bfcf4c3a2d2 in
rootskel-gtk will despacefun the graphical installer. 

However, it's good to have visual consistency between the d-i and
debian-live and grub boot graphics, so I'd like to get a consensus
about how wheezy should look on boot before making too many changes.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Task installability and britney

[Joey Hess]

Adam D. Barratt wrote:
> Time passed, and a version of tasksel which implements the "real
> package" approach will migrate to testing in the next day or so.  
> 
> joeyh / -boot - could you confirm that the task overrides {can,should}
> be dropped (and thus the fields removed from the Packages files for
> testing) once the current version of tasksel migrates?

Yes, that's right.

> From the britney point-of-view, I'm looking at dropping most of the
> current tasksel-meta-faux-* generation in favour of a single faux
> package which depends on all of the real task-* packages.  This would
> allow us to track co-installability of the tasks.

That sounds about right..

-- 
see shy jo


signature.asc
Description: Digital signature

unblock base-installer 1.119

[Joey Hess]

This version of base-installer is needed by the version of debootstrap
that already made its way into testing, so it should be allowed to
transition.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Preparation of fixes to 6.0.1

[Joey Hess]

Julien Cristau wrote:
> Is there any chance we can update the apt-setup debconf templates to
> stop talking about volatile?

Since squeeze-updates (volatile) vs squeeze/updates (security)
are now being seen as confusingly similar names --
And, since this thread demonstrates that we don't have an agreed on 
human-understandable name for it --
Perhaps we should determine what the suite will finally be called in
wheezy, and use that name in d-i?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Task installability and britney

[Joey Hess]

Adam D. Barratt wrote:
> The basic implementation on the britney side exists (in my local setup)
> since a few hours ago, after I tinkered with it during my lunch break.
> The interesting work of extracting the information required from the
> version of tasksel-data currently in unstable already exists in order to
> create the current composite list and the changes for moving from
> (essentially) a list to a list of lists weren't particularly complex.
> 
> I'm quite happy for that work to remain an interesting diversion from
> debugging customer systems, but thought it was worth discussing how we
> best resolve the current situation regarding the tasksel-meta-faux
> package being broken by the non co-installability of the tasks.

I have no problem with you rolling it out. What you described makes
sense given the current state of affairs.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Task installability and britney

[Joey Hess]

Adam D. Barratt wrote:
> In order to ensure that packages marked as "key" for a task remain present
> and installable in testing, britney uses a generated "faux" package which
> depends on each of the packages. This approach has, with the odd minor
> niggle, worked fine for some time but breaks down as soon as the set of
> packages involved are not completely coinstallable; this is now the case
> due to the gnome-desktop task indirectly depending on gdm3, and the xfce
> and lxde desktop tasks depending on gdm. The net effect is that the faux
> package becomes useless for the purpose of determining installability of
> the set of key packages, as it is itself uninstallable.

That's unfortunate. I doubt that the light desktop tasks will continue
to use gdm for too long, as it seems unlikely gdm 2 will remain in
Debian. Probably they will be using xdm or some other light login
manager. Possibly gdm3. Probably not something that conflicts with gdm3.

Co-installability of tasks is also a desirable property in general.

> We've therefore been looking at splitting the single faux package in to a
> set of faux packages, one per task. This maintains the overall property of
> requiring all of the packages to be installable but only requires that the
> packages within each task are co-installable; if there are particular
> combinations of tasks which are expected / desired to remain
> co-installable then we could add further faux packages depending on sets
> of the task packages.

Before you spend too much time on that, I have been thinking about
converting tasksel's tasks back to real packages. Now that recommends
are installed by default, it should be possible to make tasks use
Recommends for normal contents, and Depends for Key components.

This should simplify a lot of things; it would also allow moving maintenance
of some/all tasks out of tasksel, and tasksel would then only need to contain
a list of task packages.

This has been a longterm plan, and one I wanted to discuss more broadly.
But I can try to move up the implementation if it avoids duplicate work.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Preparation of fixes to 6.0.1

[Joey Hess]

Otavio Salvador wrote:
> grub-installer

I don't see a squeeze branch, but assuming it's fixing the debconf title
bug, all for it.

> tasksel

I'd prefer to note remove software from packages in stable that users
could already expect to get installed. #611951 can wait until wheezy.

Any changes to desktop tasks are inherently dangerous, the KDE CD
was barely made to fit at the very last minute (by dropping the
release notes from it). So while I'm sad that #610790 didn't get fixed
in squeeze (accessability is important), someone would need to do a lot
of checking to get that in.

> debootstrap

This seems important to allow stable to debootstrap unstable going
forward.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#611763: unblock: partman-target/72

[Joey Hess]

Adam D. Barratt wrote:
> I'm assuming that this refers to the standard CD image build during the
> release, rather than an extra, earlier, build in order to pick up the
> new partman-target?

Yes, assuming there is such a build.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#611763: unblock: partman-target/72

[Joey Hess]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

unblock partman-target/72

This is necessary to support installing kFreeBSD from CDs larger than
the businesscard CD. Without this fix, a user who got a kFreeBSD DVD
would see it show an error and then download everything via the
net.

Additionally, this fix makes "apt-cdrom add" and "mount /cdrom" work on
kFreeBSD.

I think this is RC for kFreeBSD, and kFreeBSD developers seem to concur. 
All code changes are conditionalized to only affect kFreeBSD.
Diff attached.

(d-i rc2 initrds will not need to be rebuilt to get this fix in.
Of course a final CD build will be needed.)

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#611565: debconf 1.5.36.1 in TPU, encoding fix release

[Joey Hess]

Package: release.debian.org
Severity: normal

Debconf has broken encodings for Spanish and Hebrew. The Hebrew
translation of dpkg-reconfigure debconf is ususable. The Spanish
encoding breakage is visible from inside d-i, as well as during upgrade,
where it says "Configuración de $package". It also makes the readline
frontend unusable since it will expect the user to enter "sÃ" rather than
"sí".

I've cherry-picked the fixes from unstable, where they have had 2 weeks
of testing, and uploaded debconf 1.5.36.1 to TPU.

I would hope to get this into 6.0r0; if that proves impossible I feel
this is significant enough to be included in r1.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: 75 unreported RC bugs, (mostly?) fixable by rebuilding / could lintian please prevent such packages from being uploaded in future?

[Joey Hess]

Carsten Hey wrote:
> Package: lintian
> Severity: wishlist
> 
> 
> $ dpkg-reconfigure nana
> This is not dpkg install-info anymore, but GNU install-info
> See the man page for ginstall-info for command line arguments
> install-info: No dir file specified; try --help for more information.
> zsh: exit 1 dpkg-reconfigure nana
> 
> 
> This breaks unrelated software (dpkg-reconfigure -a).

Severity inflation? "Breaking" dpkg-reconfigure -a is not an RC bug,
because dpkg-reconfigure -a is utterly useless. Nor is debconf
unrelated to a package's postinst script.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: lack of gnome on squeeze CD #1

[Joey Hess]

Josselin Mouette wrote:
> This would need to be tested, but 1+2 without recommends sounds like the
> good thing to add. We could remove the mail client (evolution) if it
> turns out too big, nowadays the media player looks more important.

I'm testing 1+2 in tasksel 2.87 and we can move the list back into a
metapackage if it works. (Uploaded; hopefully the next build of the CD
will have the change.)

> How should I name the new metapackage? My first thought is just to move
> these packages from gnome-desktop-environment to gnome-core, and to make
> gnome-core the key package.

Sounds ok to me.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: unblock request for ikiwiki 3.20100815.3

[Joey Hess]

Mehdi Dogguy wrote:
> On 12/02/2010 02:53 AM, Joey Hess wrote:
> > Unfortunatly the security fix in ikiwiki 3.20100815.2 introduced a 
> > reversion in features that users of stable may already rely on. I've
> > fixed the fix in ikiwiki 3.20100815.3 (patch attached), please accept
> > from t-p-u.
> > 
> 
> Unfortunatly a .git directory appeared in the source package. Was this
> intended?

Clearly not, I forgot to build with -I. 3.20100815.4 uploaded.

-- 
see shy jo


signature.asc
Description: Digital signature

unblock request for ikiwiki 3.20100815.3

[Joey Hess]

Unfortunatly the security fix in ikiwiki 3.20100815.2 introduced a
reversion in features that users of stable may already rely on.
I've fixed the fix in ikiwiki 3.20100815.3 (patch attached),
please accept from t-p-u.

-- 
see shy jo
diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm
index d18585d..eccbf97 100644
--- a/IkiWiki/Plugin/meta.pm
+++ b/IkiWiki/Plugin/meta.pm
@@ -39,10 +39,10 @@ sub needsbuild (@) {
 	}
 }
 
-sub scrub ($$) {
+sub scrub ($$$) {
 	if (IkiWiki::Plugin::htmlscrubber->can("sanitize")) {
 		return IkiWiki::Plugin::htmlscrubber::sanitize(
-			content => shift, destpage => shift);
+			content => shift, page => shift, destpage => shift);
 	}
 	else {
 		return shift;
@@ -161,7 +161,7 @@ sub preprocess (@) {
 	# Metadata handling that happens only during preprocessing pass.
 	if ($key eq 'permalink') {
 		if (safeurl($value)) {
-			push @{$metaheaders{$page}}, scrub('', $destpage);
+			push @{$metaheaders{$page}}, scrub('', $page, $destpage);
 		}
 	}
 	elsif ($key eq 'stylesheet') {
@@ -235,7 +235,7 @@ sub preprocess (@) {
 		my $delay=int(exists $params{delay} ? $params{delay} : 0);
 		my $redir="";
 		if (! $safe) {
-			$redir=scrub($redir, $destpage);
+			$redir=scrub($redir, $page, $destpage);
 		}
 		push @{$metaheaders{$page}}, $redir;
 	}
@@ -245,7 +245,7 @@ sub preprocess (@) {
 join(" ", map {
 	encode_entities($_)."=\"".encode_entities(decode_entities($params{$_}))."\""
 } keys %params).
-" />\n", $destpage);
+" />\n", $page, $destpage);
 		}
 	}
 	elsif ($key eq 'robots') {
@@ -261,12 +261,12 @@ sub preprocess (@) {
 		push @{$metaheaders{$page}}, scrub('', $destpage);
+			' />', $page, $destpage);
 	}
 	else {
 		push @{$metaheaders{$page}}, scrub('', $destpage);
+			encode_entities($value).'" />', $page, $destpage);
 	}
 
 	return "";
diff --git a/debian/changelog b/debian/changelog
index 7810224..2502e1a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ikiwiki (3.20100815.3) testing; urgency=low
+
+  * meta: Fix calling of htmlscrubber to pass the page parameter.
+The change of the htmlscrubber to look at page rather than destpage
+caused htmlscrubber_skip to not work for meta directives.
+
+ -- Joey Hess   Mon, 29 Nov 2010 14:44:13 -0400
+
 ikiwiki (3.20100815.2) testing; urgency=low
 
   * Bugfix-only cherry-pick release for Debian squeeze.


signature.asc
Description: Digital signature

s...@latin locale debconf pre-depends issue

[Joey Hess]

As seen in #604153, debconf templates files with fields using a
l...@modifier locale such as s...@latin will fail to work with debconf
before 1.5.34. This needs to be fixed by the affected packages
Pre-Depending (not Depending) on debconf (>= 1.5.34)

Only tasksel and keyboard-configuration are currently affected.

Lintian maintainers CCed in case they would like to add a lintian check for
this. Presumably after the next release the Pre-Depends won't be
needed, but it could also be an issue for backports then.

Release team CCed since this is one of those cases where
something that looks entirely safe, like a l10n only upload, can
completly break a package in a non-obvious way. (Hardly the first time
*that*'s happened so I'm sure you're as wary as I am about translation
updates during freezes, right? :) Also because tasksel and
keyboard-configuration will need freeze exceptions.

-- 
see shy jo


signature.asc
Description: Digital signature

preapproval for ikiwiki 3.20100815.2 via t-p-u

[Joey Hess]

le type.
+   # Deal with comments that were just deleted.
+   my $source=exists $IkiWiki::pagesources{$page} ?
+   $IkiWiki::pagesources{$page} :
+   $IkiWiki::delpagesources{$page};
+   my $type=defined $source ? IkiWiki::pagetype($source) : undef;
+   if (! defined $type || $type ne "_comment") {
+   return IkiWiki::FailReason->new("$page is not a 
comment");
+   }
}
 
return match_glob($page, "$glob/*", internal => 1, @_);
diff --git a/IkiWiki/Plugin/external.pm b/IkiWiki/Plugin/external.pm
index ec91c79..a4cc1dd 100644
--- a/IkiWiki/Plugin/external.pm
+++ b/IkiWiki/Plugin/external.pm
@@ -28,7 +28,9 @@ sub import {
 
$plugins{$plugin}={in => $plugin_read, out => $plugin_write, pid => 
$pid,
accum => ""};
+
$RPC::XML::ENCODING="utf-8";
+   $RPC::XML::FORCE_STRING_ENCODING="true";
 
rpc_call($plugins{$plugin}, "import");
 }
diff --git a/IkiWiki/Plugin/htmlscrubber.pm b/IkiWiki/Plugin/htmlscrubber.pm
index 8475181..4a90c6f 100644
--- a/IkiWiki/Plugin/htmlscrubber.pm
+++ b/IkiWiki/Plugin/htmlscrubber.pm
@@ -57,8 +57,8 @@ sub sanitize (@) {
 
if (exists $config{htmlscrubber_skip} &&
length $config{htmlscrubber_skip} &&
-   exists $params{destpage} &&
-   pagespec_match($params{destpage}, $config{htmlscrubber_skip})) {
+   exists $params{page} &&
+   pagespec_match($params{page}, $config{htmlscrubber_skip})) {
return $params{content};
}
 
diff --git a/IkiWiki/Plugin/sortnaturally.pm b/IkiWiki/Plugin/sortnaturally.pm
index 62e4276..b038b2f 100644
--- a/IkiWiki/Plugin/sortnaturally.pm
+++ b/IkiWiki/Plugin/sortnaturally.pm
@@ -7,6 +7,7 @@ no warnings;
 
 sub import {
hook(type => "getsetup", id => "sortnaturally", call => \&getsetup);
+   hook(type => "checkconfig", id => "sortnaturally", call => 
\&checkconfig);
 }
 
 sub getsetup {
diff --git a/IkiWiki/Plugin/websetup.pm b/IkiWiki/Plugin/websetup.pm
index 11b4428..0ab1899 100644
--- a/IkiWiki/Plugin/websetup.pm
+++ b/IkiWiki/Plugin/websetup.pm
@@ -219,7 +219,8 @@ sub showfields ($$$@) {
options => [ [ 1 => $description ] ],
fieldset => $section,
);
-   if (! $form->submitted) {
+   if (! $form->submitted ||
+   ($info{advanced} && $form->submitted eq 'Advanced 
Mode')) {
$form->field(name => $name, value => $value);
}
}
@@ -295,6 +296,7 @@ sub showform ($$) {
$form->field(name => "do", type => "hidden", value => "setup",
force => 1);
$form->field(name => "rebuild_asked", type => "hidden");
+   $form->field(name => "showadvanced", type => "hidden");
 
if ($form->submitted eq 'Basic Mode') {
$form->field(name => "showadvanced", type => "hidden", 
diff --git a/debian/changelog b/debian/changelog
index 98d1337..89d9195 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+ikiwiki (3.20100815.2) UNRELEASED; urgency=low
+
+  * Bugfix-only cherry-pick release for Debian squeeze.
+  * Fix htmlscrubber_skip to be matched on the source page, not the page it is
+inlined into. Should allow setting to "* and !comment(*)" to scrub
+comments, but leave your blog posts unscrubbed, etc.
+  * comments: Make postcomment() pagespec work when previewing a comment,
+including during moderation.
+  * comments: Make comment() pagespec also match comments that are being
+posted.
+  * openid: Syntax tweak to the javascript code to make it work with MSIE 7
+(and MSIE 8 in compat mode). Thanks to Iain McLaren for reporting
+the bug and providing access to debug it.
+  * blogspam: Fix crash when content contained utf-8.
+  * external: Disable RPC::XML's "smart" encoding, which sent ints
+for strings that contained only a number, fixing a longstanding crash
+of the rst plugin.
+  * websetup: Fix saving of advanced mode changes.
+  * websetup: Fix defaults of checkboxes in advanced mode.
+  * Fix test suite failure on other side of date line.
+  * Set isPermaLink="no" for guids in rss feeds. 
+  * sortnaturally: Added missing registration of checkconfig hook.
+
+ -- Joey Hess   Sun, 15 Aug 2010 11:42:55 -0400
+
 ikiwiki (3.20100815) unstable; urgency=medium
 
   * Fix po test suite to not as

Re: chromium not in Squeeze: a bit of communication needed?

[Joey Hess]

Michael Gilbert wrote:
> A an option in the installer like volatile/security should address a
> lot of this concern.

Unless it installs the package from backports, the most the installer
can do is eliminate one or two of the three or four things users must
do to use it. All my comments about user discoverability/usability still
apply.

> > If backports are really officially supported, and we encourage users to
> > install a web browser from them, which is not available in stable, how
> > is that truely different than shipping the same web browser in stable?
> 
> The difference is that there is no arduous backporting/dsa process to
> push that update

If we're encouraging users to install a web browser from an officially
supported part of Debian, then the security support requirements are not
lessened *at all*.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: chromium not in Squeeze: a bit of communication needed?

[Joey Hess]

Michael Gilbert wrote:
> I think that this need is justification to declare backports "officially
> supported by the debian project".  Thus when asked this question, you
> can point to the fact that chromium is indeed supported on stable, just
> via a different model than folks are used to.

Do you really think that desktop users[1] should be expected to learn about
backports, and manually configure them, and learn how to convince apt to
install from them, in order to get the best web browser available[2]? If
the preceding sounds simple, think again; you're suggesting that users
have to either dig up some faq or forum post, or post to debian-user, just
in order to get a good web browser.

If backports are really officially supported, and we encourage users to
install a web browser from them, which is not available in stable, how
is that truely different than shipping the same web browser in stable?
AFAICS the only difference is that only 10 to 25% [3] of users will find
the web browser in backports, while some other percentage will
install Ubuntu instead. The security team will still be left responsible
for supporting the former users' systems.

(BTW, have you considered that apt does not automatically upgrade packages
installed from backports? That the majority of documentation, including
the documentation on wiki.debian.org, about installing flashplugin-nonfree
from backports does not take this into account, and will leave the user with
a never-upgraded package?)

-- 
see shy jo

[1] As opposed to the server administrators who seem to be backports'
main current audience.
[2] Chromium or iceweasel; take your pick since backports is being
suggested as a delivery mechanism for both.
[3] Estimate based roughly on percentage of stable users who manage to
install flashplugin-nonfree, whose installation is similarly obfuscated.


signature.asc
Description: Digital signature

Re: Freeze exception for debhelper 8.0.0

[Joey Hess]

Neil McGovern wrote:
> This seems eminently sensible.
> This seems fine.

8.0.0 uploaded with said changes, please unblock.

> At this stage of the release, I'd probably prefer to see the latter
> used, not breaking existing packages can be considered a good thing.

I left out the python fix, because it surely is not needed for any
package currently in the archive.

-- 
see shy jo


signature.asc
Description: Digital signature

Freeze exception for debhelper 8.0.0

[Joey Hess]

I'd like a freeze exception for debhelper 8.0.0. The minimum change
needed from version 7.9.4 is to set the version number to 8.0.0 and make
a minor documentation update to finalize v8 mode (see debhelper-patch-1).

My plan for v8 was to put in as many good things as possible before the freeze,
and call it finished when the freeze happened. This will avoid needing to
backport debhelper when backporting packages that use v8, after the release.
The only real impact of this change is that lintian may also need an update,
in order to stop warning on v8 use.

I also have two code changes that I made some time ago and didn't get around
to uploading, which I'd *prefer* to also include in debhelper 8.0.0. The
first of these is a minor permissions fix for files in /etc/sudoers.d/
for #589574 (see debhelper-patch-2).

The other patch (debhelper-patch-3) is the riskiest, passing --force to
setup.py could conceivably cause breakage. One option would be to only
enable this in v8 mode, which would make sure it doesn't break any existing
packages.

-- 
see shy jo
commit 5ade9075ad0fedee986d8aa08a1d4c4d3965356a
Author: Joey Hess 
Date:   Sat Aug 7 07:20:20 2010 -0400

Finalized v8 mode, which is the new recommended default.

diff --git a/debhelper.pod b/debhelper.pod
index 554b7f7..b2f130b 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -337,9 +337,9 @@ introduced. You tell debhelper which compatibility level it 
should use, and
 it modifies its behavior in various ways.
 
 Tell debhelper what compatibility level to use by writing a number to
-debian/compat. For example, to turn on v7 mode:
+debian/compat. For example, to turn on v8 mode:
 
-  % echo 7 > debian/compat
+  % echo 8 > debian/compat
 
 Unless otherwise indicated, all debhelper documentation assumes that you
 are using the most recent compatibility level, and in most cases does not
@@ -477,8 +477,6 @@ directory. In previous compatibility levels it silently 
refuses to do this.
 
 =item v7
 
-This is the recommended mode of operation.
-
 Changes from v6 are:
 
 =over 8
@@ -507,8 +505,7 @@ none is specified.
 
 =item v8
 
-This mode is still under development. Using it in packages will cause them
-to probably break later.
+This is the recommended mode of operation.
 
 Changes from v7 are:
 
diff --git a/debian/changelog b/debian/changelog
index 6a1ca77..2516ce7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-debhelper (7.9.4) UNRELEASED; urgency=low
+debhelper (8.0.0) UNRELEASED; urgency=low
 
   [ Carsten Hey ]
   * dh_fixperms: Ensure files in /etc/sudoers.d/ are mode 440. Closes: #589574
@@ -7,6 +7,7 @@ debhelper (7.9.4) UNRELEASED; urgency=low
   * python_distutils: Pass --force to setup.py build, to ensure that when
 python-dbg is run it does not win and result in scripts having it in
 the shebang line. Closes: #589759
+  * Finalized v8 mode, which is the new recommended default.
 
  -- Carsten Hey   Sun, 18 Jul 2010 22:30:06 +0200
 
commit eb9464fb4bbea788f2703a9bb3314dcd9fe2e0d5
Author: Carsten Hey 
Date:   Sun Jul 18 22:36:11 2010 +0200

Bug#589574: [PATCH] dh_fixperms: Ensure files in /etc/sudoers.d/ are mode 
440. Closes: #589574

Signed-off-by: Carsten Hey 

diff --git a/debian/changelog b/debian/changelog
index 628b043..c895d78 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+debhelper (7.9.4) UNRELEASED; urgency=low
+
+  * dh_fixperms: Ensure files in /etc/sudoers.d/ are mode 440. Closes: #589574
+
+ -- Carsten Hey   Sun, 18 Jul 2010 22:30:06 +0200
+
 debhelper (7.9.3) unstable; urgency=low
 
   * perl_makemaker: import compat(). Closes: #587654
diff --git a/dh_fixperms b/dh_fixperms
index 893ca56..65beac6 100755
--- a/dh_fixperms
+++ b/dh_fixperms
@@ -117,6 +117,13 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
"-type f $find_options -print0",
"2>/dev/null | xargs -0r chmod 644");
}
+
+   # Files in $tmp/etc/sudoers.d/ must be mode 440.
+   if (-d "$tmp/etc/sudoers.d") {
+   complex_doit("find $tmp/etc/sudoers.d",
+   "-type f ! -perm 440 $find_options -print0",
+   "2>/dev/null | xargs -0r chmod 440");
+   }
 }
 
 =head1 SEE ALSO
commit 865e6266a5eaae81004bf530bc23da1c3fdc10b1
Author: Joey Hess 
Date:   Sun Jul 25 13:40:39 2010 -0400

python_distutils: Pass --force to setup.py build, to ensure that when 
python-dbg is run it does not win and result in scripts having it in the 
shebang line. Closes: #589759

diff --git a/Debian/Debhelper/Buildsystem/python_distutils.pm 
b/Debian/Debhelper/Buildsystem/python_distutils.pm
index 70307b0..5115a8a 100644
--- a/Debian/Debhelper/Buildsystem/python_distutils.pm
+++ b/Debian/Debhelper/Buildsystem/python_distutils.pm
@@ -163,7 +163,9 @@ sub setup_py {
 
 sub build {
my $this=shift;
-   $this->setup_py("bui

Constantly Usable Testing BoF @ DebConf10

[Joey Hess]

I'd like to invite any Release and FTP team members who are attending
DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am.

http://penta.debconf.org/dc10_schedule/events/681.en.html

The purpose of the BoF is to finally explore whether it would make sense
to implement the Constantly Usable Testing idea[1], ways to do it, and
get feedback and advice from teams that could be affected by it.

So it would be great to have some dak and britney wranglers to give advice
on topics like:

* Snapshotting testing.
* How to support upgrades from old testing snapshots to current testing?
* Installability/usability of testing. Issues like important packages
  being temporarily removed due to RC bugs.
* Does testing get enough testing? Would having users use CUT improve
  that and help the quality of stable releases, or the opposite?

-- 
see shy jo

[1] http://kitenet.net/~joey/code/debian/cut/


signature.asc
Description: Digital signature

ikiwiki 1.33.6 / 2.53

[Joey Hess]

I've released ikiwiki backports for testing and stable, both fixing a
malformed UTF-8 DOS, which doesn't yet have a CVE.

For testing, I've uploaded 2.53.3 to tpu. This also includes an
unrelated minor bugfix backport. Please review/unblock.

For stable, I've prepared a 1.33.7, available in the debian-stable
branch of ikiwiki's git repository, or via the attached patch. Please
issue a DSA at your liesure (this is only a crasher DOS AFAIK, and at
least so far I don't know of a easy way to exploit it).

-- 
see shy jo
diff --git a/IkiWiki.pm b/IkiWiki.pm
index efacb20..9787b44 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -231,6 +231,9 @@ sub readfile ($;$) { #{{{
 	open (IN, $file) || error("failed to read $file: $!");
 	binmode(IN) if ($binary);
 	my $ret=;
+	if (! utf8::valid($ret)) {
+		$ret=encode_utf8($ret);
+	}
 	close IN;
 	return $ret;
 } #}}}
diff --git a/debian/changelog b/debian/changelog
index 0f68f26..8192872 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ikiwiki (1.33.7) stable-security; urgency=low
+
+  * Avoid crash on malformed utf-8 discovered by intrigeri. 
+
+ -- Joey Hess <[EMAIL PROTECTED]>  Wed, 12 Nov 2008 17:42:29 -0500
+
 ikiwiki (1.33.6) stable-security; urgency=low
 
   * Some error messages in recent backported security fixes used gettext,


signature.asc
Description: Digital signature

Re: Bug#498224: ikiwiki: Undefined subroutine &IkiWiki::beautify_urlpath during rebuild

[Joey Hess]

Marc 'HE' Brockschmidt wrote:
> I don't see it in the tpu queue?

It got stuck in my laptop's queue, but was accepted a few hours ago.

-- 
see shy jo


signature.asc
Description: Digital signature

zd1211-firmware

[Joey Hess]

zd1211-firmware (2.21.0.0-0.1) needs to get into testing so that it can
be re-enabled in the d-i firmware image.

-- 
see shy jo, not a list subscriber


signature.asc
Description: Digital signature

Re: Bug#498224: ikiwiki: Undefined subroutine &IkiWiki::beautify_urlpath during rebuild

[Joey Hess]

Dominic Hargreaves wrote:
> [EMAIL PROTECTED]:~$ ikiwiki --setup /etc/ikiwiki/sysdev.setup --rebuild
> successfully generated /var/lib/ikiwiki/sysdev.cgi
> successfully generated /var/lib/ikiwiki/sysdev.post-commit
> /etc/ikiwiki/sysdev.setup: Undefined subroutine &IkiWiki::beautify_urlpath 
> called at /usr/share/perl5/IkiWiki.pm line 565.
> BEGIN failed--compilation aborted at (eval 6) line 98.

This bug affects generation of rss/atom feeds, which was, oops, not
tested by default. Just uploaded fix in 2.53.2 to t-p-u.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: ikiwiki bugfix release

[Joey Hess]

Marc 'HE' Brockschmidt wrote:
> Please upload and ping again so that we can include it from tpu.

2.53.1 in tpu

-- 
see shy jo


signature.asc
Description: Digital signature

ikiwiki bugfix release

[Joey Hess]

d smileys.
+  * smileys: Note that smileys need to be double-escaped for the escaping to
+work. Markdown removes one level of escaping.
+  * Add a postscan hook.
+  * search: Use postscan hook, avoid updating index when previewing.
+  * search: Fixes for title stemming, and use better term for tags. (Gabriel McManus)
+(Rebuilding the wiki on upgrade to this version is recommended if you use the
+search plugin.)
+  * meta: fix title() PageSpec
+  * Really fix bug with links to pages with names containing colons. 
+Previous fix mised a few cases.
+  * toggle: Fix incompatability between javascript and webkit.
+  * toggle: Fix for when html got tidied. Closes: #492529 (Enrico Zini)
+  * inline: Ignore parent dirs when sorting pages by title.
+  * external: Fix support for hooks called in an array context.
+  * edittemplate: Don't wipe out edits on preview.
+  * map: The fix for #449285 was buggy and broke display of parents in certian
+circumstances.
+  * Work around perl $_ scoping nonsense that caused breakage when loading
+external plugins.
+
+ -- Josh Triplett <[EMAIL PROTECTED]>  Wed, 09 Jul 2008 21:30:33 -0700
+
 ikiwiki (2.53) unstable; urgency=low
 
   * search: generate configuration files once only when rebuilding
diff --git a/debian/control b/debian/control
index b29d5ff..a50c13c 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: ikiwiki
 Section: web
 Priority: optional
 Build-Depends: perl, debhelper (>= 5)
-Build-Depends-Indep: dpkg-dev (>= 1.9.0), libxml-simple-perl, markdown | libtext-markdown-perl, libtimedate-perl, libhtml-template-perl, libhtml-scrubber-perl, wdg-html-validator, libhtml-parser-perl, liburi-perl
+Build-Depends-Indep: dpkg-dev (>= 1.9.0), libxml-simple-perl, libtext-markdown-perl | markdown, libtimedate-perl, libhtml-template-perl, libhtml-scrubber-perl, wdg-html-validator, libhtml-parser-perl, liburi-perl
 Maintainer: Joey Hess <[EMAIL PROTECTED]>
 Uploaders: Joey Hess <[EMAIL PROTECTED]>, Josh Triplett <[EMAIL PROTECTED]>
 Standards-Version: 3.8.0
index ac6d6db..000
diff --git a/doc/plugins/map.mdwn b/doc/plugins/map.mdwn
index df34d77..af18a8f 100644
--- a/doc/plugins/map.mdwn
+++ b/doc/plugins/map.mdwn
@@ -1,8 +1,6 @@
 [[template id=plugin name=map author="Alessandro Dotti Contra"]]
 [[tag type/meta]]
 
-[[meta description="some page description"]]
-
 This plugin generates a hierarchical page map for the wiki. Example usage:
 
 	\[[map pages="* and !blog/* and !*/Discussion"]]
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 5def4c6..c9e4c4e 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -214,6 +214,17 @@ modify the body of a page after it has been fully converted to html.
 The function is passed named parameters: "page", "destpage", and "content",
 and should return the sanitized content.
 
+### postscan
+
+	hook(type => "postscan", id => "foo", call => \&postscan);
+
+This hook is called once the full page body is available (but before the
+format hook). The most common use is to update search indexes. Added in
+ikiwiki 2.54.
+
+The function is passed named parameters "page" and "content". Its return
+value is ignored.
+
 ### format
 
 	hook(type => "format", id => "foo", call => \&format);
@@ -559,12 +570,15 @@ time.
 
 This is the standard gettext function, although slightly optimised.
 
- `urlto($$)`
+ `urlto($$;$)`
 
 Construct a relative url to the first parameter from the page named by the
 second. The first parameter can be either a page name, or some other
 destination file, as registered by `will_render`.
 
+If the third parameter is passed and is true, an absolute url will be
+constructed instead of the default relative url.
+
  `targetpage($$)`
 
 Passed a page and an extension, returns the filename that page will be
diff --git a/doc/smileys.mdwn b/doc/smileys.mdwn
index 54ac539..4c19b05 100644
--- a/doc/smileys.mdwn
+++ b/doc/smileys.mdwn
@@ -1,47 +1,48 @@
 This page is used to control what smileys are supported by the wiki.
 Just write the text of a smiley to display it.
 
-* \:)	[[smileys/smile.png]]
-* \:-)	[[smileys/smile.png]]
-* \:D	[[smileys/biggrin.png]]
-* \:-D	[[smileys/biggrin.png]]
-* \B)	[[smileys/smile2.png]]
-* \B-)	[[smileys/smile2.png]]
-* \:))	[[smileys/smile3.png]]
-* \:-))	[[smileys/smile3.png]]
-* \;)	[[smileys/smile4.png]]
-* \;-)	[[smileys/smile4.png]]
-* \:\	[[smileys/ohwell.png]]
-* \:-\	[[smileys/ohwell.png]]
-* \:/	[[smileys/ohwell.png]]
-* \:-/	[[smileys/ohwell.png]]
-* \:|	[[smileys/neutral.png]]
-* \:-|	[[smileys/neutral.png]]
-* \>:>	[[smileys/devil.png]]
-* \X-(	[[smileys/angry.png]]
-* \<:(	[[smileys/frown.png]]
-* \:(	[[smileys/sad.png]]
-* \:-(	[[smileys/sad.png]]
-* \:-?	[[smileys/tongue.png]]
-* \:-P	[[smileys/tongue.png]]
-* \:o	

unblock sleepd 1.11

[Joey Hess]

Fixes a bug that basically prevents sleepd from working on boot.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Preparation of the next stable Debian GNU/Linux update

[Joey Hess]

I'm wondering who wrote:
> > As linux-modules-extra-2.6-etchnhalf was not ready in time we decided to
> > skip it for r4 and include it in r5.
 
Frans Pop wrote:
> Well done folks. You've again managed to break at least part of the 
> functionality of Debian Installer and, more importantly, left users with 
> a potentially unbootable system after installation.

 You can now partition using loop-aes encryption, but the modules are not
  available for the installed system.
 So you cannot access any loop-aes encrypted partitions.
 Or (hopefully) the installation will fail during finish-install.

Well, it would seem we have the first peice of errata for the end of
http://www.debian.org/releases/etch/debian-installer/etchnhalf

How many months do we plan to let users stumble over this before r5?

> This is the third time since Etch where a stable release involving 
> something I have spent a serious amount of my time on is mishandled by 
> the release team.
> I've had it with this mentality where apparently it is OK to just skip 
> proper and timely preparation of releases, where it is OK to do things at 
> the very last possible moment, break promises made to colleague DDs and 
> break their work without any prior communication at all.

We're very good at releasing every day / week (hello, britney, debian-cd). We
*suck* at releasing every X years where every single thing is ad-hoc. As long
as stable release frequency is random and release preparations are ad-hoc, we
will continue to have such problems.

> As you obviously don't appreciate the work done by others to get things to 
> the point that a release is possible, I will not participate in ANYTHING 
> that has to do with releasing Lenny anymore, which means I'm dropping per 
> now a lot of my D-I work, debian-cd work, documentation work and website 
> work and any testing work I normally do.

It might help your motivation slightly to think of stable as a sub-par and
largely irrelevant derived distribution bolted onto the side of the real
Debian.

-- 
see shy jo, who at least can stop feeling bad about his original slink-and-half
release. Apparently being an official Debian release would not have
made it any better..


signature.asc
Description: Digital signature

Re: Bug#491263: network-console, etch netinst, openssh

[Joey Hess]

Perhaps we should issue a special DSA about openssh fixes in d-i
once the next point release is available? In particular, anyone
using d-i with network-console needs to make sure to update their
installation media / netboot files.


Also, network-console's copying of the ssh_host_rsa_key in
finish-install looks like it was a bad choice, because it doesn't allow
ssh to overrule the key. For lenny, it would be better if it used a
base-installer hook to install the keys before ssh got installed.

ssh's postinst will behave sanely if host keys are already present when
it's first installed: It will not overwrite them, and will check that
they're strong and prompt with debconf about overwriting them. 

So, untested:

Index: debian/changelog
===
--- debian/changelog(revision 54461)
+++ debian/changelog(working copy)
@@ -1,8 +1,13 @@
 network-console (1.18) UNRELEASED; urgency=low
 
+  [ Martin Michlmayr ]
   * Change the health LED to solid blue on the HP mv2120 to indicate
 when the installer is ready for ssh connections.
 
+  [ Joey Hess ]
+  * Install ssh keys before ssh is installed, to allow it to check them for
+weakness.
+
  -- Martin Michlmayr <[EMAIL PROTECTED]>  Mon, 14 Jul 2008 22:46:28 +0300
 
 network-console (1.17) unstable; urgency=low
Index: finish-install
===
--- finish-install  (revision 54461)
+++ finish-install  (working copy)
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e
-
-DIR=/etc/ssh/
-
-[ -d /target/$DIR ] || exit 0
-
-cp $DIR/ssh_host_rsa_key* /target/$DIR
Index: post-base-installer
===
--- post-base-installer (revision 0)
+++ post-base-installer (revision 0)
@@ -0,0 +1,7 @@
+#!/bin/sh
+set -e
+
+DIR=/etc/ssh/
+
+mkdir -p /target/$DIR
+cp $DIR/ssh_host_rsa_key* /target/$DIR

Property changes on: post-base-installer
___
Added: svn:executable
   + *

Index: Makefile
===
--- Makefile(revision 54461)
+++ Makefile(working copy)
@@ -9,8 +9,8 @@
install -m755 gen-crypt network-console network-console-menu 
$(DESTDIR)/bin
install -d $(DESTDIR)/etc/ssh
install -m644 sshd_config $(DESTDIR)/etc/ssh
-   install -d $(DESTDIR)/usr/lib/finish-install.d/
-   install -m755 finish-install 
$(DESTDIR)/usr/lib/finish-install.d/80network-console
+   install -d $(DESTDIR)/usr/lib/post-base-installer.d/
+   install -m755 post-base-installer 
$(DESTDIR)/usr/lib/post-base-installer.d/80network-console
 
 clean:
rm -f gen-crypt

-- 
see shy jo


signature.asc
Description: Digital signature

[RFC] in-d-i upgrades

[Joey Hess]

I've been working on a fix for bug #479431, and before I apply it to
d-i, I want to make you aware of it, since it can have repercussions to
DSAs and release management.

To summarize the problem for non-d-i developers: 

  If a user is installing from a CD or mirror, debootstrap is used to
  install packages from that CD/mirror, and d-i also installs a kernel
  and some other packages, before security.debian.org is configured as
  an apt source. So, many installations do not get all security updates
  applied, until the user manually upgrades the system later. This is a
  potentially crucial window to close.

  While it might be nice for debootstrap to pull in security fixes from
  security.debian.org from the beginning, this is not possible given its
  current design, and some of its constraints such as needing to be
  implemented portably and run in the limited d-i environment also make
  it hard to it have this capability.

Rather than change debootstrap, I modified d-i to upgrade packages that
debootstrap has installed, once security sources are available. The
problem with doing such an upgrade inside d-i, though, is that it
exposes installations to the entire class of problems that can occur
during an upgrade[1], and breaks the installation process if the upgrade
fails for some reason.

So if we make this change to d-i, the security and release teams can be
affected.

security teams:

  If you're making a D[T]SA for a package that is installed by
  debootstrap, or of the kernel, or of (some) of the other packages listed
  at  (d-i* files), you
  will need to keep in mind that d-i will upgrade it to the fixed version
  inside the d-i environment, and that all the issues I list in [1] should
  be avoided.

  Notable amoung these are avoiding non-debconf prompts, which can
  hang/confuse d-i, and trying to avoid prompts that don't make sense in d-i,
  such as the kernel's warning about upgrading a running kernel version.

release team:

  I guess the main impact will be that, after a d-i release candidate is
  available, any updates to base or the d-i noremove.d packages have the
  potential to cause any of the abovementioned upgrade problems, and if
  that happens, someone will have to notice and fix it. 
  
I don't like that this change adds a new class of problems to watch out
for, and tends to make things a bit more fragile. But having new
installs boot up to an insecure kernel, running insecure daemons, when
fixes are available on security.debian.org, is just too large a risk to
leave in the installer in a world where windows machines are known to be
hacked into in the period between their first boot and application of
security fixes.

(By the way, it will be possible to disable the upgrades, eg by booting
d-i with "pkgsel/upgrade=none".)

-- 
see shy jo

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479431#69


signature.asc
Description: Digital signature

Re: Mechanism in place to prevent some packages from being removed from testing

[Joey Hess]

Pierre Habouzit wrote:
>   Note that less than a week after having been removed, mplayer and lilo
> have been fixed. It's fun to see how easy it is to fix "unsolvable" bugs
> with the proper incentive.

I'm really glad that mplayer is finally fixed. That was apparently
indeed a good example of a case where a little motivation went a long
way.

The lilo fix is only a workaround. Systems can still get a large
initramfs, and have lilo abort, and end up failing to boot.

Another case is NTP, which was kicked out of testing for a
licensing bug, causing much grief to be reported on debian-user.

I think that the release team is being far too cavalier about the
collatoral damage their policies are causing. And, apparently, much too
enamoured of slavish adherence to policies and procedures.

When I was a minor member of the release team, I always tried to think
through the consequneces of my decisions. And I have always been proud
of the care, attention to detail, and followthrough that the release
managers have brought to their work. Something seems to have changed..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: d-i uses bootloaders

[Joey Hess]

A new one to add to list:

ixp4xx-microcode  [armel]

-- 
see shy jo


signature.asc
Description: Digital signature

Re: d-i uses bootloaders

[Joey Hess]

Adeodato Simó wrote:
> yaird

Another one missing. This breaks a small corner of d-i's UI. If yaird is
not going to be added back to testing (and looking at the BTS, I doubt
it will), we should modify d-i to not offer it as an option.

> vmelilo: m68k-only, not in testing.

Of course it's fine if non-release arch stuff is not in testing.

> libc6-sparcv9: only in stable?

It's ok to ignore this one, d-i will not break if it's not present to
install.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: d-i uses bootloaders

[Joey Hess]

Frans Pop wrote:
> Jérémy posted a full list that included all these in the thread about 
> #484129 and d-release was CCed in that mail: 
> <[EMAIL PROTECTED]>

And luk added the removal hint for lilo on 20080614 or 20080610 -- after
Jérémy sent that list.

BTW, I've double-checked (ie, generated my own since I didn't know about
his) the list. I'd add linux-2.6 and linux-modules-extra-2.6 to it,
otherwise we made identical lists..

-- 
see shy jo


signature.asc
Description: Digital signature

d-i uses bootloaders

[Joey Hess]

As a followup to #484129, I'd like to remind the release team that d-i
uses and installs bootloaders. These include, but are not limited to
grub, syslinux, ***LILO***, elilo, vmelilo, silo, aboot, palo, amiboot,
arcboot, emile, apex-nslu2, sibyl, colo, delo, quik, and yaboot. This is
the thick end of the wedge of packages that d-i installs, frankly it's
the ones I'd have thought obvious. (Sorry, still no complete list.)

Removing these bootloaders from testing w/o communicating with the d-i
team sucks, because you break d-i in horrible, terrible ways[1] without
letting the team know.

-- 
see shy jo

[1] That tend to boil down to "debian erased my operating system,
and then failed to boot!"


signature.asc
Description: Digital signature

Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion

[Joey Hess]

Adeodato Simó wrote:
> Could there be one? Well, if you're interested in having the same
> safeguard mechanism in place for these packages.

It would be nice to have one, but many different parts of d-i decide
what to apt-install, so extracting a list is hard.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion

[Joey Hess]

Andreas Barth wrote:
> What we should make sure then is that britney recognizes these cases,
> and shows "breaking task foo" for that. Is there a reasonable way to
> generate pseudo-packages "taskel-$task" that depend on all the packages
> that need to be present to not break anything?

You could use the information about key packages listed in
/usr/share/tasksel/debian-tasks.desc

However, there is no equivilant source of information for packages
apt-installed by d-i.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion

[Joey Hess]

Pierre Habouzit wrote:
>   Well in your list, there are several intersting examples. lv for
> example, has many replacements. That may not have all the features of
> lv, but that are a decent replacement. Moreover lv isn't _that_ known,
> and if this task doesn't install lv, noone will be hurt. OTOH of course,
> we won't remove xfce4.

In the specific example of lv, if you remove it from testing, tasksel
will decide not to use the japanese tasks.

>   Usually those non explicit goals depends upon meta-packages like
> kde-core/kde/gnome/xfce4/... And we trust maintainers of those
> meta-packages to provide dependencies on the really hot stuff.

No, as I've already demonstrated, it's much more complicated than that,
and removal of lots of leaf packages that you may not consider important
at all can affect tasksel and the installer in various ways.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion

[Joey Hess]

Pierre Habouzit wrote:
>   No, tasks are not our concern directly, as it lists many packages that
> any user can live without, without being hurt or even impeded. The sole
> thing that matters is the priority, but packages with high priorities
> are hardly leaves packages as a general rule.

Tasksel is designed to continue working if not all packages in a task
are available, but at the same time most tasks have certian Key packages
which, if unavailable, will prevent the task from being used at all. The
idea is that, without those packages, the task cannot be performed at
all.

Most of these are low priority, and some (starred below) are leaf packages.
The release team should be aware of this, and should try to avoid killing
tasks by removing them unnecessarily, and should probably communicate to the
tasksel maintainers if it does need to remove them.

 language-env
*ttf-sil-abyssinica
 manpages-pt
*jfbterm
*zhcon
 console-cyrillic
 t1-cyrillic
 postgresql
 xorg
 xserver-xorg-video-all
 xserver-xorg-input-all
 desktop-base
 menu
 iceweasel
 bind9
 nfs-kernel-server
 samba
 manpages-fr
 manpages-de
 gnome-desktop-environment
 gsfonts-x11
 ttf-dejavu
 ttf-freefont
 xfonts-base
*manpages-it
 manpages-ja
*lv
 kde-core
 kdeadmin
 kdeartwork
 kdegraphics
 kdemultimedia
 kdenetwork
 kdeutils
 kdepim
 kdm
 acpid
 hibernate
 anacron
 cupsys
 cupsys-client
 cupsys-bsd
*manpages-ru
 manpages-es
*manpages-tr
 apache2-mpm-prefork
*xfce4
 gdm

Beyond tasksel, your criteria that low priority leaf packages can be removed
at any time is flawed. Another example is that d-i apt-installs a variety of
low priority leaf packages. I don't have a complete list of those.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#484009: ftp.debian.org: Core gnome metapackages removed from Lenny breaks gnome desktop

[Joey Hess]

Pierre Habouzit wrote:
>   First it's not part of a task, as it's pulled by a chain of
> recommends.

Tasksel does not use recommends; update-notifier is part of the
gnome-desktop task (apt-cache show will show you the Task field).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: debhelpers "dh_pycentral: failed to write to log" fails

[Joey Hess]

[ This isn't the right list. ]

Soeren Sonnenburg wrote:
> Only on mips and mipsel dh_pycentral dies for shogun:
> 
> dh_pycentral -pshogun-python
> dh_pycentral: failed to write to log
> make: *** [debian/stamp-build-python] Error 1
> 
> http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=shogun
> 
> I don't see the reason why it fails as the module is included in
> dh_python use Debian::Debhelper::Dh_Lib; and
> the /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm open call looks OK to
> me.
> 
> # Run at exit. Add the command to the log files for the packages it acted
> # on, if it's exiting successfully.
> my $write_log=1;
> sub END {
> if ($? == 0 && $write_log) {
> my $cmd=basename($0);
> foreach my $package (@{$dh{DOPACKAGES}}) {
> my $ext=pkgext($package);
> --> open(LOG, ">>", "debian/${ext}debhelper.log") || error("failed to 
> write to log");
> print LOG $cmd."\n";
> close LOG;
> }
> }
> }
> 
> Anyone seeing similar things?

Combination of fun factors:

- mips* run the binary and clean target as real root
- cdbs runs dh_listpackages *after* dh_clean, thereby leaving root-owned
  logfiles behind after clean
- your rules file, for some reason, runs dh_pycentral in a build target
  (instead of the much more common binary target .. can that possibly be
  right?), which is not run as root and so cannot write to the log files

I've put a (partial) fix into debhelper 7.0.3.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Freeze exception for dpkg 1.14.18

[Joey Hess]

Lucas Nussbaum wrote:
> And most of the bugs have been filed within days, and
> fixed already. It's possible that some packages were broken in more
> subtle ways not resulting in a build failure, but we still have 5 months
> to find them.

Wouldn't it be better to have 18 months to find them? This change could
have been delayed 5 months with no downside that I can see. Instead
we're left wondering how many packages might accidentially pass broken
CFLAGS into subdirectories, build successfully, and yet change behavior
in unknown ways. These bugs can be exposed at any time up till the hard
freeze as a given package is uploaded and gets recompiled for the first
time since the change.

Effectively, we've chosen "it builds -- ship it!"

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposed release goal : icon caches

[Joey Hess]

(This seems sorta offtopic for -release.)

Josselin Mouette wrote:
> The libgtk2.0-bin package would still have to be installed by something,
> in this case. Maybe as a Recommends: for gnome-icon-theme?

Recoomends are still not installed by default in all cases (d-i) so it
would be better to have it as a dependency. I assume that if you're
installing gnome icons, a dependency from them on gtk is not excessive..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposed release goal : icon caches

[Joey Hess]

Andreas Barth wrote:
> Actually, I think it should be first part of Policy before approving it
> as release goal.

Debian systems, as it stands, are at a high risk of being broken when
many third-party debs are installed on them. Especialy if those debs were
built on an Ubuntu system.

You don't think that we should try to fix this before the fix has gotten
into policy? Bear in mind that the policy process
a) takes a long time to a very long time
b) is currently in a weird mix of a state of stagnentation and incipient
   flux, based on talks at DebConf 
c) tends to want a thing widely implemented before it goes into policy

I thought that the release goals were useful as a way to work toward
changes that would later get into policy, by letting something get
implemented first -- so it's suprising to hear you think they need to be
in policy first.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposed release goal : icon caches

[Joey Hess]

Loïc Minier wrote:
>  So I understand that we will need a second NMU round after doing this
>  change?
> 
>  I proposed a slightly different approach at:
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=407837>
>  with basically one more level of indirection (directories for icon
>  caches are not directly updated by the maintainer scripts; instead a
>  wrapper updates them if necessary / possible)
> 
>  I requested feedback from Joey Hess directly, and mentionned the idea
>  to Josselin, but didn't receive any comment on the benefits of this
>  level of indirection.  The advantages are numerous IMO:

Please bear in mind that I'm involved in this discussion only as the
maintainer of debhelper. Whatever solution Debian decides on and
implements is the one debhelper will use. I have no particular expertise
with gtk, icons, or icon caches, and am the wrong person to vet your
designs (except for the parts of them that touch debhelper, which for a
good design in Debian, should be a very narrow part).

The only other thing I've brought to this is an awareness that I think
others share that this issue needs to be resolved *soon* -- the longer
Debian goes without something handling updating the icon caches, the
more users will break their system by installing some third-party deb or
other thing that creates icon caches.

So based on that, it's probably not suprising that as soon as Joss sent
me a patch that is a) working and b) has a transition plan that dosesn't
involve (much of) a flag day, I accepted it. If a better thing gets
implemented, I'll want to change debhelper to use it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposed release goal : icon caches

[Joey Hess]

(This subthread feels OT to Debian-release.. please direct any followups
to -devel or something.)

Raphael Hertzog wrote:
> Ubuntu already has a "dh_iconcache" AFAIK. What approach did they use? Is
> there anything for us to reuse?

Please see bug #369755.

> If this new mechanism is going to replace the mechanism invented by
> Ubuntu, it would make sense to reuse the same script name.

Not if it has a significantly different behavior. Also, I prefer to vet
debhelper script names before they are added to Debian, and dh_icons is
IMHO more appropriate, since it shouldn't be limited to icon cache
issues.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposed release goal for lenny: Switch to dependency based boot system

[Joey Hess]

Steve Langasek wrote:
> What do the dependency-based init system replacements that have been
> proposed to date do in order to handle init scripts that don't have LSB
> headers?  Is there some sort of backwards-compatibility interface so that
> those init scripts will at least be run?

Based on a conversation I had with Pere, insserv assumes such
scripts have *no* dependencies, and runs them first. :-(

-- 
see shy jo


signature.asc
Description: Digital signature

ikiwiki 1.33.3 TPU (deja vu)

[Joey Hess]

I've just uploaded ikiwiki 1.33.3 to TPU. This backports a security fix
for a bug that allows injection of problimatic stylesheets and
javascript via the meta tag. The diff is a bit larger for this one than
for the last one..

-- 
see shy jo


signature.asc
Description: Digital signature

ikiwiki 1.33.2 TPU

[Joey Hess]

I've just uploaded ikiwiki 1.33.2 to TPU. This backports a security fix
for a bug that allows injection of arbitrary html by including it in
the page title.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#413469: ion3: The package is outdated

[Joey Hess]

Norbert Tretkowski wrote:
> If you change the license in the next release, we can't update the
> package in unstable, because of the broken license.

His proposed license, somewhat like the tex license, allows us to
distribute it as long as it's renamed.

Tumov has kindly written ion2 and doesn't have a problem with us
distributing it in stable. If you respect that, it's worth granting some
respect to his wishes to not have to deal with a random development
snapshot indefinitely.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RC-ness of this bug

[Joey Hess]

Robert Millan [ackstorm] wrote:
> I urge you to reconsider severity of this problem.  There's another situation
> that makes it much worse:
> 
>   - User boots off USB stick
>   - sda is USB, sdb is SCSI or SATA
>   - GRUB install on (hd0) (i.e. sda) fails.
>   - Manual repairing is not possible, because if you boot a rescue system
> off USB stick, root disk will still be sdb.

Is this theoretical with SATA, or have you reproduced it?

The usb sticks include sata-modules as well as usb-modules, so AFAICS,
hardware detection should happen in the same order when booting from the
usb stick as booting from eg, netboot.

And I don't understand your report about problems with SCSI either,
since the USB stick also includes all SCSI modules.

-- 
see shy jo


signature.asc
Description: Digital signature

apt

[Joey Hess]

apt 0.6.46.4-0.1 needs a review and unblock. d-i is completly broken
until this gets into testing. I think that all arches are now built, and
I hope this can get in tonight..

(While reviewing, you may want to keep in mind that this breakage was
triggered by the new version of debian-archive-keyring, and was
basically impossible to catch in any review that did not include running
a debootstrap using the package. FWIW, I've done a debootstrap of i386
using apt 0.6.46.4-0.1.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: zd1211-firmware: diff for NMU version 2.16.0.0-0.1

[Joey Hess]

Joey Hess wrote:
> 3721fe605336a2facf4c15zd1211-WS11Ur.fw
> zd1211_ur

Of course that's not the full md5sum. The correct one is
24942601c03721fe605336a2facf4c15

-- 
see shy jo


signature.asc
Description: Digital signature

zd1211-firmware: diff for NMU version 2.16.0.0-0.1

[Joey Hess]

[debian-release: This mail serves as both an NMU diff an an unblock request.
Please review and unblock.]

I have uploaded an NMU of zd1211-firmware to the 5 day delayed queue.
This upgrades it to a new upstream version, so providing a complete NMU
diff is tricky. I have attached a diff for the packaging changes. The
changes to the firmware blobs consist of renaming the existing ones, and
adding several new ones, as follows:

md5sum  old new
86c2d2fae72e8921b510d7bd13be4c24zd1211-WS11Ub.fwzd1211_ub
432ac12a108496ea074eac59ac36bbb3zd1211-WS11UPh.fw   zd1211_uph
a3d88304fcf81bf6e6723929f3cf5118zd1211-WS11UPhm.fw  zd1211_uphm
491aeb0e0d558c9461445979fe9ef074zd1211-WS11UPhR.fw  zd1211_uphr
3721fe605336a2facf4c15  zd1211-WS11Ur.fwzd1211_ur
0a8573604fa5ce9761b717610765f335N/A zd1211b_ub
432ac12a108496ea074eac59ac36bbb3N/A zd1211b_uph
8e20edaee2720dfa1d708376477e7613N/A zd1211b_uphm
78292aa7cc304f7e765c9c11308c480cN/A zd1211b_uphr

As noted in the changelog, I have made sure that it provides the same
filenames (and md5sums) as the old version did, to avoid breaking
anything with the zd1211 driver, while also providing the new filenames
and new firmwares for the zd1211rw driver.

I've also confirmed that the current version of the zd1211-source driver
does not need or try to use any of the new firmware files. (FWIW, it
doesn't try to use zd1211-WS11UPh.fw at all either.) And I've checked
that zd1211 stull successfully loads the firmware files. Therefore I feel
that the possibility of breakage introduced by my changes is very low.

-- 
see shy jo
diff -Nru /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/README /home/joey/tmp/YCkCJDEfEp/zd1211-firmware-2.16.0.0/README
--- /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/README	1969-12-31 19:00:00.0 -0500
+++ /home/joey/tmp/YCkCJDEfEp/zd1211-firmware-2.16.0.0/README	2006-12-30 17:23:40.0 -0500
@@ -0,0 +1,31 @@
+README
+
+This distribution contains the firmware files for the
+ZD1211 chip, which is used in WLAN USB sticks. Copy these files to
+/lib/firmware/zd1211, where it can be loaded by the rewritten
+zd1211 driver.
+
+The files are generated from C header files distributed in the
+original ZyDAS ZD1211 driver under the GNU Public License.
+
+The full source of the original ZYDAS driver is available from
+http://www.deine-taler.de/zd1211/.
+
+HISTORY
+
+VERSION 1.3 (2006-12-30)
+Sync to vendor driver v2.16.0.0
+Large packet support is now disabled. The zd1211 firmware is now the same as
+v1.1 but the zd1211b firmware is new: It is the same which is shipped in the
+2.10.0.0 release which supposedly fixes a "reboot issue"
+
+VERSION 1.2 (2006-07-22)
+Sync to vendor driver v2.13.0.0
+Release notes mention that this firmware includes largepacket support
+
+VERSION 1.1 (2006-04-30)
+Added ZD1211B firmware files
+
+VERSION 1.0 (2006-04-16)
+This firmware has been generated from fersion 2_5_0_0 of the Zydas
+driver, 2006-04-16.
diff -Nru /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/debian/changelog /home/joey/tmp/YCkCJDEfEp/zd1211-firmware-2.16.0.0/debian/changelog
--- /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/debian/changelog	2007-02-21 16:15:05.0 -0500
+++ /home/joey/tmp/YCkCJDEfEp/zd1211-firmware-2.16.0.0/debian/changelog	2007-02-21 16:15:06.0 -0500
@@ -1,3 +1,25 @@
+zd1211-firmware (2.16.0.0-0.1) unstable; urgency=low
+
+  * NMU
+  * New upstream release. This is version 1.3 from
+http://sourceforge.net/projects/zd1211/, which is in turn derived from
+version 2.16.0.0 from Zydas. Keeping the Zydas version number to avoid
+introducing an epoch in an NMU.
+  * Old firmware files are not changed by this release (md5sums
+identical), but 5 new ones needed by other hardware are added.
+Closes: #363271
+  * Use symlink farm to provide the firmware in the locations used by the
+zd1211rw in-kernel driver, as well as the zd1211 extra-kernel driver.
+Closes: #383604
+  * Should be suitable for etch release now. Closes: #411912
+  * Modify package description to note that it will work with both the
+out of tree and in-tree kernel modules.
+  * Downgrade recommends of zd1211-module to a suggests, since the in-kernel
+module will also work.
+  * Current standards-version (no changes).
+
+ -- Joey Hess <[EMAIL PROTECTED]>  Wed, 21 Feb 2007 15:09:09 -0500
+
 zd1211-firmware (2.4.0.0-1) unstable; urgency=low
 
   * new firmware from upstream. this dropps the -b version
diff -Nru /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/debian/control /home/joey/tmp/YCkCJDEfEp/zd1211-firmware-2.16.0.0/debian/control
--- /home/joey/tmp/LVqfDExHoz/zd1211-firmware-2.4.0.0/debian/control	2007-02-21 16:15:05.0 -0500
+++ /home/joey/tmp/YCkC

TPU ikiwiki 1.33.1

[Joey Hess]

I've uploaded ikiwiki 1.33.1 to TPU, fixing a security hole I recently
found that allowed injection of malicious CSS and possibly images and
other file types into wikis over the web. Please review and accept into
testing.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: debian-installer build deps testing/unstable divergences

[Joey Hess]

Steve Langasek wrote:
> These changes include a bump to the debhelper compat level with no apparent
> rationale, in addition to the extensive upstream changes; I'm not
> comfortable unblocking this (and it hardly seems I would have a chance to
> anyway, we're already at version 1.4.15 in unstable now).  It sounds like
> any differences between the two versions are already worked around, so that
> this shouldn't be an issue for d-i?

Well, it still remains a problem if d-i images include a version of apex
that is not included in testing..

-- 
see shy jo


signature.asc
Description: Digital signature

debian-installer build deps testing/unstable divergences

[Joey Hess]

These are d-i build deps that provide files that go on d-i images, that
currently have different versions in unstable and testing. The
significance is that since rc2 will be built on the autobuilders, it
will build against the unstable versions of these packages.

 libc6 | 2.3.6.ds1-10 |   testing | amd64, arm, hppa, i386, m68k, mips, 
mipsel, powerpc, s390, sparc
 libc6 | 2.3.6.ds1-10 |  unstable | m68k, s390, sparc
 libc6 | 2.3.6.ds1-11 |  unstable | amd64, arm, hppa, i386, mips, 
mipsel, powerpc

IIRC this is targeted at testing, so no problem.

libnewt-pic |   0.52.2-9 |   testing | alpha, amd64, arm, hppa, i386, ia64, 
m68k, mips, mipsel, powerpc, s390, sparc
libnewt-pic |  0.52.2-10 |  unstable | alpha, amd64, arm, hppa, hurd-i386, 
i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

No significant to d-i changes according to the changelog..

  syslinux | 3.31-1 |   testing | source, amd64, i386
  syslinux | 3.31-2 |  unstable | source, amd64, i386

A fun new feature that would be nice for amd64+i386 CDs, if it is
allowed into testing.

apex-nslu2 |  1.4.7 |   testing | arm
apex-nslu2 | 1.4.14 |  unstable | arm

Several changes. (New version also makes d-i FTBFS though that should be
easy to fix.)

-- 
see shy jo


signature.asc
Description: Digital signature

tasksel 2.66

[Joey Hess]

Changes since 2.63 include one code change, which fixes the other half
of the cause of RC bug 406630, and numerous changes to deal with
iceweasel's migration to etch. As usual, all the task membership changes
are already live in the overrides files.

I've tested this version of tasksel in an etch chroot and it seems to
work ok.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Choice of default browser for etch

[Joey Hess]

Steve Langasek wrote:
> Do you have any insight into what's been breaking it?  If the release team
> is doing something wrong here, I'd like to know what it is so we can do
> better.

Well, there was #405639, and then breakage caused by my attempts to work
around it. There was #406630, which was my bug, but wasn't caught by
release team review either. I'd suggest incorporating more testing into
the review process of these core packages, especially ones that involve
tasksel, which is not normally tested much in unstable.

-- 
see shy jo


signature.asc
Description: Digital signature

tasksel 2.61

[Joey Hess]

Changes since 2.58 are mostly task changes, and translation updates. At
least one line of code was changed. Getting this in has suddenly become
somewhat urgent, since it has a workaround for #405639, which has
completely broken all desktop tasks.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Solving the linux-2.6 firmware issue

[Joey Hess]

Frederik Schueler wrote:
> Does this create any trouble, beside the package having to go through
> the NEW queue? 

If it's only a renaming of the source package, and not a change to the
form of the binary package names, then I don't see any problem from a d-i
or debian-cd POV.

-- 
see shy jo


signature.asc
Description: Digital signature

please carefully review debconf 1.5.11 and unblock

[Joey Hess]

This new version of debconf fixes an RC bug that affects the graphical
installer. Or it destroys all systems on the planet. Up to you to
decide. We've tested it in d-i and in an aptitude upgrade.

There's also some translation updates, and quite a lot of the kind of
gratuitious po files changes that translation systems produce when you
relocate a translated string to a different line number.

-- 
see shy jo, who wouldn't feel right letting a freeze go by w/o a debconf upload


signature.asc
Description: Digital signature

unblock sash 3.7-7.2

[Joey Hess]

I've NMUed it to work around a CDBS change that caused its
LDFLAGS=-static setting in its Makefile to be overridden. Non-static
sash is not very useful as noted in the bug report. :-)

-- 
see shy jo


signature.asc
Description: Digital signature

znc 0.045-3

[Joey Hess]

znc 0.045-3 in incoming fixes a security hole, please review and unblock

Note that the fix is known to be less than ideal, since it also
disallows files with ".." in their name. But it's the quick fix that
upstream developed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: tasksel 2.58

[Joey Hess]

I'm still hoping to see 2.58 get into etch, because #386244 is a really
*nasty* bug, even though it won't effect enough users to be RC.

I also still hope to release a tasksel 2.59, which would probably be
limited to task changes (some of which are already active in the
override files) and translations. But I can't do that until 2.58 gets
reviewed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: tasksel 2.58

[Joey Hess]

Marc 'HE' Brockschmidt wrote:
> There are some changes to the Makefile that have no fitting changelog entry:
> 
> @@ -49,7 +49,6 @@
>  install-data:
> install -d $(DESTDIR)$(TASKDIR) \
> $(DESTDIR)/usr/lib/tasksel/tests \
> -   $(DESTDIR)/usr/lib/tasksel/info \
> $(DESTDIR)/usr/lib/tasksel/packages
> install -m 0644 $(TASKDESC) $(DESTDIR)$(TASKDIR)
> for test in tests/*; do \
> @@ -58,9 +57,6 @@
> [ "$$test" = "tests/lang" ] && continue; \
> install -m 755 $$test $(DESTDIR)/usr/lib/tasksel/tests/; \
> done
> -   for script in info/*; do \
> -   install -m 755 $$script $(DESTDIR)/usr/lib/tasksel/info/; \
> -   done
> for package in packages/*; do \
> [ "$$package" = "packages/list" ] && continue; \
> install -m 755 $$package 
> $(DESTDIR)/usr/lib/tasksel/packages/; \

  * xserver-xorg has been changed in version 7.1.0-5 to do all hardware
detection in its postinst, and so the desktop.preinst script to 
pre-install those tools is no longer necessary. Thanks to the X Strike
Force for finally ending this special case. 
  * Hangs during standalone tasksel runs due to apt prompting for a CD
switch when installing packages in desktop.preinst are therefore no longer
a problem. Closes: #386244

> Though /usr/lib/tasksel/info is still referenced in the README. This
> looks a bit inconsistent?

/usr/lib/tasksel/ is still supported by tasksel's code, and can still be
used by derived distrubutions (eg, it's still used by Ubuntu, although they
add some quite complex stuff to work around #386244). But there's no point
in including the empty directory in the Debian package.

-- 
see shy jo


signature.asc
Description: Digital signature

tasksel 2.58

[Joey Hess]

Please review tasksel 2.58 and let it in if possible. Note that all the
task changes made in this version are already live in the archive; there
are some code changes too.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: draft guidelines for official CD images

[Joey Hess]

Andreas Barth wrote:
> ==begin draft==
> Any CD/DVD image needs to (I'll just write CD now for lazyness):
> - CD-lintian doesn't report errors (as soon as we have it);
> - CD uses the official d-i (of course, preseeding is ok), or if otherwise
>   agreed by the d-i RMs (which are currently Joey Hess and Frans Pop);
> - There is an extended README, including:
>   - responsible persons for the creation of this CD,
>   - selection criteria for packages on the CD,
>   - what additional packages are on the CD, how to report bugs for them,
> and where updates are,
>   - place of the errata for this CD;
> - All "official" packages are the same as on ftp.d.o, additional packages
>   can be in other directories;
> - All packages are DFSG-free;
> - All software that ends up on the installed system comes from .deb packages
> - Images available to be put on cdimages.d.o (actual uploading is done
>   via Steve or someone else - we just require the images to be available
>   for upload; it is ok if upload needs to be delayed by a short time);
> - Prepare a news item and send it to debian-publicity;
> - All source needs to be available, and you need to conform to the licenses
>   on the CD, especially to GPL.

One problem with these guidelines is that I could create a CD that
followed each of them to the letter, and yet used preseeding to
download and auto-install windows (or install a free subset of ubuntu from
debs on the CD).

> As these are guidelines, the final decision is shared between Steve McIntyre
> and the stable release managers. For approval requests, please contact them
> via [EMAIL PROTECTED]

Obviously this adds enough human element to avoid a CD that installs
windows, but what then is the cutoff point? Would a CD that
auto-installs debian-edu be able to be called an "Debian CD"?
What about a CD that only changes the default desktop to kde?

I feel it will be confusing if there are different "Debian" CDs that
behave in different ways. If the CD has different behavior it should be
called an "Debian-Edu CD" or an "Debian KDE CD" or what have you.

(Note that I've left out the word "official" since apparently that was a
mistake in the subject.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How are things going?

[Joey Hess]

Steve Langasek wrote:
> Since "Breaks field" here means "doesn't complain about the Breaks field",
> rather than "honors the Breaks field", these changes look ok.
> 
> As far as *implementing* Breaks, I don't think a new feature of that level
> should be introduced during a freeze.

Couldn't it be potentially dangerous to have a dpkg in a released
version of Debian that silently ignores Breaks? It seems it would both
allow for much foot-shooting by anyone who tries to install packages
from another source that use Breaks, as well as prevent us from using
Breaks in any packages in etch+1, since upgrades won't work.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: arm release issues

[Joey Hess]

Steve Langasek wrote:
> Does anyone know what happened to make ld so much slower on arm all of
> a sudden?

I'm not sure about linking, since I can't build xulrunner yet, but on my
64 mb arm box (bitsyxb with a USB disk), I'm seeing some very slow (12
hours) gcc runs. It mostly seems to be due to gcc using so much ram for
compiles of large files that it thrashes swap.

Compiling arts with 4.1:

Cpu(s):  0.3%us,  3.0%sy,  0.0%ni,  0.0%id, 96.7%wa,  0.0%hi,  0.0%si,  0.0%st

16936 root  18   0 76608  43m  836 D  1.3 73.0   1:33.59 cc1plus

If it was able to use more than 2% of the cpu for compiling, perhaps the
compile wouldn't take 12+ hours.

I've tried with gcc 4.0 and it doesn't seem any better though, RSS is
just as high and CPU usage just as low. BTW, even more memory (140 mb) is
used on i386 for the same build.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: arm release issues

[Joey Hess]

Joey Hess wrote:
> > Another package which caught my attention is arts, please see
> > http://buildd.debian.org/fetch.php?&pkg=arts&ver=1.5.4-1&arch=arm&stamp=1156962832&file=log&as=raw
> 
> Trying this now. Gotta love it when a >/dev/null 2>&1 line crashes a
> build..

Built and uploaded ok, must have died due to a local problem on the buildd.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: arm release issues

[Joey Hess]

Andreas Barth wrote:
> Unfortunatly, xulrunner is still not fixed yet.

It can't be until gcj-4.1 has been bootstrapped to a current version on
arm. Unfortunatly my try at this died strangely after 6 days. I
understand that doko has a build running and I'm hoping his succeeds,
otherwise it will take me 6+ days to try again.

Once that's out of the way I can try a xulrunner build and get some idea
of what timeouts it needs now.

> Another package which caught my attention is arts, please see
> http://buildd.debian.org/fetch.php?&pkg=arts&ver=1.5.4-1&arch=arm&stamp=1156962832&file=log&as=raw

Trying this now. Gotta love it when a >/dev/null 2>&1 line crashes a
build..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: kernel packages to remove from 'testing'

[Joey Hess]

Steve Langasek wrote:
> Can these docs be updated to remove the references to 2.4?

Some of the docs are in the syslinux boot screens, and would be hard to
change, others are in the manual.

Note that I'm not necessarily saying that the breakage is a reason not
to remove the 2.4 kernel.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: kernel packages to remove from 'testing'

[Joey Hess]

Steve Langasek wrote:
> Sorry Frans, but any current use of these packages is well overdue to be
> fixed.  Given that kernel-source-2.4.27 is RC-buggy, I'm now working through
> getting its reverse-dependency tree removed from testing.
> 
> Are there still architectures using 2.4 in d-i as of beta3?  If so, why?

Yes, i386 still includes 2.4 as an option as of beta3. It wasn't removed
before then because I hadn't had a clear statement from anyone that we
were ready to remove 2.4 before then. That support has been removed in
the dailys. If the 2.4 kernel images are removed from testing then
anyone who follows the docs for doing a 2.4 install with beta3 will have
it fail at one point or another.

-- 
see shy jo


signature.asc
Description: Digital signature