Re: d-i has 99% support for filesystem labels

[Frans Pop]

On Monday 14 March 2005 19:55, Eric Lavarde wrote:
> It took me quite a while to figure out the problem, so here is the
> message: labels do only properly work at install time, if no other
> system is using them as well.
> (and, no, I didn't think about posting a bug, but I can do. Against
> which package actually?)

package: partman

Cheers,
FJP


pgpJeXvnD3l2V.pgp
Description: PGP signature

Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog

[Frans Pop]

On Thursday 24 November 2005 22:54, Thomas Weber wrote:
> > Second, I'm a member of the debian-installer team. I never say
> > uploads with such entries.
>
> http://lists.debian.org/debian-devel-changes/2005/11/msg01337.html

Wrong example. The changelog for that version is:

base-installer (1.37) unstable; urgency=low

  * [actual entries removed]

 -- Joey Hess <[EMAIL PROTECTED]>  Fri, 18 Nov 2005 13:02:56 -0500

This is the way _all_ our (d-i team) uploads are done.

All our control files look like this (actual people listed as uploader 
depends on the package):

Maintainer: Debian Install System Team 
Uploaders: Joey Hess <[EMAIL PROTECTED]>, Other Developer 
<[EMAIL PROTECTED]>, ...

The changelog is always "signed" by a real person (mostly someone listed 
as uploader), not by the list address.


pgpo5N5E0gunr.pgp
Description: PGP signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frans Pop]

On Monday 28 November 2005 19:36, Thiemo Seufer wrote:
> If you know you are intersted in "foo", then it is easy anyway
> (apt-cache pkgnames instead of search for the purpose of this
> discussion):
>
> apt-cache pkgnames | grep '^foo.*-doc$'
>
> If the idea is to remove some documentation from a space-constrained
> system, a -doc suffix would be easier.

I disagree. Most regular users use frontends like aptitude for package 
management that sort on package name. For those having related packages 
together and sorted on language makes most sense.
Thus: foo-doc-

For removing you can still egrep on '^foo-doc(-.*)?$'.
For me, this is a specialized use case. Using a package management 
frontend is the normal use-case and should be an important factor in 
package naming.


pgpitoKQFdKsg.pgp
Description: PGP signature

Re: sparc64 system?

[Frans Pop]

On Wednesday 30 November 2005 14:49, Bernd Eckenfels wrote:
> I need a sparc64 test system to debug a bus  error (#340384).
> Cananybody tell me where I get an account, or do the debug symbols
> compile and backtrace for me? And also update the availability
> information of vore in the db.

I can give you an account on my Ultra10.
Contact me on IRC (nick fjp, both networks) or by mail for details if 
you're interested.

Cheers,
FJP


pgpcAgqOxEQIU.pgp
Description: PGP signature

Re: Automatic closing of bugs

[Frans Pop]

On Thursday 01 December 2005 23:45, Roberto C. Sanchez wrote:
> Is there a way to not allow changelog entries to automatically close
> bugs assigned to other packages?

This sounds like a usefull restriction. I've seen enough cases where the 
wrong bug was closed to see the benefit of this.
If the involved developers don't spot this a bug will be closed 
incorrectly and another remain open equally incorrectly.

Maybe the check could be defined a bit broader as "(not) belonging to the 
same source package".

If a bug is not closed because of this rule, a message should probably be 
sent to the uploader suggesting to check his changelog and correct and 
close manually where needed.

Cheers,
FJP


pgp6fFsqQyL7d.pgp
Description: PGP signature

Re: Debian and the desktop

[Frans Pop]

On Monday 12 December 2005 21:25, Joey Hess wrote:
> It's possible that this statement is false, and that some change might
> have been made in this area under less than clear circumstances as a
> kind of experiment just to see how long it takes for someone to notice
> and what traspires if they do. Or not.

Hmm. I do know why the change was made and expect either
- a reversal to the Sarge situation when the reasons for the change have
  disappeared;
_or_
- a proper discussion on wether to keep things as they are now, default to
  "the other" desktop (no, not that one ;-) or a solution where the user
  is actually offered a choice during the installation (which has always
  been my personal preference).

Keeping the current situation just because nobody comments is not a really 
nice thing to do IMO. Please take this as me commenting.


pgp8gW67I2efb.pgp
Description: PGP signature

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Frans Pop]

On Sunday 18 December 2005 15:34, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I hope this will be solved soon!
>
> use nameif.

This has been suggested before but AIUI nameif has problems/limitations 
renaming eth0.

The correct solution seems to be to use udev rewriting rules to make sure 
interfaces keep their name.

We will work on implementing this in Debian Installer before the next beta 
release. Both Ubuntu and Marco d'Itri have offered to help with that.

For existing users we should make sure this issue will be documented in 
the Release Notes for Etch. I'm filing a bug against release-notes as a 
reminder.


pgpQRkSVAJr2o.pgp
Description: PGP signature

Re: Please test new sysvinit, sysv-rc, initscripts

[Frans Pop]

On Tuesday 20 December 2005 00:29, Gabor Gombas wrote:
> fsck logs are OK, /var/log/dmesg.0 is root:root instead of root:adm.
> bottlogd is still broken.

Did you move bootlogd init script before udev? That should at least get 
you a log and allow you to check the rest.


pgp8wK5rjLGkN.pgp
Description: PGP signature

Re: switching to vim-tiny for standard vi?

[Frans Pop]

On Tuesday 20 December 2005 22:22, Glenn Maynard wrote:
> For me, it's a clear win: at least I can edit files.  I'm
> probably a fairly typical vim user.

I have to agree with that.
I have used the standard vi for quite some time but always got into 
problems by pressing cursor keys which resulted in being dropped out of 
edit mode and a letter changing to uppercase for weird reasons.

Ever since discovering vim, I have no more problems (well, except for 
occasionally pressing q instead of :q and ending up in macro mode or 
something). So now it's one of the first things I install on a new 
system.

IMO vim is a lot more intuitive for users who are not old-hat Linux/Unix.


pgpr3jgAWzWtE.pgp
Description: PGP signature

Re: switching to vim-tiny for standard vi? -> which editor should be standard?

[Frans Pop]

On Saturday 24 December 2005 14:15, Osamu Aoki wrote:
> Sarge installer installs nano and nvi.  I thought it was sort of
> overlooked bug of installer.  nano and nvi are in /usr/bin.

s/installer/debootstrap/

And debootstrap just installs the base system based on package 
characteristics (mainly priority), so it all boils down again to the 
definition of the base system.

Cheers,
FJP


pgp9NZmd3YKPx.pgp
Description: PGP signature

Re: Your Confirmation Required

[Frans Pop]

On Tuesday 27 December 2005 22:50, Steve Langasek wrote:
> hadn't thought of initially; so yeah, it'd be good to either have abuse
> headers to track, or (probably easier) just blacklist the domain...

I forwarded one of the messages to listmaster yesterday and they should be 
filtered now.


pgpyBdVDA0u1o.pgp
Description: PGP signature

Re: debian-devel@lists.debian.org

[Frans Pop]

A general note to everybody thinking of making hardware donations.

On Wednesday 28 December 2005 21:23, Milan P. Stanic wrote:
> I could try to arrange donation of one UltraSparc machine to Debian
> project. I think that the transport would be to complicated from
> Serbia to anywhere (because of our laws) but I can connect it to the
> Net for DD's to use it.

The fact that you think of Debian is of course very much appreciated.
In general though, there is really no demand from "the project" for older 
hardware for porting efforts. When it comes to build daemons or machines 
for developer access, "the project" needs relatively heavy and up-to-date 
systems.
Also, the Debian System Administrators have fairly heavy requirements when 
it comes to hosting and network connectivity for official project 
machines.

You may of course make an individual developer very happy with an older 
system and there will probably be quite a bit of interest if you have 
fairly recent hardware on offer (like sunblades for Sparc).

So, if you have older hardware you wish to donate, please offer it to 
individuals who work on Debian rather than "the project". That also means 
that offering to host it is in general irrelevant.
Shipping is in general the biggest issue when it comes to donations to 
individuals, so much depends on where you are relative to the individuals 
interested in taking over a system.

There is of course another way you can help the project with older 
hardware: keep it, try installing it sometimes from scratch and report 
any issues. If you have the skills to trace a bug and suggest a fix for 
it, so much the better.

The issue threatening the Debian Sparc port is not so much lack of 
hardware (and certainly not older hardware), but rather people who spend 
time on hunting down and fixing (kernel) bugs and working on architecture 
specific packages like silo.

Thanks again for your kind offer though.

Cheers,
Frans Pop

P.S. I myself was "donated" a Sparc Ultra10 in this fashion and that 
system has since seen some very useful usage for the project.
I'm still very grateful for that donation.


pgpNEiMIcaWjV.pgp
Description: PGP signature

Re: debian-devel@lists.debian.org

[Frans Pop]

On Wednesday 28 December 2005 23:21, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The issue threatening the Debian Sparc port is not so much lack of
> > hardware (and certainly not older hardware), but rather people who
> > spend time on hunting down and fixing (kernel) bugs and working on
> > architecture specific packages like silo.
>
> Do we have a developer-wide accessible sparc64 system yet? LAst time I
> asked I get no response (only proivate offers for accounts, what I am
> very thenkfull for)

I saw a comment a few days back that vore was back up (see below).
AIUI vore being down was partly caused by networking problems and partly 
due to the recurring kernel crashes. So the question is: for how long 
will it be up.

RM seems to consider porter machine still missing, not because the 
hardware is not there, but because it will not stay up reliably.

Hmm. Maybe we should just feed it some pills?

From #d-release:
< neuro> vorlon: you know vore is up, right?
< vorlon> ah, no
< vorlon> any reason to think it's going to stay up this time?
< neuro> it's been up for 18 days
< neuro> it's just been a network problem for most of that, aiui
< neuro> which was fixed on the 16th or so?
< neuro> it may eventually hit the same kernel bug with people using it, 
tho
< vorlon> ah


pgp2CAOMSS2dV.pgp
Description: PGP signature

Re: stable aliases for CD drives

[Frans Pop]

On Thursday 29 December 2005 01:00, Marco d'Itri wrote:
> Some component of debian will have to install a rules file with static
> aliases, and so far I think that this should be a task for d-i.

Is this document still usable for writing udev rules?
http://www.reactivated.net/writing_udev_rules.html

If not, is there a better one?


pgpNP1r4R7efj.pgp
Description: PGP signature

Re: How to Increase Contributions from Volunteers

[Frans Pop]

On Monday 02 January 2006 15:42, Andreas Schuldei wrote:
> so should we try to compile such a list and advertise it better,
> perhaps from the startpage on www.debian.org?

http://www.debian.org/devel/join/ seems more suited for that.

That whole page could maybe be organized a bit better by separating the 
content into sections.


pgpimuafQHeEU.pgp
Description: PGP signature

Re: No 2.6 kernels for 586 in Sarge and up

[Frans Pop]

