Re: [RFC] DEP-6: Meta-Package debian/control field

[Joe Smith]

Joe Smith wrote:

Counter proposal:

New meta-package Boolean field.

Meta-packages would normally have few or no Depends, being almost 
completely recommends.


Recommends (perhaps also Depends) of meta-packages are not marked as 
automatically installed.


The usefulness of this part of my counter proposal is debatable. It allows 
removing the meta-package without removing the installed packages. If that 
is not desired, then don't include it. That would make meta-packages special 
only due to the following:


Attempting to install a meta-package if apt is not configured to install 
recommends by default will terminate in an error, rather than completing, 
unless a force flag was passed. (This is to ensure the meta-package does 
not basically completely fail if that setting is off, without spitting out 
some form of error).




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] DEP-6: Meta-Package debian/control field

[Joe Smith]

"David Paleino"  wrote in message 
news:16193268.79mvg96...@home.hanskalabs.net...

Hello people,
per the DEP process described at http://dep.debian.net/deps/dep0/, this is
the first call for comments on this proposal.

   Title: Meta-Package debian/control field
   DEP: 6
   State: DRAFT
   Date: 2009-12-20
   Drivers: David Paleino , Luca Bruno 


   URL: http://dep.debian.net/deps/dep6
   License:
Copying and distribution of this file, with or without
modification, are permitted in any medium without royalty
provided the copyright notice and this notice are preserved.
   Abstract:
Introduce the usage of a new field in debian/control, 
Meta-Package,

to mark "meta-packages" as such, and allow easy choice of
installed packages, without being bitten by the "autoremove"
feature of package management tools.



Counter proposal:

New meta-package Boolean field.

Meta-packages would normally have few or no Depends, being almost completely 
recommends.


Recommends (perhaps also Depends) of meta-packages are not marked as 
automatically installed.


Attempting to install a meta-package if apt is not configured to install 
recommends by default will terminate in an error, rather than completing, 
unless a force flag was passed. (This is to ensure the meta-package does not 
basically completely fail if that setting is off, without spitting out some 
form of error).






--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Joe Smith]

"Manoj Srivastava"  wrote in message 
news:87my1uhtb7@anzu.internal.golden-gryphon.com...

On Mon, Dec 07 2009, Joe Smith wrote:



The net result here is that ucf may be keeping excess state related to
package foo.


   But it is not. ucf knows well that when it is reinstalled the
state information can't be trusted, it is merely historical, and takes
steps to preserve, but not trust, that data.




It certainly sounds like a plausible way to leak disk space.


   And again, ucf has a limit on the historical data that it
keeps.  Next?


If this is the case (and considering that ucf is your software, I'm sure it 
is), then I see no reason for any changes.


UCF does the right thing, and its data stores clearly belong to UCF, and no 
other packages have any claim to them, nor has any level of responsibility 
beyond notifying ucf on purge if ucf is still around.


So Patrick is worried about nothing, as far as I can tell. 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Joe Smith]

I suspect Patrick might be worried about a scenario like the following.

Lets assume there is a package Foo that depends on and uses ucf. Further the 
package is the only one ucing UCF on the system.


At some point the admin decides to remove Foo. Since there are no other 
packages that use ucf on this hypothetical system, the admin also chooses to 
remove ucf.


The admin purges Foo, but not ucf. Later the user installs some other 
package that uses ucf.


The net result here is that ucf may be keeping excess state related to 
package foo. Since it was not around to be alerted when Foo was purged, ucf 
is unaware that this excess data may no longer needed. Thus any state of ucf 
related to the package Foo will live on until some point when ucf is purged, 
or perhaps if Foo is reinstalled, and then re-removed and re-purged.


On the other hand, had the admin purged ucf at the same time that he purged 
Foo, when ucf was reinstalled later it would start from a clean slate and 
not keep around this old state that is not terribly useful anymore.


Now I'm not familar enough with ucf to know if this is a real possibility. 
Perhaps ucf's design has something to prevent such a thing from occuring. 
I'm not sure. It certainly sounds like a plausible way to leak disk space. 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Has Debian abandoned Python?

[Joe Smith]

"Piotr Ożarowski"  wrote in message 
news:20091203235820.gf6...@piotro.eu...

Right now we're working on updating the Debian Python Policy. Once we'll
be happy with the first set of patches, we'll send them to debian-python
mailing list. I don't see a reason to make it public right now as it's
simply not ready. Does it really matter that I'm not preparing it alone?
If I would work on it alone would I still be obligated to make
everything public?



What we needed to know was that progress is being made, and the basic nature 
of the progress. Your message tells us that.


Progress is being made by way of preparing changes to the Python Policy.

It might be nice if the patches were hashed out in public, but it is not 
essential, and since that might just slow things down, which is exactly what 
we don't want, nobody should complain too much.





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine

[Joe Smith]

"Manoj Srivastava"  wrote:

Virt-what is more accurate than Imvirt, version 1.0 can tell the
difference between Xen Dom0 and DomU. The new version (1.1, released
on 23 july 2009) can tell the difference between QEMU and KVM, and can
tell if you are running inside a Xen fullvirt guest.


   This sounds cool. Does it support user-mode-linux as well?


At the moment, it can detect VMWare, Microsoft Versions of Virtual PC, 
OpenVZ, Xen-HVM, Xen-DomU, Xen-Dom0, KVM, and QEMU.


I'm betting the author would be willing to incorporate checks for other 
systems if they can be easilly done in a bash script.





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Joe Smith]

"Mark Brown"  wrote in message 
news:20090427092413.ga1...@sirena.org.uk...

On Mon, Apr 27, 2009 at 01:48:27AM +0100, Ben Hutchings wrote:

On Sun, 2009-04-26 at 21:41 +0200, Robert Millan wrote:



> #494120 and #494122.
[...]



I disagree with these as the tables in question are easily small enough
to be a plausible preferred form for modification.


Indeed; this is a *very* common way of expressing register values,
especially when working with large numbers of them at once.  I've no
idea what Robert believes the preferred form of modification is.


Perhaps some indication of where the heck the numbers came from? Surely 
there is some meaning to the numbers. In the original Windows drivers, there 
was quite possibly a set of enums for each register with descriptive names. 
If not, then somewhere there exists some sort of documentation as to the 
meanings of the values. Relevant excerpts really should have been included.


If the values lacked meaning, then the hardware would behave just fine with 
all zeros as initalization values. If the values were just arbitrary data 
that must be uploaded by default for the hardware to activate, as a 
protection against certain types of driver/interface corruption, then that 
should be explained in a comment.


For some reason, anywhere but a device driver an opaque sequence of 64 bytes 
(or even 16 bytes) without comments explaining what they mean, or where they 
come from (ie "This is the standard MD5 seed value") would be considered 
unacceptable. Pretty much any time you have a numeric constant in code where 
the meaning is not obvious it should be explained in a comment, or even 
better, refactored into a symbolic constant. Thats just plain standard 
coding practice.


So why do drivers get to have sequences of bytes without any rational 
explanation attached? 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Joe Smith]

Don Armstrong wrote:

On Tue, 03 Mar 2009, Steve McIntyre wrote:

I've got to wondering: are the large -dbg packages actually really
useful to anybody?

Thoughts?


I think they are useful, but probably not for the vast majority of
users. [I've used them on a few dozen occasions.]

What I really wish for is the ability to have a relatively centralized
location where the symbols from every single package ended up that was
separate from the normal mirrors.


Even Microsoft has a service for downloading symbols files for many core 
windows components on demand (integrated with the crash dump analysis tool. 
(I forget of the chrash dump tool is part of the pre-installed debugger or 
it itis seperate)).


It would be really nice to have a similar service. I suppose that if the 
official buildds would keep the debugging data around using a technique like 
debug.debian.net uses, and debug.debian.net uses that data, we would be 95% 
of the way there. Then all we would need is some nice convienece scripts and 
the deprecation of the -dbg packages. 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Joe Smith]

Joerg Jaspert  wrote:



finger
It's been a while since I've seen a useful finger server, I think it's 
fine

to drop this too.


db.debian.org, but that doesnt need it standard.


For what it's worth finger's local features are still important.
I've recently seen a professor explain to a class of students
mostly unfamilar with Unix-style systems that the command to
list the users current logged in was "finger". Obviously
the normal command for this purpose is "who".

Also AFAIK finger is the only program that normally exposes
the contents of the /etc/passwd GECOS feild, as well as the .plan
and .project file. I'll admit those are rarely used today,
but there is some major tradition behind finger being a basic UNIX
component. 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Hardware compatibility test: draft proposal

[Joe Smith]

"Giacomo Catenazzi" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Wouter Verhelst wrote:

Hi,

As I mentioned in my blog[1], I kindof like the suggestion that Bdale


Yes, I find the talk very interesting.


So, after more than twelve hours of boredom on an airplane and half a
night of not-being-able-to-sleep-due-to-jetlag, which is certainly
enough to think about this problem, I came up with the following things
such a system could need:


/me too


- It should support a notion of what I'll call 'profiles'. A 'server'
  profile should check for different things than a 'desktop' or 'laptop'
  profile; e.g., it's usually okay if a server doesn't have graphical
  support or wireless drivers, while the same isn't true for a laptop.


No. I don't think we should provide profiles.
The check should be:
"complete": test all hardware that it is installed on system.
If the system doesn't have the video-card or the wifi just it doesn't
test it, but it write a notice.
Listening the available hardware is pretty trivial (see i.e. my
AutoKernConf).



Ok. What does the test do if it notices that a pecie of hardware exists, but 
cannot identify it?

Should it warn about that?

The long list of hardware not found may be a problem. Let's picture a modern 
desktop PC.

"No floppy drive found."
"No touchpad found."
"No webcam found."
"No firewire found."
"No modem found." (This is common enough these days, but we would definately 
want to test any found modem due to the proliferation of weird winmodems 
these days).

"No physics acellerator found."
"No PC card slot found"
"No HD-DVD drive found"
"No Blu-ray drive found"
"No RAID controller found"
"No gigabit ethernet found"
"No EFI firmware found" (This theoretical PC is not a Intel Mac.)
"No fingerprint scanner found".


(The list could go on and on).

Perhaps a few of those could be merged into other tests, like a single 
optical drive test, but in some of those cases it would then be important 
that a list of hardware that was found is printed. That way the manufacturer 
can be sure that both optical drives (in a two optical drive PC) were found.


If there is any hardware that cannot be tested with only a single test 
script due to major implementation differences between all brands of 
hardware (and no current unified software interface), we would want to avoid 
having a notice printed for each possible manufacture of the device.





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

Re: Package management unsafe?

[Joe Smith]

"Brian May" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Joe Smith wrote:
However, if the security updates come from trusted security mirrors 
rather than
a general mirror, that attack would fail too. So with the exception of 
Sid or
Testing users that do not use the testing-security system to receive 
security

updates, Debian really is not terribly vulnerable to this.
It would still be possible to mount this attack if the attacker can 
intercept packets on the way to the official trusted security mirror and 
redirect them (e.g. transparent proxy) to an older copy of the mirror.




Well that is true. It is however, more difficult to pull off than the 
get-an-offical-mirror-and-run-a-replay-attack described in the article.


Anybody could do what is described in the article with little difficulty. It 
is far more difficult to set-up packet interception.


Use of https on the security mirror should virtually elimate the 
Man-in-the-middle risk.


I think that would make stable imune to security replay attacks. 




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

Re: Package management unsafe?

[Joe Smith]

Andrei Popescu  gmail.com> writes:

> How about distributing the Release files *only* from a trusted server?
> 
> Regards,
> Andrei

That is problematic, as it does not deal with mirror synchronization properly.
If a mirror takes a few hours to update, it's Packages files may not be up to
date during those hours, resulting in apt claiming the Packages file is not
validly signed.

I see no benefits over re-signing the Release file daily, even if none of the
Packages files (and hence the checksums and Release file itself) have changed,
with apt then complaining if Release.gpg has a signature that is too old.

This adds security against the published attack for testing users who do not use
testing-security as well as sid users. It also helps warn users about
non-malicious stale mirrors. As my post made clear, stable is already secure
against the published attacked.


The other attack I mentioned (the attack of attempting to exploit a flaw in any
client that requests a security update) cannot be fixed in the general case,
except by clients using a trusted server, or a trusted proxy that does not
reveal the true requesting system's IP.
Stable is safe because the security servers are trusted. Users of testing or sid
should choose servers they trust or some form of trusted proxy. 


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

Re: Package management unsafe?

[Joe Smith]

Florian Weimer  deneb.enyo.de> writes:

> 
> * Ron Johnson:
> 
> >
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
> >
> > What are people's thoughts on this?
> 
> HTTPS doesn't help against non-trusted mirrors.
> 
> The difficult question is how to tell an APT source which is not updated
> regularly from an APT source that has been rolled back in a replay
> attack.

Actually the attack works just fine without rolling back for a replay attack.
I have my mirror stop updating. If I can assume that most clients use only my
mirror, and not others, then once a major security flaw comes out in a package
version my mirror uses, then I have a list of IP addresses (from my server logs)
that may be exploitable. 

