Re: debian-cd BoF at DebConf
On Wed, Jul 18, 2012 at 05:19:40PM +0100, Steve McIntyre wrote:
> EFI and Secure Boot
> ===
>
> Just a brief mention here - there was a separate BoF about this and
> I'll summarise that shortly. I think it's much too late in the release
> process to get Secure Boot working for Wheezy, but we *do* need to get
> EFI working. (Bug#658352). This should be do-able, but we'll need to
> get lots of help with testing. I currently don't have any EFI-capable
> machines at all, so need to fix that for simple development/testing
> purposes anyway. Maybe worth asking the DPL for some Debian money to
> acquire some machines for this. There will be a call for testing once
> we have some stuff done.
For the avoidance of any doubt: no problem in buying the needed
hardware.
And while I'm at it: thanks a lot for your examplar work in preparing,
holding, and summarizing DebConf BoFs. For one thing, I'm catching up
now and your summaries are being extremely useful. Kudos!
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: (forw) Switch to graphical installer by default?
[ Gah, crappy subject in reply, resend with good subject.
Please Cc:-me on replies. ]
Christian PERRIER wrote:
> I was fearing that. So at the end, the question becomes: do we trade
> on accessibility for the default Debian Installer and therefore need
> to put some specific note in the Release Notes.
>
> Or do we stick to "The Universal System" concept and therefore leave
> the only accessible installer as default. (which indeed makes the
> installer not universal either because of several missing languages).
>
> I'm really balanced on this as I personnally care about *both* of
> course.
It is not clear to me how accessible the initial splash screen --- the
one with currently contain the choice between default, graphical, and
advanced installation options --- is.
*If* that screen is accessible, then maybe an option could be having the
graphical installer by default, but clearly labeling the non-graphical
installer option with something that explains it is more accessible.
My (tentative) rationale is that it'd be easier for someone who is in
need of accessibility to discover the best option for them (thanks to
the accessibility of the splash screen), than for someone who is in need
of a non-English language to discover theirs (because the splash screen
is not translatable, so they're more likely to take the default option
in English and hope it'll get better afterwards).
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708010311.ga16...@upsilon.cc
Re: <20120708001451.gm4...@mykerinos.kheops.frmug.org>
[ please Cc:-me on replies ]
Christian PERRIER wrote:
> I was fearing that. So at the end, the question becomes: do we trade
> on accessibility for the default Debian Installer and therefore need
> to put some specific note in the Release Notes.
>
> Or do we stick to "The Universal System" concept and therefore leave
> the only accessible installer as default. (which indeed makes the
> installer not universal either because of several missing languages).
>
> I'm really balanced on this as I personnally care about *both* of
> course.
It is not clear to me how accessible the initial splash screen --- the
one with currently contain the choice between default, graphical, and
advanced installation options --- is.
*If* that screen is accessible, then maybe an option could be having the
graphical installer by default, but clearly labeling the non-graphical
installer option with something that explains it is more accessible.
My (tentative) rationale is that it'd be easier for someone who is in
need of accessibility to discover the best option for them (thanks to
the accessibility of the splash screen), than for someone who is in need
of a non-English language to discover theirs (because the splash screen
is not translatable, so they're more likely to take the default option
in English and hope it'll get better afterwards).
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708003536.ga14...@upsilon.cc
Re: Debian & the FSF Secure Boot petition
On Sun, Jun 10, 2012 at 11:17:25AM +0200, Stefano Zacchiroli wrote:
> So, what do you think? Do you see any reason why Debian should /not/
> endorse such a campaign? Are you aware of any other initiative on the
> same vein that we should support to make our worries on that front
> heard?
Dear all, thanks for your feedback! Based on it I've indeed contacted
FSF to join the secure boot petition on behalf of Debian. Our
endorsement for it is now live at
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/stand-up-for-your-freedom-to-install-free-software
I've been asked to provide a quote for FSF press release on the matter
and I'll be happy to do so. OTOH I haven't planned to do a _Debian_
press release on the matter, because I don't think at present we've
anything more to say than what's written in the petition itself. But if
you, as d-i team, want to say something on this matter, please let me
know.
Thanks
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Debian & the FSF Secure Boot petition
On Sun, Jun 10, 2012 at 11:17:25AM +0200, Stefano Zacchiroli wrote:
> Dear d-i hackers, I've been contacted by Paul Wise about FSF campaign on
> "secure boot" [1] (thanks Paul!). As observed by various commenters over
> the net, it is indeed striking that no FOSS distros is in there. I plan
> to contact the FSF asking that Debian is listed as an endorser of the
> campaign.
>
> As you are the Debian people working on our installer, I think it should
> be done in agreement with you.
Thanks a lot for your feedback. I'll check tomorrow with the FSF if they
accept project-level subscriptions and, if they do, submit one on behalf
of Debian.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Debian & the FSF Secure Boot petition
Dear d-i hackers, I've been contacted by Paul Wise about FSF campaign on
"secure boot" [1] (thanks Paul!). As observed by various commenters over
the net, it is indeed striking that no FOSS distros is in there. I plan
to contact the FSF asking that Debian is listed as an endorser of the
campaign.
As you are the Debian people working on our installer, I think it should
be done in agreement with you.
So, what do you think? Do you see any reason why Debian should /not/
endorse such a campaign? Are you aware of any other initiative on the
same vein that we should support to make our worries on that front
heard?
(Please Cc:-me on replies, as I'm not subscribed to -boot.
M-F-T header set accordingly.)
Many thanks in advance for your help,
Cheers.
[1] https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Squeeze, firmware and installation
On Wed, May 05, 2010 at 06:29:55PM +0200, Kurt Roeckx wrote:
> So I was wondering what the state is of everything, and what
> issues people will run into, specially when installing.
So, let me try to wrap-up this discussion. I've gather some info from
Ben Hutchings (thanks!) on the actual impact on the installation. That
is quite significant, as at the very minimum people having the following
network cards won't be able to install without the firmware:
- Intel, Ralink or Realtek wifi controller
- Broadcom NetXtreme II Ethernet controller
Nevertheless, the split of the firmware is an achievement for Debian,
which answers to the criticism we got for having made compromises in
past releases. It is also a success story in the sense that, while
people ranted with us for those compromises, our kernel team worked on
the issue and the net result is that things have improved also upstream
now, thanks to their contributions. In fact, I think we should also do a
bit of communication on the subject, as it will be a remarkable
achievement for Squeeze.
From here, the point is of course how to avoid making the life of users
which need non-free firmware non miserable upon install, while still
making clear that those bits are not part of Debian.
Early on in this thread [1] I've tried to identify our options, which
essentially boil down to:
1) have the non-free firmware on the (first) install media, "protected"
by a BIG FAT WARNING saying that you need non-free firmware to
proceed, but that using it: you get out of Debian, you don't have
support, you should complain with your HW manufacturer, and that
thousands of kittens will be killed by your choice
2) have an alternative set of installation medias (basically Debian +
non-free firmware), shipped under a non-free section of our mirrors
My reading of this thread, assuming that it is representative, is that
(2) is preferred among developers; that is also my favorite choice.
I've then asked Steve McIntyre his opinion (thanks!), as Debian CD team
member, to understand the impact/feasibility on the media production. In
short [2]:
- it seems to be feasible
- he suggested to just do that for netinst (to avoid duplicating the
production of all media)
- a reasonable ETA to have the work-flow for producing both sets of
images is about 2 weeks
Another interesting proposal advanced in this thread [3] by Steve
Langasek is to create on the fly the non-free images. That would be
cool, but I think we should pose the requirement that our users are able
to download the non-free image as usual, and that the image is created
on the fly for them behind the scenes (as Steve has hinted in [3]
already). So, the point to whether this is possible or not is the
obvious one: who volunteers to work on that? I suggest that we go for
the alternate image set by default, unless someone steps up with a
working implementation of Steve idea in time for Squeeze.
A last important point is how to advertise the non-free images on the
web. We should obviously write in the release note the change and IMHO
we should have a link to the non-free images near the download links for
the free images, visually "warning" that they are non-free, pretty much
as we visually warn non-free packages on packages.d.o and similar other
parts of our infrastructure.
Cheers
PS thanks to Kurt for having started this discussion!
[1] http://lists.debian.org/debian-project/2010/05/msg00046.html
[2] disclaimer: IIRC, hence Cc:-ing debian...@lists.d.o to ensure I'm
not on crack; please Steve or other debian-cd people correct me if
I'm utterly wrong!
[3] http://lists.debian.org/debian-project/2010/05/msg00081.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Bug#512740: Sparc disk labels broken on LDOM and Parallel installs
On Mon, Feb 08, 2010 at 10:04:05PM +, Jurij Smakov wrote:
> My main concern is whether it affects installer in any adverse way, so
> if you could arrange for an installer image to be built with the
> modified parted, we could do some testing. I don't have access to a
> machine which supports LDOMs, but I could at least confirm that it
> does not introduce any regressions.
Personally, I'm not very proficient in d-i (read: not at all), so I'm
getting -boot into the loop forwarding your request, for help. Bottom
line for d-i, to test the patch proposed to fix #512740, we need a d-i
sparc image to check for regression on sparc. The patch is attached for
your convenience, see bug log for full context.
Thanks for your feedback!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
#! /bin/sh /usr/share/dpatch/dpatch-run
## sparc-new-label.dpatch by David S. Miller and
## Fabio M. Di Nitto
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix sparc disk label generation. This is required for LDOM and
## DP: parallel installations with Solaris 10.
@DPATCH@
diff -urNad parted-1.8.8.git.2008.03.24~/libparted/labels/sun.c
parted-1.8.8.git.2008.03.24/libparted/labels/sun.c
--- parted-1.8.8.git.2008.03.24~/libparted/labels/sun.c 2008-06-24
12:52:11.0 +0100
+++ parted-1.8.8.git.2008.03.24/libparted/labels/sun.c 2008-06-24
12:56:06.0 +0100
@@ -38,12 +38,30 @@
#define SUN_DISK_MAGIC 0xDABE /* Disk magic number */
#define SUN_DISK_MAXPARTITIONS 8
-#define WHOLE_DISK_ID 0x05
+#define SUN_TAG_UNASSIGNED 0x00/* Unassigned partition */
+#define SUN_TAG_BOOT 0x01/* Boot partition */
+#define SUN_TAG_ROOT 0x02/* Root filesystem */
+#define SUN_TAG_SWAP 0x03/* Swap partition */
+#define SUN_TAG_USR0x04/* /usr filesystem */
+#define SUN_TAG_BACKUP 0x05/* Full-disk slice */
+#define SUN_TAG_STAND 0x06/* Stand partition */
+#define SUN_TAG_VAR0x07/* /var filesystem */
+#define SUN_TAG_HOME 0x08/* /home filesystem */
+#define SUN_TAG_ALTSCTR0x09/* Alt sector partition */
+#define SUN_TAG_CACHE 0x0a/* Cachefs partition*/
+#define SUN_TAG_RESERVED 0x0b/* SMI reserved data*/
+#define SUN_TAG_LINUX_SWAP 0x82/* Linux SWAP */
+#define SUN_TAG_LINUX_NATIVE 0x83/* Linux filesystem */
+#define SUN_TAG_LINUX_LVM 0x8e/* Linux LVM*/
+#define SUN_TAG_LINUX_RAID 0xfd/* LInux RAID */
+
+#define SUN_FLAG_UNMNT 0x01/* Unmountable partition*/
+#define SUN_FLAG_RONLY 0x10/* Read only*/
+
#define WHOLE_DISK_PART2 /* as in 0, 1, 2 (3rd
partition) */
-#define LINUX_SWAP_ID 0x82
typedef struct _SunRawPartition SunRawPartition;
-typedef struct _SunPartitionInfoSunPartitionInfo;
+typedef struct _SunPartInfo SunPartInfo;
typedef struct _SunRawLabel SunRawLabel;
typedef struct _SunPartitionDataSunPartitionData;
typedef struct _SunDiskData SunDiskData;
@@ -53,18 +71,31 @@
u_int32_t num_sectors;/* ...and it's length */
};
-struct __attribute__ ((packed)) _SunPartitionInfo {
- u_int8_tspare1;
- u_int8_tid; /* Partition type */
- u_int8_tspare2;
- u_int8_tflags; /* Partition flags */
+struct __attribute__ ((packed)) _SunPartInfo {
+ u_int16_t tag;/* Tagged type */
+ u_int16_t flags; /* Partition flags */
};
+#define SUN_LABEL_ID_SIZE 128
+#define SUN_VOLUME_ID_SIZE 8
+
+#define SUN_LABEL_VERSION 0x0001
+#define SUN_LABEL_SANE 0x600ddeee
+
struct __attribute__ ((packed)) _SunRawLabel {
- charinfo[128]; /* Informative text string */
- u_int8_tspare0[14];
- SunPartitionInfo infos[SUN_DISK_MAXPARTITIONS];
- u_int8_tspare1[246];/* Boot information etc. */
+ charlabel_id[SUN_LABEL_ID_SIZE];/* Informative text
string */
+ u_int32_t version;
+ charvolume_id[SUN_VOLUME_ID_SIZE];
+ u_int16_t num_part;
+ SunPartInfo infos[SUN_DISK_MAXPARTITIONS];
+ u_int16_t pad1;
+ u_int32_t bootinfo[3];
+ u_int32_t sanity;
+ u_int32_t resv[10];
+ u_int32_t part_timestamps[SUN_DISK_MAXPARTITIONS];
+ u_int32_t write_reinstruct;
+ u_in
Bug#468624: discover-data: diff for NMU version 2.2008.06.25+nmu1
tags 468624 + pending
thanks
Dear maintainer,
I've prepared an NMU for discover-data (versioned as 2.2008.06.25+nmu1)
and uploaded it to DELAYED/7. Please feel free to tell me if I should
delay it longer.
The patch, which you can find attached, ports the Python scripts shipped
under /usr/share/tools/ to legacy Python APIs, removing the need (and
the dep) of python-xml. Part of the patch is from Ben Hutching (from
what concerns reduce-xml).
A few notes:
- I've tested the new scripts by running the non-shipped Makefile and
Makefile.update which seem to be the only part of discover-data using
those scripts
- /usr/share/tools/ is not a terribly good path, wouldn't it be more
appropriate to ship those scripts under /usr/share/discover-data/ or
so?
- debian/control still contains a XS-Vcs-Svn which should be turned in
Vcs-Svn as it is now officially supported by dpkg-dev
I've refrained from doing other changes than the Python porting in the
NMU to ease integration of my patch.
Cheers..
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
diff -Nru discover-data-2.2008.06.25/debian/changelog discover-data-2.2008.06.25+nmu1/debian/changelog
--- discover-data-2.2008.06.25/debian/changelog 2008-06-25 22:42:39.0 +0200
+++ discover-data-2.2008.06.25+nmu1/debian/changelog 2009-09-09 13:06:09.0 +0200
@@ -1,3 +1,13 @@
+discover-data (2.2008.06.25+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Drop build-dep on python-xml (deprecated). Port the following Python
+scripts to legacy python modules (Closes: #468624):
+- reduce-xml (patch from Ben Hutchings)
+- merge-lst-to-xml
+
+ -- Stefano Zacchiroli Wed, 09 Sep 2009 13:01:23 +0200
+
discover-data (2.2008.06.25) unstable; urgency=low
* Update pci-devices.xml and pci.lst
diff -Nru discover-data-2.2008.06.25/merge-lst-to-xml discover-data-2.2008.06.25+nmu1/merge-lst-to-xml
--- discover-data-2.2008.06.25/merge-lst-to-xml 2006-08-13 03:32:04.0 +0200
+++ discover-data-2.2008.06.25+nmu1/merge-lst-to-xml 2009-09-09 13:07:23.0 +0200
@@ -4,7 +4,8 @@
import optparse
import string
-from elementtree import ElementTree, XMLTreeBuilder
+from xml.etree import ElementTree
+from xml.etree.ElementTree import XMLTreeBuilder
class LstParser:
"""Parser for discover 1 device lists. Once initialized, the
@@ -116,14 +117,14 @@
return False
-class TreeBuilderWithComments(XMLTreeBuilder.FancyTreeBuilder):
-"""This class extends ElementTree's FancyTreeBuilder to
+class TreeBuilderWithComments(XMLTreeBuilder):
+"""This class extends ElementTree's to
parse comments, which no builder in ElementTree seems able
to do by itself.
"""
def __init__(self):
-XMLTreeBuilder.FancyTreeBuilder.__init__(self)
+XMLTreeBuilder.__init__(self)
self._parser.CommentHandler = self._comment
def _comment(self, data):
diff -Nru discover-data-2.2008.06.25/merge-lst-to-xml.diff discover-data-2.2008.06.25+nmu1/merge-lst-to-xml.diff
--- discover-data-2.2008.06.25/merge-lst-to-xml.diff 1970-01-01 01:00:00.0 +0100
+++ discover-data-2.2008.06.25+nmu1/merge-lst-to-xml.diff 2009-09-08 22:19:59.0 +0200
@@ -0,0 +1,30 @@
+--- merge-lst-to-xml.orig 2009-09-08 22:11:42.777558468 +0200
merge-lst-to-xml 2009-09-08 22:18:59.330558360 +0200
+@@ -4,7 +4,8 @@
+ import optparse
+ import string
+
+-from elementtree import ElementTree, XMLTreeBuilder
++from xml.etree import ElementTree
++from xml.etree.ElementTree import XMLTreeBuilder
+
+ class LstParser:
+ """Parser for discover 1 device lists. Once initialized, the
+@@ -116,14 +117,14 @@
+
+ return False
+
+-class TreeBuilderWithComments(XMLTreeBuilder.FancyTreeBuilder):
+-"""This class extends ElementTree's FancyTreeBuilder to
++class TreeBuilderWithComments(XMLTreeBuilder):
++"""This class extends ElementTree's to
+ parse comments, which no builder in ElementTree seems able
+ to do by itself.
+ """
+
+ def __init__(self):
+-XMLTreeBuilder.FancyTreeBuilder.__init__(self)
++XMLTreeBuilder.__init__(self)
+ self._parser.CommentHandler = self._comment
+
+ def _comment(self, data):
diff -Nru discover-data-2.2008.06.25/reduce-xml discover-data-2.2008.06.25+nmu1/reduce-xml
--- discover-data-2.2008.06.25/reduce-xml 2005-07-17 14:12:58.0 +0200
+++ discover-data-2.2008.06.25+nmu1/reduce-xml 2009-09-09 13:06:39.0 +0200
@@ -10,8 +10,6 @@
import getopt
import xml.dom
import xml.dom.minid
Bug#468624: python-xml removal: please drop/replace (build) dependencies
tags 468624 + patch
thanks
On Thu, Aug 27, 2009 at 02:33:28AM +0100, Ben Hutchings wrote:
> Sorry, that only covers the reduce-xml script. merge-lst-to-xml also
> needs to be modified.
This patch should cover merge-lst-to-xml . Hence I'm tagging the bug
+patch, but note that the actual patch should contain both mine and
Ben's slices.
The patch to port to the new etree module should be fine, but I'm unable
to test the actual script as I don't know its logics. If someone can
provide some test data, I'd happily put everything together and test
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--- merge-lst-to-xml.orig 2009-09-08 22:11:42.777558468 +0200
+++ merge-lst-to-xml 2009-09-08 22:18:59.330558360 +0200
@@ -4,7 +4,8 @@
import optparse
import string
-from elementtree import ElementTree, XMLTreeBuilder
+from xml.etree import ElementTree
+from xml.etree.ElementTree import XMLTreeBuilder
class LstParser:
"""Parser for discover 1 device lists. Once initialized, the
@@ -116,14 +117,14 @@
return False
-class TreeBuilderWithComments(XMLTreeBuilder.FancyTreeBuilder):
-"""This class extends ElementTree's FancyTreeBuilder to
+class TreeBuilderWithComments(XMLTreeBuilder):
+"""This class extends ElementTree's to
parse comments, which no builder in ElementTree seems able
to do by itself.
"""
def __init__(self):
-XMLTreeBuilder.FancyTreeBuilder.__init__(self)
+XMLTreeBuilder.__init__(self)
self._parser.CommentHandler = self._comment
def _comment(self, data):
Re: removal of svenl from the project
On Tue, Mar 14, 2006 at 09:01:09PM -0500, Andres Salomon wrote:
> Some might argue that we should just kick him from the channel and
> remove his commit access to the debian-kernel project, but that does not
> solve the problem of him abusing other teams, as well as his abusive
> mailing list posts. He also {co-,}maintains some 47 packages, which
> means users for those packages will have to deal w/ him as well. I
I don't know if you've a clue about Sven's behaviour in teams other then
debian-kernel. I do have a clue about Sven's behaviour in the
debian-ocaml-maint team, which he founded and which I joined something
like 5 years ago. That team collaboratively maintains some 30 packages
now and Sven is still an active part of it.
He has always been a valuable contributor of the team, happy to hacking
and to discuss with other people in order to reach common goals.
Discussing with him may be sometimes difficult, that's true, but hey: if
we are supposed to be a community, we need to learn to accept each other
peculiarities! In my experience, Sven has always done more good than
harm to the debian-ocaml-maint team.
So far, I have never took the time to study the detail of the expulsion
process, so sorry if this mail is inappropriate. But be sure that I will
do everything I can as a DD to stop Sven's expulsion.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
signature.asc
Description: Digital signature
Bug#241011: success, but failed to find CD drives
On Thu, Jul 29, 2004 at 02:34:51AM +0200, Frederik Dannemare wrote: > If you can confirm they are no longer present, I will close this report. I'm sorry, but I can't try it again ATM. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#241011: debian installer beta 3, installation report
Package: installation-reports Debian-installer-version: uname -a: Date: Method: Machine: Dell Precision Workstation 360 Mini Tower Processor: P4 2.6 GHz Memory: 1 Gb Root Device: IDE /dev/hda4 Root Size/partition table: Disk /dev/hda: 80.0 GB, 800 bytes 255 heads, 63 sectors/track, 9726 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 15 120456 83 Linux /dev/hda2 * 16 988 7815622+ b W95 FAT32 /dev/hda396059726 979965 82 Linux swap /dev/hda4 989960469208020 83 Linux /dev/hda4 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/hda2 on /windows type vfat (rw) /dev/hda1 on /boot type ext3 (rw) usbfs on /proc/bus/usb type usbfs (rw) Output of lspci: 00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02) 00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801EB USB (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02) 00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corp. 82801EB LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02) 00:1f.2 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 82801EB SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801EB AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro FX 500] (rev a1) 02:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [E] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: The machine is equipped with two CD-like medium: a standard DVD-ROM reader and DVD-Burner, neither of them was detected during the installation. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