On Monday 02 January 2006 16:40, Jérôme Warnier wrote:
> I wonder why there is no 2.6 kernel package for 586 in Sarge while
> there is for 2.4?
> I can find 386-486-686 and k7, but no 586.

Try linux-{source,image,headers}.


pgpWpHgVmaU8B.pgp
Description: PGP signature

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> We will have a kernel which is outdated by two versions at release time
> with this plan, since there are about 1 kernel upstream release every 2
> month.

2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
starting to get implemented).

I remember we did consider using 2.6.10 instead of 2.6.8 and decided not 
to mainly because it was not really that much better than 2.6.8.
As I remember it, this was a joint decision by the kernel team, release 
managers and the d-i developers. Not something that the kernel team were 
really pushing and was blocked by some assholes from the d-i team who did 
not want to cooperate.

The first kernel after 2.6.8 that was a real improvement was 2.6.12 and 
that was released definitely too late for Sarge.

> Already it should be possible, provided the d-i guys get their act
> together, to have a new d-i .udeb sets within 48 hours or less of a new
> upstream kernel release, altough the image build may take longer, and
> we hope to get the external modules and patches streamlined by then.

This is an extremely bad way to get friendly cooperation and discussion 
about changing anything.
Producing new udebs for all architectures for d-i can be done quite fast, 
as evidenced by the recent uploads for 2.6.14, provided the porters 
taking care of the udebs for their architecture . I expect little 
problems or delay for 2.6.15.

As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for 
i386. Yes, we did wait a while before updating to 2.6.14, but that was 
mainly because d-i itself first had to prepare its userland for the 
removal of devfs.

So please, get off your hobbyhorse and stop pissing people off with 
unfounded statements.


pgpQBmyWehbrh.pgp
Description: PGP signature

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 23:01, Sven Luther wrote:
> Indeed. The d-i team usually says "no" outright to any kind of proposal
> of this kind, so it is up to the kernel team to come up with an
> implementation which convinces them :)

Bullshit.
We (d-i team, mainly Joey) gave very good reasons why we thought the 
proposal was not good and would result in more problems than it solved.
That you choose to structurally ignore the opinions, comments and 
objections by others who are a lot more knowledgeable about the _other_ 
area in Debian impacted by the proposal is typical.
Your half-baked proposals may look good from a kernel maintenance 
viewpoint, but in our opinion they have a negative impact on the d-i side 
of the equation.

Rejecting a badly thought out proposal is _not_ the same as saying no 
outright.

I'm not going to repeat the arguments here. They can be found in the 
archives.

Your attitude does nothing to motivate me to work on this.


pgp6Ql7CIlWlU.pgp
Description: PGP signature

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> The current proposal is about simply using the same .udeb organisation
> and move it inside the linux-2.6 common package, which is something
> that works out just fine for ubuntu even, but which the current
> linux-2.6 common package infrastructure could also handle.

So, when can we expect a coherent, full proposal (with overview of 
benefits, possible pitfalls, things that need to be worked out further, 
and so on) on this in a dedicated mail on a new thread to the relevant 
mailing lists, so we can actually comment on it instead of only seeing a 
rough outline mentioned every so often as part of a flame?

(Without the "current method sucks" comments please; saying "I think the 
current situation could be improved by..." is much more likely to get 
positive reactions.)

> The only 
> reason i saw against this was a mail from joeyh mentioning ease of
> moving modules around inside .udebs, and that this would be easier
> under the d-i umbrella than if it is inside the kernel, and naturally
> the old sarge-time brokeness in the archive infrastructure, which is
> presumably fixed by now, or should be fixed for etch.

You forget the argument that when kernel udebs are maintained within d-i, 
we will be much more likely to spot changes in them as a possible cause 
of breakage when installation-reports come in.


pgpRRzbMYjt34.pgp
Description: PGP signature

Re: bits from the release team

[Frans Pop]