So there is no reason to differentiate between a stale mirror and a potential
attack mirror. Any mirror more than say 7-days out of date should be considered
potentially unsafe, and the user should be warned that the mirror is stale,
which may be an attack attempt, and that they should consider choosing a new
mirror. Having the signature on the package file update daily, even if the
package file contents have not changed would be an easy way to detect a stale
mirror. Just add a check on the signature time-stamp as part of checking the
package signature, and warning if signature is too old.

 
But the attack is not really applicable to Debian, where security updates come
from trusted security mirrors, and not the general mirrors. If this were not the
case, then the following statement from the site would be concerning:

>For example, it is known that an earlier version of OpenSSL for Debian has a
>security flaw. The list of files from the repository that previously included
>this package is still correctly signed. Using this old signed file list, a
>malicious mirror can keep a client on the insecure version of OpenSSL by
>responding to the client's package manager with the old list of files. 

As it is, the mirror can do no such thing. (Only a security mirror could do
this) This is a very good thing.

Indeed there is a second possible attack vector if the general mirrors were used
for security updates. I could set my mirror up to watch for people requesting a
specific security update. While the file is being downloaded, a script could
automatically attempt to exploit the vulnerability on the system that requested
the update. The idea is that there is a high probability that the system
requesting the update has the insecure version installed, and is thus
exploitable.

However, if the security updates come from trusted security mirrors rather than
a general mirror, that attack would fail too. So with the exception of Sid or
Testing users that do not use the testing-security system to receive security
updates, Debian really is not terribly vulnerable to this. 

But I still strongly recommend the signature time-stamp solution  (which Don
Armstrong suggested first) as it would let us notify users that a mirror is
stale regardless of whether this is malicious, and it would help protect Sid and
testing users. It would even add some additional security to Debian-derived
distros that do not use a separate security mirror system. (Although they would
still be vulnerable to the exploit while downloading issue.)




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

Re: Not stopping daemons, where are we?

[Joe Smith]

"Marvin Renich" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

* Bernd Eckenfels <[EMAIL PROTECTED]> [080701 20:45]:

In article <[EMAIL PROTECTED]> you wrote:
>> I mean the pending-write case is the most obvious. But what about 
>> resolver

>> caches, VPNs and the like?
>
> What kind of data loss do you expect to arise from shutting down a VPN
> client without giving it time to save state?

I dont expect any data loss - hopefully protocols are not that
optimistic/broken. But with unclean shutdown you can affect external 
parties
with unexected errors. Like resolver problems, user not found and 
similiar

problems.



Either I don't understand the usage scenario you are talking about, or I
misunderstand what is being proposed in this thread, or you
misunderstand what is being proposed in this thread.  Here is a more
concrete example of a situation based on what I think is being proposed:

The Debian maintainer for a specific VPN decides it does not need
special shutdown handling, so he marks it to not require calling
"/etc/init.d/SuperVPN stop" when doing a shutdown or reboot.  This is
what I understand this thread is about.  This will result in SuperVPN
not being stopped until the final "kill all remaining processes" step of
the halt or reboot (i.e. don't waste time shutting this daemon down
cleanly, let it die abruptly just before halting).


Well, sending SIGTERM should not cause software to die abruptly, and IIRC 
sending SIGTERM to all processes happens before sending SIGKILL.




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

Re: Generating debian package using cmake (take 2)

[Joe Smith]

"Mathieu Malaterre" <[EMAIL PROTECTED]> wrote:
>

THANK YOU !
So far I only had FUDs about: 'no this is impossible, 'this is not the
right way'. Thanks for taking the time to answer in detail, this much
more supportive. I finally understood the previous aggressive answers,
I was simply looking at the problem from opposite direction.
So the next question is: where do I get started :)



My gut alos told me that you were going at it the wrong way, but It was not 
until I read this, that I realized what the right way was.
debhelper extracting the usuable information, and creating the files. This 
would potentially then support two ways of working. If the debhelper support 
is complete enough, the generic debhelper buildscript is all that would be 
needed. The contents of the binary packages could potentially be determined 
by by the INSTALL(...) commands, which apparently support multiple packages.







I still do not understand this one. cmake is able to say I need
'zlib.h' and 'z.so', so I do not see why this is so hard to find out
that zlib-dev is required (dpkg -S, or equivalent call), right ?



That system may work in quite a few cases, but would not nessisarally work 
in all cases.


However, it is perfectly possible to have the dh_make (the script that 
initially creates a debhelper-based debian/ directory) do a preliminary 
pass, and determine as many of the build depends needed as possible. Then 
anything it did not catch could be added manually.


(Actually a new non-buildtime script that dh_make would call would probably 
work better. This seperate program could be used by the maintainers to 
update the build-depends with any new packages it can detect. The idea being 
that in at least some cases, new build-depends could be automatically 
added.)



Anyway, the best way to become familar with debhelper is to use it to 
package a few simple traditional make based packages. Then jump in. Keep in 
contact with the Debhelper maintainer (Joey Hess) and dh-make's maintainer 
(Craig Small).


Hope this message has helped in some way. 




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

Re: Handling macro change in an exported library header

[Joe Smith]

"Bernhard R. Link" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

* Nikita Youshchenko <[EMAIL PROTECTED]> [080626 11:51]:
To fix #486693, I need to apply a patch that changes #define'd macro in 
an

exported library header.

The pattern is:

extern int foo(char *param1, int param2);
#define bar(param) foo(param, expr(param))

and changed thing is expr(param)

Looks like binary interface of the shared library does not change, 
however

strictly saying any user of the library that uses bar() macro needs to
recompile his code.


I think the relavant questions are: what is semantically changing:


My thoughts:

If the change is a define in a header, where said define is *not* used in 
the library itself, then the libraries binary will not change. Thus 
physically it would have the same API and ABI. However, the convience API 
would change. So the end applications would need to be recompiled to take 
advantage of this, but since either version of the binary of the library 
would work with these recompiled apps. So the library should not be changed, 
but the programs recompiled, and a warning added to readme.Debian warning 
that locally compiled programs must be recompiled with the new headers.



However if the library itself used the macro, then it has a true API change, 
and must be SONAME bumped.




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

Re: Large data packages in the archive

[Joe Smith]

"Joerg Jaspert" <[EMAIL PROTECTED]> wrote:

[snip]
c.) We can host an own archive for it under control of ftpmaster.
[snip]
So the way to go for us seems to be c.), hosting the archive ourself
(somewhere below data.debian.org probably).
[snip]


A data.d.o would presumably be running on a debian project machine. Do we 
really have the bandwidth and reasources to be hosting large files that 
could be downloaded by a great many people?
Or do we intend to get a mirror network and point users to some form of 
round-robin DNS entry?


Because of the size of the packages involved, I would expect this to create 
a much bigger strain on our infrastructure than volatile.d.o. (Which is the 
only similar system I can think of off the top of my head).




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

Re: triggers wishlist

[Joe Smith]

"Michael Biebl" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

I guess Joss is right here. triggers tell you *if* something has changed

>(in a subdirectory), but not *what*.

Remember, that we have to call
gtk-update-icon-cache /usr/share/icons/$subdir
for the directory that has changed.

Michael


How expensive is running gtk-update-ican-cache? I mean, it would be easy 
enough to have a script run
that runs "gtk-update-icon-cache /usr/share/icons/$subdir" for each of the 
subdirectories. Then the /usr/share/icons
trigger would just run that script. 




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

Re: best package for windows Vista

[Joe Smith]

"Jonathan Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hello,
I was not sure if the image for Debian 4.0 downloaded completely.  This is 
why I feel >obliged to order it.   I will be using Debian for GrADS and for 
compiling FORTRAN >code.  Can I get some recommendations from anyone.


Thank you

First of all, this is the wrong mailing list for this type of question. The 
correct list to use is Debian-users. Please post any further questions or 
replies to that list.


There are tools that could be used to determine if the file was completely 
downloaded.
Any tool to calculate md5 hash/checksum of the file could be used. The 
output of that file should be compared to the corresponding line in the 
http://cdimage.debian.org/debian-cd/4.0_r3/i386/iso-cd/MD5SUMS file. 
Alternatively a tool to calculate the SHA-1 checksum can be used. In that 
case the file to compare with is 
http://cdimage.debian.org/debian-cd/4.0_r3/i386/iso-cd/SHA1SUMS


If you have a broadband internet connection, what is important is that you 
have a cd with an installer. CD 1 or 'nestinst' or 'business card'. If all 
else fails you can use the tool available at http://goodbye-microsoft.com/. 
That tool will ensure that the installer components are downloaded 
correctly. (That is also the easiest way to install Debian if an existing 
Windows install is present).


If you want to purchase a CD or CD set anyway (perhaps the computer to be 
installed on does not have a broadband internet connection), then please use 
any vendor from our vendor list. We do not recomended any vendor over 
another, and have not tested all of them. However, if you repost on the 
users list, another user may have a recomendation. 




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

Re: How to install Suggested (Was: Are all recommended modules equally important?)

[Joe Smith]

"Andreas Tille" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Wed, 19 Mar 2008, Don Armstrong wrote:


So you do something like:

apt-get -o APT::Install-Suggests=true install foo; or similar.

[Though it probably should be an easier option, it is possible to do.]


Well, this hint was given now in the initial thread on Debian-Med
and well, this actually would be an option - but if I fail to find
this documented in the man pages I posted I think it is not
apropriately documented.  I also was sure that it is _possible_,
but IMHO this is (1) a quite difficult option for a feature that might
be needed by users who do not want to dive into details of apt and
(2) not properly documented.



I will say the following. I fully agree that "--install-suggests" should 
exist, and should do the right thing. It sounds like an easy enough feature 
to add, my guess is that the code for installing or not installing 
recommends could be adapted to work with relatively little difficulty. (I'm 
guessing the recommends feature is simply setting a configuration option, so 
duplicating it and changing the option set should work. I may be wrong 
though.) That is definately a wishlist bug.


As for the apt.conf configuartion option, I think it is documented in the 
correct place (configure-index.gz), although it may be wise to mention that 
file from the main apt-get manpage, as a list of other options that can be 
used through the -o command line option. That mention is worth a seperate 
wishlist bug.


Finally, if the documention indicating how one uses the -o command line 
option is not clear (the apt-get manpage should definately have at least one 
example of that options use), then that is annother wishlist bug, but may be 
worth merging in with the previous one. 




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

Re: dpkg-buildpackage now reorganizing debian/control Depends field??

[Joe Smith]

"David Paleino" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Il giorno Fri, 22 Feb 2008 10:04:52 -0300
Otavio Salvador <[EMAIL PROTECTED]> ha scritto:


As I said, for APT, the order has meaning _always_.

apt-get install foo bar

Is completely different of

apt-get install bar foo


Could you please elaborate on this? I know for sure that Pre-Depends exists
just for the cases where order _does_ matter. But I've never had problems 
in

installing packages in any order (or probably I've just been lucky).

David


I'm not sure, but I think the follwing indicates the problem.

Imagine that you have none of {foo, bar, baz, qux} installed.

Foo has "Depends: baz|qux"
and Bar has "Depends: qux|baz"

My understanding is that in that case

apt-get install foo bar

installs {foo, bar, baz} but

apt-get install bar foo

installs {foo, bar, qux}.

This is not always a major problem, and in most cases the end user will not 
notice
it, but under rare cases it is theoetically possible that the dependency 
chain with conflicts could cause problems. (At least it seems like that 
might be the case)






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

Re: The 30 most popular packages missing in Debian

[Joe Smith]

"Sebastian Pipping" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

* Would non-free be an option to all or some of them?
  Do we have binary only packages in Debian?


My understanding is that it is possible to have binary-only packages in 
non-free,
although I really don't know anything about that. I usually try to avoid 
things from non-free that are not at the very minimum semi-free. (A.K.A, I 
can have the source, make changes, destribute them, etc, but there are some 
conditions limiting my freedoms that just manage to fall on the wrong side 
of the DFSGs, [for example GFDL manuals with invarient sections]). 




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

Re: Is a free document whose sources have been lost free?

[Joe Smith]

"Charles Plessy" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Le Fri, Jan 25, 2008 at 10:35:16PM -0800, Don Armstrong a écrit :

Unless the pdf is exceptionally complicated, it's not all that
difficult to resurect LaTeX that does a similar job; it'd probably be
ideal to do this and distribute the pdf files built from that, unless
the underlying codebase never changes and you won't ever need to fix a
bug in the documentation.


Thanks for your answers (and thank for the private answer I got as
well). I will prepare an update of dialign-t using unmodified sources
and ask for the removal of dialign-t-doc from non-free.

Actually, the documentation has been almost completely rewritten in
DocBook format for making the manpage of dialign-t for Debian, but I am
reluctant to replace the original html and pdf files: it is just like
adding my name into a work I have not done.


Umm.. If that dockbook file is cabable of generating basically the same 
documents

as the current HTML and PDF files, then it seems to me that a line that says
"Converted to docbook format by Charles Plessy" would be fine, and 
definately

not like adding your name to a work that is not your own.
Further, I would tend to guess that if the original source for those files 
is gone,
upstream would be interested in any replacments  so that they could update 
those

files in the future.


Have a nice day,





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

Re: How to cope with patches sanely (Was: State of the project -input needed)

[Joe Smith]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

On Fri, 25 Jan 2008, Michael Banck wrote:

And there I thought we'd use whatever we like until wig&pen lands, which
will have native patch support.

What's the status of that?  Is my assumption bad?


Not completely, I'm following the discussion closely as I really want to
provide the required features in dpkg-dev directly. But I'm afraid that
wig&pen as defined might not be enough for all cases.


Well surely wig&pen would be used with aditional tools in some cases.
A tool providing the ability to unapply arbitrary patches (by rolling back 
all the patches, and re-apply skipping that one) and other similar things 
would be common enough that tools would need to be available for the 
developer to use.


It would seem to me that tools that a developer could use for such a purpose
could be used (possibly conditionally) in the debian/rules file.

I suspect that would cover the vast majority of special patching needs.


And Joey already made a proposal for a 3.0 source package (wig&pen is 2.0)
based on git.







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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Joe Smith]

"Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Well that wasn't what I understood, but I'm really not a D-Bus expert
at all :) Though it doesn't makes sense to let the D-Bus connector be a
separated component as you then only pull the library which is of a
reasonable size.


I'm no dbus expert either, but my description of the current situation is 
based havilly on this part of the

message martin sent:

"martin f krafft" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Currently, the netconf control socket is implemented using,
a pseudo-rfc822-based protocol (see [1] for some information).
Many people have suggested using dbus for this, but I always refused
because I did not want the dependency. I always wanted to make dbus
optional, i.e. provide netconf-dbus which, when installed, links
netconf in with the dbus infrastructure. However, that would be
independendent of the control socket, for which I still need
a protocol.


Now I don't really see a good reason to have a seperate package
either, as the dependecy on the dbus library is only ~300KB
which seems reasonable to me. Especially if the current ifupdown
is still available for embeded systems that really need that space.
But of course, I'm just a mere user, so ... 




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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Joe Smith]

"Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

 That's wrong, and XML-RPC *SUCKS*, as does most of the text-only
interfaces, when you want real-time events. DBus isn't such a bad way to
do things, it doesn't requires the daemon up and running to interact
with netconf, when netconf acts as a dbus server.


Huh? If by "the daemon" you are refering to the netconf daemon, and if by 
dbus server you meant
D-Bus service (an app the dbus daemon can launch on demand) then that 
matches my reading.
But if "the daemon" meant the D-Bus daemon, and you did mean dbus server, 
then that does not
match my understanding. From my reading of the docs, I thought that the dbus 
daemon must be running

for the protocol to work at all.


I assume that it's
possible to write tools that directly hit your netconf server withouth
going through the dbus daemon, making it lightweight and a really good
solution even for small systems.


That is how it currently works. The idea is to have two packages, one that 
is the actual service with some kind of protocol
working over a control socket. A second package would provide a DBus 
interface, and basically translate DBus messages to whatever the native 
message format of the control pipe is.


However, he would still need some sort of protocol for the control socket.

The alternative is to have the control socket use the D-Bus system, meaning 
only one package is needed, but messages

would need to pass through the dbus-daemon in order to be recieved.



 And then for 0 cost, you see desktops being able to use your
procedures being routed automatically through the dbus daemon acting as a
proxy. At least it's what I grok reading [0]. And that's an invaluable
advantage as almost all desktop applications are slowly (or not _that_
slowly actually) migrating to DBus. It means that you'll provide a
tested robust known interface to people wanting to interface with you.


That is very true. A dersktop network managment tool could certainly send 
messages to netconf with ease using

D-Bus, which is a really nice feature.




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

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joe Smith]

"Joel Franco" wrote in message news:[EMAIL PROTECTED]



HEY SPONSORS.. PLEASE LOOK NETTEE :)

I'm guessing that sponsors are waiting for your acknowledgment and 
correction of the issues mentioned in 
http://lists.debian.org/debian-mentors/2008/01/msg00034.html




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

Re: Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joe Smith]

"Joel Franco" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

- simplicity: like you already said, the simple command, without complex
 pipe setups like showed in your example comments. You have to agree
 with me that that netcat + tee pipe commands are not trivial. If I
 had known about that commands, i will not have searched for somenthing
 like nettee in Google.


Good point. However, while it did take me a few minutes to cook that up, was 
still
reasonably simple piping. The biggest trick was the '>(...)' syntax, and 
knowing the arguments to use for netcat. The rest was simple pipes and 
input/output redirection.
Definately not trivial, but not too terrible either. Command line plumbing 
can be much more complicated (although very complicated plumbing is honestly 
rarely ever useful).
But you said something very important, that I somewhat hoped you would say. 
You did seach for a utility because you did not know how to do it manually. 
That there is an important advantage to a package. In particular, having the 
manpage to document things.





- multiple target: you can specify multiple targets to send the stream
 and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
 Ok.. ok.. you can make it with a complex pipe; i just can say that
 i will say again the previous argument.


You can indeed do that with complex piping, although it definately begins to 
get very large and hard to deal with. This is a useful advantage of such a 
package.




- error check in the stream data: there is a check for transmission
 errors in the code. This is util when there are failed nodes.


Yes it is indeed a useful benefit that definatly difficult to do with just 
tee and netcat.




- error handling while data is being transmited: there is a lot of
 options to the chain not die if there is a single node failure. In
 your pipe commands, if one node die, the full chain is lost.


Yes, indeed. That is a real downside to chaining like that. And something 
that a dedicated program can handle much better.


Your defense of the program here was quite good, as it does clearly show the 
benefits of such a program. A useful skill to have as a package maintainer. 
Futher, I now know to look for that utility if I ever have such a need. :D



In short, simplicity and error check.

If you liked, can you be my sponsor? :)


Unfortunately, I cannot, as IANADD.



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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.dextention

[Joe Smith]

"Josselin Mouette" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Ubuntu discovered this a while back, and introduced a method to avoid
calling stop scripts in runlevel 0 and 6.  It is the "multiuser"
extension to update-rc.d, and in Ubuntu packages are changed to calls
dh_installinit with '-- multiuser' as an argument to enable it.  This
add the "multiuser" argument (instead of to the "default" argument) to
update-rc.d, which go on and set up the boot sequence without
references to the script in runlevel 0 and 6.  This can be done
without such extention, and how is the topic of the rest of my email.


Frankly I couldn’t imagine a worse idea to fix this problem.

Many daemons will corrupt their state if they aren’t killed cleanly.
Leaving them a grace time is actually worse than simply cutting the
power, because you can be sure the daemon is actually writing some data
at the moment you kill it.


Really. First AIUI most of the candidates for this already do something 
similar
in their shutdown scripts. The sigkill ensures that a program which hanged 
in the sigterm handler
gets terminated. Further, it ensures that any service that chose to ignore 
the sigterm signal for some

odd reason gets killed as well.



The most funny thing comes from daemons which depend on each other. You
will easily hit cases where a daemon will not shut down properly because
it cannot find the one that depends on it, and in the end increase the
shutdown time instead of shortening it.


Those cases are also not candidates for this.


Let’s just switch to a parallel init system, and the Ubuntu wannabees
will win their precious few seconds without risking to introduce data
corruption bugs on production systems.


While those with dependecies and complex clean shutdown procedures would 
benefit from such a system, the remaining
cases would still be sped up slightly more by letting the later script take 
care of them.



On a somewhat related note, it has just occured to me that the standard 
GNU/Linux system design (and as far as i know, the standard UNIX design) 
does not really have a concept of shutdown priority. I know that Microsoft 
Windows does have some meathod of indicating a higher than normal priority 
shutdown (useful for things like autoshutdown when the UPS indicates that it 
is running out of power). Should a similar sytem of some kind be implemented 
in Debian GNU/Linux? 




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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Joe Smith]

"Petter Reinholdtsen" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


[Joe Smith]

Obviously removing those scripts should have no impact on the other
initscripts.


Exactly, (unless there is a dependency relation between two scripts
and one of them is removed from the shutdown sequence. :).


Ok. Good catch. So it seems to me that any service that is not a shutdown 
prerquisite of annother service (a.k.a must be shut down first) and which 
can be cleanly shutdown with [SIGTERM; pause; SIGKILL] is a good candidate 
for removing the shutdown init script.


Any service that is a shutdown prerequisite, or has a more complicated clean 
shutdown procedure should remain using the initscript system for shutting 
down.


Those could still benefit from a parallelized initsystem, but that is beyond 
the scope of current discussion. 




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

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joe Smith]

"Joel Franco" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Package: wnpp
Severity: wishlist
Owner: Joel Franco <[EMAIL PROTECTED]>


* Package name: nettee
 Version : 0.1.8
 Upstream Author : David Mathog <[EMAIL PROTECTED]>
* URL : http://saf.bio.caltech.edu/nettee.html
* License : GPL
 Programming Lang: C
 Description : a network "tee" program

It can typically transfer data between N nodes at (nearly) the full
bandwidth provided by the switch which connects them.  It is handy for
cloning nodes or moving large database files.



Out of curiosity, besides being a bit easier to remember/type,
and not requiring the user to choose a port,
what benefits over combining normal tee and netcat does it have?

for example:

On A:  nettee -in IMAGE -next B -v 31  #full logging
On B:  nettee -next C >/dev/hda
On C:  nettee -next D >/dev/hda
On D:  nettee -next E >/dev/hda
On E:  nettee -next F >/dev/hda
On F:  nettee >/dev/hda


AFAICT, that could be done more or less equivlently as
On A: nc -q0 B 12345 (nc -q0 C 12345) >/dev/hda

On C: nc -l 12345 | tee >(nc -q0 D 12345) >/dev/hda

On D: nc -l 12345 | tee >(nc -q0 E 12345) >/dev/hda

On E: nc -l 12345 | tee >(nc -q0 F 12345) >/dev/hda

On F: nc -l 12345 >/dev/hda

(Some stdout redirections to /dev/null could be added, so stdin on the 
reciving does not come out as stdout on the sending end.) 




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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Joe Smith]

"Petter Reinholdtsen" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


[Roger Leigh]

On a heavily loaded or slow system, I suspect it would be highly
likely some would get SIGKILL before they could shut down properly.
I can't say I'm a big fan of the proposal for this reason.


I do not understand this objection.  The only way I can get it to make
sense is by assuming that you believe my proposal is to remove most
packages init.d scripts from the shutdown runlevels, even the ones
that need special care when taking the service down.  And that is not
what I am proposing.  I am claiming that there are daemons around that
_do not_ need any special care when the service is taken down, and
that these daemons do not need a script in runlevel 0 and 6 to take
them down as it is faster to let the sendsigs script kill them.


Indeed it seems redundant for the initscripts to send signals that will be 
sent by a later script anyway.


Obviously removing those scripts should have no impact on the other 
initscripts.


However, I think the concern is that more processes would end up getting 
SIGKILL'ed, as
an initscript that more or less what sendsigs does (SIGTERM, 5 seconds, 
SIGKILL) would be more likely to result in the program shutting down 
cleanly. Why? Well odds are that there are plenty of idle cycles, so the 
program basically has the full 5 seconds to shutdown. However, if that 
process has to share those 5 seconds with several other processes being 
SIGTERM'ed it is somewhat less likely to reach the end of the clean shutdown 
cycle than if it were the only process being shutdown. We are of course 
discussing processes where being SIGKILL'ed is not a really big deal, but it 
is still preferable to have as few SIGKILL'd processes as reasonably 
feasible during shutdown.



Btw, if the 5 second wait isn't long enough for sendsigs, we can
extend it.  There is code there to make sure sendsigs terminates as
soon as the last process it tries to kill is dead, so we could
increase the timeout without affecting the normal shutdown times.  It
will wait from 0 to 5 seconds at the moment, depending on how long it
take for the processes to die.  It would not be a problem to let it
wait from say 0 to 10 seconds, or 0 to 30 seconds.


That does sound like a reasonable solution to the concern.

How feasible would it be to make the pause time a function of the number of 
processes sendsig must reclaim? That seems to make some sense to me. 
Obviously there should be a sane upper and lower bound (5 seconds and 30 
seconds sound fine to me). 




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

Re: Bug#455730: ITP: lua-peg -- Parsing Expression Grammars For Lua

[Joe Smith]

"Enrico Tassi" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Thu, Dec 13, 2007 at 11:39:43AM +0100, Enrico Tassi wrote:

On Thu, Dec 13, 2007 at 04:17:48PM +0900, Miles Bader wrote:

If you are inpatient, or want to test it before it passes the new queue,


Oops, I've just discovered that "inpatient" means something completely
different then the Italian "impaziente"...

I was meaning, "If you can not wait, or want ..."


The word you were looking for was impatient. Many people do
pronounce it a bit more like inpatient, but impatient is the
correct pronounciation.

Fortunately, your original version was fully understandable,
as it looked to be a simple typo. 




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

Re: Menu categories

