[David Weinehall]
> Since all Ubuntu packages are recompiled against a different set of
> libraries, the bug might not even affect the Debian package, even though
> they share the same source.
The same can be said about Debian architectures, when the autobuilder
build the packages at different ti
[Junichi Uekawa]
> 3. support for X. Some of my packages are command-line console tools,
>but many are actually graphical apps. It would be a plus to have
>some kind of interactive/noninteractive X-based testing.
Would xnee do the trick?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
[Jérôme Warnier]
> But why would you want to become a DD if you are not willing to
> maintain a package. Debian is just about maintaining packages.
Debian needs more than just people maintaining packages. We need
people working on translations, documentation, testing, web pages,
system administr
[Eric Dorland]
> This has probably been covered ad nauseum, but where do we stand in
> respect to getting mplayer in Debian?
[Nathanael Nerode]
> IIRC, the copyright issues were carefully worked out and solved
> after several years, finally reaching the approval of debian-legal.
> At which point
[David Nusinow]
> As far as I know this wasn't any corporate decision by Canonical to
> give back to Debian, but it was a personal decision by Daniel to
> help me (for which I'm immensely grateful).
I do not really understand this kind of reasoning. I get the
impression that you see a difference
[Florian Weimer]
> What about: stop threatening your fellow developers?
Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?
Personally I believe it is time we made clear and written down
explanations on what will happen to badly maintained pac
[Michael Vogt]
> Sorry for the delay. I'm preparing a new upload that adds the 2006
> archive key to the default keyring.
Sounds good. Will this automatically take care of the key update and
make sure no manual intervention is needed to get packages upgraded?
Isn't Ubuntu using the signed apt
When I try to upgrade one of my machines running testing, I get a
warning about a missing public key:
[...]
W: GPG error: http://ftp.no.debian.org testing Release: The
following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 010908312D230C5F
W: Yo
[Neil McGovern]
> Sounds like an idea that's being thrown around at the moment:
> http://wiki.debian.org/FriendsOfDebian
Ah, right. Very good idea indeed. :)
That page even had a few more of those. Perhaps we should just go
ahead and implement it . :)
--
To UNSUBSCRIBE, email to [EMAIL PROT
Your ideas reminds me of the Mandriva Club system, where users can
come together and show their commitment and involvement in Madriva
(previously Mandrake Linux). The site is supposed to be
http://club.mandriva.com/>, but I'm unable to get any response
from it. The google cache gave me this intr
[Russ Allbery]
> Also, I think this is a little silly for small packages. My
> experience with this sort of volunteer work in other areas is that
> if one person does nearly all the work on a regular basis, you're
> not gaining that much by having a backup. The person who is
> theoretically the
[Thomas Hood]
> I don't think that it is ridiculous to require that every package
> have a team behind it---i.e., at least two maintainers. First, if
> someone can't find ONE other person willing to be named as a
> co-maintainer of a given package then I would seriously doubt that
> that package
[Petter Reinholdtsen]
> One user is bootlogd, needing before init is started to store
> stats about the boot. That is before both these points in the boot.
I managed to write bootlogd when I intended to write bootchartd. That
is the package making statistics about the boot process.
[A
ib/run vs /somewhere on the root partition, I'm not
sure what I believe is the best option. I see several valid points
for moving it away from /, and several for keeping it there.
Friendly,
--
Petter Reinholdtsen
One of those
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Anthony Towns]
> I note the FHS's limited definition of /lib (essential libraries and
> kernel modules) is already incorrect for /lib/udev,
> /lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo,
> /lib/alsa, /lib/alsa-utils, /lib/discover and /lib/init.
I did not look closely at the ot
[Marco d'Itri]
>> > I do not remember a consensus about this.
>> Changes in Debian are generally decided by package maintainers, not by
>> consensus.
> Good to know. So I'm happy that nobody will complain when I will make
> udev mandatory.
You seem to have mixed up lack of complaints with decision
[Thaddeus H. Black]
> 3. If James' imperial rules are unacceptable to us, then the
> alternative is to change the person in James' position. It has
> been years since any other option was credible. We all know
> this. This means dismissing James from his fortified posts of
>
[Marc Haber]
> Acknowledged. Debian might have problems, but NEW queue processing
> surely isn't one of them (any more).
I agree that the NEW processing is working quite well these days, and
is no longer the source of much frustration in debian. The
ftp-masters are doing a great job processing n
[Josselin Mouette]
> I started my implication in the project four years ago. For four
> years, there have been problems with keyring maintenance and buildd
> administration. For four years, people responsible for these tasks
> have refused help on these matters. For four years, everything that
> w
[Marc 'HE' Brockschmidt]
> I'd like to know if anyone cares about using these binary signatures
I can not really say if I care or not, as I do not really know what
these binary signatures are. Care to send URL to pages explaining the
topic?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
[Gabor Gombas]
> I'm thinking that it would be very useful to redirect stderr to a
> file (say /var/log/boot/.error). It happens far too often
> that the error message scrolls off the screen, then
> fonty/gdm/etc. starts making scrolling back impossible.
There are ideas to send boot messages to s
[Thijs Kinkhorst]
> If package foo-data is useless when foo is not installed, foo-data
> should depend on package foo. This follows from policy manual 7.2: "The
> Depends field should be used if the depended-on package is required for
> the depending package to provide a significant amount of
> fu
[Nathanael Nerode]
> It's a pity the DPL hasn't anointed a less-busy person with
> authority to alter the keyring.
I suspect and hope the DPL try to reason with the people in question
first, before the DPL wields his authority and push the current holder
of privileged positions aside, as a power
[Wouter Verhelst]
> Oh, and here's something else to ponder: Maybe, just maybe, James
> has more time to go to Ubuntu below zero than he has to handle
> keyring updates because he prioritizes by what gets the bills
> paid. As most of us do, I suppose.
Yes, most of us have changing priorities, and
[Chip Salzenberg]
> I see no point in trying to force my way (back) into a project that
> shows no interest in allowing me to keep participating. Therefore,
> I hereby resign from the Debian Project.
Please, do not do this. "The project" is to large and fuzzy to have
any interest, but there are
[Frank Küster]
> Actually that wouldn't be hard for teTeX, since it looks for
> texmf.cnf at multiple places and reads them all. Even the order is
> as intended - a file in /etc/texmf would override settings from the
> file in /usr/share/texmf.
Very good. Should make it possible to implement a
[Peter Samuelson]
> 'conffile' is dpkg jargon that has a specific meaning: configuration
> files that dpkg handles specially w/r/t upgrades and removals. Editing
> a conffile at install time makes no sense. If you want to edit a
> configuration file, don't ship it as a conffile - in fact, don't
[Frank Küster]
> assume that an update to a package brings in a changed conffile, and
> because the local admin had changed the conffile, he is asked, and he
> refuses to accept the changed version.
>
> Because one of the changes in the new version was crucial for the
> function of the program, th
[Marc Haber]
> If so, we need an adduser interface which properly handles LDAP and
> NIS. This is something that our current adduser does not do, and the
> corresponding bugs are open for many years.
Well, it would be nice to have, but is not really a requirement.
Those of us using LDAP and NIS ar
[Alejandro Bonilla]
> Will OpenOffice2 hit Sid anytime soon? Is there anything to do to
> help to get it in?
It is waiting in NEW at the moment, so as soon as the ftpmasters had a
look at it, I expect it to go into sid.
http://ftp-master.debian.org/new.html>.
I'm sure the OOo-maintainers want mor
[Steve Langasek]
> This seems like an opportune time for someone to write a config
> interface for /etc/pam.d/common-*, so that we have a generally
> useful means of enabling other PAM modules as well.
Good idea. We need a better way to enable LDAP and NIS authentication
then to tell every admin
[Sean Finney]
> that's a good idea, and i'm imagining that it's probably quite
> a feasible one too. i wonder if anyone who knows more about
> mailman could chime in?
I maintain one such list on alioth, and I have not been able to find a
way to let bug reports and other debian-related messages g
[Olaf van der Spek]
> If there's no approval, shouldn't 'that' be fixed also?
Depends on the form of the lack of approval. If there is no reply,
the MIA process should be started, and if there is a NACK, the NMU
should not go throught without further discussion. But one should not
have to waint
[Frank Küster]
> Shouldn't NMU's without the maintainers approval be restricted to RC
> and maybe important bugs?
Well, assuming we want as many bugs as possible fixed before the
release, and not only RC bugs, I believe NMUs should be possible for
all kinds of bugs.
With maintainer approval if po
[Gustavo Franco]
> Have you a TODO list to share with us and are you thinking in ways
> to expand the popcon visibility in the short term ?
We are two persons maintaining the package (it is on alioth,
https://alioth.debian.org/projects/popcon/>), and you should
probably use our mailing list to dis
nt to announce the existence of popularity-contest to
Debian users or other lists, please do so. I prefer to limit my posts
to the lists I am on. :)
Friendly,
--
Petter Reinholdtsen
One of the popularity-contest maintainers
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
[Simon Guerrero]
> I am developing a "kiosk" type of system, where I want to a) boot up fast
> and b) be able to switch off and back on and restart with a clean image.
Part a is a bit tricky, but should be solvable. Part b sounds like a
the system from a normal live CD. Perhaps you should check
[Joerg Jaspert]
> Another pointer:
> http://lists.debian.org/debian-legal/2005/08/msg00128.html
Are you sure you get this right. When I read the license, it look
like a bad choosen license for PEAR (because of all the references to
PHP), but not like a non-free license. The fact that the PHP nam
[Robert Epprecht]
> I have a suggestion for a new feature of a program which I'd like to
> sent to the author. What is the exact command to generate the patch
> in the usual format?
This was answered on the list not too long ago. Use for example
'diff -ur original yourver' to get the patch betwee
[Nathanael Nerode]
> I'm thinking of python2.1, which is a key element in some testing transitions.
> It's out of date on alpha, mips, mipsel, and powerpc -- *yet the buildd logs
> indicate successful builds on all of them on August 30*. I have already
> emailed debian-mips@lists.debian.org, and t
[Nico Golde]
> AFAIK this will not happen because some people don't want
> their blog entries in a public archive.
Well, these people need to stop publishing their content on the
Internet then, as all web page versions end up in the wayback machine,
and thus their blog entry is already in a public
[Debian-armeb Porting Team]
> However, how does one get "armeb" recognised as a valid option for
> the graphs on http://popcon.debian.org? Will simply sending in
> valid survey results with armeb as the architecture cause the graphs
> on that page to list armeb separately?
Yes. The url to the po
[Ingo Juergensmann]
> As I tried to say: there need more exact quidelines for
> this. Currently they are very vague in my eyes.
You failed to say why the guidelines need to be more exact. In my
view, the guidelines are good enough. This is probably colored by the
fact that I trust the good judge
[Kalle Kivimaa]
> It's actually pretty easy. Count the number of posters that seem to
> disagree. If this number is over half of the current developer
> count, then yes, a majority of the developers are in
> opposition. What you _cannot_ do is say "because over 50% of the
> people participating in
[Josselin Mouette]
> This has been indeed discussed to death. The result of the
> discussion seems to be that a large majority of the developers
> doesn't agree with all your criteria.
I guess that depends on the viewpoint of the reader what the results
were. It is hard to tell if there is a voca
[Ingo Juergensmann]
> Although it was discussed several times, I have still no idea how those
> users should be counted?
Two ideas.
- Get them to install popularity-contest. This will make their
machine show up on popcon.debian.org, and we would assume there are
users of the given machin
[Alexander Schmehl]
> I don't think RFPs per se are useless - actually I have a list of
> some 20 RFPs I would like to take a deeper look to, as soon as I
> have some time - it's just that it's difficult to look at so many
> wnpps.
I agree. There are packages I would like to assist into the archi
[Henrique de Moraes Holschuh]
> No. They are not even "supposed" to be scripts at all, it is pretty ok to
> use binary initscripts
[Anthony DeRobertis]
> Ummm, not it's not.
And to make sure the scripts start in the correct order, the init.d
scripts should include dependency information, for exa
[Henning Makholm]
> Unless the difference between Norwegian and Danish law is much
> greater than I imagine, "værkshøjde" is not purely a matter of
> quality.
You are right, of course. I just lacked the ability to express this
clearly in english. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
[John Hasler]
> I suspect that you misunderstood the lawyer.
We have the the same limitation in norwegian law, were the work need
to have (the norwegian expression) "verkshøyde", which implies a
certain quality level as Andreas puts it. There are no limits on
copying and distribution of text belo
[Humberto Massa Guimarães]
> Yes, you do need a license to the content of your books. Only thing is,
> when you buy a book you are buying the right to read it. NOT the right
> to copy it. NOT the right to modify it. NOT the right to redistribute
> (modified or not) copies.
Actually, in Norway, I g
[MarkX A Allyn]
> What would happen if we can change the policy of the lists
> (debian-boot, debian-devel, and so forth) so that they will not
> accept email except from those people who have already subscribed
> and have confirmed?
Is this a retorical question? A lot of spam and non-spam message
[Jon Dowland]
> I would like to make a desperate plee that some attempt is made to
> incorporate a clear indication of the licence under which material on
> this wiki is available under, either with a user-readable prompt or
> machine-readable metadata (ideally both).
I might be slow, but can you
out spam. :)
I wish the debian mail server would do an equally good job. :)
Friendly,
--
Petter Reinholdtsen
Linux user #14 with the Linux Counter, http://counter.li.org/ >
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Allyn, MarkX A]
> I have been noticing (and a bit irritated) at the spam I am seeing
> on this and some other email lists. The latest was a bit offensive
> for me in my work environment.
The debian lists are not doing a great job in blocking spam. You
might want to consider reading the lists usi
[Florian Weimer]
> > typedef int64_t long long;
>
> There are 64-bit architectures which whose C compiler does not
> support long long. "long long" is a C99 feature, too, but it's much
> older than (it was supported by the GNU compiler in the
> early 90s, IIRC).
Any examples of an 64-bit archit
[Delian Delchev]
> I'm very new to debian development, but I'm old debian fan. I don't
> know is that the right list for suggestions because I'm really
> new. Please somebody to read that mail and to show me the right way
> :)
I'm working on similar things. My approach is to add dependency
inform
[Ondrej Sury]
> I am unsure if such patch would be accepted upstream, since Cyrus
> runs on more then Linux and *BSD variants.
>
> Does Solaris/AIX/whatever(tm) has ?
I believe both SOlaris and AIX got it. It is a POSIX standard header. Check
http://www.opengroup.org/onlinepubs/009695399/basede
[Andreas Tille]
> ... I'm not skilled enough to fix this. :-(
Try using lesstif instead. It is a motif clone. I recommend
installing lesstif2-dev instead of the motif development package, and
try again.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Co
[Goswin von Brederlow]
> Nothing is available before init is started, init is always the
> first thing to start, even on initrd or initramfs (some archs call
> init linuxrc though).
You suspect you miss the point. bootchartd is a init _replacement_.
We use it by passing init=/sbin/bootchartd to t
[Robert Lemmen]
> db.debian.org contains (optional) fields for the location of each
> developer, an information which currently is only used to generate
> edwards's fancy maps. there are other potential uses for this, like
> making it possible to find fellow debian developers at some place that
>
[Javier Fernández-Sanguino Peña]
> Any free GIS anyone?
Lots of Free GIS software around. Check out
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl>. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Javier Fernández-Sanguino Peña]
> Either case they should be REJECTED with a proper reasoning as to
> why they have been rejected.
And please add this information to the WNPP request, for the rest of
us to see it. It is hard to fix the remaining issues if we need to
track down a description of t
[Joerg Jaspert]
> You can find this list at
> http://ftp-master.debian.org/REJECT-FAQ.html in the future and that
> one will also be updated if we need to.
Nice list. What about linking it in from
http://ftp-master.debian.org/new.html>? :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
[Tollef Fog Heen]
> This doesn't handle the case of dynamic dependencies:
That is correct. So to handle those, one need to support override
files loaded from somewhere else. This also make it possible to add
dependency info for scripts currently missing it.
I got a sketch package working as a r
[Thomas Bushnell]
> Quite the contrary; it seems to me that this is to work *passively*
> against something.
Not doing the work is working passively against it, while prohibiting
others from doing the work is working actively against it. If you do
both, you are working actively against it.
--
On Mon, Aug 22, 2005 at 12:59:49PM +0200, Marc Haber wrote:
> On Mon, 22 Aug 2005 09:32:48 +0200, Petter Reinholdtsen
> <[EMAIL PROTECTED]> wrote:
> >Yeah, me too. I've seen incorrect init.d ordering several times. And
> >to be able to detect and fix incorrec
[Marco d'Itri]
> I'm sure that a fair number of critical scripts (e.g. some dealing
> with networking) are not.
Yeah, me too. I've seen incorrect init.d ordering several times. And
to be able to detect and fix incorrect boot order, we need to know
dependencies. I hope as many as possible will a
[Martin F Krafft]
> The place to discuss issues like this would be the initscripts-ng
> project on alioth. There's a mailing list...
Good idea. I'll head over there. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Marcelo E. Magallon]
> Isn't just:
>
> wait
>
> enough?
In this case, yes. In the general case, it is unknown if a background
process was forked off earlier in the script, so you want to control
which processes to wait for.
I suspect 'wait $pid || true' or similar is needed though, as t
Recently, I have been investigating how to speed up the boot process
in Debian, and during this work, I found a simple way to change
/etc/init.d/rc to run all init.d scripts with the same sequence number
in parallell. Patch included below. For this change to work as it
should, we need to make sur
[Wouter Verhelst]
>b) the three beforementioned teams could already refuse to
>support a port anyhow, simply by not doing the work.
This is not really a valid argument. If a team in debian refuses to
accept decisions made by a majority of debian developers, or rejects
democratic control,
[Roberto C. Sanchez]
> OK. Please identify the most important packages in Debian :-) Hint:
> this is not easy. There would need to be some sort of metric or
> heuristic for deciding the "importance" of a package.
I do not see the need for a waterproof definition capable of splitting
the archive
[Alexander Schmehl]
> Do you realy think you can enforce teamwork? I don't think so.
> Either some people will work together as a team or individuals will
> do it their own way. And I don't think it will be a good idea, to
> force those individuals to work in a team.
I agree. There will always
[Daniel Stone]
> Ubuntu implements this from the installer down (although only for
> the special cases of four nVidia, MGA, or ATI cards, and even then
> you may need to fiddle with the configuration a little bit), with a
> bunch of patches to xorg -- no kernel patches required. Those
> patches ar
[Steinar H. Gunderson]
> How do you make this work? Last time I tried it, X would only show
> the one connected to the ???active??? virtual console, and blanked
> the other.
It need some patches to the kernel and X. I'm not sure how many of
these are included in the mainstream kernel and X implem
[John Hasler]
> You would have a team maintain 'units'? That's silly.
I guess it is equally silly as it is to maintain prebaseconfig in a
team. The prebaseconfig package is very simple, and maintained by a
team together with a lot of other very simple packages. It works
quite well to maintain s
[W. Borgert]
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.
I agree that it is good to maintain packages in teams, to make sure
the project is less vulnerable to single maintainers going on
vacation, becoming sick, being run over by a bus or other
[Marc 'HE' Brockschmidt]
> After I invested an hour so to track down the reason for an evil
> FTBFS, I have a very simple request: If you maintain a library that
> gets used by other people and you break the API, you should notify
> them. Really.
A good idea. Perhaps we should have a tool in the
As
long as the communication between me and the upstream author is good,
it is not such a big deal. And the communication between a debian
maintainer and upstream should alwasy be good for the maintainer job
to be done properly. :)
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [
[Miquel van Smoorenburg]
> If you don't want NFS mounts in single user mode, don't put them in
> /etc/fstab ...
Your simple solution do not match all installation. For those
installation with NFS mounts in fstab and no automount setting, it
would be useful with a singleuser mode without mounting
[Simon Richter]
> I'd counterpropose to make this optional. I very much like the fact
> that the runlevels have no default meaning and would prefer it to
> stay that way, although I can see the issue of LSB compliance.
Care to share with us on why you like the current setup?
Personally, I hate th
[Timo Aaltonen]
> "Single-user" mode is a fiasco, because in /etc/rcS.d/* there are a number
> of services that really should not belong there. Examples:
>
> -network
> -all disks (including NFS) mounted
>
> ..and those that depend on them.
Yes, singleuser in debian is not working v
[Piotr Roszatycki]
> I've tried to replace /bin/sh with /bin/posh and it was completly disaster.
Did the same happen using /bin/dash as /bin/sh? I believe it is
comparable in size with posh.
> The system was fucked up. I've found the errors in critical init
> scripts: file-rc (/etc/init.d/rc),
oice of name with upstream as well, to try to make the choosen name
used in other distros.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Eldon Koyle]
> Maybe I'm missing something?
I suspect you are. Are you aware of
http://secure-testing.alioth.debian.org/>?
If you see through
http://dc5video.debian.net/2005-07-12/08-Securing_the_Testing_Distribution-Joey_Hess.mpeg>,
you will hear more about it. The status of testing might be
[Marcelo E. Magallon]
> The list and script can be found in
> http://people.debian.org/~mmagallo/gcc-transition/
Are you going to keep it up to date? Is it generated using a cronjob,
or do you update it manually?
It would be great if someone could add a link to your updated graph
from http://p
[Henrique de Moraes Holschuh]
> I will probably drop arts support on the floor to be able to be
> happy once again (also known as not needing to care about a
> dependency hell the size of a small mountain to add almost no useful
> functionality whatsoever to timidity), if KDE does not transition
>
[Andrew Suffield]
> How about 'not second guessing people without cause'?
Sounds like a good idea. I am not sure how this comment is connected
to the message you replied to.
I tried to avoid second guessing you, by asking the following
question:
You seem to assume that all rejections are corr
[Andrew Suffield]
> AMs aren't much better, as a group. The FD checks their applications
> so as not to waste the DAM's time reviewing bogus ones, and the DAM
> checks them to filter out people who shouldn't get in. The reason
> why we need both these checks is most simply explained by pointing
> o
[Ron Johnson]
> Soon after you put it in Experimental, installed it, for that very
> reason.
I got a parse error on this one. I suspect you are unaware that the
HTTP option is available in unstable, version 1.30.
> Maybe a post to d-u would spread the word.
Yes, that would be nice. But I leave
[Erik Schanze]
> Perhaps more will participate if you zip the report, to reduce
> traffic. It's requested in bug 149425 for years.
[Michelle Konzack]
> FullACK. - Most of my friends in Turkey and arabic counties too.
The HTTP upload is sending a gzip-ed version. I'm working on a
version compr
[Michelle Konzack]
> Are there really only 5398 machines in i386 ?
Well, you need to remember the 620 reports without any arch info. 95%
of them are probalby running i386 as well. :)
> I cant belive it... I have already 13 i386 machines with popcon and
> now I will install it on my Macintosh II
620 without arch info)
New in version 1.30 is support for reporting using HTTP POST, to make
it possible for machines without working MTA to participate as well.
Please direct any questions to popcon-developers at lists.alioth.debian.org.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, em
[Florian Weimer]
> Developers must be careful to Cc: the submitters, otherwise they
> probably never receive the message.
What about the [EMAIL PROTECTED] address? I thought it send
a message both to BTS and to the submitter? I use it all the time
when I want the submitter to get the message. I
[Lars Wirzenius]
> The way I'm running it now, it installs and purges each package
> (plus dependencies), and then compares the state of the filesystem
> (the chroot) before and after and reports files that have been
> modified, removed, or created.
Can you do upgrade testing as well. It would be
[Jon Dowland]
> I've been thinking about how popcon might be suggested by
> debian-installer. A cursory google search shows that this has been
> discussed in the past: can anyone point me at a summary?
The next version of d-i will ask for participation during the
installation. It was fixed just b
[Andreas Tille]
> if you ask me any bug is worth fixing, also if only a single user
> complained about the problem. So why spending effort in "rating"
> bugs?
To get some indication on the order the bugs should be solved in? As
we have limited time and people, it is smart to start with the bugs
[Martin Pitt]
> This gave me a good laugh, and it's certainly way better than "SuSE"
> or "Micro$$$ IIS" :-), but still a bit embarrasing...
Why is it embarrasing? Are Ubuntu sponsoring the machine, the hosting
site, providing the OS, or what?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
[Thomas Hood]
> The package is only 20 kbytes installed. Let's just start Depending on it.
I agree. We should start using the LSB, not just talk about trying to
be LSB conforming. :)
But I made the use optional for discover1 because someone complained
and said it was just a fancy way to get col
501 - 600 of 734 matches
Mail list logo