On Wednesday 04 January 2006 00:17, Adeodato Simó wrote:
>   Given that backports.org seems to successfully track kernels on sid
>   already (as per Steinar's comment), and given that I've heard Frans
>   Pop mention the possibility of a sarge d-i update using 2.6.12,

Hmm. That needs a bit of context.
The only way in which the d-i team has so far considered an update of d-i 
for Sarge is if a newer kernel version is officially supported for Sarge.

For us this would be easiest if the new version would be included in a 
point release, but I personally doubt such a proposal would ever pass the 
Stable release manager.

We could also look into this if a new kernel were made part of volatile, 
although that would mean d-i would have to be extended in some places to 
be able to support that.

Still, first requirement is selection of a kernel that will be supported. 
Downside of anything more recent than 2.6.12 is that a lot of structural 
changes in d-i would need to be backported to deal with the removal of 
devfs and to support the new initrd generators.


pgp2ItpXdtkUs.pgp
Description: PGP signature

Re: outdated links on http://www.us.debian.org/doc/

[Frans Pop]

(Moving this thread to d-www where this is more on-topic.)

On Wednesday 04 January 2006 20:58, kamaraju kusumanchi wrote:
> I was reading http://www.us.debian.org/doc/ and found a link to
> "Installation guide for Debian 2.2" (at the end of the page). I am
> thinking with sarge release this is somewhat outdated and might send
> wrong hints to the end user browsing the website. I think this link
> should be removed. Any ideas?

Yes, I agree. Although the link does contain some nice information, most 
of it is clearly obsolete.

I'd like to propose deleting the entire line, unless ppl feel linking to 
the Installation Howto [1] (which is part of the Installation Guide) 
instead would be useful.

Cheers,
FJP

[1] http://www.debian.org/releases/stable/i386/apa.html


pgpHHrS6Gm4Qe.pgp
Description: PGP signature

Re: Canonical's business model

[Frans Pop]

On Monday 09 January 2006 10:02, Josselin Mouette wrote:
> This is fair. After all, that's what Free software is about. But I know
> for sure that "contributing back to Debian" stuff is 100% talk and 0%
> reality.

There is at least one area where there is a substantial contribution from 
people working on Ubuntu and that is Debian Installer. I also think that 
X.Org maintenance has benefitted a lot from work done earlier for Ubuntu.

So 0% is just not true.


pgptxlk4fY6j5.pgp
Description: PGP signature

Re: APT public key updates?

[Frans Pop]

On Saturday 20 February 2010 09:15, Joey Hess wrote:
> Nonzero exit; odd, it doesn't seem to notice that the key is expired at
> all. But apt won't use gpgv like that, I suppose, but instead like
> this:

Note though that other packages, like debmirror, do:

my $GPG="gpg --no-tty -q";
[...]
if (!-f "$tempdir/dists/$dist/Release.gpg" || \
!-f "$tempdir/dists/$dist/Release" || \
system("$GPG --verify $tempdir/dists/$dist/Release.gpg 
$tempdir/dists/$dist/Release")) {


pgpZ9nb0orHXk.pgp
Description: PGP signature

Re: Dissection of an Ubuntu PR message

[Frans Pop]

On Thursday 12 January 2006 00:09, Andrew Suffield wrote:
> Let's take this one apart and see what it is that pisses people off so
> much.

What pisses me off is ppl keeping this thread alive without adding new 
arguments with as their main goal to widen the gap that is definitely 
there, but is also not as wide as they want others to believe.

This discussion has been repeated at least three times here and in this 
thread I have so far seen no significant new arguments.

My observations:
- almost all development effort that may help narrow the gap is done on
  the Ubuntu side, not on the Debian side;
- the paid Ubuntu developers all work very hard (sometimes somewhat
  resulting in less attention to their Debian responsibilities than
  we'd like, but hey, real live (i.e. making money to live on) comes
  first;
- there are plenty of Debian developers who take little or no trouble to
  see how Ubuntu might help them; there are also plenty Ubuntu developers
  who maybe could make more of an effort to give back; at least Ubuntu
  has a policy of giving back; never seen policy not (fully) implemented
  in practice?
- I expect things to get better over time, not worse.

Note: I am on the Debian side but am happy with any of my work also being 
used in Ubuntu as I see plenty coming back personally. And even if not: 
Ubuntu is doing great things for the promotion of free software.

Cheers,
FJP


pgpXmOgvzGXoK.pgp
Description: PGP signature

Re: For those who care about lesbians

[Frans Pop]

On Sunday 15 January 2006 00:47, Adam Heath wrote:
> In fact, both of the last 2 emails to d-d-a go against the AUP. 
> Procedures should be started to punish the offenders.

They are of a completely different order. One is an error of judgement and 
"merely" off-topic, the other is intentionally offensive and therefore 
unacceptable.


pgp6jYbKvhKpJ.pgp
Description: PGP signature

Re: how to link 2 bug reports ?

[Frans Pop]

On Sunday 29 January 2006 14:38, Marc Chantreux wrote:
> i've done the bug report #350119 last week (providing a patch) and just
> seen that this patch fixes #342008. Is it a way to 'link' them in the
> BTS?  (as i'm not a DD)

http://www.debian.org/Bugs/server-control
See "merge" command and read the comments below it carefully.

You don't need to be a DD to use it.

Cheers,
FJP


pgpTPAeuUTCV9.pgp
Description: PGP signature

Re: limitations of reportbug and BTS

[Frans Pop]

On Wednesday 15 February 2006 20:56, Marco d'Itri wrote:
> On Feb 15, kamaraju kusumanchi <[EMAIL PROTECTED]> wrote:
> > This kind of thing is not possible currently. Do you think it is a
> > good implement such a feature? Currently bugs.kde.org allows this
> > (searching for strings in the bug reports without worrying about
> > package names etc.,).
>
> You use google groups to search the linux.debian.bugs.dist newsgroup.

Maybe we should document that on the bugs.debian.org main webpage.

Any objections to the patch below (I can commit it myself)?

@@ -62,6 +62,14 @@
   http://bugs.debian.org/tag:tag
 

+Searching bug reports
+
+Probably the easiest way to search bug reports is use
+http://groups.google.com/group/linux.debian.bugs.dist";>Google 
Groups.
+If you use the
+http://groups.google.com/advanced_search?q=""+group%3Alinux.debian.bugs.dist";>
+advanced search option, you will be able to limit the period to be 
searched.
+
 Supplementary information

 The current list of http://bugs.debian.org/release-critical/";>


pgpIsbHBc4ojp.pgp
Description: PGP signature

Re: limitations of reportbug and BTS

[Frans Pop]

On Wednesday 15 February 2006 21:28, Frans Pop wrote:
> + href="http://groups.google.com/advanced_search?q=""+group%3Alinux.debian.bugs.dist";>

Hmm. Quotes within quotes probably won't work, so this is better:
http://groups.google.com/advanced_search?q=+group%3Alinux.debian.bugs.dist";>


pgpauf7fJtMxQ.pgp
Description: PGP signature

Re: Avoiding installation trouble (suggested fix)

[Frans Pop]

On Monday 06 March 2006 10:43, Daniel Haude wrote:
> In the end I found out what was wrong: I had used an old install CD
> back from sarge==testing days. My /etc/apt/sources list therefore
> pointed at "testing" resources which, without a proper "dist-upgrade"
> (which at no point I had wanted because I wanted a sarge system),
> couldn't have worked.
>
> After downloading burning a contemporary install CD everything of
> course went as smoothly as one has come to expect from a Debian system
>
> To come to the end: I think a "sarge" install CD should always stay a
> "sarge" install CD no matter how old.

This is already the case for current versions of the installer, though you 
are right that it was an issue with Sarge.


pgpOTEPEGNHpL.pgp
Description: PGP signature

Re: freetype pre-release packages: testing needed

[Frans Pop]

On Tuesday 07 March 2006 00:25, Steve Langasek wrote:
> Packages for freetype 2.2rc4 can be found at
> .  Please test them and let
> me know what breaks!

I have tested the udeb from that location with the graphical version of 
Debian Installer and seen no problems.

> In particular, it would be appreciated if users 
> could install freetype 2.2rc4 on sarge and confirm whether they're
> truly compatible; these binary packages are built against etch, though,
> so you'll need to rebuild to install it on sarge.

Done.

One strange thing is that the package let me install libfreetype6 without 
upgrading libfreetype6-dev.

Installing the new version also resulted in a change in how fonts look in 
KDE. See attached screenshots.

I'll let you know if I notice anything else.

Cheers,
FJP



pinentry_new.png
Description: PNG image


pinentry_old.png
Description: PNG image


pgpG0CT2jVc5X.pgp
Description: PGP signature

Re: removal of svenl from the project

[Frans Pop]

Dear Sven,

So, where do I stand in this expulsion thingy?
So far I've resisted mailing on this thread. My general feelings were very 
well worded by Adeodato Simó. However, my name being brought up in your 
reply to Joey kind of forces me.

I don't actually think that expulsion is the correct action in this case 
(even though I was one of the initiators of the previous request), so I 
will not support it. That said, I understand what drove Andres to doing 
it very well.

I would very much hope that instead of feeling abused and misunderstood, 
the comments in this thread and the fact that some people _do_ think your 
behavior is bad enough to warrant expulsion will make you take a good 
hard look at your own behavior.

It would also be very nice if you could change your habits regarding:
- feeling personally insulted when people disagree with you
- dragging in old grievances on unrelated issues
- repeating yourself over and over and over and over in the same thread
  (let alone in unrelated threads)
- replying to each and every message in a thread where you feel in some
  way personally involved
- always replying "to all" instead of just the mailing list, even when
  repeatedly asked not to do so (you could even manually trim the address
  list, but I guess that would take to much time with the volume of mail
  you send - see previous item)

I think it would probably also be a good idea if you concentrated your 
involvement into areas you actually enjoy working on.
It seems to me that you don't actually enjoy kernel and d-i powerpc work, 
but rather see it as an obligation because your business in part depends 
on Debian supporting powerpc.

Below is a nice flame from me in reply to your reply to Joey. Please don't 
bother answering if you're not prepared to accept a large part of the 
blame for this expulsion process.
After all, how come so many people involved in this thread all work 
happily together but all have problems working with you? Ah, but of 
course, the problem must lie with them, it could never lie with you, 
right?

Cheers,
FJP

P.S. I was very sorry to hear about your mother. My sympathy for the
 difficult time ahead.


On Wednesday 15 March 2006 20:51, Sven Luther wrote:
> Notice that i left almost if not all debian-boot involvement some time
> ago because of that, and that the problems you mention where mostly

Ah, so that is basically why powerpc support in d-i is in the state it is.

I actually consider powerpc the worst supported port in d-i at the moment 
[0]. And that is not because "we broke things that were working perfectly 
during the Sarge release", but because you, as the main powerpc d-i 
porter and our main contact with the powerpc community, have failed to 
keep up with development and to run occasional tests and to get the rest 
of the powerpc community behind you to solve issues.

Instead you wait until just before a release and then try to get untested 
changes uploaded because "of course we cannot release while powerpc 
support is broken".
I really do wonder why you build the daily d-i images if you don't try 
them occasionally.

> caused by Frans commenting on things i said on debian-kernel, and not
> really directed at him, and he taked offense.

They were directed against debian-installer and were mostly a repeat of 
the complaint (in an unrelated thread) that the way d-i handles kernel 
udebs is totally broken.
So I felt that, as d-i release manager, it was my job to ask you to not 
repeatedly bash d-i over an issue that had been discussed extensively 
before and which ended unresolved because you were unwilling to consider 
some of the objections to your grand plan, which basically consisted of 
hijacking the kernel udebs. My asking you to stop resulted in you feeling 
personally insulted which resulted in a nice flamewar.

It is absolutely no fun to hear that something you spend a lot of time on 
is continually being described as "fucked" (kernel udebs, partman) and 
when you're blamed for accidental breakage (which happens mostly because 
of the complexity of d-i and not through malice and is often fairly 
easily fixed if only the people involved are willing to do it right, 
which luckily most are).

> Notice also that i am still expecting excuses on how you threated me in
> april last year, when i almost was brought to leave the project due to
> the abuse i got at the time, but i really am not expecting them
> anymore.

Why can't you just forget about it instead? You keep bringing this up 
every two months or so. How does that help?
Your habit of dredging up old grievances is one of the things that makes 
you a pain to work with.
It's just like what you do with smileys: you seem to think that you can 
abuse someone and that putting a smiley after it as an afterthought will 
make it OK. Well, it does not.

> Ever since i have questioned my involvement in debian, and 
> after 8 years of participation, i have to say that issues got worse and

What does that mea

Re: HOWTO Help (was: Debian DPL Debate Comments)

[Frans Pop]

On Tuesday 22 March 2005 22:08, Alexander Schmehl wrote:
> < cc-ing to -doc, since most part of the mail is more relevant there >
>
> Hi!
>
> * Nico Golde <[EMAIL PROTECTED]> [050318 18:59]:
> > [...]
> >
> > > I've been thinking of contributing to Debian for a long time since
> > > I started using it. The problem is that I've not been able to find
> > > a good comprehensive documentation on "Contributing to Debian" yet.
> >
> > I think the descrition on:
> > http://www.debian.org/support
> > is ok.
>
> Nico, did you take a look at that page?  It is more a "Where to get
> support" than a "howto support us".
>
>
> AFAIK we don't have a good "What you can do to help us" documentation
> (please correct me, if I am wrong).

How about http://www.debian.org/devel/join/ ?
Which is linked from the main debian.org page (bottom left: "Help Debian")

> However I was about to write a new document about that, based on the
> talk I did on the asian miniconf (which I btw, just uploaded to
> ,
> not yet fixed the bugs or made a nice frontpage).
>
> If you have further Ideas for content, please drop me a mail.
>
>
> Yours sincerely,
>   Alexander


pgpDOPfxiYzks.pgp
Description: PGP signature

[Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Frans Pop]

Short version:
Should users first upgrade dpkg and aptitude before upgrading the rest of 
the system or can the upgrade safely be done using Woody's version of the 
package tools?

Long version:
The current version of the release notes tells users to (simplified):
1. apt-get install aptitude
2. change the /etc/apt/sources.list to point to "stable"
3. aptitude update
4. aptitude -f --with-recommends dist-upgrade

Step 1. is meant to install the Woody version of aptitude, but of course 
it will not if the sources.list already points to "stable" and the user 
has already done an 'apt-get update'.

There have of course been improvements in Sarges version of aptitude. Also 
I wonder if upgrading the packaging tools as part of the dist-upgrade 
could in itself be a source of problems.

Therefore the question if it would be better to change the procedure to:
1. change the /etc/apt/sources.list to point to "stable"
2. apt-get update
3. apt-get install aptitude dpkg
4. aptitude -f --with-recommends dist-upgrade
???

I have done an upgrade myself a while back using the second method [1] and 
noticed:
- 'apt-get install aptitude' does _not_ upgrade dpkg automatically;
  as it seemed to me better to have all package tools from the same
  version, I upgraded both aptitude and dpkg before continuing with the
  rest of the upgrade;
- in my test upgrading aptitude and dpkg also upgraded the following:
apt apt-utils aptitude debconf debconf-utils debhelper dpkg dpkg-dev 
libc6 libc6-dev libdbd-mysql-perl libdbi-perl libgcc1 libncurses5 
libncurses5-dev libpopt0 locales perl perl-base perl-modules whiptail 
zlib1g
  and installed:
debconf-i18n dselect gcc-3.3-base gettext intltool-debian
libdb1-compat libdb4.2 libgdbm3 liblocale-gettext-perl
libnet-daemon-perl libnewt0.51 libplrpc-perl libsigc++-1.2-5c102
libstdc++5 libtext-charwidth-perl libtext-iconv-perl
libtext-wrapi18n-perl linux-kernel-headers po-debconf slang1a-utf8
  I understand that for some arches (hppa) this may necessitate upgrading
  the kernel first.

Comments very, very welcome.

Cheers,
Frans Pop

[1] http://lists.debian.org/debian-release/2004/11/msg00105.html


pgpF555xdnwJg.pgp
Description: PGP signature

Sarge Release Notes - Architecture specific news?

[Frans Pop]

If there is any architecture specific news that you'd like to have 
included in the Release Notes (like new subarchs supported or dropped), 
please send a proposed text to the d-doc mailing list (CC the list for 
the architecture) before the end of this week.

Cheers,
Frans Pop


pgpJSfW0bTfFl.pgp
Description: PGP signature

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Frans Pop]

On Monday 16 May 2005 17:58, Frans Pop wrote:
> Should users first upgrade dpkg and aptitude before upgrading the rest
> of the system or can the upgrade safely be done using Woody's version
> of the package tools?

From the reactions to this thread and a thread on #309340 [1], the 
consensus seems to be that the upgrade method least likely to have 
problems is:

1. Check that /etc/apt/sources.list points to "woody"
2. apt-get update
3. apt-get install aptitude
4. change the /etc/apt/sources.list to point to "sarge"
5. apt-get update
6. aptitude install aptitude dpkg
7. aptitude -f --with-recommends dist-upgrade

Comments
1. If the sources.list pointed to stable the user should check if
   he has already updated anything; he will be largely on his own
   if that should produce problems.
3. Woody's aptitude is installed because using that to install/upgrade
   to Sarge's aptitude produces less problems than using apt-get.
4. The consensus seems to be that using "sarge" instead of "stable" is
   more secure as it will prevent premature upgrades for a next release.
5. apt-get is used to work around #309357.


The main open question now is step 6. There are two options:
- upgrade both aptitude and dpkg _before_ the dist-upgrade;
- upgrade _only_ aptitude and leave the upgrade of dpkg to be done as
  part of the dist-upgrade.

From my own experiences [2] it seems it could be wise to advise a bit more 
flexible method. For me 'aptitude install aptitude dpkg perl' (i.e. with 
"perl" added) produced the best results for step 6.


Cheers,
FJP

[1] http://lists.debian.org/debian-testing/2005/05/msg00060.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309548


pgpUlcyROdGLg.pgp
Description: PGP signature

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Frans Pop]

On Wednesday 18 May 2005 02:47, Steve Langasek wrote:
> Is there a difference in packages removed if you run "aptitude install
> aptitude" instead of "aptitude install aptitude dpkg"?  I don't see any
> reason why dpkg needs to be upgraded first, unlike aptitude.

No, makes no real difference. I still need perl to keep my system at least 
somewhat alive.

> If perl needs to be added to the list, I say to just add it.  People
> who have Prio: standard packages missing from their systems probably
> won't want to follow our advise to use aptitude, either.

perl was not missing on my system. It just needed to be upgraded along 
with aptitude because of dependencies (no idea which). That upgrade had 
to be forced by adding it in the install command.
Otherwise perl would be removed, taking half my system with it.

I think we will be getting two kinds of upgrade:
- servers or light desktops that can get by with just upgrading aptitude
- desktops with kde, gnome (from unofficial backports or not) that will
  have to look at the results of 'aptitude install aptitude' and decide if
  anything else is needed; perl probably is a prime candidate

I going to try to rewrite/reorganize chapter 4 of the release notes 
somewhat on Saturday to see if I can make the upgrade instructions a bit 
more organic.


pgpLCBeArcofP.pgp
Description: PGP signature

Re: Bug#310887: Sarge doesn't mount scsi harddisks on boot

[Frans Pop]

reassign 310887 debian-installer
severity 310887 important
retitle 310887 Does not mount non-root partitions before fs check if other 
drivers required
thanks

On Thursday 26 May 2005 21:19, [EMAIL PROTECTED] wrote:
> Package: general
> Version: Sarge

Please use a proper package when filing bugs!
A little bit of research could have shown you that either debian-installer or
installation-reports are the proper ones to use. "general" is just being lazy.

Even better would be to use the installation report template:
http://www.debian.org/devel/debian-installer/report-template

> Just Sarge try to do an fsck of scsi disks before the device
> exists, and the fsck then fails and Sarge don't mount the scsi
> hard disks.

You can work around this by adding the driver modules required for your scsi
controller in /etc/modules. After that the system should boot normally.

It is something we need to look at in the installer though. I think I've seen
another report that mentioned the same problem.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Ubuntu a debian derivative or is it a fork?

[Frans Pop]

On Wednesday 01 June 2005 07:53, Matt Zimmerman wrote:
> I don't have any hard statistics, but here are some random examples of
> patches whose development was sponsored by Canonical, were tested and
> proven in Ubuntu, were proactively submitted to Debian by an Ubuntu
> developer, and remain in debbugs months later without comment from the
> maintainer:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298060
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298064

I don't think the second one is a very good example either as it seems to 
assume udeb support and Debian is not there yet.

I guess the maintainer could have given a response, but AFAICT 
implementing the request is not possible for the foreseeable future.


pgpxwb3WeX58F.pgp
Description: PGP signature

Re: Is Ubuntu a debian derivative or is it a fork?

[Frans Pop]

On Wednesday 01 June 2005 19:25, Matt Zimmerman wrote:
> > You mean http://people.ubuntu.com/~scott/ongoing-merge/ which has
> > been there for at least half a year?
>
> Or rather http://people.ubuntu.com/~scott/patches/ which even provides
> separated patches.

What seems to be missing is something that unites all this and makes it 
accessible to a DD who would like to see for the first time what Ubuntu 
has done with "his" packages.

How about putting something like that together and making it available in 
the Developers Corner. A "Ubuntu HOWTO for Debian Developers"?

Cheers,
FJP


pgpF8kiJTCXEr.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Tuesday 07 June 2005 03:21, Joey Hess wrote:
> Planned, and ground already laid in tasksel (and indeed, it does do it
> for some easy things like language tasks). One thing I really want to
> see happen is a laptop task. The big missing peice is some simple
> program tasksel can call out to, like
>
> if this_is_a_laptop; then
> ..
> fi
>
> This should use whatever hardware probing works best for laptops.

This sounds like a good idea, but will need very careful logic.
For instance, some older (APM-based) Toshiba laptops work well with the 
toshiba module and the toshset package where newer (ACPI-based) laptops 
need the toshiba-acpi module which does not work with toshset.
I would suspect that similar distinctions exist for other makes.

> I'm interested in other ideas for automatic selection of default tasks.

One thing I feel is currently missing is to show users which tasks have 
been automatically selected and the option to deselect them (maybe only 
at medium or lower priority).

Which brings me to another pet wish: make it a lot easier to install at 
medium priority than currently.
IMO there is a real use for medium priority:
- experienced users now often choose expert and get confused by some of
  the informational dialogs (especially the "unavailable drivers" one)
- for users installing for the first time the "no dhcp" boot option and
  such are not really obvious, medium priority can be used to offer
  useful freedom in a structured way keeping expert for difficult hardware


pgpNsdIZI6dAN.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Tuesday 07 June 2005 01:03, Javier Fernández-Sanguino Peña wrote:
> Feel free to add some new items or add (hopefully new) information to
> the ones I list below:
>
--
[ Overall improvements ]
- Implement some package reorganizations that have been postponed over
  several releases; example:
  #100332: tetex-bin: please move xdvi to its own package


pgpcZfdXQ1b3d.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Tuesday 07 June 2005 22:10, Roger Leigh wrote:
> - When UTF-8 is the default locale, it shouldn't need a .UTF-8
> suffix, e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1
> (the opposite way round to the current situation which creates
> en_GB.UTF-8 and en_GB [Latin-1]).
>
> [...]
> This won't affect existing installs, so breakage should be none to
> minimal. 

This looks to be a contradiction.
If you make UTF-8 default and remove the suffix for UTF-8 usage, won't 
existing installs that have LANG=en_GB in their /etc/environment be very 
much affected?


pgpRtPcPbtWWi.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Tuesday 07 June 2005 23:02, Roger Leigh wrote:
> Existing installs are already configured with debconf.  Their
> /etc/locale.gen will not be touched.
>
> If you do dpkg-reconfigure locales, then users could have the locale
> switch to UTF-8 if they so choose.

AFAIK locales are automatically regenerated when the locales package is 
upgraded, so this _would_ effect every existing install directly on 
upgrade to the new release.


pgpcJoebcmWnk.pgp
Description: PGP signature

Re: Planet Debian and Akregator

[Frans Pop]

On Thursday 09 June 2005 09:59, Isaac Clerencia wrote:
> I've read about this before, but I read Debian Panet with akregator
> without any problem. ??

I use akregator too (1.0 beta 10) and every once in a while you get an 
icon indicating a feed cannot be read. Most of the time this will be 
fixed pretty soon.
From an explanation a while back I understood the main (?) cause is 
ampersands ("&") in headers, but I'm not sure.

One thing that is quite bad about akregator is that if a feed can not be 
read correctly, it will retry very often (something like once a minute or 
even more frequently). This has already gotten me banned temporarily 
from /. once (they only allow one refresh per 30 minutes).


pgpUVcMeNecbi.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Thursday 09 June 2005 18:45, Marco d'Itri wrote:
> On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > Dropping 2.4 can easily be done on relatively short notice prior to
> > etch release, so no need to worry about now.
>
> It would be too late, because at that time we would have wasted a
> couple of years trying to support them.
> This kind of decision should be taken early in the development cycle.

Making the decision early would also help d-i development as we could then 
start cleaning e.g. keyboard selection (and console-data).
Being able to rely on sysfs being present would also simplify hardware 
detection in some cases.


pgp0SKYarfXri.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Sunday 12 June 2005 00:24, Russell Coker wrote:
> New laptops tend to ship without floppy drives and desktop machines
> will surely follow soon.  Plans for future hardware support should not
> involve floppy disks.

Please, we do not only support new hardware.
I have a very nice Pentium I (my internet gateway) that has a broken 
CD-drive and no USB (and certainly wouldn't boot from USB even if it had) 
but that installs perfectly from floppy.
There are also other platforms that only do floppy boots (older macs, 
probably m68k too).

IMO we should try very hard to keep floppy installation supported.


pgpEme5MM7QKV.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Frans Pop]

On Sunday 12 June 2005 00:51, Marco d'Itri wrote:
> On Jun 12, Frans Pop <[EMAIL PROTECTED]> wrote:
> > I have a very nice Pentium I (my internet gateway) that has a broken
> > CD-drive and no USB (and certainly wouldn't boot from USB even if it
> > had) but that installs perfectly from floppy.
> You said it: it's *broken*.

Pardon my French, but that's bullshit. The system is perfectly fine. Since 
when is a CD drive an essential component. Since never!

> Expecting to support some old hardware is OK, expecting to support old
> and broken hardware is not.

Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or 
booting from USB. Are we going to be like M$ and force users to buy the 
latest and greatest hardware to run Debian?

I hope not if it can be avoided with a little bit of extra effort. As long 
as the kernel supports it, we should try to allow people to install 
Debian on it. For me, it's one of the attractions of Open Source.


pgpciJI6k5JLo.pgp
Description: PGP signature

Re: Greylisting for @debian.org email, please

[Frans Pop]

On Sunday 19 June 2005 00:18, Marco d'Itri wrote:
> If your ISP is a good ISP, this will be advertised (by way of DNS,
> whois records or private communications).
> If it is less than good then I will take an educated guess. HTH.

My experience is that ISP's are probably not very good: I have a static 
address that's listed as dynamic if you look at the name for the range.

That indication is probably based more on history of the range (i.e. how 
was it intended to be used when first created) than actual use.

I think blocking mails based on an address being dynamic/static sucks.


pgprKaRyXi2nz.pgp
Description: PGP signature

Re: Greylisting for @debian.org email, please

[Frans Pop]

On Sunday 19 June 2005 17:48, Simon Richter wrote:
> Hi,
>
> Frans Pop wrote:
> > I think blocking mails based on an address being dynamic/static
> > sucks.
>
> Indeed, but the only systems that send out email from dynamic IP
> addresses are spam zombies (90%[1]) and people who run their own MTA,

You are missing my point which was that you can not trust ISP's to 
properly designate an address as being dynamic/static, so blocking on 
that basis will also block people who actually _do_ have a static 
address.


pgpO4BwY1Wmzm.pgp
Description: PGP signature

Re: Greylisting for @debian.org email, please

[Frans Pop]

On Sunday 19 June 2005 18:39, Simon Richter wrote:
> Hrm, that would indeed be a reason to accept mail from some IPs inside
> such "dynamic" blocks. Your IP does not seem to be listed as being
> dynamic, though. :-)

Try mine: 195.240.184.66
And yes, it is static and not "dynamic but unlikely to change rarely".

> OTOH, I think greylisting can help here, by applying it to hosts that
> are listed as being dynamic. If the technology your ISP uses to connect
> you to the internet is so strikingly similar to the technology used by
> people who don't even care whether they have a fixed IP, I would assume
> your bandwidth would not allow you to send amounts of mail that
> greylisting would adversely affect you. :-)