[Joe Smith]

"Sune Vuorela" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On 2007-10-21, Ben Goodger <[EMAIL PROTECTED]> wrote:

--=_Part_8909_32361462.1192962485303
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 21/10/2007, Sune Vuorela <[EMAIL PROTECTED]> wrote:


I have tried to make a script that converts desktop files into 
reasonable

menu files.



I have trouble understanding the difference. Please elaborate.


Hi!

I thought it was basic knowledge what menu files are and what desktop
files are.

For menu files, read /usr/share/doc/menu/ for details
For desktop files, read
http://standards.freedesktop.org/menu-spec/latest/

Menu files is a debian internal format for menu entries. desktop files
is a fdo specification that does more or less the same, but in a
different way.


A while back when the menu system was last under major discussion, It was 
suggested that the menu system be changed in the long term.


The idea is that the desktops that support Desktop files only use those 
files, and ignore the Debian menu system completely. (Although the files 
would need to conform to a new Menu policy).


The Destop systems not supporting Desktop files would continue to use the 
Debian menu system. The menu system would support desktop files as an imput 
format.


Obviously there would be a significant transitioning period. During which 
all desktops would need to continue to use the menu system, and the system 
needing to accept both types of input.


What ever happened to that? Is that by chance what you are working on? (The 
script you are writing would be an important part of the transition.) 




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

Re: Enabling and installing of "risky" ("patented") codecs - madeeasy

[Joe Smith]

"Clint Adams" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Fri, Oct 19, 2007 at 08:11:13PM +0200, Reinhard Tartler wrote:

How about just using non-free for that? In the past, patented packages
like gif encoders have been hosted there, so why can't we just use them
for mpeg encoders as well?


I think you're thinking of non-us.


Please note though that non-us was hosted outside of the US, but was 
supposed to contain packages that were legal in the US, but simply could not 
be exported from the US (cypto software). Because of its name, people 
started putting other things there were not legal in the US, but that is 
very different than its original purpose.




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

Re: Installation of Recommends by default on October 1st

[Joe Smith]

"Julien BLACHE" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

I've read that but I didn't take it into account because people google 
for
docs and they will find documentation recommending apt-get (they usually 
won't

notice if the doc is recent or not). Furthermore, there's also the fact
that on user forums there are people who will still be recommending
apt-get as it's what they are using.

So you might be right on your first assertion, but I don't agree with 
your

conclusion "If doc is the only problem, then it's not a problem".


When aptitude came out, we've been told that aptitude was the real apt
frontend that apt-get was never meant to be to begin with (apt-get
being only a debug/devel tool for libapt) and that it was the tool to
use from now on for everybody except maybe for advanced users who will
probably stick with apt-get.

Either this hasn't got enough publicity, or people decided to stick
with apt-get because aptitude didn't cut it.

The former case is easy enough to fix before October 1st; the latter
might not be that easy to fix, depending on the reasons behind the
dislike for aptitude.

Now, from the Debian users I know around me, I can tell you that none
of them like aptitude, and they especially dislike the "install
recommends by default" so-called "feature".

I am a Debian user in so far as I maintain 0 packages for Debian, and am not 
a DD.
I use aptitude almost exclusively. I install reccomends by default. I rarely 
have any reason to override that default.

Things just work.

I chose to use Aptitude because it worked and the dependency tracking 
feature was quite nice. (I'll admit that at the time, if you wanted an 
interactive package selector, your choices wre dselect, and aptitude. IIRC 
synaptic was not really in great shape at that time, and as you will learn 
form the rest of this message, would not have been appropriate even if it 
was in good working order.)
Besides I accepted that apt-get was really only ever a minimalistic 
front-end for the APT package management system. Aptitude is much fuller 
featured.


Some things to note about me though:
I have been using Linux for only ~3 years, and even on day one I was a 
poweruser. I did not have any UNIX experience, but I had DOS experience, so 
the command line did not scare me. I decided not to fear things breaking as 
that is merely an opertunaty to learn how to fix it. So besides a bit a 
playing with Knoppix, and tomsrtbt, I installed a virtual machine 
containning a command line only Debian sid. That is what I still use. Yes, I 
dove right in to sid and never looked back despite having only ~1-2 months 
of linux experience (and of that, most was only part-time experience).


I don't worry about breakage as it is not my production machine, and is 
command line only, so a good chunk of the breakage misses me completely.


My main OS is still Windows (unfortuantely), so I learned some commands and 
whatnot that way. (I do intend to eventually swap, and run a Linux system on 
the hardware (with a desktop environment), and Windows in a VM, but have not 
yet done so.)


As for why I chose Debian I honestlly don't rember. I belive it was because 
of hearing about the nice package management system. (Also, I had previously 
tried installing RedHat Linux on the metal of that laptop, and the results 
were awful. Problems with the video settings (X configuration issue I 
suspect), and an unsupported southbridge.) 




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

Re: adding desktop files to misc packages

[Joe Smith]

"Joe Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


"Don Armstrong" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

So it seems like we should do the following:

1. Make changes to the menu system to use .desktop files in preference
to .menu files when they exist

2. Generate .desktop files from .menu files using the menu system when
.desktop files don't exist.

3. Continue using the menu system for window managers which don't
natively understand .desktop files; drop the Debian menu for those
that do.

The other issue that was brought up was improving the hierarchical
organization of the menus, but how to do that hasn't been made clear
in this thread.



That is exactly the correct thing to do. It has the advantage of basically 
converting Debian to the stardard FDO .desktop format.
It also effectively adds limited support for the FDO format to the other 
window managers (the menu system would be converting the .desktop files of 
any installed package automatically).


Of course one of the keys to this transition would be to eventually 
depreciate the .menu files. If the menu system can read the .desktop files 
then there would be no reason to keep the .menu format around long term, 
but it would need to stay temporally as part of the transition.


To formalize this as a proposal:
-BEGIN PROPOSAL-
Given that .desktop is a standardized file format, and is roughly a superset 
of the current .menu format,
the Debian menu system will add support reading .desktop files as source in 
addition to the .menu files.


When both a .desktop file and a .menu file exists the .desktop file takes 
precedence.


The Debian menu system will generate .desktop files from .menu files if the 
.desktop file does not exist. This is intended solely

as a temporary compatibility measure.

The .menu format is depreciated. Lintian should add a check warning about 
packages that include a .menu file but no .desktop file. Maintainers are 
encouraged to replace the .menu file with a full .desktop file, conformant 
with the "Desktop Menu Specification" and the "Desktop Entry Specification". 
However, once a revised Debian menu policy has been adopted, the files 
should conform with policy in any case where policy contradicts those 
specifications.


Windows managers that support the "Desktop Menu Specification" should stop 
including the Debian menu, as all its entries would be available as .desktop 
files.


A revised menu policy should be drafted. It should indicate when a package 
requires a .desktop file, and when it would not require a desktop file. It 
should also specify which types of menu entries should default to 
NoDisplay=True. If extensions to the .desktop format are desired, such as to 
implement a roles based system for determining which entries appear in the 
menu, this would be to document which should specify the extension. Finally 
the document may amend the "Desktop Menu Specification" hierarchy, if it is 
determined that a change to that hierarchy would be benifical to the users.

-END PROPOSAL-


Comments? 




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

Re: adding desktop files to misc packages

[Joe Smith]

"Don Armstrong" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

So it seems like we should do the following:

1. Make changes to the menu system to use .desktop files in preference
to .menu files when they exist

2. Generate .desktop files from .menu files using the menu system when
.desktop files don't exist.

3. Continue using the menu system for window managers which don't
natively understand .desktop files; drop the Debian menu for those
that do.

The other issue that was brought up was improving the hierarchical
organization of the menus, but how to do that hasn't been made clear
in this thread.



That is exactly the correct thing to do. It has the advantage of basically 
converting Debian to the stardard FDO .desktop format.
It also effectively adds limited support for the FDO format to the other 
window managers (the menu system would be converting the .desktop files of 
any installed package automatically).


Of course one of the keys to this transition would be to eventually 
depreciate the .menu files. If the menu system can read the .desktop files 
then there would be no reason to keep the .menu format around long term, but 
it would need to stay temporally as part of the transition.




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

Re: APT 0.7 for sid

[Joe Smith]

"Michael Vogt" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Dear Friends,

I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge
of the version in debian/experimental and the version in Ubuntu.

It will break the ABI, so all packages that depend on libapt will need
a rebuild against this version (so expect a bit of a transition until
everything is rebuild). It should be straightfoward, I will do uploads
for synaptic and python-apt, I hope that the other depends follow
quickly (I will be happy to do NMUs if someone asks me about it).

The big new stuff is:



- automatic removal of unused dependencies moved into libapt so that
 applications like synaptic, python-apt, update-manger etc directly
 benefit from it. A HUGE thanks to Daniel Burrows (one of my personal
 heros) for his work on this feature.



Quick question: this feature is basically the moving of the dependency 
tracking of aptitude to libapt?
If so, and if the noting of dependencies is enabled by default, then this is 
wonderful news.
The bigest problem with this feature in apritude is that other apt-frontends 
do not mark the packages
installed automatically. Even if those other frontends did not reomve the 
packages automatically,
it is still a huge gain if they mark them. 




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

Re: Handling of (inactive) Debian Accounts

[Joe Smith]

"Joerg Jaspert" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On 10927 March 1977, Mark Purcell wrote:


On Saturday 10 February 2007 01:34, Joerg Jaspert wrote:

Selection of the people included in those runs will be done in a way
that we avoid sending out such mails to active people. As a good start
we will take the upcoming DPL vote as an input source, everyone who 
doesn't

vote this year will be included in the first run.

 * Please note that you can vote without expressing an opinion! *

Whilst you might be able to vote without expressing an opinion,
we already have a documented MIA process.
http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa


If you read my mail you will find out that We know this and its planned
to take that as source for future/additional runs.


I don't think using the single criteria such as DPL voting is a good,
approach.


Now, explain where the problem in my approach is? The worst case that
can happen to someone who does not vote is that he replies to one
mail. Its not as if not voting means immediate account deactivation...



I would hope that there would be a grace period after deactivation, where a 
person who misses the WaT mail, and then later has his/her account disabled 
can quickly speak up and say they are still here, and be re-enabled without 
having to go through any sort of NM process. 




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

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

[Joe Smith]

"Frans Pop"  wrote in message news:[EMAIL PROTECTED]

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.)


The data is still useful for new installations (rather than updates) of sid.
If many packages are 'broken' by the definition they are using,
then it is quite possible that desired programs will not be installable
at that time.

It may be useful for other things also, depending on the exactly what tests
are being run. 




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

Re: Request for virtual package ircd

[Joe Smith]

"Jeremy Stanley" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Thu, Oct 12, 2006 at 09:14:19AM +0200, Mario Iseli wrote:

Ok, this is a good argument.
I think the oppinion is more or less clear:

Some people think it would be a nice idea, BUT it can be also a problem
because some people want more than one Ircd on a system.

I only wanted to ask you for your oppinion, so thank you all! :-)


Maybe what you're looking for is a "Provides: irc-server" in the
ircd packages and a "Recommends: irc-server" or "Suggests:
irc-server" in the service packages that potentially benefit from
(but do not necessarily require) a locally-installed ircd to which
to connect? That way when someone installs the services via, say,
aptitude or synaptic, an ircd is pulled in automatically (if one is
not already installed) or at least mentioned as being suggested, but
multiple ircd packages providing irc-server could still be installed
on the same system since there is no conflict expressed.


That seems fine to me. Arguably, as mentioned in a different post the ftp
servers should do the smae thing instead of conflicting with each other.

Mail-tansport-agent should also do the same thing, using the alternatives
system to handle the multiple 'sendmail' binaries.

Conflicts on a virtual package by a package that provides it is generally 
questionable
because often these is no valid technical reason to restrict the user to 
only one of
the providers of that virtual package. 




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

Re: Code of Conduct on the Debian mailinglists

[Joe Smith]

"Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Mon, Aug 07, 2006 at 11:39:51AM +0900, Miles Bader wrote:

"Joe Smith" <[EMAIL PROTECTED]> writes:
> So I really wonder why mailing lists are so common.

It sort of depends on what you're looking for.

Some advantages of mailing lists:

  * E-mail generally has a "wider reach" -- it gets past corporate
firewalls, (my company has never allowed external nntp connections),
works even on strange systems, etc.


Point. Then again, if your corporate sysadmins don't want you reading
news, they probably don't want you reading mailinglists, either.


  * With email, you can use the same MUA you always use, with the
features you're used to.  People are _used_ to email, know how to
configure it.


OTOH, many MUA's (including Thunderbird, mutt with some patches, pine,
Mozilla Mail, MS Outlook Express, and of course gnus (which is more of a
news client than a mail client)) can read news just fine[1], with an
interface that is almost the same as the mail interface. Outlook
Express, which does not support threading in the mail interface, will
suddenly support threading for NNTP, too.


Sorry for the very late reply, but wanted to clarify this: OE does support 
threading for Email,
it is simply disabled by default. However overall the threading is more 
accuracte an reliable for
newsgroups. 




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

Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