I started using my own mailserver because the one from my provider was 
down a lot for a while or not delivering within something like 8 hours 
(they seem to be better ATM).
Using my own server I would at least _know_ what was happening to my 
mails.

If I am blocked by something like SORBS when answering installation 
reports or something like that, I will sometimes resend a mail through my 
ISP, sometimes I just say "@[EMAIL PROTECTED]@ you, if you don't want to 
receive my 
mail, then don't".


pgpxaA8CP7ObW.pgp
Description: PGP signature

Re: raidtools2 -> mdadm change: woes and problems

[Frans Pop]

On Wednesday 22 June 2005 11:16, Brian May wrote:
> http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.e
>n.html#s-mdadm

> The documentation said that there was no need for a config file, and I
> never used a 2.2 kernel, so the paragraphs starting with "If your RAID
> array was created on a 2.2 Linux kernel patched with RAID" seem
> irrelevant.

Correct. That para is only relevant for Sparc and therefore is only 
included in the Release notes for Sparc, not in the version linked to 
above.


pgpxK2fFvo6ln.pgp
Description: PGP signature

Re: Debian Installer etch beta 3 released

[Frans Pop]

On Monday 14 August 2006 14:43, Steve McIntyre wrote:
> The DVD torrents are already produced, just not linked from the page
> at http://www.debian.org/devel/debian-installer/. Check out

I've committed a change to the d-i page that adds all missing links (there 
were a few others that were omitted). I've changed the presentation a bit 
to keep things as compact as possible.

Result should be visible in a few hours on:
http://www.debian.org/devel/debian-installer/

Steve noted on IRC that it may not be worth including links to DVD 
torrents for weekly images. Let me know if these should be removed.
Does the same go for weekly CD images?

(Note that links to weekly images are currently 404 as there has not yet 
been a weekly build since the release of Beta 3).


pgpZazoH0BIqr.pgp
Description: PGP signature

Re: Status of inetd for etch

[Frans Pop]

On Thursday 17 August 2006 19:21, Hendrik Sattler wrote:
> Am Donnerstag 10 August 2006 23:56 schrieb Roger Leigh:
> >   The inetd daemon installed by default:
> > etch:   openbsd-inetd | netkit-inetd
>
> Note: etch beta 3 show me a dpkg status of "ic" for netkit-inetd after
> a fresh installation. openbsd-inetd is installed. Where does this come
> from?

From the fact that debootstrap currently tries to install both due to the 
fact that the priority for netkit-inetd had not yet been changed (I think 
this has been fixed now).

> The default installation also shows other questionable services that
> automatically get installed:
> - identd (who actually _needs_ this?)
> - lpr (useless on systems without a printer)

Also due to their current priority.


pgpJx6fFBgkOc.pgp
Description: PGP signature

Re: Extended partition creation policy ?

[Frans Pop]

Hello David,

On Thursday 07 September 2006 14:14, David Balazic wrote:
> I noticed, that when the debian installer is instructed to create
> two partitions, whose joint size is less than the size of the disk,
> then it creates one primary partition and one logical partition inside
> an extended partition.
>
> The issue is, that this extended partition has the size of the logical
> partition and not the maximum possible size (the entire empty disk
> space plus the logical parition).

The correct way to report this would be to file a bug report [1] against 
the package "partman-base". That will make sure it is brought to the 
attention of the debian-installer team and that its resolution will be 
tracked in the Debian Bug Tracking System (BTS).

Could you please do that?

Thanks,
FJP

[1] http://www.debian.org/Bugs/Reporting


pgpSzVmmudrW9.pgp
Description: PGP signature

Re: First call for votes for the assets handling constitutional amendment GR

[Frans Pop]

On Sunday 10 September 2006 01:46, Debian-project Secretary wrote:
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
b7af2494-93e2-490e-9312-85647b0928b3
[ 1 ] Choice 1: Amend the constitution  [needs 3:1]
[   ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


pgpjZnrjyNAXL.pgp
Description: PGP signature

Re: First call for votes for the assets handling constitutional amendment GR

[Frans Pop]

On Tuesday 12 September 2006 02:07, Frans Pop wrote:
> On Sunday 10 September 2006 01:46, Debian-project Secretary wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines
> =-=-=-=-=-=-=-=-

Oops. Sorry.


pgpogZFg9RR6Q.pgp
Description: PGP signature

Re: Request to mailing list Pkg-qof-maintainers rejected

[Frans Pop]

On Tuesday 12 September 2006 02:11, Charles Plessy wrote:
> It is really unfortunate that the regulation of moderation is hidden
> under a "privacy" menu in Mailman. Maybe the most straightforward mean
> to slove this in the future would be to make the new lists unmoderated
> by default?

Or ask the alioth admins to set up defaults that allow at least BTS and 
PTS and maybe some other categories of mails?


pgpps4b0v8RFJ.pgp
Description: PGP signature

Re: Bug#387286: Acknowledgement (postrm_hook is not run)

[Frans Pop]

reassign 387286 grub
severity 387286 grave
retitle 387286 grub path transition is breaking kernel removals
thanks

On Wednesday 13 September 2006 16:28, Manoj Srivastava wrote:
> The grub maintainer has not thought through all use cases,
>  including yours -- changing /etc/kernel-img.conf to not contain
>  absolute path names while there are kernel images on disk with the
>  older postrm scripts will cause problems when those packages are
>  removed.

If the bug is caused by the grub transition, why don't you reassign it 
there with appropriate severity?

FWIW, I've seen the issue myself too.


pgppoOr4TDenE.pgp
Description: PGP signature

Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?

[Frans Pop]

On Saturday 16 September 2006 23:07, Petter Reinholdtsen wrote:
> I agree that this need to be documented.  We work on some notes for
> the sysvinit package, and will include it there.

Sounds to me like this belongs in policy.


pgpTZyxVfGvin.pgp
Description: PGP signature

Re: Moving /var/run to a tmpfs?

[Frans Pop]

On Sunday 17 September 2006 11:23, Steve Langasek wrote:
> On Sun, Sep 17, 2006 at 11:10:33AM +0200, Mario 'BitKoenig' Holbe wrote:
> > Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as
> > 2.4 are maintained kernel-trees and just because the kernel-team
> > seems to like to live on the bleeding-edge of still heavily-changing
> > kernels only, there is no need for admins of stable systems to do the
> > same.
>
> There is no requirement that 2.2 kernels be supported by the etch
> userspace, and indeed for most release architectures there is no such
> support in glibc for etch.

It does make a case for keeping a package like initrd-tools around though.


pgp91xXafQQR0.pgp
Description: PGP signature

Re: (proposed) Mass bug filing for debconf "abuse" by using low|medium priority debconf notes?

[Frans Pop]

On Monday 18 September 2006 16:36, Nathanael Nerode wrote:
> Frankly, the kernel's "You NEED to restart your computer SOON" message
> is a good example, if it's telling the truth.  But that cheats by not
> using debconf.

Oh yes it does!
When have you last done a kernel upgrade in testing/unstable? ;-)


pgp89qPM3iRQy.pgp
Description: PGP signature

Re: Compatibility between Debian amd64 and other distributions

[Frans Pop]

On Monday 25 September 2006 09:39, Andreas Jochens wrote:
> The proposed glibc patch will break the installer. The installer does
> not have the symlink from /usr/lib64 to /usr/lib. (This is not by
> accident. It has been decided following some discussion.)

The symlink currently is there actually:

rootskel (0.79) unstable; urgency=low
[...]
  * Joshua Kwan