[Joe Smith]

"Sven Luther" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote:

On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote:

> Debian must decide whether it wants to ship BLOBs with licensing which
> technically does not permit redistribution.  At least 53 blobs have 
> this
> problem.  Many of them are licensed under the GPL, but without source 
> code

> provided.  Since the GPL only grants permission to distribute if you
> provide source code, the GPL grants no permission to distribute in 
> these

> cases.
Many people disagree with this interpretation.


A few very vocal people do. I guess they can be counted on the fingers of 
both

hands or so.



I think everybody can agree that it would be clearer if the blobs used a 
licence that clearly allows distribution without requiring source.


In the case of the GPL that is definately not clear.


About the main issue:
As I see it, there are three possible catagories for drivers using firmware 
that all drivers should ideally fall into assuming the driver  part is free 
:


1. Module and firmware in free. (The firmware can be compiled into the 
module, or can be loaded from a file.)


2. Module in free, firmware in nonfree, loaded from file by driver. [One 
could argue that the modules belong ion contrib, unless the firmware is

optional (perhaps allowing access to non-essential features)].

3. Module in non-free. [Firmware compiled into module, has not yet be 
seperated into seperate file. This is acceptable, but many of these could be 
converted to type 2 if somebody puts in the work].



I know we have some modules of type 1. I'm pretty sure we have some modules 
of type 3. It has not been clear to me if we currently have any modules of 
type 2.

Obviously if the infrastucture is not there, that should be fixed.

Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 
modules. This can definately be fixed, but doing it for etch could delay 
release.


Besides all of that we have quite a few modules with problematic licences. 
Generally the licence problem is on the firmware, although some might affect 
the
rest of the driver. Some are type-3 style (firmware hard-coded into module, 
firmware lacking source.)Many of those could be shipped as type-3 modules if 
licence clarification can be obtained (or preferable: relicencing). A few 
are type-2 style, they could be shipped as type-2 if proper clarification 
can be obtained.



The above is a rough summer of the problems as I understand it. Please 
correct be if I am wrong.



So the question I have is how long would etch need to be delayed to add 
support for non-free firmware to D-I?




We could also push back the freeze on the kernel by the same amount and have 
some people work on obtaining clarification on some of the problematic 
licences.


With the combination of those two we could end up with having very few 
drivers not ship, and all shipped drivers both free and non-free be usable 
during installation.


While pushing Etch back is a big deal, it almost seems to me that some of 
the proposed GRs are an even bigger deal, and, as has been pointed out, the 
GRs would probably only make a difference for a small number of modules, 
unless we ignore the problematic licencing of most of the remaining drivers.





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

Re: Code of Conduct on the Debian mailinglists

[Joe Smith]

"Ben Pfaff" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Magnus Holmgren <[EMAIL PROTECTED]> writes:




No problem at all.  Especially with gmane.org around.  I used to
subscribe to dozens of mailing lists, but now I can just browse
all of them as newsgroups.


I agree, I use Gmane for the same reason.

There are many problems with mailing lists. If email was intended to be 
threaded, a message ID would be manditory.
It is actually optional. Email was designed for unidirectional or 
recipricating (back and forth replying to the last message) messages,
not threaded conversation. This is why few UA's can handle threading well, 
and even the best UA will have problems with some messages.


Email was also definately not designed with mailing lists in mind. Multiple 
recipients, yes. That is why many MUA's have a "reply all" feature.
But it was certainly not designed with what we think of as mailing lists in 
mind.


On the other hand, USENET is the oldest Internet service around that is 
still in relatively common use. It even predates what we know of as
the Internet. It is designed for threaded content, and NNTP messages are 
closely related to rfc822 (and it successors) messages that tools like

spamassassin work just fine.

Not to mention with newsgroups it is easy to reply to messages sent before 
you subscribed, which can be a pain with mailing lists.


I am not aware of any common complaint about mewsgrousps that cannot be 
resolved simply by using a private (i.e. not syndicating) server

to host the groups.

So I really wonder why mailing lists are so common.


--
"The road to hell is paved with convenient shortcuts."
--Peter da Silva






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

Re: Successful and unsuccessful Debian development tools

[Joe Smith]

"Goswin von Brederlow" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]