- Symlink lib to lib64 to unhork amd64 images. Patch by Kurt Roeckx
  <[EMAIL PROTECTED]> (Closes: #256738)

 -- Colin Watson <[EMAIL PROTECTED]>  Fri,  2 Jul 2004 12:05:29 +0100

The link is currently created for amd64 and ppc64.


pgpIyWlEAQKnp.pgp
Description: PGP signature

Re: Compatibility between Debian amd64 and other distributions

[Frans Pop]

On Tuesday 26 September 2006 08:11, Andreas Jochens wrote:
> rootskel only creates the symlink from /lib64 to /lib which is required
> to run dynamically linked binaries. It does _not_ create the symlink
> from /usr/lib64 to /usr/lib.

Sorry, my mistake. Missed the /usr/ bit :-(


pgpZmrpeO4K3F.pgp
Description: PGP signature

Re: Accepted kde-icons-crystalclear 0.0.20050623.dfsg.1-1 (source all)

[Frans Pop]

Please do _not_ use a mail@ or root@ or daemon@ address to send mail to 
debian addresses. They will be filtered out as such addresses are 
considered to be reserved for administrative and system accounts.

I've attached 2 mails that were filtered out because of this today.

See also man procmailrc(5), under MISCELLANEOUS.

Cheers,
Frans Pop
Debian List master

On Friday 29 September 2006 00:03, you wrote:
> Format: 1.7
> Date: Tue, 26 Sep 2006 12:41:59 +0200
> Source: kde-icons-crystalclear
> Binary: kde-icons-crystalclear
> Architecture: source all
> Version: 0.0.20050623.dfsg.1-1
> Distribution: unstable
> Urgency: high
> Maintainer: Bastian Venthur <[EMAIL PROTECTED]>
> Changed-By: Bastian Venthur <[EMAIL PROTECTED]>
> Description:
>  kde-icons-crystalclear - Everaldo's "Crystal Clear" icon theme for KDE
> Closes: 389499
> Changes:
>  kde-icons-crystalclear (0.0.20050623.dfsg.1-1) unstable; urgency=high
>  .
>* Removed non-free Firefox icon (Closes: #389499)
>  - Introduced dfsg-version scheme since I needed to alter upstreams
>orig-tarball.
>  - See README.Debian-source for further information.
>  .
>* Bumped standards-version (no changes)
> Files:
>  f5920d53f713e0d5f03fca8b226f1209 665 kde optional
> kde-icons-crystalclear_0.0.20050623.dfsg.1-1.dsc
> 70ecc3c04aa4b6ac525dd1602ee21702 17293444 kde optional
> kde-icons-crystalclear_0.0.20050623.dfsg.1.orig.tar.gz
> 346af3995a5f5ebd8ace529eaf552e9d 1794 kde optional
> kde-icons-crystalclear_0.0.20050623.dfsg.1-1.diff.gz
> a81edb66e4ad97a0aed34dea33e154a2 17438874 kde optional
> kde-icons-crystalclear_0.0.20050623.dfsg.1-1_all.deb
>
> Accepted:
> kde-icons-crystalclear_0.0.20050623.dfsg.1-1.diff.gz
>   to
> pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.
>dfsg.1-1.diff.gz kde-icons-crystalclear_0.0.20050623.dfsg.1-1.dsc
>   to
> pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.
>dfsg.1-1.dsc kde-icons-crystalclear_0.0.20050623.dfsg.1-1_all.deb
>   to
> pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.
>dfsg.1-1_all.deb kde-icons-crystalclear_0.0.20050623.dfsg.1.orig.tar.gz
>   to
> pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.
>dfsg.1.orig.tar.gz

--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 26 Sep 2006 12:41:59 +0200
Source: kde-icons-crystalclear
Binary: kde-icons-crystalclear
Architecture: source all
Version: 0.0.20050623.dfsg.1-1
Distribution: unstable
Urgency: high
Maintainer: Bastian Venthur <[EMAIL PROTECTED]>
Changed-By: Bastian Venthur <[EMAIL PROTECTED]>
Description: 
 kde-icons-crystalclear - Everaldo's "Crystal Clear" icon theme for KDE
Closes: 389499
Changes: 
 kde-icons-crystalclear (0.0.20050623.dfsg.1-1) unstable; urgency=high
 .
   * Removed non-free Firefox icon (Closes: #389499)
 - Introduced dfsg-version scheme since I needed to alter upstreams
   orig-tarball.
 - See README.Debian-source for further information.
 .
   * Bumped standards-version (no changes)
Files: 
 f5920d53f713e0d5f03fca8b226f1209 665 kde optional 
kde-icons-crystalclear_0.0.20050623.dfsg.1-1.dsc
 70ecc3c04aa4b6ac525dd1602ee21702 17293444 kde optional 
kde-icons-crystalclear_0.0.20050623.dfsg.1.orig.tar.gz
 346af3995a5f5ebd8ace529eaf552e9d 1794 kde optional 
kde-icons-crystalclear_0.0.20050623.dfsg.1-1.diff.gz
 a81edb66e4ad97a0aed34dea33e154a2 17438874 kde optional 
kde-icons-crystalclear_0.0.20050623.dfsg.1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFHCXrCV53xXnMZYYRAjgDAJ47lzUdsWSdXRZmYuRmZ6bfVZYI7gCfYzNv
viGDIiwzkzPsdu5Ic4T2OAQ=
=GXDL
-END PGP SIGNATURE-


Accepted:
kde-icons-crystalclear_0.0.20050623.dfsg.1-1.diff.gz
  to 
pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.dfsg.1-1.diff.gz
kde-icons-crystalclear_0.0.20050623.dfsg.1-1.dsc
  to 
pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.dfsg.1-1.dsc
kde-icons-crystalclear_0.0.20050623.dfsg.1-1_all.deb
  to 
pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.dfsg.1-1_all.deb
kde-icons-crystalclear_0.0.20050623.dfsg.1.orig.tar.gz
  to 
pool/main/k/kde-icons-crystalclear/kde-icons-crystalclear_0.0.20050623.dfsg.1.orig.tar.gz

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 26 Sep 2006 14:14:43 +0200
Source: kde-icons-nuovext
Binary: kde-icons-nuovext
Architecture: source all
Version: 1.6.dfsg.1-1
Distribution: unstable
Urgency: high
Maintainer: Bastian Venthur <[EMAIL PROTECTED]>
Changed-By: Bastian Venthur <[EMAIL PROTECTED]>
Description: 
 kde-icons-nuovext - nuoveXT icon theme for KDE
Changes: 
 kde-icons-nuovext (1.6.dfsg.1-1) unstable; urgency=high
 .
   

Re: Simpleminded members better than abusive members

[Frans Pop]

On Monday 02 October 2006 17:15, Dan Jacobson wrote:
> You might want to have related workshops at the next Debian
> conference or seminars. The leadership team should get involved.

Try filing better bug reports instead. I don't see _any_ rationale in 
#390564 why the maintainer should add the Suggests.

Do you really think it is strange that people dismiss your bug reports if 
you habitually fail to present them decently?


pgpzuQPm2Z1Sy.pgp
Description: PGP signature

[Debian Installer] General release plan for RC1

[Frans Pop]

=== D-I STRING FREEZE: Thu 12 Okt, 00:00 UTC - Sun 22 Okt, 00:00 UTC ===

Hi folks,

This mail really should have gone out at least two and probably three 
weeks earlier. Blame goes to the discussions on d-{private,vote,wherever} 
which resulted in a serious drop in my motivation in recent weeks and in 
me dragging my heels on preparing the release.
My apologies for letting you all down.


GENERAL STATUS
==
The most important work planned for RC1 has been done and the installer in 
general works well, although some finishing touches and testing are still 
planned in the run up to Release Candidate 1 of the installer.

I don't have a hard planned release date yet, but it will probably be 
first week of November. Detailed planning and updates will be sent to 
d-boot and d-release lists.
General status and preparations for Etch RC1 can be found on [1].

As it looks now RC1 will be released with kernel 2.6.17, unless 2.6.18 is 
ready to migrate to testing in time for us to make the switch before the 
release. If not, we plan to switch to 2.6.18 ASAP after RC1 and release 
RC2 ASAP after 2.6.18 does migrate to testing.

How can you help?
-
If you have some time, please help us by testing the installer. We need 
testing especially for the non-mainstream architectures and new features 
recently introduced in the installer (e.g. encrypted partitioning).

Especially welcome is also specific testing by e.g. maintainers of 
packages/functionality used in the installer: RAID/LVM support, PCMCIA, 
filesystems (JFS, XFS, ...), bootloaders, etc.
Please check if the bits *you* care about are supported well!

Watch out for calls for testing on d-d-a!


GRAPHICAL INSTALLER
===
The graphical installer now, for the first time, uses udebs built from 
official GTK library packages (2.8.x), which means we will be able to 
drop the various unofficial packages we have been using up to Beta 3. 
Thanks to Dave Beckett, Loïc Minier and Josselin Mouette for helping us 
get this far!

The GNOME maintainers have decided to stay with 2.14 and GTK 2.8.x for 
Etch. This means that g-i will also stay with the current 2.8.x libs, so 
until the release we need to focus on that and leave work on 2.10.x for 
post-Etch.
There is one RC issue that will need to be resolved before RC1: #390683.


TRANSLATIONS

As announced at the top of this mail there will be a string freeze from 
Okt 12 to 22, which means there will be no changes in English strings for 
level1, unless it is absolutely unavoidable.
Please try to update your translations (for level 1) in that period 
(preferably to 100%). There will be a full upload of all installer 
components with updated translations immediately after the freeze and 
these will be included in the release.

There have been a few important changes in strings this weekend and there 
may be a few more in the next few days.

Please also reserve time for testing the installer in you translation 
after the release. The RC2 release is very likely the last chance to fix 
any issues!

After discussion with Christian Perrier (the god of Debian/D-I i18n), we 
have, with regret, decided to drop support in the installer for a few 
translations that are very incomplete and have seen no activity from 
translators for a very long time. The affected languages are: Belarusian 
and Xhosa, and probably also Tamil and Georgian.
Besides the incompleteness of the translations, an important factor in 
this decision is that the installer requires a huge amount of memory 
currently and a large percentage of that goes to translations. Disabling 
some languages gives us some needed breathing space.

A few other languages are still in danger of being dropped before Etch. 
Christian and I will keep you updated on d-i18n.

On the positive side: we've gained support for Marathi.


INSTALLATION GUIDE
==

The installation guide will need at least some important updates and 
hopefully there will be a little time and energy left over for some 
restructuring, though probably nothing really major.


Cheers,
FJP

[1] http://wiki.debian.org/DebianInstaller/EtchRC1Prep


pgpfPlDacAEvO.pgp
Description: PGP signature

Re: debian-policy: New virtual package: cron-daemon

[Frans Pop]

On Sunday 08 October 2006 21:05, Javier Fernández-Sanguino Peña wrote:
> I propose re-adding 'cron-daemon' with the following requirements (that
> will need to be written down similarly to the 11.6. section "Mail
> transport, delivery and user agents"):

Maybe add:
- should be able to work nicely with anacron

I realize that this is really the other way around and that it is probably 
not much of an issue, but still something to keep in mind.


pgp50EiNMh7hQ.pgp
Description: PGP signature

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[Frans Pop]

On Sunday 08 October 2006 22:26, Marc Haber wrote:
> I'd now like a low priority debconf note in exim4, exim4-base and the
> daemon packages which is only shown if the package is to be
> _re_configured, and tells people to dpkg-reconfigure exim4-config.

A _low_ priority note probably makes no sense as with the default debconf 
prio (high) almost nobody would ever get to see it, which kind of defeats 
its purpose.
Or am I missing something?


pgprzmgBrF1Ua.pgp
Description: PGP signature

Re: Bug#392017: apt.conf contains Acquire::HTTP::Proxy "false", does apt-listbugs need to support it?

[Frans Pop]

On Tuesday 10 October 2006 15:34, Junichi Uekawa wrote:
> Today, I've received at least two reports about people who have set
> Acquire::HTTP::Proxy "false"
>
> From reading apt.conf manpage, the correct configuration is "DIRECT".
>
> Why are people setting this value "false", and do I need to support it
> in apt-listbugs?

This is probably due to an error that was present for some time in Debian 
Installer:

apt-setup (1:0.15) unstable; urgency=low

  * Fix broken proxy setting code in 90security. Closes: #378868
Some systems installed before this fix will have Acquire::http::proxy
"false" set in apt.conf, which leads to breakage in some situations.
Also, if a proxy was set, it would not be written to the file.

 -- Joey Hess <[EMAIL PROTECTED]>  Thu, 17 Aug 2006 17:45:07 -0400

Cheers,
FJP


pgpV9l5801Yd3.pgp
Description: PGP signature

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Frans Pop]

On Thursday 12 October 2006 12:34, Ian Jackson wrote:
> Matthew Wilcox writes ("Re: Lack of a GR proposal explicitly condemning 
dunc-tank"):
> > I'm so thoroughly disgusted by you and the actions of people like you
> > that I've stopped working on Debian.  nice job, wanker.
>
> That is the sole content of Matthew Wilcox's message to me, apart from
> some quoted text from debian-private, which I have removed.
>
> Normally I wouldn't publish private email but I think in this case the
> abusive nature warrants it.

Well, if he really has stopped worked on Debian, he has a point doesn't 
he? Sorry, but I don't see why you felt the need to share this message.


pgpFkfHrzXUKK.pgp
Description: PGP signature

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Frans Pop]

On Thursday 12 October 2006 18:50, Russ Allbery wrote:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > Normally I wouldn't publish private email but I think in this case
> > the abusive nature warrants it.
>
> Two wrongs didn't really make a right here, IMO, and I'm not talking
> about publication of private e-mail.  Losing one's temper and insulting
> one's colleagues in e-mail isn't okay, but neither is deciding to
> escalate an already angry situation by trying to humiliate someone in
> public for losing their temper.  Nothing good is going to come from
> that.

Yes, and quietly ignoring an emotional private mail would help to prevent 
escalating anything; certainly more than posting it on a public mailing 
list does.


pgpOpOcB7x8Hj.pgp
Description: PGP signature

Re: delay of the full etch freeze

[Frans Pop]

On Thursday 12 October 2006 22:22, Petter Reinholdtsen wrote:
> So I would recommend against moving the freeze deadline to allow
> packages in NEW to enter.

I would guess for the most part package is  NEW are not totally new 
packages, but rather packages with a new upstream release that causes 
(minor?) ABI changes or e.g. changes in packaging because of licencing 
issues forcing _existing_ packages to go through NEW.
In those cases I can well understand maintainer's frustration if NEW 
processing suddenly takes weeks again after we all just got used to 
having NEW processed within days for a while.

Your point is valid, but I doubt it is valid for most packages currently 
waiting in NEW.

Cheers,
FJP


pgpk5KMLIhsFi.pgp
Description: PGP signature

Debian Installer - Call for testing *this week*

[Frans Pop]

(Please reply to the debian-boot list.)

Preparations for Release Candidate 1 of the installer have now really 
started. All important functional changes are now included in the daily 
images.

In order improve the quality of the release and reduce the number of nasty 
surprises afterwards, it would be great if we could get some help testing 
the installer during *this week*.

Please make sure you use one of the _daily built_ images available from:
http://www.debian.org/devel/debian-installer/
or
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/

and file an installation report with your findings:
http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug

See this wiki page for a general overview of the planned release, 
including known issues:
http://wiki.debian.org/DebianInstaller/EtchRC1Prep


Testing the installer for your favorite architecture(s)
===
This is the main focus for this call for testing. Please let us know if 
there are any important issues, especially regressions from previous 
releases. If you can, try different installation methods.

Note that the installer still uses 2.6.17. Main reason is that 2.6.18 is 
not yet ready to migrate to testing and switching to 2.6.18 would 
therefore block RC1 of d-i. Depending on the kernel team and RMs, we may 
still switch to 2.6.18 before RC1, but switching immediately afterwards 
looks more likely.

Other things to test

There is a number of other things that could be tested, mostly new 
functionality that was added recently:
- graphical installer, especially whether your mouse and touchpad work
  correctly
- crypto support in partman: the installer now has crypto support both
  for guided [1] and manual [2] partitioning; thorough tests, including
  of the actual security of the installed system, very, very welcome
- automatic raid partitioning (preseeded only [1])
- 2.6 based installation floppies for i386
- support for non-standard filesystems (i.e. anything other than ext3)
- if you speak a language other than English, consider installing in
  that language; note that one last round of translation updates is
  still planned, but reports of issues are still appreciated

TIA,
Frans Pop

[1]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#di-partition
[2]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#partman-crypto
[3]http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-partman-raid


pgpJWmZuObmyg.pgp
Description: PGP signature

Re: Bug mass filling

[Frans Pop]

On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
> If no problem is caused by it, I believe 'normal' or even 'wishlist'
> severity is the proper severity to use.

s/wishlist/minor/

It _is_ a bug after all.


pgp8CuxfBlHbn.pgp
Description: PGP signature

Re: openssh packages with updated selinux patch

[Frans Pop]

On Tuesday 24 October 2006 07:19, Manoj Srivastava wrote:
> No, it is not. The configure patch:
>
>  ensures that LIBSELINUX expands to -lselinux only on machines where
>  it is available, not otherwise.
>
> Unless you are saying that the configure.ac patch is broken,
>  in which case please supply a log of the regenerated configure script
>  showing that it fails.

AFAICT the argument is that selinux should not be hard linked at all. 
Having openssh require selinux libs is unwanted overhead for the 
installer.

A solution should be found so that selinux will only be used if it is 
available _at runtime_, as was already done for some other libs that also 
produce udebs.

See for comparison:
http://bugs.debian.org/318115
http://bugs.debian.org/375413

Alternatively the udebs could be compiled separately without selinux 
support.

Cheers,
FJP


pgptRNovt1e3b.pgp
Description: PGP signature

Re: openssh packages with updated selinux patch

[Frans Pop]

On Tuesday 24 October 2006 23:18, Manoj Srivastava wrote:
> Either of these would be fine (though looking at the size of
>  libselinux1, I wonder if there are any numbers behind  the burden
>  theory?), but that would be a more intrusive change for openssh than
>  I am willing to make as a non-maintainer at this stage of the game.

We don't need any "numbers". The installer runs fully in memory, sometimes 
on systems with very little memory, and a lot of it runs before swap 
is/can be enabled. This means that _every_ byte is worth saving.

Call it a design goal.

Cheers,
FJP


pgp8UvXF83xpQ.pgp
Description: PGP signature

Re: Is something wrong to XGL, Compiz, Cgwd be packaged?

[Frans Pop]

On Saturday 28 October 2006 23:11, Gustavo Franco wrote:
> If there will be no regressions, please add the composite bit in the
> xorg.conf by default.

Is that really a good idea for something that is so young and untested, so 
shortly before the release?
Is it wanted for all architectures, for all systems, irrespective of their 
speed?

Please really consider and discuss the implications before so casually 
suggesting something like this.


pgpb7t1wxGjUX.pgp
Description: PGP signature

Re: Is something wrong to XGL, Compiz, Cgwd be packaged?

[Frans Pop]

On Saturday 28 October 2006 23:56, Gustavo Franco wrote:
> > Is that really a good idea for something that is so young and
> > untested, so shortly before the release?
> > Is it wanted for all architectures, for all systems, irrespective of
> > their speed?
>
> Calm down Frans, what about aiglx then?

Yes, possibly the same goes for aiglx.

> I wrote 'if there will be no 
> regressions', that's up to XSF and the users using unstable and even
> testing tell us. I still trust our release process (as in
> unstable->testing).

The problem that we hardly have the time to get feedback.
I do know that I currently see loads of bug reports passing by on the 
debian-x list relating to compiz, beryl and related stuff, which would 
make me very reluctant to enable anything by default.

However, I will be the first to admit that I have not used any of it 
myself so far and don't know enough about it anyway. My mail was purely 
intended to make the people working on this take a step back and ask 
themselves if these new functionalities are really ready to be enabled by 
default.

> Btw, i like the debconf suggestion too.

Only if the question is only asked at lower debconf priorities and still 
have sensible defaults.


pgposFCgv4rnu.pgp
Description: PGP signature

Re: Is something wrong to XGL, Compiz, Cgwd be packaged?

[Frans Pop]

On Sunday 29 October 2006 14:14, David Nusinow wrote:
> [0] I'd love some feedback from KDE people on this. I'll sit down and
> poke around the kwin code a bit to see how it works if I have the time.

In that case wouldn't a mail to debian-kde with some information and 
instructions be the best way to go about that.

Some info on how to check that it is enabled and what to expect would be 
nice.

I use KDE, but have not tried this stuff yet as it all seemed very 
GNOME-centered...

Cheers,
FJP


pgpPmGYMCzeom.pgp
Description: PGP signature

Re: ca-certificates symlinks out of /etc

[Frans Pop]

On Tuesday 31 October 2006 21:03, Stephen Frost wrote:
> If they expire then they should be updated by the package.  One does
> not generally modify issued certificates.  If the package isn't
> handling certificate expiration then the point of having them packaged
> at all pretty much goes away.  Incomplete certificates would be a bug
> in the package (by incomplete I expect you mean that somehow it's a
> partial file, if you mean that some certificates are missing, then
> you're certainly free to add those into that directory as regular
> files, or to ask for inclusion of them in the package).

Which probably means that ca-certificates is a perfect candidate to be 
updated on volatile.debian.net-soon-to-be-org for stable releases.


pgpom7f38Q4jL.pgp
Description: PGP signature

Re: Lots of (easily recognisible) spam sent to the BTS today

[Frans Pop]

On Thursday 02 November 2006 02:56, Blars Blarson wrote:
> Rather than that, I would like to see non-versioned close messages
> depriciated, other than ones that are explicitly so.  No change would
> be needed for the majority of cases, only the rare "not a bug" close
> message would need to be different.

And closures for pseudo packages like installation reports, the website, 
lists, etc.


pgpxUoxuSTtNb.pgp
Description: PGP signature

Re: Downgrading the priority of nfs-utils

[Frans Pop]

On Thursday 09 November 2006 15:57, Michael Banck wrote:
> I believe this (= standard stuff that everyone expects to be on a UNIX
> system) should be shoved into a task or even CDD.  Or we could just not
> install those if people select "Desktop" during the install (the latter
> might be the case already, haven't checked).

When have you last done an installation? It _is_ in a separate task now. 
If you don't select it, you get only what is installed by debootstrap.
The "standard" task is always selected by default. You have to deselect it 
if you do not want it installed.


pgpPE8XYtNrqL.pgp
Description: PGP signature

Re: default ext3 options (was: Re: Debian Installer etch RC1 released)

[Frans Pop]

On Tuesday 14 November 2006 09:44, Bastian Venthur wrote:
> And where can I get the full list of ext3-options which are enabled now
> by default?

Enabled by default when creating a new file system:
$ less /etc/mke2fs.conf

Cheers,
FJP


pgphSiVM6R856.pgp
Description: PGP signature

Re: default ext3 options

[Frans Pop]

On Tuesday 14 November 2006 13:35, Sam Morris wrote:
> filesystem. However, to get the benefit of the indexing for
> already-created directories, e2fsck -D should be run after dir_index
> has been added; therefore it's probably best to just document the
> procedure in the release notes.

If you'd really like to see this documented, then please file a bug report 
against release-notes with a proposed text. Just mentioning it here is 
not going to make it happen...

Cheers,
FJP


pgpEZ3VgtidAt.pgp
Description: PGP signature

Re: Debian Installer etch RC1 released

[Frans Pop]

On Tuesday 14 November 2006 14:58, Roberto C. Sanchez wrote:
> I understand that the line must be drawn somewhere.  However, I am
> concerned about Etch shipping with a 2.6.17 kernel because of Xen.
> AIUI, Xen has issues with 2.6.17 kernels (at least those available from
> backports).  I run some Xen servers, each with a number of domUs and so
> would like to see that Xen be treated as a "first-class citizen" in
> Debian.
>
> If I am wrong, I apologize.  I am going from discussion I recall seeing
> on the pkg-xen list.

Yes, you are wrong: there is an RC2 planned that will use 2.6.18. Please 
read the comment near the bottom of the D-I release mail.

OTOH, there are still some issues with 2.6.18 that need to be resolved 
before it is ready to migrate to testing...

Cheers,
FJP


pgpToFmfLAfcs.pgp
Description: PGP signature

Re: Debian Archive Automatic Signing Key (4.0/etch)?

[Frans Pop]

On Wednesday 22 November 2006 07:22, Andreas Tille wrote:
> But Hendrik Sattler is perfectly right and this knowledge has to be
> stored at prominant places like:
>
> a) installation manual
> b) apt-key.8
> c) perhaps somewhere else
>
> Could maintainers of a) and b) (and perhaps c) ;-)) acknowledge, that
> this will be done

I don't think the Installation Guide is the correct place for this 
information (rationale: it has nothing to do with installing a system, 
but rather with maintaining an installed system).
I would suggest the Debian Reference instead.

> or should we rather file bug reports (IMHO with severity "important")
> to these packages? 

Well, you probably know that a bug report with a patch attached is most 
likely to produce positive results :-)


pgpiwJrhVLhef.pgp
Description: PGP signature

Re: KDE and Gnome panel applets showing percentage of broken packages

[Frans Pop]

On Tuesday 05 December 2006 22:25, Berke Durak wrote:
> I will just say that in my opinion, a repository such as stable,
> testing or unstable should be self-contained.

For stable and testing that is true. However, sid is broken by design as 
it will always receive new versions of packages first and basically 
packages that depended on it can only be recompiled against the new 
package (if needed) once it is in.
So, sid will always have a short period after some new uploads where it is 
inconsistent and a transition is being managed.

The strength of Debian's package management tools is that you can still 
update the part of sid that is good even while some packages you have 
installed are "broken". (Though you need a little bit of understanding of 
what is happening to use the tools correctly, which is one of the main 
reason why sid is not recommended for new users.)

Cheers,
FJP


pgpIGdcDihLQf.pgp
Description: PGP signature

Re: KDE and Gnome panel applets showing percentage of broken packages