[EMAIL PROTECTED] (Marco d'Itri) writes:


On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:


Also, pbuilder and debootstrap are considered absolutely critical for
serious work.

That's a bold statement.

--
ciao,
Marco


Never used either one.

I have cdebootstrap do create chroots, dchroot to use them,
buildd/sbuild to test compile under true buildd conditions. Why would
I want something else?

Debootstrap couldn't even handle dependency resolving a while back.


I think that by debootstap David was including both normal and cdebootstrap.
After all, cdebootstrap is mostly a port of debootstrap, although with some 
improvments.





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

Re: Place to submit scripts useful for Debian

[Joe Smith]

"Daniel Dickinson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Well, I intend to do an update-menu thing that calls 'fburn --gui',
which makes for a somewhat friendly interface from a window manager
menu or icon.  Also it doesn't just blast out the image and hope it's
okay; unless you specify otherwise, the script will verify (using cmp)
that the image can be read back and, if not, will reformat the floppy
and try again (exactly once).  I did this after far too many bad
floppies (a combination of flaky drives and the fact that floppy
quality is absolutely horrible these days).


I suggest you submit the script to the fdutils package.


Thanks!  That's the sort of info I was looking for :-)

Be sure to submit the above text also.
Fdutils's maintainer is likely to want to know what advantages this script 
has.
The text above asnwers that very well. 




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

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Manoj Srivastava" <[EMAIL PROTECTED]> wrote:

   I see you have not fully followed through on reading policy
here:
,[ § 7.2 ]
|  In case of circular dependencies, since installation or removal 
order

|  honoring the dependency order can't be established, dependency loops
|  are broken at some random point, and some packages may not be able 
to

|  rely on their dependencies being present when being installed or
|  removed, depending on which side of the break of the circular 
dependcy

|  loop they happen to be on.
`



Well then policy contradicts iteself by failing to note this exception in 
the other location.




Clearly if dpkg really enforeced that, no circular dependecy would
ever work as the packages would be installed, but could not be
configured because a depencency was not configured.


   Clearly, dpkg authors have read all of policy, including the
caveats about circular dependencies.


Be that as it may, dpkg does not act as that part of policy indicates.
If there is an exception it really should be noted at that location, not 
someplace else.







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

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Manoj Srivastava" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Fri, 21 Jul 2006 15:09:56 -0400, Joe Smith
<[EMAIL PROTECTED]> said:


Well, strictly speaking all circular dependencies could be
considered a policy violation because they depend on dpkg not
working as policy states it does.


   Could you elaborate on this?

   manoj
In the sense that you are abusing the terms of policy. It is true that dpkg 
will install and configure with circular dependecies,
but Policy states "A package will not be configured unless all of the 
packages listed in its Depends field have been correctly configured."


Clearly if dpkg really enforeced that, no circular dependecy would ever work 
as the packages would be installed, but could not be configured because a 
depencency was not configured.


Depending on a package not acting in the manner in which policy states it 
will could be considered a type of policy violation.


Granted it would not be sensical to report this as a bug on dpkg because it 
is simply going beyond what policy states it will do.
I would say that no package is directly violating policy, but ther packages 
are abusing policy. In one sense policy itself is the buggy package because 
it asserts something that is not true.


Then again, that section of policy looks a bit dated anyway, mentioning 
"dselect" despite the fact that that package is now all but completely 
obsoleted by apt and the various apt-frontends.




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

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Ian Jackson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Bill Allombert writes ("Getting rid of circular dependencies, stage 5"):

Here the list of packages involved in circular dependencies listed by
maintainers.


Didn't we already have the conversation where we explained that there
is nothing necessarily wrong with a circular dependency ?



Well, strictly speaking all circular dependencies could be considered a 
policy violation because they

depend on dpkg not working as policy states it does.

They are also a pain to any person who is manually feeding packages to dpkg 
one at a time.
There seems to be no reason why that should not be able to work, but 
circular dependencies will
always break that. There are other issues with them as well. If there is a 
circular dependency your package
cannot rely on the fact that its dependecies are indeed installed and 
configured. That is not
good. 




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

Re: Getting the buildds to notice new architectures in a package

[Joe Smith]

"Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Jul 15, 2006 at 10:55:32PM +0200, Ludovic Brenta wrote:

Where should I ask for help?  Neither buildd.debian.org nor
www.debian.org/devel/buildd, mention where the buildd admins can be
reached; and lists.debian.org does not have a "buildd@" list.


<[EMAIL PROTECTED]>. I just committed a change to the
wanna-build-states page to that effect.


I will upload ~20 source packages in the next few weeks, adding
support for more architectures to each package.  So I'm really looking
for a general solution and not one that only applies to asis.


There is no such general solution. See



That says:
However, wanna-build does not look at the control file of a package when 
creating its database;

only at the packages' name and section, its urgency, and its priority.


Shouldn't wanna-build use the control file? It would then mean that the 
lists of packages-arch-specific
would not be needed, except in the case of a single version override in the 
event that a package's control
file accidentally listed an architecture on which it is not supported, or 
failed to list an architecture on
which it is supported. 




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

Re: Bug#376588: ITP: cryptomount -- a utility for accessing encrypted filesystems

[Joe Smith]

"Baruch Even" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Package: wnpp
Severity: wishlist
Owner: Baruch Even <[EMAIL PROTECTED]>
X-Debbugs-Cc: debian-devel@lists.debian.org


AIUI, there is no need to CC debian-devel with ITP's, as debian-devel 
normally gets them anyway. 




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

Re: #195752: Can somebody mark this bug as grave or critical?

[Joe Smith]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

severity 195752 important
thanks

On Thu, Jun 29, 2006 at 08:43:57PM +0200, martin f krafft wrote:

But yeah, I'm not in an official position to say, but if this
isn't considered a "critical" or at least "grave" bug, then
I don't know what is.

Agreed. I tried to ping the release team on IRC before, but they
were all busy it seemed. So since changing severity isn't a final,
irreversible action, I am just doing it.


I really can't get this to be critical in any way; it does not make the
entire system break (unless you count temporary loss of network access on 
a
laptop critical), it does not cause serious data loss (or really data loss 
at
all), and it does not introduce a security hole. I can't fit it into any 
of
the other categories on http://release.debian.org/etch_rc_policy.txt 
either;

thus, I'm downgrading it to important. Sure, I agree it is a bad bug which
should be fixed, but critical? Not IMHO.

(In case of further disagreement, I'd leave it to the maintainer, who has 
the

final say pending the RMs' input, to decide the severity.)


Actually I agree that critical is too high, grave might be reasonable, as it 
causes system downtime. (System downtime is something anybody running 
servers would agree is a very big problem).


However I suspect it is at least Serious.
Definition of serious:
"serious is a severe violation of Debian policy (roughly, it violates a 
"must" or "required" directive), or, in the package maintainer's opinion, 
makes the package unsuitable for release."


The maintainer apparently agrees this is a very nasty problem, and may very 
well feel that it makes the package unsuitable for release.
Of course only the package maintainer could set the package to serious for 
that particular reason.





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

Re: Debian mactel linux support?

[Joe Smith]

"Junichi Uekawa" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> I don't quite grok how I can make erfit be the default bootloader
> without access to MacOSX command-line to 'bless', I hope I can find
> out as I delve deeper.

You can't. Intel Mac blessing is different to traditional HFS stuff -
it's not too difficult to do the blessing, but we have no way of
generating HFS+ filesystems without resorting to APSLed code and that
seems to be the only useful bootable format.


I thought EFI should work with FAT (I was surprised to see blessing
can be applied to HFS+ also), which is the first partition on the
internal disk.

I'm hoping that I can switch default boot through some kind of nvram
setting.


Worst case: You have to abuse the firmware update released to facilitate 
Boot camp, and have that boot normal lilo.
Perhaps not as nice as having EFI boot a bootload, or running a bootloader 
as an EFI application, but

I think that is what most people are currently doing.

Disclamer: I have not used a Mac. Ever. I have no experience with EFI. 




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

Re: These new diffs are great, but...

[Joe Smith]

"Bastian Venthur" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Robert Lemmen wrote:


standard method. you will however find out that the size of all diffs
together is already less than the size of the regular packages file.


Yeah, looking at the average filesize of a diff compared to a packages
file, I guess you'll need to wait like 100-200 days until the sum of the
diffs becomes larger than the package file itself. However, downloading
a 5meg file takes a few seconds on my boxes while downloading the diffs
from 10-20days can take a few minutes, which is not very attractive.

This is quite a dilemma since I understand that the bandwith of
volunteering archive mirrors is not free.

Since the main problem seems to be that downloading many small files can
take much longer than downloading one big file, a compromise could be to
provide only one diff. The trick: generate x diffs for:

today-1day, today-2days .. today-x days

so you only have do download one file if your last update is less than x
days ago.

A good compromise for x could be 50 days or something. The diffs would
be reasonable small, fast to download and if your last update is more
than x days ago you still could download the package file directly.

This solution should keep the bandwidth utilization on the servers small
(older diffs are less likely to be downloaded than the most recent ones)
while being faster than the current (and even faster than downloading
the whole packages) solution.

Plus, you don't have to keep all the old diffs (only the last x ones) on
the servers.


Any ideas?



A very good idea. This is trading a slight increase in file space for 
bandwidth and speed. There is some additional server-side processing 
required, but diffing is realatively cheap.


If reversible diffs are used then generating today's diffs requires only 
yesteday's Package file, the most recent (x-1) diffs from yesterday,and 
todays package file. Scripting a program to update the diffs would not be 
terribly hard. Once the diffs are updated, everything from yesterday can be 
discarded.


Apt would always download the main package file if it was smaller than the 
appropriate diff. If it turns out that some of the diffs (the ones around 
today-x) are pretty large they can be compressed like the main package file.



Regardless, diffs should obviously not be used for file:// Sources or cd-rom 
sources unless the user explicitly says otherwise. This is because it is 
normally faster to fetch the main file when using those sources.





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

Re: Is OSS only support to be considered a bug?

[Joe Smith]

"Preben Randhol" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Mon, 26 Jun 2006 21:35:19 +0200
Wouter Verhelst <[EMAIL PROTECTED]> wrote:


On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote:
> With the 2.6 kernel programs using OSS for sound are not working
> anymore. Sound that is. One *may* use aoss, but then the user needs
> to open a terminal and write:
>
> aoss program-name
>
> because launching from the menu it won't work. So I consider aoss
> only as a temporary dirty hack before alsa takes over completely.
>
> My question is if it is legitimately to open bugs against
> applications that only support OSS for spund?

No. There is snd-pcm-oss.ko, which provides working OSS sound, even if
you don't use aoss. Just make sure to load the proper module.


Yes, but isn't this considered to be a temporary transitional thing? It
isn't loaded by default by the debian kernel image at least.



Umm... See these pages:

http://alsa.opensrc.org/aoss
http://alsa.opensrc.org/OSSEmulation

It sounds like both meathods are supported by the alsa devs, but obviously
native Alsa support is prefered, 




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

Re: new tar behavior and --wildcards

[Joe Smith]

"Petr Vandrovec" wrote in message news:[EMAIL PROTECTED]


Since this seems to have been an intentional behavior change by
upstream to better align with a published standard, I'm uninclined to
fight it, and think our best response is to update our utilities to
include the --wildcards option, with a suitable versioned dependency on
tar.


This decision makes tar completely incompatible.  Programs which worked 
fine with tar for 6 years are suddenly broken, and now you have to have 
two versions - one for 'tar' before this brokeness, which do not 
pass --wildcards, and one for this broken 'tar', which passes --wildcards. 
And older version on newer 'tar' extracts nothing, while new version on 
older 'tar' fails with an unknown option error.


Maybe it could be default for tar's POSIX mode, but I have no idea why GNU 
mode behavior should be changed in any way.

Petr Vandrovec


Indeed. If POSIX compatability is important to the GNU tar maintainer, then 
why has he not updated GNU pax yet?
UNIX03 has no tar, but has pax. So reviving the paxutils package seems more 
imporant than fixing an incompatibility with an outdated

version of the Unix spec.




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

Re: cgiirc Hijacking

[Joe Smith]

"Mario 'BitKoenig' Holbe" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote:

In cases where a security bug is being fixed, you usually try to
upload the package as soon as possible.  If your sponsor is on



We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were
no newer version in unstable, the version on s.d.o should have had
automatically override even the unstable version. Of course, if you
don't source in s.d.o, you don't get security updates :)


I run unstable and do not have s.d.o
As I understand it, there is no good reason to have s.d.o in
my sources list, as the packages in there are for sarge, and may not be
compatible with the current sid ABI.

Besides, s.d.o is already a highly stressed server. (AFAIK) 




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

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Joe Smith]

"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Joe Smith wrote:

Is this really needed? Google was very careful in making sure that the
package installs in /usr/local, and does not interfere with the
system. Normally the main reason why a debian package is better than
what upsteam distributed is because using upstreams packages will mess
with stuff it should not touch.

Well, it doesn't install in /usr/local (by default, you can get it
there) but in a user's home directory. Actually, perhaps if you run it
as root it will pick /usr/local by default, but I didn't try that (I
don't usually run things as root, even stuff from Google).

Google Earth takes care of its own updates by prompting the user, and
allowing them to download and run the new installer (or at least it
does on windows, and I can't imagine why the linux version would not).
Needing to use a *-package utility prevents automatic updates anyway,
and does not simplify installation much if any. So the only real
advantage would seem to be that it would make Google Earth easier to
uninstall. Well I guess it simplifies pushing updates out to a bunch
of workstations, but in most cases users should just download the the
.bin and run it.

Apparently, the "easier to uninstall" is a bigger deal to me than it is
to you. So this utility may not be for you.

There has only been one version out for GNU/Linux as far as I'm aware,
so I'm not sure anyone knows exactly how the updater works. Seeing how
their software is packaged, I actually don't see any way that the
Debianized version would break updates if run as root (which would have
to be the case anyway unless every user has their own version) but
personally I don't like programs that try to update themselves outside
of package management.
I agree that programs that use mechanisms other than the package manager to 
manage files can be a real pain, but remeber that a GNU/linux system is not 
guarenteed to have any package manager at all. On such a system self-updates 
can be quite usefull. Also remeber that /usr/local is not managed by package 
managers, so programs that live there can manage their files however they 
want without any problems.


I'm pretty sure that it simply downloads and run the new installer. This is 
what it does on windows. The problem is that if a user uses the installer, 
and installs into /usr (like the debian package presumably does) then unless 
the debian package puts everything in exactly the same spot the installer 
would have, then it will not be possible to fully uninstall using the debs.




Anyway, there are a few advantages:
 * Once you've made the package, you can install on multiple machines
easily.
 * It's much cleaner, as you have a managed Debian package to
install/uninstall.
 * In-program updates are optional (run as root and do them, or don't).
 * If you don't like doing it this way, nobody is going to make you do
it. =)

But the most important one of all is: I've found it useful, I've got it
working[1], and I'd like to give others an opportunity to use it if they
want to.



Fair enough. Ideal would be to recive permission from upstream to simply 
repackage the files in the tarballs into a non-free deb, possibly showing 
the EULA as a debconf question of the highest priority. Preseeding the EULA 
question could easilly be seen as pre-accepting the EULA, so that should not 
be a problem. With a package like that, the only potiential problem is the 
programs internal update mechanism. Perhaps Google would consider adding a 
way to remove/hide the internal update choice. 




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

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Joe Smith]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Ok, I agree that it's ok to trust installer source that they will not
install a backdoor into your system.

However, chances that they will write to directories that should be under
control of package manager, or write to system files that should be under
control of package manager or appropriate update scripts or administrator's
hands - are very high.


But AFAICT (I analyized the package quite closely, but neve did install it) 
Google Earth's Installer does not do this.



IMHO, running 'foreign' installers as root is *the* whay to break your
debian system.


Normally, yes.




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

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

[Joe Smith]

"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Package: wnpp
Severity: wishlist
Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>

* Package name: googleearth-package
 Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]>
* URL : (native package)
* License : GPL
 Description : utility for automatically building a Google Earth 
Debian package


Google Earth is a great program now available for GNU/Linux, but sadly
is both non-free and non-distributable. For those who wish to run it on
their Debian system, but wish it to be managed by the normal Debian
packaging system, this program will assist in building a local Debian
package in a similar fashion to java-package. This package *itself*
contains absolutely no code from Google and is 100% free. (For the
curious, this is appropriately destined for contrib.)




Is this really needed? Google was very careful in making sure that the 
package installs in /usr/local, and does not interfere with the system. 
Normally the main reason why a debian package is better than what upsteam 
distributed is because using upstreams packages will mess with stuff it 
should not touch.


The reason java-package is needed is that upstream's packages are not well 
behaved, and install into /usr, potentially causeing problems if it decides 
to edit the files of other packages.



Google Earth takes care of its own updates by prompting the user, and 
allowing them to download and run the new installer (or at least it does on 
windows, and I can't imagine why the linux version would not). Needing to 
use a *-package utility prevents automatic updates anyway, and does not 
simplify installation much if any. So the only real advantage would seem to 
be that it would make Google Earth easier to uninstall. Well I guess it 
simplifies pushing updates out to a bunch of workstations, but in most cases 
users should just download the the .bin and run it. 




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

Re: Non-DD's in debian-legal

[Joe Smith]

"Ian Jackson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Jeremy Hankins writes ("Non-DD's in debian-legal"):

I'm not sure I understand this part, though.  Do you think that folks
like myself, who are not DD's, should not participate in the discussions
on d-l?


Actually, I think they should not participate, in general.



Um.. That is absurd. I participate some in D-legal, and IANADD.
Recently, most of my messages have been initial scans of a licence,
pointing out things that may be problematic, based on what I have seen 
previously,

as well as common sense. I believe I usually notice most (not all, but most)
potential problems in a licence, and try to add appropritae recommendations.

If such behavior is not helpful, I will stop, but I find it hard to belive 
that

what I described above is not helpful.

I suspect you are speaking more about the non-dd's who start 'software vs 
documentation',
or 'softwave vs executables' style threads. I tend to stay out of those, as 
regardless of
my feeling on the issues (I'm not even sure what they are), I'm pretty sure 
that Debian
has decided that issue, and will not be changing it's mind in the near 
future. 




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

Re: Who can make binding legal agreements

[Joe Smith]

"Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On 6/7/06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

Russ Allbery <[EMAIL PROTECTED]> writes:
> John Goerzen <[EMAIL PROTECTED]> writes:
>> Sure.  SPI owns many of the machines that Debian owns.  If any of 
>> these

>> machines are being used to distribute this software, as I think is
>> likely, then SPI could be liable.
>
> Oh, very good point.  I hadn't thought of this.

No.  SPI is liable under the terms of copyright law; at most, it can
be told to stop distributing things.


Err, copyright infringement can be a criminal act as well. So if a DPP
(DA or whatever it's called in your jurisdiction) takes a dislike to
you (or perhaps someone whispers into their ear), they can haul you or
SPI or mirror operators into court without Sun having anything to say
about it. And the result could include gaol time, especially for this
sort of large-scale willing mass copyright infringement.


Except that In order to prove copyright violation the DA would need
to involve Sun. There is no way for the DA to know if Sun secretly
granted the infringer the right to distribute in that manner. AFAICT
the infringer need not even know about such a grant for it to be valid.

IANAL 




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

Re: Red team attacks vs. cracking

[Joe Smith]

"Javier Fernández-Sanguino Peña" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


Claiming that what Martin did was good since he was showing something 
useful
for our community is equivalent to saying it was a "red team attack". 
Nobody

used that term explicitly probably because they are unfamiliar with it. I
know what it means, I've done my share of pen-testing to companies.

I do agree with Manoj that this was *not* a legitimate experiment (i.e.
not a "red team" test) and that Martin *did* abuse our [0] trust [1]


Had Martin never mentioned this, it would have been a non-issue.
There is no real damage. While signatures may have been based on
a non-offical ID, Martin did indeed own the key in question, so
the end harm is zero. But Martin decided to publish this experiment.
Is this really a bad thing? He proved that KSP are bad for the web of trust.
A legitimate attacker could abuse the KSP just as easilly as Martin, but
would result in actual damage, and would most likely not have been caught.

So, if KSPs are not changed, then the Web of trust becomes effectively 
worthless.
Manoj should be far more concerned about that, then about Martin's 
demonstration
of this. 




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

Re: Please revoke your signatures from MartinKraff's keys

[Joe Smith]

"David Moreno Garza" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Luca Capello wrote:

As a side note, while my passport was valid (re-newed the day before
leaving for Mexico because I forgot it was expired after 5 years and
not 10), I didn't get any Mexican seal when I arrived at Mexico City
airport.  As 2 others DDs with me (Aurelien Jarno and Matthias Klose)
got a seal, I went back to the customs officer asking for the seal and
he answered me I didn't need it.


That's illegal actually. It is quite often to get your passport sealed
while leaving your country but it is supposed to be mandatory to get the
seal in the country you are arriving, otherwise you could be thought
you are an illegal alien since no local official government dependency
testifies you are arriving the country legally.


I have travelled oversees serveral times, and it is relatively common for 
customs to fail to stamp US Passports.
Apparently the US makes it very clear that US Citizens are not to be 
pestered at customs

"OR ELSE".

Of course, customs offcials have also stamped my passport on the wrong page, 
among other things, although
that usually happens at ground borders. 




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

Re: multiarch status update

[Joe Smith]

"Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:

On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
> Why would that not fly?
> Both versions of the arch-independent package could be installed at
> the same time.
/usr/share/foo/bar can't point to two different files at the same time,
so you can't install multiple package versions containing
incompatible /usr/share/foo/bar files.
The only way to support your proposal would be to kill the concept of
arch-independent packages and make everything arch-dependent.


And what if dpkg knows about it and handle arch-independant packages in
a different way?

In fact, if the system is multiarch, dpkg should have a centralized list
of which packages are installed for each architecture and which packages
are installed for arch: all...

But there's still the problem of arch-independant files inside
arch-dependant files (maybe an arch-dependant package should not include
arch-indenpendant files at all)...


The problem is when foo [i386] depends on bar [all] 1.0,
but foo [amd64] depends on bar [all] 2.0.

There is simply no good way to have bar [all] 1.0 and bar [all] 2.0 
installed,
so foo [i386] and foo [amd64] cannot both be installed. 




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

Re: multiarch status update

[Joe Smith]

"Adam Borowski" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:

On the other hand, if we continue that thought process we could end up
with all headers and libraries in /usr/share/, which is absurd.


Why?  This is exactly what's beautiful, especially if EVERYTHING ends up 
in
/usr/share/ at one day, at which point /share/ will be redundant and the 
FHS

will change.


That will be hard, a /usr/share to /usr symlink would likely end up part of 
that transition,

and poorly written software could ave some trouble with that.


Hm... This entire concept seems messy. It seems that processors that
support multiple architectures, as well as cross compilition are begining
to blur the line between /usr and /usr/share.


It's not "messy", it's plain awesome.  And if the line gets blurred into
oblivion, it will be a reason for joy.

Indeed. I was speeking about the transition being messy, not the final 
result.
I take it that you are interested in a multi-arch solution for binaries, 
which the "upstream"

proposal currently does not cover.

Overall the idea seems good. 




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

Re: multiarch status update

[Joe Smith]

"Matt Taggart and others" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi debian-devel,

For a couple years now a few of us have been talking about an idea called
"multiarch". This is a way to seamlessly allow support for multiple 
different
binary targets on the same system, for example running both i386-linux-gnu 
and
amd64-linux-gnu binaries on the same system (many other working 
combinations
exist as well). I have created a new page in the wiki to track info and 
status


My thoughts on a few multi-arch concepts.

It is important to differentiate between the types of non-native files.

There are files that are not native, but are intended to be used by native
programs targeting the non-native arch. These include things like 
arch-specific header files.
It almost seems like these should be put in /usr/share/include/$arch-$os/. 
(where $arch and $os represent the target arch) That is because headers for 
cross compiling are normally dependent on the target arch, but not the host 
arch.


On the other hand, if we continue that thought process we could end up with 
all headers and libraries in /usr/share/, which is absurd.


Indeed, the current proposal almost seems to be reversing this.
Non-target specific libraries and header files remain in $prefix/lib and 
$prefix/include.
It seems to me that libraries and headers that are not target specific are 
supposed to go in /usr/share.
That is because if they are not target specific they are most certainly 
cross-platform.


Hm... This entire concept seems messy. It seems that processors that support 
multiple architectures,
as well as cross compilition are begining to blur the line between /usr and 
/usr/share.





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

Re: patching a package?

[Joe Smith]

"Lionel Elie Mamane" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


apt-get source ${PACKAGE}
cp -R ${PACKAGE}-${VERSION} ${PACKAGE}-${VERSION}.pristine-deb
cd ${PACKAGE}-${VERSION}
# hack away
cd ..
diff --recursive -u ${PACKAGE}-${VERSION}.pristine-deb 
${PACKAGE}-${VERSION} > descriptive_name.patch

#(add -N option to diff if appropriate)
#send descriptive_name.patch to the maintainer, probably through a bug
#report.


Um... the person wanted to build a deb and install it for testing. You 
should add those to the list of commands. 




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

Re: Debian Policy version

[Joe Smith]

"Raphael Hertzog" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
It seems to me that it is unreasonable for the PTS to be updated before 
the

policy package actually hits the mirrors.
There is a period of time after a package leaves incomming but before the
mirrors are updated when the package is difficult to
obtain.


Frankly, I updated it a bit soon, right, but that was only because 3.7.2
revert the cgi-lib stuff and the PTS will let people notice that there's a
newer version and that they must take care...

And do we really need to complain of something that is broken for a
few hours and that's will resolve itself alone in a few hours?

/me wishes people wouldn't complain when we're actually fast


I was not complaining. I was suggesting that the actions that were taken be 
avoided in general.
It realy is not a big deal, and you are right that complaining about 
excessive speed is
nearly absurd considering the last release cycle. Especially considering the 
context,

what was done is reasonable.




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

Re: Debian Policy version

[Joe Smith]

"Frank Küster" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hendrik Sattler <[EMAIL PROTECTED]> wrote:


However, version 3.7.2.0 is neither in unstable nor at
http://www.debian.org/doc/debian-policy/
Both only have version 3.7.1.0. How comes that the PTS has a newer 
version

than all the other sources?


http://incoming.debian.org/


It seems to me that it is unreasonable for the PTS to be updated before the 
policy package actually hits the mirrors.
There is a period of time after a package leaves incomming but before the 
mirrors are updated when the package is difficult to

obtain.

It is bad enough that Debian-policy 3.7.1 does not indicate meeting itself, 
but now the PTS is stating that debian-policy should be updated to a version 
policy newer than "Latest Version" (as the general information section 
states).

See http://packages.qa.debian.org/d/debian-policy.html





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

Re: Compiling packages for the standard distribution with -Os instead of -O2

[Joe Smith]

"Rogério Brito" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi there.

I think that this may be interesting to anybody that has to work with
computers that are not the latest/more recent as most people in richer
countries seem to have.

It seems to be that a good amount of people upgrade their computers in a
regular basis and, then, don't notice how things can get slower in
"weaker" computers.


Those of us that live in a country where the already installed base of
computers is not recent have to live with software that is ever growing
in terms of both RAM and CPU cycles and this leaves less computing power
for the applications needed to run.

One way to mitigate the memory consumption is to, among other things,
compile packages with optimization of GCC set to -Os, instead of -O2,
which seems to work at least for some programs (the Linux kernel,
mozilla-firefox and my own home-grown programs).


Wait a second. Optimizing for size should decrease speed.
That is the whole idea of size/speed optimization tradeoffs.






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

Re: python-minimal

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Apr 29, 2006 at 09:00:53PM -0700, Thomas Bushnell BSG wrote:

The alsa-utils package depends on python-minimal.
As a result, I must now have two versions of python installed.  That's
a bug.
alsa-utils should depend on "python | python-minimal", or perhaps the
python packages should Provide python-minimal.
Does this seem right?


Er... alsa-utils should be depending on python, *not* on python-minimal at
all.  The previous discussion of this package was that python-minimal 
exists

only for the possibility of use as an Essential: yes package, should never
be installed without python, and should not be used as a dependency by 
other

packages.


To clarify, AIUI Python-minimal should never be installed without python, 
unless install of only python-minimal is explicitly requested by the user. 
This is to avoid having to include full python on an embeded Debian, while 
minimizing cases where a user is surprised by missing python libraries. 




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

Re: python-minimal

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Apr 29, 2006 at 09:32:52PM -0700, Russ Allbery wrote:

Steve Langasek <[EMAIL PROTECTED]> writes:



> Seems to me that this should be at least a bug report on alsa-utils.
> I'm surprised that there would be a need for a lintian check for it, 
> but

> I guess it's better than letting such bugs go unnoticed.


I can add one; it's not a lot of overhead given that lintian already has 
a

framework for checking for bad dependencies.  It's basically just another
branch in an if statement.



What's the precise check?  Any package depending on python-minimal should
receive an error (or a warning?)


Based on Vorlon's message:

If (package depends on python-minimal) and (package is not essential) then 
ERROR.



It's pretty definitely a bug, so AIUI should be marked as an error.


with roughly the text of Steve's previous message?


Short message: "Non-essential package depends on python-minimal."

Long Message: Something along the lines of Steve's meassage.


Uh... sure :)

--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/






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

Re: [Help] Versioning of a library

[Joe Smith]

"Andreas Tille" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi,

I'm the maintainer of libgtkdatabox-0.2.3.0-0.  Until now there
was no request for an update of the upstream version and I had
personal reasons to stay with an outdated version.  Now I was
asked to package the latest version and the library is probably
not important enough to keep different versions and thus I will
package version 0.5.2.0 that is the latest version avialable from
http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there
is an ABI change involved and thus I have to rename the package
to libgtkdatabox-0.5.2.0-X .  My question is: What is the right
choice for 'X' if I skipped several upstream versions inbetween?



If this is your first upload of that version then X=1.
The correct list for these types of questions is
debian-mentors. 




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

Re: No insulting messages?

[Joe Smith]

"Sven Luther" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Yeah, will use that nexty time. I don't know if native speaker realise
this, because many non-native speaker seem to have a fluent english, but 
there

are times when the right words just don't come, and you are grasping with
finding the right word, and often make un-wise choices.


Speaking as a native English speaker, I understand this.
We too have this problem, although not as often, and generally not as bad
as non-native English speakers. Nevertheless it does exist for us too.




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

Re: Fonts packages maintenance team (second) proposal

[Joe Smith]

"Rene Engelhard" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Enforcing this policy to existing font packages is not in the top
priority of the team.


What is a policy useful for when most packages are not following it? I
think if there's a sane policy people should have to migrate to it;
otherwise you don't need to write a policy for that...


Well they said that it was not the top priority, but did not deny that it 
would be a goal.
The Policy could be written and time given for people to adapt, then it 
could be proposed as
an offical sub-policy which would make the other packages RC-buggy AIUI. 




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

Re: New packages.debian.org

[Joe Smith]

"Henrique de Moraes Holschuh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Mon, 06 Mar 2006, Martin Schulze wrote:

Wolfgang Jeltsch wrote:
> Am Montag, 6. März 2006 18:29 schrieb Martin Schulze:
> > The Debian project happily announces the re-availability of the
> > packages.debian.org service on a new machine.  The system has been
> > donated by Schlund + Parner where it is hosted as well.  It is a
> > DualCore Opteron and only runs this service for Debian users and
> > developers.
>
> What does it mean that the machine runs this service only for Debian 
> users and
> developers?  How can the machine make sure that the person which 
> accesses the

> machine is either a user or a developer of Debian?

It checks the User-Agent string.

And now, the important question: why are we doing this?

That was sarcasm.

"  It [...] only runs this service for Debian users and developers."
should have been something like:
"This is the only debian user/developer service running on this machine"




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

Re: acceptance of morse-2.1 in unstable

[Joe Smith]

"Jeroen van Wolffelaar" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sun, Mar 05, 2006 at 07:42:12PM +0100, Joop PG4I wrote:

   I have uploaded morse-2.1 about 2 weeks ago.
   Nothing heard if it will get accepted or not.
   Wondering what is going on Is ftp-master overloaded?


NEW queue is actually a heap, and your package simply didn't reach the
top yet. Please hang on

.
A heap http://en.wikipedia.org/wiki/Heap_%28data_structure%29 ?
I would have assumed a like a queue, just slightly modified as to allow a 
package to be skipped temporarally.



--Jeroen

--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl






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

Re: Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)

[Joe Smith]

sorry, but i disagree with you on that. For me volatile is handling
packages with volatile data, not for handling packages the stable
release manager denys to take into a stable release.


I've not followed this bug but AIUI SRM has approved the package for the 
next point release.
If the bug is important enough to make it easy for uers of current sarge to 
upgrade then

the proper venue is security, not volitile.
If it is not important enough for the security repository then users will 
just have to wait.


Although if I have misunderstood the issue than the above may not apply.




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

Re: buildd and experimental

[Joe Smith]

"MJ Ray" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



MFT is broken by design. No-one should expect to remote control other
people's mail clients. All one can do is ask and if you want to ask in
the headers, fine, but don't go flaming when it gets lost in the noise.
All of From, Reply-To and List-Post seem more useful to me than MFT's
wrongheaded confusion of Reply-To and Followup-To.


Actually mailing lists are broken by design. Email was designed wth private 
communication in mind.

Mailing lists were added to that design but have always had problems.
Newsgroups are what most mailing lists should be.
They have historically been threaded and most UA's do this right,
While some mail UA's do things like omit message-id or reply-to or 
references.
Also newsgroups make it much easier for a new subscriber to reply to 
messages sent

from before they subscribed. (I use GMANE for these reasons).

Now if mailing lists are to be used, then nobody should be complaining about 
cc's.
If the mailing list checks for people who are cc'ed then there will be no 
duplicate messages.
Otherwise the mailer should be able to deterimine that the two messages are 
in fact the same message

with one copy coming from the list, and therefore display it only once.

So whenever somebody complains about CC's it seems to me that the problem is 
a broken or

incorrectly configure mail client on the side a the *reciever*.




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

Re: /lib/modules//volatile on tmpfs

[Joe Smith]

"Sergio Callegari" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

I have this directory on an Ubuntu system and it seems to be present
on recent Debian systems too...
It is on tmpfs.
Can anybody tell me what is its purpose (as many other distros don't
have it) and when it gets mounted?

Thanks!

Sergio


I'm betting that it is caused by a bug somewhere. Something is presumably 
tring to create
a tmpfs on /etc/svc/volatile, but is accidentally doing it in that directory 
instead.


What is probably happing is a script that thinks it is executing in /etc/svc 
is not, or is having its
cwd changed unexpectedly. 




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

Re: Mirror split, amd64 update

[Joe Smith]

"Philip Charles" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

I have built up a fine-grained mirroring script over time which not only
selects the architecture but also the version (stable, testing etc) to be
mirrored.  Unfortunately this script will require ftp/http access
to ../debian-all.  Is there any reason to restrict access
to ../debian-all to rsync?


It looks like nobody else responded to your message, so I will. (IANADD)
Allowing http or ftp access to ftp.debian.org/debian-all is somewhat 
dangerous.
Anybody blindly mirroring ALL of ftp.debian.org via http or ftp would end up 
with

two copies of the major architectures.

However, doing that is a stupid thing anyway, and Debian has no obligation 
to protect fools who do that. 




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

Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Joe Smith]

Sorry to change the topic, but looking at some of the manpages in the 
"manpages" package,
and some of the pages in the "manpages-dev" causes me no notice some pages 
that look like they probably should be in a different package.


ld-linux(8)
ld-linux.so(8)
 These probably belong in libc6 which appears to be the provider of 
ld-linux.so


sync(8)
 This should be deleted. Coreutils (the provider of the sync utility) 
provides sync(1) for that utility.


tzselect(8)
This should be removed. it duplicates tzslect(1) (which i presume is 
provided by the package providing tzselect)


ksoftirqd(9)
 I'm pretty sure this does not belong in the manpage package.


As for manpages-dev, it would seem more logical for the linux syscall 
manpages to be part of linux, and the library documentation to be a part of 
the libraries that provide the documented functions.




If somebody with more time can check on these and, if they are valid, file 
bugs, I would appreciate it, as I do not have the time right now. 




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

Re: Deadline for amendments to the GR

[Joe Smith]

"Manoj Srivastava" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



   If you do not know what GR's are currently open (despite mails
on -announce about them), asnd do not know how to simply look it up
on vote.debian.org, the subject matter is irrelevent to you anyway.

   manoj

While you have a point, here is annother point: Putting an indicator of the 
GR in question may help people make sense of that mesage while sorting 
through the archives someday down the road. Not to say that there is a need 
to go out of ones way for that, but when it is easy to add information that 
may help people doing that (regardless of the type, content, or context of 
the message) it is a nice thing to do.


Just a reminder that people do sometimes read long-ago postings, not 
intended to be criticism of any kind. 




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

Re: copyright law vs. license text (Was: Honesty in Debian)

[Joe Smith]

"Stuart Yeates" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

In the USA copyright can be enforced even on laws:

http://www.constructionweblinks.com/Resources/Industry_Reports__Newsletters/May_17_2004/supreme.html



I'm assuming that the legislation in question included the codes (literally 
the text of the codes) rather than simply refer them.


IMHO that ruling was just simply wrong. Laws by their nature must be freely 
available and editable. Therefore public domain or something similar must be 
applied to them. A state government (or even the federal government) cannot 
just publish a work copyrighted by somebody else without permission. That is 
copyright infringment. I would argue that the introducer of the bill should 
have been sued by the holder of the rights to the codes. But The holder 
waited far too long, and the law was published, and so now it has implicity 
granted the right to the government to publish the work into the public 
domain.








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

Re: Provides: scheme-interpreter

[Joe Smith]

"Florian Weimer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

* Chad Walstrom:


I'm trying to package up tex2page and noticed that there is no virtual
package for scheme-interpreter.  I would like to specify in the
"Depends:" that some sort of scheme-interpreter is required instead of
having to list each of them individually.

Any thoughts on this suggestion?


Are Scheme interpreters sufficiently compatible (in particular in
their command line conventions) so that this is feasible?  How do you
find one?  There doesn't appear to be a /usr/bin/scheme.


http://people.debian.org/~forcer/debian-scheme-policy/debian-scheme-policy.html/

Which may be an unofficial policy mandates certain symlinks managed by 
alternatives
to scheme interpreters based on what they support. The virtual package names 
have been accepted by consensus

(nobody said anything, so they implicitly concurred).

Therefore if the script needs R5RS Scheme it should depend on 'scheme-r5rs' 
which is a virtual package,

and the first line of the script should be:
"#! /usr/bin/env scheme-r5rs"
or
should be
"#! /usr/bin/scheme-r5rs"




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

Re: returning emeritus developer, no response from [EMAIL PROTECTED]

[Joe Smith]

"Adeodato Simó" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

 Can we please fast-track this clairvoyant NM?


Umm... I belive that is the policy. He needs to have his email read, and 
then answer a few questions.
The process for returning emeritus Developers is intentionaly much easier 
than normal NM, as they
obviously were able to pass once before, so now the only important thing is 
to check that they still remember.






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

Re: Getting rid of circular dependencies, stage 3

[Joe Smith]

"Joey Hess" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Joey Hess <[EMAIL PROTECTED]>
 debconf
 debconf-english
 debconf-i18n


These are all necessary, and debconf is an essential package which is
not subject to the circular dependency postinst ordering problems afaik.


Well, I'm not sure if that is an excuse for violating policy.
(Actually apt is the one violating policy, but if apt did work as policy 
states it should these packages [like all other packages with circular 
dependencies]
would be uninstallable, which as debconf is essential, would probably be a 
critical priority bug.)





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

Re: APT public key updates?

[Joe Smith]

"Michael Vogt" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote:

[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?


I uploaded a new apt that supports multiple signatures on the release
file. The policy is that it needs at least one good signature and no
bad signatures (but any number number of NO_PUBKEY signatures) to be
considered trusted. It will still warn about missing keys but that's
only fatal if no good signature was found.

The upload also contains the new key in apts default keyring. This
dosn't fix the key-upgrade problem yet. I outlined my proposal in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891

Early testing (from incoming) is welcome :)

Wait a second. How will people download the new key using apt if apt refuses 
to download because it does not have the new key?
And then what about the future? A stable release will not be upgradable if 
the key is not downloaded, but the key will not be downloadable.


Or am i missing something? This whole thing sounds like a major problem. 




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

Re: /run vs /var/run (was: Please test new sysvinit)

[Joe Smith]

"Marco d'Itri" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Furthermore, /dev/shm is a mount point with a _very_ specific function.
It's a bad idea to start using it for something else.

Reality check: packages have been using it for a long time and the world
has not fallen yet.

Hmm...
Lets see:

1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, 
or that if it does exist, that it can be be read as a block device, or that 
if it can, it has a file system on it.

2. Neither does FHS.
3. The Linux 2.6 device list states that as of now, if /dev/shm exists it 
should have a tmpfs filesystem. But makes no guarentees that it exists, or 
that it will remain a filesystem



So AIUI:
1. It exists only on Linux-based OS's
2. There is no gaurentee that it will continue to be there at all
3. There is no guareteee that it will remain a filesystem in the future even 
if it is there.

4. There is no gaurentee that it exists at all.

Sounds it sounds to me like it is a bad idea to use it. 




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

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

[Joe Smith]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

I won't complain, I'll just send a friendly assassin to your house :-)
A friendly assasin? Is that the type that comes in, talks with you for a 
while, and eventually offers you a poisioned beer?




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

Re: buildd administration

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote:

You have failed to detail any particular difficulty that this causes,


I'm pretty sure I saw him do this already, by noting that it increases the
number of packages that the release and QA teams have to keep track of.
It's great that you're concerned about the portability of the package, but
there are 500+ open RC bugs known to be relevant to the next release, and
1300+ RC bugs all up that affect packages in unstable.  Packages with bugs
in the first category add to the release team's workload of
downgrading bugs/NMUing/pestering maintainers/removing packages; packages
with bugs in the second category add to the QA team's workload of figuring
out if maintainers are MIA, whether packages should be removed from the
archive, and so on.  Bugs in both categories make it harder for would-be
bugsquashers to sift through the bug lists to find packages that they can
usefully NMU.


Steve, I'm not sure i agree with what you are saying here, although i do 
generally agree with you.
Keep-out-of-testing bugs seem to be fairly common, Especially on packages 
that maintainers belive
are not stable enoughto possibly be included in releases.This is often found 
in convience packages
such as the weekly cvs snapshots of emacs, which proably should never be 
part of a stable release.
It sounds to me like what is needed as a tag for bugs that tells QA (you 
post noted that the release team
would ignore RC bugs on packages not in testing) that it can ignore those 
bugs.




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

Re: apt PARALLELISM

[Joe Smith]

"Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On 12/5/05, Joe Smith <[EMAIL PROTECTED]> wrote:


"Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote:
>> Example: (/etc/apt/sources.list)
>> deb http://ftp.en.debian.org/debian main stable contrib non-free
>> deb http://ftp.de.debian.org/debian main stable contrib non-free
>>
>> in this case the stable packages will be ONLY downloaded from first
>> server
>> from the list ...
>
> And what is the problem?

This person is requesting parallel downloads from multiple servers. So
basicly during package download, if there are three full and up-to-date
mirrors in sources.list, there should be simulatious downloads of 
different

packages from all three different mirrors.
The concept is that in some cases this can noticable improve performance,
especially whith sites that bandwidth throtle, or have some other sort of
bottleneck.


Do you mean throttling at the mirror site? Or between the mirror and
the end-user?
Either. It is possible that a router could be throttling the flow rate to a 
network owned by annother company. Other possible cases are where a user has 
connections speeds higher than some of the servers. (for example, some rich 
user could have multi-T3). I'm not sure it is needed, but I do understand 
that in some cases such a feature may be usefull.


Now it is useless for users where the bottleneck is on their end. 




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

Re: apt PARALLELISM

[Joe Smith]

"Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote:

Example: (/etc/apt/sources.list)
deb http://ftp.en.debian.org/debian main stable contrib non-free
deb http://ftp.de.debian.org/debian main stable contrib non-free

in this case the stable packages will be ONLY downloaded from first 
server

from the list ...


And what is the problem?


This person is requesting parallel downloads from multiple servers. So 
basicly during package download, if there are three full and up-to-date 
mirrors in sources.list, there should be simulatious downloads of different 
packages from all three different mirrors.
The concept is that in some cases this can noticable improve performance, 
especially whith sites that bandwidth throtle, or have some other sort of 
bottleneck.


I would say this is a feature request, rather than a bug report of any kind. 




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

Re: Uploading amd64 packages

[Joe Smith]

Jérôme Marant said:


Quoting Joerg Jaspert <[EMAIL PROTECTED]>:

Jérôme Marant schrieb:

> Is it currently possible to upload amd64 packages to ftp-master?

No.
Well. Yes. Of course you can upload. They just get rejected. :)



Not good. What is missing to get this fixed?


Well There are two mirror changes. I suspect that scc will need to become 
operational,
before amd64 is added to ftp-master. The scc change is a big change and 
certainly has te potential to break things,
including offical mirrors. So this change will likely be delayed as long as 
possible.
Until amd64 is made an official architecture it would be nonsensical to 
allow dinstall (or is it katie?) to accept packages for amd64.




> If not, is there any upload queue dedicated at them?

Nope.
Well. Yes (again). But only about 5 people are allowed to upload there,
plus one script that syncs the source from Debian. So you dont need to
upload there.


So, I guess I have no choice but building packages in a i386 chroot, right?


I would assume that it was fairly ovbious that the binary upload would need 
to be
for an offical arcitecture, which amd64 is not (yet). In fact, it is 
probably not reccomended

to be developing under a system that is not offically a debian system.
(Although amd64 is a bit of a special case. I would not reccomend doing 
development for

debian on an ubuntu system for example. Too much possibility of conflict.)

Re: I am still on the keyring. With my old key.

[Joe Smith]

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Who does a developer have to fuck around here to get his key deleted?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Wait. Ignore my previous post. I had forgotten that the resignation post was 
indeed signed. It might however be the case that your key will not be 
removed until the new key makes it into the keyring. 




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

Re: I am still on the keyring. With my old key.

[Joe Smith]

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Who does a developer have to fuck around here to get his key deleted?


I'm not sure your resignation was valid. Most important debian mechanisms 
require a signature from a key in the keyring.
It is hard for anybody to verify that you really are the developer named 
"chip salzenberg" without having the relevent post signed.
If nothing else the resignation shuld have been signed by the new key. 




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

Re: Resignation and orphan list

[Joe Smith]

"David Moreno Garza" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Thu, 2005-11-10 at 15:23 -0800, Chip Salzenberg wrote:

Over the past five weeks

And guess how long will take to get your account removed.
Hmm... Doesn't a resignation require a message signed with a key on the 
keyring?




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

Re: altzone

[Joe Smith]

"Josselin Mouette" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



The documentation mentions that some compilers might need to be
executed as :

``CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure''

But there is no posix library as far as I can make out in Debian, so
that won't do.


Yes, and I can't find the altzone symbol in any of the libraries I have
installed. Does POSIX really require it?


A search of SuS v2 showed no results for altzone.


In which system did you get that statement?


I found a ctime(3c) man page that mentioned it, labeled as being part of ' 
SunOS 5.9'. 




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