[Frans Pop]

On Wednesday 06 December 2006 03:18, Anthony Towns wrote:
> That's true to a point -- but the weather analogy could still work,
> in that the "rainy" areas shouldn't move around the archive, not get
> stuck anywhere. It'd probably be interesting to get a general idea of
> any spots that have a climate that tends to be "wet" or "dry" too...

Oh, sure. I wasn't saying that the provided data is not useful, but rather 
that the fact that sid is not consistent to some degree (mostly only 
minor) is expected rather than an indication that something is seriously 
wrong.


pgpMm2NU7MXgq.pgp
Description: PGP signature

Re: debian-private and Gmail

[Frans Pop]

On Wednesday 06 December 2006 03:32, Nelson A. de Oliveira wrote:
> I saw that it's possible to redirect my @debian.org email to an
> address and also redirect debian-private to another email. @debian.org
> is set to @gmail.com. Good. But what do I do with debian-private?
> Is it possible to redirect debian-private to @people.debian.org and
> read it at this machine?
> Can someone give me help on this, please?

What I sometimes do when I go on holiday is just clear the "email 
forwarded to" field in LDAP and then the mail stays on master.

So when I get back, I can just:
$ ssh master.debian.org
master:~$ mutt

(Well, actually I currently don't have the forward field set at 
allanymore. Instead I do some basic procmail filtering on master to get 
rid of image spam and then let procmail forward the mail for me.)

Cheers,
FJP


pgpr65WGnPhMd.pgp
Description: PGP signature

Re: debian-private and Gmail

[Frans Pop]

On Wednesday 06 December 2006 08:08, Nelson A. de Oliveira wrote:
> What I am wanting is to redirect all my @debian.org emails to my Gmail
> account (the field "email forwarded to") and to read debian-private
> emails on a Debian machine.
>
> Is it easy to do this (using procmail maybe)?

Yes, you can do this using procmail, though not quite in the way you 
describe. (Maybe it can be done like you describe too, but this seems 
simpler.)

If you clear the "email forwarded to" field and then create a 
~/.procmailrc on master.d.o with the following content, you should get 
the desired result.

<.procmailrc>
SHELL = /bin/sh
MAILDIR=$HOME/Mail
#DEFAULT=$MAILDIR/incoming  #completely optional
LOGFILE=$MAILDIR/_procmail.`date +%Y%m`.log   #recommended
YEARMONTH=`/bin/date +%Y%m`
#VERBOSE=yes
#LOGABSTRACT=yes

# Keep mail from debian-private list on master
:0:
* ^X-Loop: [EMAIL PROTECTED]
private

# Forward the rest to gmail account
:0
! [EMAIL PROTECTED]


With this your debian-private mail should end up in ~/Mail/private, so you 
need to read it (on master) using:
$ mutt -f ~/Mail/private

Cheers,
FJP


pgpDpkbUnI6bv.pgp
Description: PGP signature

Re: python 2.3

[Frans Pop]

On Friday 29 December 2006 03:10, Steve Langasek wrote:
> It was?  I don't remember this...  I certainly wanted to make sure etch
> didn't release with ancient, lingering versions of python like 2.1 and
> 2.2, but from a release POV I never had strong feelings about getting
> rid of python 2.3, which was the current version in sarge.

If it does stay in Etch, could the priority be dropped from standard to 
optional, so that it does not get included on CD1 anymore?

AFAICT there are no more dependencies on it that would require it to be 
included on CD1. Currently it just gets included based on its priority.

Cheers,
FJP


pgpxgCdXyEnSQ.pgp
Description: PGP signature

Re: dicussion about patches ... ignoring patches make motivation to provide them fall

[Frans Pop]

On Monday 20 March 2006 16:04, Thomas Hood wrote:
> It might not be so simple.  Suppose I have taken it upon myself to push
> change Foo through Debian.  The Foo project requires cooperation from
> several DDs and at the beginning I can't tell whether I will get that
> cooperation from all of them.  After having devoted many hours to
> project Foo and after the passage of some months I find that progress
> is blocked by needed changes to package P.  I write to the maintainer
> of P but get no reply.  After repeating this a few times I (finally!)
> get a message from the P maintainer... about his having more important
> things to do than deal with my patch.

Alternative conclusion to this saga...
I discuss on d-devel if the Foo project is a worthwhile goal and how I've 
gotten stuck. There is general agreement that Foo is worth pushing for 
the next release. I ask for a review of/help with my patches to the 
packages that block progress, deal with the comments that come back and 
NMU them (after mailing the maintainer one last time). Foo makes it into 
the next release.


pgp1tkwhNPe0c.pgp
Description: PGP signature

Re: Linux kernel upgrade & udev

[Frans Pop]

On Wednesday 22 March 2006 23:55, Jose Luis Rey wrote:
> I just did a kernel upgrade from 2.6.8 to 2.6.15, but I do have my
> root partition on a RAID 1 config, and the initramfs stops with a
> message about /dev/md0 not existing.
>
> There is a problem of timing, udev waits too much to create the scsi
> devices /dev/sd[abc], so I did an script to wait for this files to
> appear in /dev, which I installed on
>/etc/mkinitramfs/scripts/local-top

Please file a bug report against initramfs-tools. The maintainer is very 
responsive to issues like these and is best placed to (help) find a 
structural solution.


pgpkirHtHzjLO.pgp
Description: PGP signature

Re: We want to honestly apoligize to the whole Debian Community

[Frans Pop]

On Thursday 23 March 2006 00:02, Gregg Coner wrote:
> And plus, to the average user, the most up to date gnome is most
> important. 

Haven't you heard? The average Gnome user is switching away from Gnome to 
other alternatives.

Myself, I'm a KDE user currently, so why do I not propose to sync Debian's 
release to their release schedule? Or why not MySQL, or Apache or ...?
Because I happen to know that releasing Debian involves a bit more than 
waiting for random upstream releases.

Debian follows its own release schedule (which may or may not be optimal) 
and personally I'm very happy with the fact that all signs are that Etch 
will be released in about half the time it took for Sarge to be released.

Cheers,
FJP


pgp070k11HPQm.pgp
Description: PGP signature

Re: Emphasize teams, not packages

[Frans Pop]

On Wednesday 29 March 2006 11:11, Thomas Hood wrote:
> Obviously you can't, currently.

This is not true. The NM team and the DAMs have a certain amount of 
freedom to tailor the NM process to individual applicants.

The "Tasks and skills" part of [1] currently explicitly lists "either 
documentation and internationalisation or package maintenance" as tasks 
for which an applicant can be tested, so not only package maintenance. I 
became a DD via the "documentation and internationalisation" route 
myself.
I don't see why in a specific case "general and Debian specific system 
administration" tasks and skills could not be tested instead.

The best thing to do IMO is to discuss this with the NM Front Desk 
<[EMAIL PROTECTED]>.
I would guess that in this specific case the NM people will want to 
consult with existing DSA members before entering a NM process on that 
basis as obviously there is little point in going through with it if 
Jerome would not be accepted into that team after becoming a DD.
I'd even guess that they'd prefer to have an existing DSA member act as 
AM, at least for the tasks and skills part.

Cheers,
FJP


pgpzFXXn2YwJe.pgp
Description: PGP signature

Re: Emphasize teams, not packages

[Frans Pop]

On Wednesday 29 March 2006 12:08, Frans Pop wrote:
> The "Tasks and skills" part of [1] currently explicitly lists "either
> documentation and internationalisation or package maintenance" as tasks
> for which an applicant can be tested, so not only package maintenance.

Forgot the link:
[1] http://www.debian.org/devel/join/nm-checklist


pgpgRwXuQx781.pgp
Description: PGP signature

Re: glibc_2.3.6-6_i386.changes REJECTED

[Frans Pop]

On Tuesday 11 April 2006 15:08, Goswin von Brederlow wrote:
> When doing a full upgrade (stable->unstable) could it happen that apt
> breaks the libc6<->libc-bin depends cycle and put them into seperate
> dpkg calls? I don't remember how smart/stupid libapt was there. It
> might be best to add "apt-get install libc6 libc-bin" to the upgrade
> instructions.

If that is needed, please file a bug report against release-notes.


pgperiaqtiwg1.pgp
Description: PGP signature

Re: Lintian package-has-a-duplicate-relation

[Frans Pop]

On Sunday 16 April 2006 22:13, Steve Langasek wrote:
> Now, the clean solution for those cases when there's a compelling
> reason to implement this bad idea:  see what dpkg-shlibdeps(1) has to
> say about shlibs.local.

One minor gripe about dpkg-shlibdeps(1)...
If I look at that page, I get redirected to dpkg-source(1). This is fine, 
but the page also contains:
   See  dpkg-shlibdeps(1)  for  details  of  the  format of shared library
   dependency files.

AFAICT there's no separate manpage for dpkg-shlibdeps(1) and I cannot find 
details if the format of shlibs files in dpkg-shlibdeps(1).
Is this a bug that should be reported or am I missing something?


pgpfAvc682oqn.pgp
Description: PGP signature

Re: Installation is FANTASTIC!!!

[Frans Pop]

On Saturday 22 April 2006 01:27, Henning Makholm wrote:
> I don't care much for mouse clicks, but "80x25 characters and a 8-bit
> font" is a very low common denominator for the amount of text one can
> show on the screen when selecting packages or answering complex
> debconf questions. The 8-bit-ness of the font is not a problem for
> people installing in English, but being able to see more lines at a
> time should benefit everybody who want or need more control than just
> accepting all of the defaults.

You can boot the installer with a vga=... boot option to use a higher 
resolution console. When I install on my sparc with framebuffer enabled I 
get something like 40 lines and 132 columns.


pgpz8rgiNMZkU.pgp
Description: PGP signature

Re: utnubu-desktop for the masses

[Frans Pop]

On Sunday 23 April 2006 23:14, Luk Claes wrote:
> Note that the KDE meta packages are only really taken care of near a
> release because of the transitioning problems... If the meta packages
> get to testing earlier it's very probable they will not be installable
> for a long time...

IMO that is not really a very nice policy. Wouldn't it be possible to 
update the meta packages after each KDE transition has settled down?

Seems to me that there are not that many KDE releases that could not be 
done and it would help the general quality of testing.


pgpN0q06SVwdA.pgp
Description: PGP signature